This section will introduce some of the key vocabulary that is prevalent in the project environment and then summarize a general life cycle model. Throughout this discus- sion and the book, the PMI’s PMBOK® Guide model vocabulary and life cycle view will
be generally followed (PMI, 2013).
One of the values of standard methodology is that it uses a defined vocabulary. In the absence of this, communication among the team participants is more difficult as they struggle for terms to represent various project issues and processes. The vocabulary items below are frequently used and need to be understood in their context.
Table 7.1 Benefits Offered by Project Methodologies
No. Focus areas Supports PM By
1 Effective processes Defining key processes required
2 Reusability Using key artifacts from project to project
3 Integrated metrics support Provides techniques to evaluate project performance 4 Quality focus Ensures proper consideration for quality management 5 Managing complexity Provides techniques to help sort out root cause issues
6 Project documentation Provides templates and aid in producing required documentation 7 Standard approach Provides a mechanism for cross-project comparisons and
simplifies team training
8 Consistency Pursues projects using a similar approach 9 Project planning Provides project planning techniques
10 Team management Guides the project team to completion by defined phases 11 Elimination of crises
management By establishing an improved structure, future crises situations are avoided 12 Training Supports team training through its formal process documentation 13 Knowledge Supports lessons learned to improve future projects
Project Life Cycle Models • 59
7.2.1 Feasibility Review
Most projects have some related concerns regarding technical, political, resource, or economic feasibility. Feasibility analysis is designed to consider such issues and provide an early assessment of the Business Case vision viability. In some cases, the initial proj- ect vision is more of a wish list than a feasible proposal, so a follow-on step is needed to ensure that the vision can be achieved and at what cost, time, and risk. The concept of feasibility occurs in more than one step as the formal planning stage crystallizes the requirements. By the end of the planning stage, the feasibility assessment should be suf- ficient to make a GO/NO GO decision.
7.2.2 Project Plan
Every project should proceed under the control of a plan customized to its size and com- plexity. One analogy for this is that you would not consider building a house without a plan, yet multimillion dollar projects are pursued with only rudiments of a plan. The plan must consist of more than a technical goal and more than time and budget projec- tions. It must also describe how the work will be performed and other aspects of the KAs. A key management question for every project is how much planning is appropriate and how detailed should the plan be. Often the pressure to complete the project moves the team into execution before a coherent plan is completed. This move creates added risk and impacts the ability to control the project. On the other side of this coin, there is always the question as to when a plan is sufficient to proceed. There is a concept of “analysis paralysis” which means the problem was overanalyzed.
According to the PMBOK® Guide a well-formed project plan should contain subplans
based on the following nine familiar process components or KAs: 1. Scope 2. Time 3. Cost 4. Quality 5. Procurement 6. Risk 7. Communication 8. HR 9. Stakeholders
7.2.3 Logical versus Physical Design
During the early stages of the project life cycle there are various techniques to describe the future view of the product or system prior to actual construction. In the case of a physical product, prototypes or mock-up models are often used (i.e., houses, commercial real estate, airplanes, cars, refineries, etc.). In some industries, this process is very mature, whereas in many others, it is not. In the situation where the project goal is less tangible, the requirements must be translated into what is called a logical design. Logical designs are abstractions from the real product. A blueprint for a house would be a logical design. Likewise, a flowchart or data model for a computer program would be a logical design.
The role of design documentation is to allow user and technical participants to exam- ine the project goal before investing significant resources. Regardless of the method used to document the future project goal some process of requirements evaluation should be undertaken with both technical and user stakeholders prior to moving very
far into the physical design activity, or execution. The role of this review is to provide the stakeholders with some better understanding regarding what the final deliverable would be. At this early stage the concern is more on “what” is going to be done and less focus on “how” it would be accomplished.
7.2.4 Quality Control and Quality Assurance
These activities involve the middle ground of the life cycle and are focused on delivering the item (produce or process) that was specified. Formal review points in the life cycle are used to evaluate either the technical or functional aspects of the output goal. Prior to a physical product being delivered, the technical specialist might review the planned general approach, tool selection, or any other technical issues related to the execution process. These reviews move the focus toward “how” the problem will be solved.
As physical output becomes available, the user community needs to be heavily involved in the evaluation. An operational goal at these points is to assess how the out- put compares to the design specifications. In the case of software, this midstage evalua- tion would be code modules that would be compared to defined requirements. Tangible projects would produce subsystems that had similar review characteristics. Reviews related to this segment would have the characteristic of a quality examination by tech- nicians, or a user acceptability review.
7.2.5 Monitor and Control
This high-level activity essentially lies across all the life cycle phases and its role is to measure status and take corrective action as needed to influence the move of the project in the proper direction.
7.2.6 Periodic Status Reviews
It is customary to distribute formal project status communication on a periodic basis. The format, frequency, and audience for these reviews are specified as part of the for- mal project communications plan. The review process can be very formal or casual and occurs at defined points throughout the life cycle (i.e., time periods, milestones, etc.). In some cases, this communication would be performed through a non-face-to-face defined reporting process through defined status metrics.
7.2.7 Milestone or Stage Gate Reviews
Beyond the major phase review points outlined above, most projects have some addi- tional requirements for a more formal face-to-face technical, user, management, or other group review. These may occur at key budget cycle points or with visiting dignitaries. One example of a milestone review would be the demonstration of some key technology or pilot prototype performance. In 2008, Boeing engineers wanted to demonstrate that their new Dreamliner carbon fiber wing would withstand a particular level of flexing, so they built a mock-up and publically bent the wing and measured the flex until it broke. This was meant to ensure all (including the future riders) that the design was safe. This would be called a technical review, but it was also filmed and distributed to others, so probably had a dual role.
7.2.8 Project Close
The model described here is that all projects should enforce a formal closing process. Appropriate stakeholders and the project team should review both ongoing and final
Project Life Cycle Models • 61
status of the project to evaluate both good and bad results. This review is designed to help the current project and future ones gain value from the current experience. This method has been proven to be a viable approach for organizations to improve their internal processes.
7.2.9 Project Communication Processes
Various project communications activities focus on some unique physical product or project artifact and involve some specific collection of stakeholders (typically project team, user, sponsor, or management). These communication processes often take of the form of face-to-face meetings that have high potential to waste the member’s produc- tive time. Effective communications and problem solving are some of the most difficult goals for the project team to accomplish. Specifically, excessive use of face-to-face group meetings for this purpose is very costly and represents one of the time and productivity robbers that have to be recognized.
During the course of project execution one of the key communication roles is to pro- vide confidence that the project is moving forward in an appropriate manner, or con- versely at least to communicate actual status. From a management control viewpoint, it is desirable to not allow the continuation of a project that has fallen below its value threshold. A phase review is the typical time to perform such analysis and at that point either specify corrective action or shut the project down. Runaway projects consume resources that could better be spent on other options.
Note that in the various vocabulary items given above, reviews are given names like stage gate, kill points, milestone reviews, acceptance test, and so on. Certainly the terms “gate” and “kill” have obvious implications to the PM and highlight the significance of this activity. Many organizations approach these key points with the attitude that the project must justify why it should go forward, so the built-in bias is to stop it. Regardless of the local culture, the communication and review processes are vital to the life cycle management process.
7.2.10 Life Cycle Models
There are many project life cycle model designs based on the project’s goal objective, complexity, and bias toward planning. Each one has some unique aspect to its structure and phasing. Small projects typically will combine some of the steps indicated above and exhibit a lesser level of planning detail and control. The PMBOK® Guide would
suggest that the various KAs (risk, HR, quality, etc.) always be reviewed before deciding to omit them from formal consideration. Large, high technology projects such as those found in the military, NASA, or other government agencies often encompass technical state-of-the-art issues to resolve before the project could move forward. In that type of situation there should be strong consideration to strictly following the full model vari- ables. Also, the role of formal technical reviews related to requirements creation and evaluation has particular value.
Mega-projects spend a significant amount of planning and review time in the vari- ous life cycle stages because of broad stakeholder interest and the high level of resources involved. Alternatively, in the case of a lower technology effort such as that found in traditional building construction we would likely see a very formal logical design review phase, but less formality in the risk, communication, and HR planning aspects of the project so long as standard components were defined in the design. Also, construction and other industries profit from having well-defined quality standards that can be easily
specified in their requirements definition and subsequently implemented. This is a les- son all industries need to adopt more.
7.2.11 Templates
Organizations typically develop standard project templates for various types of project document types and these provide a good starting point for laying out a reasonable approach to a new project. There is no universal set of templates that will fit all projects, but the use of this strategy can save a great deal of time in the various management aspects of the project (see Appendix B for further discussion on templates). Recognize that across all projects, there is much more similarity of processes than most recognize. The argument that a particular project is unique is often a lack of understanding of basic project management principles. This point is one of the most important items to take away from this section. The technical sequence of tasks required is certainly different, but the overall management processes are basically fundamental. That thesis is stressed throughout the book, but not always accepted by some practitioners.