Table 1.1: One-Tool-at-a-Time versus the PM Toolbox Approach
Impact on SPM Process Requirement One-Tool-at-a-Time PM Toolbox
Speed Lower Higher
Repeatability Less repeatable More repeatable Concurrency Less likely More likely
impacts the standardization level of the PM Toolbox. For example, a methodology that is highly standardized will probably be supported by a highly standardized PM Toolbox.
Regardless of whether an organization’s project management methods and pro- cesses are standardized, flexible, or semiflexible, a PM Toolbox needs to be designed so that it aligns with both the PM methods and processes employed as well as the strategy of the project and the business strategies driving the need for the project. To accomplish this, a process for selecting and adapting the PM Toolbox is needed.
CONSTRUCTING AND ADAPTING A PM TOOLBOX
PM tools serve two roles. First, in their conventional role, the tools are enabling devices for reaching a project deliverable. Second, in their new role, they serve as basic building blocks to construct the PM toolbox.
There are three major steps, each including several substeps, in constructing and adapting a PM Toolbox for specific projects or a project organization (Figure 1.4):
1. Secure strategic alignment 2. Customize the PM Toolbox 3. Improve continuously
As detailed in the previous sections, aligning the PM Toolbox with the organization’s business strategy tells us in broad terms what categories of project management tools to select. This alignment drives the next step—customization of the PM Toolbox—by
Secure Strategic Alignment
• Understand business strategy
• Visualize Toolbox alignment
• Align Toolbox with strategy
Customize PM Toolbox
• Customize by project size, or
• Customize by project family, or
• Customize by project type
Continuously Improve Toolbox
• Form an improvement team
• Identify mechanisms to collect ideas
• Follow improvement process
Figure 1.4: Steps for Constructing and Adapting a PM Toolbox
selecting specific tools to use on the projects. The deployment of the PM Toolbox in real-world projects will reveal its glitches and generate new learning, which leads to the third step—continuous improvement of the toolbox. Details about each step follow.
Secure Strategic Alignment
One of the primary purposes of the PM Toolbox is to enable the implementation of projects that affect the organization’s strategic business goals. To make this purpose happen, the PM Toolbox needs to be in alignment with both the business and project strategies, as we discussed earlier in this chapter. To be successful in designing the Tool- box, therefore, project managers must have an understanding of the business strategy, at least knowing if their company follows a fundamental strategy of being a market leader, a market follower, a cost leader, or a customer service leader. However, many of them do not have this level of understanding. Why? Among many reasons for this is the fact that in many organizations, strategy formulation and implementation is viewed as the executive’s domain. They are tasked with charting the business strategy for the enter- prise. Project managers often are not in a position to access this knowledge or show little interest in gaining it. Project managers need to be tenacious by probing and digging to comprehend the strategic reasons for executing the projects they are in charge of, even if the strategy is not communicated to them.
This lack of strategic knowledge can create substantial obstacles for project man- agers and will limit the strategic alignment of their PM Toolbox. To remove the obstacles, project managers need to have conversations with top managers and convince them that business strategy is key to planning and implementing projects and that project managers need this knowledge in order to secure expected returns on their projects.
Our mandate is simple: Gain an understanding of your organization’s business strategy, or designing the toolbox will be like shooting an arrow into the fog—we don’t know where the target is or whether we hit it.
Visualizing Alignment
Part of understanding how a toolbox should align to business strategy is the ability to clearly visualize the relationship. Earlier in the chapter, we laid the foundation for the alignment by using examples of three companies—Sirius, Park, and Prima—to illustrate how the PM Toolbox can be focused to support business strategies.
To visualize this alignment, in Figure 1.5 we show what we conveniently call investment curves—a more precise term is the net present value curves—for three comparable projects performed in alignment with their base business strategies.
Each curve shows four important points: (1) project start, (2) time to deployment, (3) time to breakeven, and (4) salvage point. Project start is the time when the project is initiated and begins to consume resource hours and budget; therefore, the cash flow begins to turn negative. Investment and negative cash flow continue to increase until the project is completed. At that time, the project outcome (a product, service, or other capability) can be deployed, which constitutes time to deployment. Instead of time to deployment, some project managers prefer the termproject cycle timeor, simply,project completion. Note thatnegativecash flow usually reaches its peak at the
CONSTRUCTING AND ADAPTING A PM TOOLBOX 11
Salvage Point Time-to-breakeven
Time-to-deployment Cash Flow ($)
Positive
Project Start
Cash Flow ($) Negative
Schedule-driven Project & Toolbox Cost/Performance -driven Project & Toolbox
Cost-driven Project & Toolbox
Time
Key:
Sirius Prima Park
Figure 1.5: Visualizing a Strategy-Driven Toolbox
time-to-deployment point. After that, the use of the project output begins to generate returns (revenue, cost savings, efficiency gains), and the curve begins to turn upward.
Hopefully, the upward trend will continue until at least the time-to-breakeven point is reached. This is the point where all investments in the project are equal to returns gen- erated by the use of the project output. Beyond that point, the cash flow turns positive and typically continues to do so until the project output is salvaged.
We use the curves to explain the nature of the PM Toolbox’s alignment with the business strategy for each of the three companies discussed earlier. Consider, for example, Sirius. A primary element of Sirius’s differention strategy is project cycle time speed. Figure 1.5 illustrates that point: Time-to-deployment and time-to-breakeven points are reached much sooner than for the other two companies. For this to be possi- ble, Sirius needs a timeline-driven toolbox in which the central role and priority belong to tools that can help enable fast cycle times. These may include tools such as the Gantt chart, time-scaled arrow diagram, critical path diagrams, milestone charts, and so on (Chapter 6). This does not mean that other components of the typical PM Toolbox such as cost, risk, and stakeholder tools are ignored. Quite to the contrary—they are important and have their role in the toolbox as well, but they are subjugated to timeline-driven tools.
The case is different for the toolbox for Park, a company that concentrates on cost leadership. Logically, then, most projects within Park are cost driven, searching to mini- mize project cost whenever possible. This logic is apparent in Figure 1.5. The Park curve shows less negative cash flow than those of Sirius and Prima. It is the intended goal and realized outcome of project actions. To accomplish the project strategy, Park is willing to take the longest time to reach time to deployment and time to breakeven. Crucial in this
effort is a cost-driven toolbox that emphasizes cost, cost, and cost. Correspondingly, cost estimates and cost baselines are carefully prepared, as is the assessment of return on investment, even for small cost-cutting projects (Chapter 5).
The intent to align the PM Toolbox with the business strategy is aggressively pursued in Prima as well. The driving force is the best-cost strategy that is also translated to the project level. As can be seen from Figure 1.5, time to deployment and time to breakeven are shorter than Park’s, but longer than Sirius’s. This means that cost focus is lower than Park’s but higher than Sirius’s. Such cost philosophy is closely intertwined with the need for the project to emphasize performance goals more than the other two companies.
Given this situation, how does one shape a cost-performance-driven PM Toolbox?
A combination of well-balanced performance and cost tools has the priority. Formal and informal voice of the customer tools and feature requirement tools are crucial for hitting customers’ expectations, as are cost estimates and cost baselines. To Prima and its customers, delivering on schedule is important, as keeping customers satisfied is not possible without delivering when promised. Nevertheless, schedule goals are subju- gated to performance and cost. Other tools, such as a risk management plan, are mod- ified to support the combination of cost and performance focus. For example, the risk management plan may be focused on lowering cost rather than schedule (Chapter 14).
As can be gleaned from our discussion, the nature of alignment of the toolbox is reflected in the balance of two issues. First, many of the tools show up in all three tool- boxes. The second issue concerns the situational approach: adapting tools to account for the characteristics of the three toolboxes (see Table 1.2)
Customize the PM Toolbox
There are multiple options for customizing a strategically aligned PM Toolbox. Three options are perhaps the most viable:
1. Customization by project size 2. Customization by project family 3. Customization by project type
The options are three different ways to select and adapt the toolbox. Each option has the purpose of showing which specific project management tools to select and adapt for the PM Toolbox. For this to be possible, each option is based on the particular method- ology used, which has a large influence on the choice of tools.
An in-depth knowledge of individual tools is a prerequisite to each of the options because you need to understand how each tool can support a project deliverable. We will describe the customization options in turn and offer guidelines for selecting one of them for implementation.
Customization by Project Size
Some organizations use project size as the key variable when customizing a PM Toolbox.
Their logic is that larger projects are more complex than smaller ones, or that size drives differences in project management methodology complexity. The reasoning here is that as the project size increases, so does the number of activities and resulting project deliverables associated with a project, as well as the number of interactions among
CONSTRUCTING AND ADAPTING A PM TOOLBOX 13
Table 1.2: Characteristics of Strategically Aligned Toolboxes
Company’s Core Business Strategy Differentiation Low-Cost Best-Cost
Nature of PM Toolbox Characteristics of the PM Toolbox
Schedule
Driven Cost Driven
Performance- Cost Driven Central role and priority belong to schedule
tools
✓ Management attention is on schedule
performance
✓ PM spends majority of time managing to
schedule
✓ Schedule tools are primary basis for decisions ✓ Other tools adapted to support schedule
tools
✓
Central role and priority belong to cost tools ✓
Management attention is on cost performance ✓
Project manager spends majority of time managing cost
✓
Cost tools are primary basis for decisions ✓
Other tools adapted to support cost tools ✓
Central role and priority belongs to cost-performance tools
✓ Management attention on performance and
cost
✓ PM spends majority of time managing
performance requirements and cost
✓ Performance and tools are primary basis for
decisions
✓ Other tools adapted to support performance
tools
✓
them. Worst of all, this number of interactions grows by compounding, rather than linearly.10 Such increased complexity, then, has its penalty—larger projects require more work to coordinate the increased number of interactions.
Since different project sizes require different processes and tools, we first need a way to classify projects by size and then customize their toolboxes. For size classification we draw on the experience of some companies. In Table 1.3, we present three examples.
All companies use three classes of project size: small, medium, and large. The units used to measure project size are dollars or person-hour budgets. On the basis of the size, the companies determined the managerial complexity of its project classes and processes.
The complexity further dictated the PM Toolbox makeup, a simplified example of which is illustrated in Table 1.4. For the sake of simplicity, only the toolbox is shown, leaving out the project deliverables.
Table 1.3: Examples of Project Classification per Size in Three Companies Project Size
Project and Company Type Small Medium Large
Product development projects in a $1 billion/
year high-technology manufacturer
$1–2m $2–10m >$10m
Infrastructure technology projects in a
$300 million/year food processing company
<$50k $50–150k >$150k Software development projects in a $40 million/
year customer relationship management software company
300–400 person-hours
1,000–3,000 person-hours
>3,000 person-hours
Table 1.4: Examples of PM Toolbox Customization by Project Size Project Phases
Project Size Initiation Planning Execution Closure Small Project charter Scope statement Progress report Final report
WBS Responsibility matrix Milestone chart
Medium Project charter Scope statement Progress report Final report Skill inventory WBS or PWBS Change process Change log
Responsibility matrix
Change log Postmortem report Cost estimate Gantt chart
Gantt chart Cost burn down Risk plan Risk register
Large Project charter Scope statement Progress report Final report Stakeholder matrix WBS and PWBS Project indicators Postmortem
report Stakeholder
strategy
Responsibility matrix
Change process and log
Closure checklist Cost estimate Time-scaled arrow
diagram Time-scaled arrow
diagram
Slip chart
P-I matrix EVM
Risk register
EVM=earned value management; P-I=probability-impact; PWBS=program work breakdown structure;
WBS=work breakdown structure.
CONSTRUCTING AND ADAPTING A PM TOOLBOX 15
As Table 1.4 indicates, some of the tools in the toolboxes for projects of different size are the same, while others are different. For example, all use the summary status report (Chapter 12) because all projects need to report on their performance. Since managerial complexity of the three project classes and their processes call for different tools, some of the tools differ. A P-I matrix (Chapter 14), for example, is needed only in large projects.
To be successful, the process team designing the toolbox should carefully balance the standard tools with those that account for the specific size of the project.
Experience of these companies offers several guidelines for customizing the PM Toolbox by project size:
■ Identify a small number of project classes and their methodologies.
■ Define each class by the size parameter.
■ Match the project size with the proper toolbox, each tool supporting a specific project deliverable.
Note that while customization by project size offers advantages of simplicity, it also carries a risk of being generic, disregarding other situational variables. To some, these other variables may be of vital importance, as will be pointed out in the next section on customization by project family.
Customization by Project Family
When the PM Toolbox is strategically aligned, you can opt to customize it by family types within an industry. Many companies choose such options in a belief that project fami- lies in their industry are sufficiently unique to merit an industry-specific project family methodology and toolbox.11
As a group of organizations that compete directly with each other, an industry is characterized by the nature of its environment and business risk. For example, com- panies in the high-technology industry face an environment of dynamic technology change. Because of this, their portfolio abounds with fast time-to-market projects driven by the desire of their customers to continuously buy the latest and greatest technolog- ical products and services. Combined, the business environment and risk profile create similar challenges in families of projects. For example, a family of new product devel- opment projects in high-tech industries face similar challenges. So do facilities manage- ment projects, manufacturing projects, marketing projects, and information technology projects within the same industry.
Often, project families are defined by the novelty of the capabilities the projects produce. Generally, the more novel the capability, the more complex the projects.12 This is because increasing novelty (newness or uniqueness) in projects leads to more uncertainty, elevating the need for more flexibility in the processes and the supporting toolbox. For example, as novelty grows:
■ The more evolving the scope statement and WBS become.
■ The project time line becomes more fluid.
■ The cost estimates follow the fluidity of the schedules and scope.
■ More risks need to be identified and managed.
Table 1.5: Customizing the Toolbox by Project Family Project Phases Project Family
(Novelty) Initiation Planning Execution Closure Derivative
projects
Project charter Milestone chart Progress report Final report Financial scoring
model
Requirements baseline WBS Incremental
projects
Project charter Scope statement Progress report Final report Financial scoring
model
WBS or PWBS Change log Change log Stakeholder map Requirements
baseline
Gantt chart Retrospective Cost estimate Cost burn down
Gantt chart Risk register Risk plan
Breakthrough projects
Project charter Scope statement Progress report Final report Voting Models WBS or PWBS Project indicators Postmortem
report Stakeholder map Requirements
baseline
Change process and log
Closure checklist Stakeholder
strategy matrix
Responsibility matrix
Milestone chart Cost estimate Slip chart Milestone chart EVM P-I matrix Risk register
EVM=earned value management; P-I=probability-impact; PWBS=program work breakdown structure;
WBS=work breakdown structure.
A simple example reflecting these trends in adapting the toolbox for the three classes of project families is illustrated in Table 1.5.
As the table shows, the toolboxes of the three classes of projects are similar in some and different in other aspects. For example, all use schedules and progress reports. Still, the schedules differ in that simple projects rely on a simple milestone chart, while com- plex projects use a rolling wave type of the time-scaled arrow diagram. Obviously, the variation in the novelty of the project is the source of the differences.
Customization by Project Type
While the previous two approaches to PM Toolbox customization rely on one dimen- sion each—project complexity and project family as defined by novelty, respectively—
customization by project type uses both dimensions.13
CONSTRUCTING AND ADAPTING A PM TOOLBOX 17
To make it more pragmatic, we will simplify the model, while maintaining its com- prehensive nature. Each of the two dimensions includes two levels: (1) novelty of the capability under development (low, high) and (2) project complexity (low, high). This helps to create a two-by-two matrix that features four types of projects: routine, admin- istrative, technical, and unique (see Figure 1.6).
A routine project is one having a low level of capability novelty (less than half of the features are new) and low complexity (few cross-project interdependencies). Due to the low levels of novelty and complexity, the project scope can normally be frozen before project execution begins or early in the execution stage. Scope also remains fairly stable, with few scope changes. With scope remaining stable, project scheduling, cost management, and performance management are also quite static.
Typically, routine projects are performed within a single organization or organiza- tional function (e.g., infrastructure technology). Examples include the following:
■ Continuous improvement project in a department.
■ Upgrading an existing software application or existing product.
■ Adding a swimming pool to an existing hotel.
■ Developing a derivative model in a washing machine product line.
■ Expanding an established manufacturing line.
Administrative projects are similar to routine projects in terms of novelty. Business goals and scope are normally well defined, stable, and detailed. The added complexity requires the coordination of multiple organizational functions and the mapping of the many functional interdependencies, but the lack of capability novelty allows for stan- dard scheduling techniques. The same added complexity generally means larger project size, with higher financial exposure, justifying the need for detailed bottom-up cost esti- mates reconciled with financial targets contained in the project business case. Risk is primarily related to the increased number of interactions between the function’s project teams; therefore, additional risk planning and analysis is required.
Administrative Projects
Unique Projects
Routine Projects
Technical Projects
Capability Novelty High Low
HighLow
Project Complexity
Figure 1.6: Four Project Types