1
INTRODUCTION TO THE PM TOOLBOX

Project management tools support the practices, methods, and processes used to effectively manage a project. They enable the primary players on a project-the project manager, project team, executive leadership team, and governance body.

For purposes of this book, tools are considered to be processes, techniques, artifacts, software, or other job aids that assist in creating deliverables or project information. PM tools may be qualitative or quantitative in nature.

To illustrate, consider two examples, the Team Charter and a Monte Carlo Analysis. The Team Charter is an artifact that outlines how the team will work together on a project. A Monte Carlo analysis involves analyzing data that is generated from a software tool that uses an algorithm to quantify uncertainty around cost or schedule outcomes.

Note there is no mention of specific software tools here. While many PM tools discussed in this book exist in a software format, the focus is not on tool formats. Rather, the focus is on the use of tools to manage projects more effectively and efficiently.

A project management (PM) toolbox provides a set of tools that serves several purposes, such as:

1. Increasing the efficiency of the project players
2. Providing the right information to support problem solving
3. Providing relevant information for making decisions
4. Helping to establish and maintain alignment between business strategy, project strategy, and project outcomes.

The design of a PM Toolbox should align with the approach an organization takes for establishing project management methodologies and processes.

ALIGNING THE PM TOOLBOX

Organizations have a host of options when developing their methodologies and processes-they can be more standardized or more flexible. Generally, projects with a high degree of certainty do well with more standardization. Projects that face a high degree of uncertainty require more flexibility. The decision about how much to standardize project management methodologies and processes is driven by business strategy and by the types of projects needed to realize the business strategy.

The rationale behind standardization is to create a predictable process that prevents activities from differing substantially from project to project, and from project manager to project manager. Put simply, standardization saves project players the trouble of reinventing a new method and process for each individual project. As a result, the process is repeatable despite changes in customer expectations or management turnover.

The rationale behind flexibility is to give the project team the ability to explore, experiment, and iterate processes to reduce uncertainty. The players learn and adapt through multiple iterations in order to meet the needs of the project and the stakeholders.

When developing a PM toolbox, organizations should weigh the need for fixed and repeatable processes against the need for flexible and adaptable processes. This need may vary depending on the different departments or functions in an organization. For example, an engineering department may benefit from well-established policies, processes, and tools. In the same organization, the IT department may benefit from a more flexible and adaptable set of processes and tools. Both approaches are fine as long as they support the business strategy and are aligned with the project objectives.

Since the PM Toolbox is aligned with the PM methodology used, it is understandable that the level of standardization of the methodology 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.

CUSTOMIZING THE TOOLBOX

Developing a PM Toolbox is an evolutionary process. In a practical sense, PM toolboxes will look quite ad hoc at first. The tendency is to begin building the PM Toolbox with existing tools due to a project manager's familiarity with them. Thus, the early-stage PM Toolbox has more to do with familiarity of use than with standardization. As a firm begins to mature its project management practices, there is a greater understanding of the tools that are needed in the Toolbox.

Often, project managers assume that the PM Toolbox is of a one-size-fits-all nature. This is incorrect. The PM Toolbox reflects the project management methodology and types of projects the methodology serves.

Regardless of whether an organization's project management methods and processes are standardized, flexible, or semi-flexible, 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.

There are multiple options for customizing a PM Toolbox. Three of the most common are:

1. Customization by project size
2. Customization by project innovation
3. Customization by project type.

Each option has the purpose of showing which specific project management tools to select and adapt for the PM Toolbox. 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. This section describes the customization options and offers 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 the size drives differences in project management methodology complexity. The reasoning here is that as the project size increases, so does the number of project management activities and resulting project deliverables associated with a project, and so does the number of interactions among them.

Since different project sizes require different processes and tools, we first need a way to classify projects by size and then customize their toolboxes. In Table 1.1 you can see examples of how different companies classify small, medium, and large projects.

Based on size, the companies determined the managerial complexity of the project classes and processes. The complexity influences the PM Toolbox make-up. A simplified example is shown in Table 1.2.

As Table 1.2 indicates, some of the tools in the toolboxes for projects of different size are the same, others are different. For example, all use the Lessons Learned (Chapter 17) because all projects need to learn from their performance. Since managerial complexity of the three project classes and their processes calls for different tools, some of the tools differ. For example, Earned Value Management (Chapter 15) is needed in large projects, but not medium or small projects.

Table 1.1: Examples of Project Classification by Size

Project and Company Type Project Size Small Medium Large Product development projects in a $1Billion/year high-technology manufacturer $1-2M $2-5M >$5M Infrastructure technology projects in a $300M/year food processing company <$50k $50-150k >$150k Software development projects in a $40M/year customer relationship management software company 300-400 person-hours 1000-3000 person-hours >3000 person-hours

Table 1.2: Examples of PM Toolbox Customization by Project Size

Project Size Origination Planning Development Closure Small Project canvas Scope statement Summary status report Project closure report WBS Responsibility matrix Milestone chart Medium Project Charter Stakeholder register
Stakeholder analysis
Communication matrix
Scope statement Summary status report Project closure report WBS Change management system Post mortem review Responsibility matrix Change log Cost estimates Critical path method Critical path method Cost baseline Risk register
Risk assessment
Risk responses Risk register Large Project charter Stakeholder register
Stakeholder analysis
Communication matrix
Scope statement Summary status...