and the project stakeholder register and assumptions list should evolve from the corresponding documents begun when developing the project charter.
Deciding Which Projects to Move to the Second Phase of Their Life Cycle
The decision whether or not to allow a proposed project to proceed to the next phase of its life cycle is the last step of the first stage of the project’s life cycle (starting the project). The last step of one phase that leads to the first step of another phase is called a phase gate.
To maintain control over the progress of a project, it’s essential to assess how a project has progressed as measured by its key performance indicators (KPIs) and only to allow those projects that have met or exceeded their performance targets to proceed to the next phase. If one or more of a project’s KPIs do not meet the established standards, the organization must decide whether to have the project remain in its current stage and work to improve the unacceptable KPIs to acceptable levels, or whether to cancel the project completely.
Projects are evaluated in one of two ways in order to determine whether they should be allowed to proceed to their next phase:
Individually, against a set of minimum acceptable values of the established project descriptive and performance data that must be achieved for a project to proceed to the next phase.
In a group with one or more other projects — first, as described in the preceding bullet, to identify those projects that meet the minimum requirements for proceeding to the next phase, and second, to determine the relative rank in each of the descriptive and performance data categories that met the minimum standards.
The decision about which projects will proceed to the organizing-and-preparing phase of their life cycle (commonly referred to as a “Go/No-Go Decision”) will be based on the total amount of funds available to support the type of projects proposed in this group and the relative rankings of the desirability of each of the projects.
Tailoring Your Delivery Approach
You’ve probably already figured out that very rarely are two projects ever the same. Even projects with the same scope, stakeholders, schedule, and budget yield different outcomes when external factors differ from one project to the next. Since so few projects fit into a precise, repeatable mold, why then would you use the same approach, methods, and artifacts (to name a few) to manage every project? The answer is you wouldn’t. The concepts covered up to this point can be universally applied to all projects. Many other project factors, however, are better suited for some projects and organizations than others.
Nearly everything you use to manage your project can and should be tailored, including:
Life cycle and delivery approach
Processes
Engagement
Tools
Models, methods, and artifacts
Let’s deconstruct these project factors to understand what each entails and the value each offers.
The life cycle and delivery approach is one of the most impactful factors to tailor. Approaches range from predictive (Waterfall) to adaptive (Agile) with various hybrid models in between that each utilize different aspects of predictive and adaptive approaches (see Chapter 18 for more on Agile methodology). The approach you elect to use at this stage will set the foundation for the rest of your project.
Processes are added to bring more control or address unique product or environment conditions and requirements; they are modified to better suit the project or project team requirements; they are removed to reduce cost or effort when the benefit they offer does not justify the cost to keep them; they are blended to enhance other processes by incorporating select elements that add the most value; and finally, they are aligned to ensure they have consistent definition, understanding, and application.
Engagement tailoring addresses people, empowerment, and integration. People (project team and leadership) should be evaluated for their skills and capabilities and selected for the project based on their ability to complement each other and round out the team; empowerment involves the project responsibilities and the decision-making authority that resides with the project team or is reserved for leadership; integration considers all contributors to the project, internal and external (i.e., subcontractors, channel partners, and vendor partners, to name a few), and aims to bring them all together as a unified team working toward a common goal.
Tools that the team will use to manage the project, such as software applications and equipment, can also be tailored. Two factors that most often influence which tools are best suited for a project are cost to procure or use the tools and the familiarity of the project team and stakeholders with the tools.
The strategies, or models, to explain project processes, the means, or methods, to achieve project outcomes and the documents, templates, and presentations, or artifacts, to be prepared and used or delivered during the project should be tailored to include only those that add more benefit than the cost required to prepare and maintain them.
© John Wiley & Sons, Inc.
FIGURE 3-2: The tangible and intangible benefits of tailoring a project.
For the organization
Organizations have internal processes, constraints, and requirements — the “guard rails” within which projects are expected to operate — even where the project team has authority and autonomy. Additionally, external factors such as environmental or regulatory restrictions often exist to which an organization is ultimately held accountable. Projects must be tailored to ensure that organizational needs are satisfied.
Let’s consider an organization that provides contract engineering services to government clients and similar services to private sector clients. The government clients require stringent time-keeping practices and routinely subject their vendors to financial audits. Failing an audit would result in the loss of the government business so, for this reason, the organization requires all associates to log all time, for all projects (government and private), to the nearest 15-minute increment.
The resources on your project to design, build, and deliver a custom software application for a fixed fee, to a private sector client, must adhere to the same organizational requirement. Your private sector client is not aware of the actual number of hours your team expends
