Skip to main content
Engineering LibreTexts

5.3: The Project Life Cycle (Phases)

  • Page ID
    75165
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    The project manager and project team have one shared goal: to carry out the work of the project for the purpose of meeting the project’s objectives. Every project has a beginning, a middle period during which activities move the project toward completion, and an ending (either successful or unsuccessful). A standard project typically has the following four major phases (each with its own agenda of tasks and issues): initiation, planning, implementation, and closure. Taken together, these phases represent the path a project takes from the beginning to its end and are generally referred to as the project “life cycle.”

    Initiation Phase

    During the first of these phases, the initiation phase, the project objective or need is identified; this can be a business problem or opportunity. An appropriate response to the need is documented in a business case with recommended solution options. A feasibility study is conducted to investigate whether each option addresses the project objective and a final recommended solution is determined. Issues of feasibility (“can we do the project?”) and justification (“should we do the project?”) are addressed.

    Once the recommended solution is approved, a project is initiated to deliver the approved solution and a project manager is appointed. The major deliverables and the participating work groups are identified, and the project team begins to take shape. Approval is then sought by the project manager to move onto the detailed planning phase.

    Comparing Options Using a Weighted Decision Matrix

    Sometimes we have multiple options to choose from when determining requirements and deciding which project to work on. To select the best option, we can use tools such as a weighted decision matrix.

    A basic decision matrix consists of establishing a set of criteria for options that are scored and summed to gain a total score that can then be ranked. Importantly, it is not weighted to allow a quick selection process.

    A weighted decision matrix operates in the same way as the basic decision matrix but introduces the concept of weighting the criteria in order of importance. The resultant scores better reflect the importance to the decision maker of the criteria involved. The more important a criterion, the higher the weighting it should be given. Each of the potential options is scored and then multiplied by the weighting given to each of the criteria to produce a result.

    The advantage of the weighted decision matrix is that subjective opinions about one alternative versus another can be made more objective. Another advantage of this method is that sensitivity studies can be performed. An example of this might be to see how much your opinion would have to change in order for a lower-ranked alternative to outrank a competing alternative.

    weighted decision matrix therefore allows decision makers to structure and solve their problem by:

    1. Specifying and prioritizing their needs with a list a criteria; then
    2. Evaluatingrating, and comparing the different solutions; and
    3. Selecting the best matching solution.

    A weighted decision matrix is a decision tool used by decision makers.

    decision matrix is basically an array presenting on one axis a list of alternatives, also called options or solutions, that are evaluated regarding, on the other axis, a list of criteria, which are weighted depending on their respective importance in the final decision to be taken.

    Weighted Decision Matrix Sample

    The example in Figure 7.4 shows a weighted decision matrix that compared three options for a web development project (SJS Enterprises). This method is especially useful when choosing purchase alternatives and comparing them against specific desirable system requirements.

    7-4-Weighted-Decision-Matrix-for-Game-Delivery-Project.jpg

    Figure 7.4: Weighted Decision Matrix for Game Delivery Project.

    Planning Phase

    The next phase, the planning phase, is where the project solution is further developed in as much detail as possible and the steps necessary to meet the project’s objective are planned. In this step, the team identifies all of the work to be done. The project’s tasks and resource requirements are identified, along with the strategy for producing them. This is also referred to as “scope management.” A project plan is created outlining the activities, tasks, dependencies, and timeframes. The project manager coordinates the preparation of a project budget by providing cost estimates for the labour, equipment, and materials costs. The budget is used to monitor and control cost expenditures during project implementation.

    Once the project team has identified the work, prepared the schedule, and estimated the costs, the three fundamental components of the planning process are complete. This is an excellent time to identify and try to deal with anything that might pose a threat to the successful completion of the project. This is called risk management. In risk management, “high-threat” potential problems are identified along with the action that is to be taken on each high-threat potential problem, either to reduce the probability that the problem will occur or to reduce the impact on the project if it does occur. This is also a good time to identify all project stakeholders and establish a communication plan describing the information needed and the delivery method to be used to keep the stakeholders informed.

    Finally, you will want to document a quality plan, providing quality targets, assurance, and control measures, along with an acceptance plan, listing the criteria to be met to gain customer acceptance. At this point, the project would have been planned in detail and is ready to be executed.

    Implementation (Execution) Phase

    During the third phase, the implementation phase, the project plan is put into motion and the work of the project is performed. It is important to maintain control and communicate as needed during implementation. Progress is continuously monitored and appropriate adjustments are made and recorded as variances from the original plan. In any project, a project manager spends most of the time in this step. During project implementation, people are carrying out the tasks, and progress information is being reported through regular team meetings. The project manager uses this information to maintain control over the direction of the project by comparing the progress reports with the project plan to measure the performance of the project activities and take corrective action as needed. The first course of action should always be to bring the project back on course (i.e., to return it to the original plan). If that cannot happen, the team should record variations from the original plan and record and publish modifications to the plan. Throughout this step, project sponsors and other key stakeholders should be kept informed of the project’s status according to the agreed-on frequency and format of communication. The plan should be updated and published on a regular basis.

    Change Control

    When you find a problem, you can’t just make a change, because it may be too expensive or  take too long to do. You will need to look at how it affects the triple constraint (time, cost, scope) and how it impacts project quality. You will then have to figure out if it is worth making the change. If you evaluate the impact of the change and find that it won’t have an impact on the project triple constraint, then you can make the change without going through change control. Change control is a set of procedures that lets you make changes in an organized way.

    Any time you need to make a change to your plan, you must start with a change request. This is a document that either you or the person making the request must complete. Any change to your project must be documented so you can figure out what needs to be done, by when, and by whom.

    Once the change request is documented, it is submitted to a change control board. A change control board is a group of people who consider changes for approval. Not every change control system has a board but most do. The change request could also be submitted to the project sponsor or management for review and approval. Putting the recommended changes through change control will help you evaluate the impact and update all the necessary documents. Not all changes are approved, but if the changes are approved, you send them back to the team to put them in place.

    The implementation phase uses the most project time and resources, and as a result, costs are usually the highest during this phase. Project managers also experience the greatest conflicts over schedules in this phase. You may find as you are monitoring your project that the actual time it is taking to do the scheduled work is longer than the amount of time planned.

    When you absolutely have to meet the date and you are running behind, you can sometimes find ways to do activities more quickly by adding more resources to critical path tasks. That’s called crashing. Crashing the schedule means adding resources or moving them around to to bring the project back into line with the schedule. Crashing always costs more and doesn’t always work. There’s no way to crash a schedule without raising the overall cost of the project. So, if the budget is fixed and you don’t have any extra money to spend, you can’t use this technique.

    Sometimes you’ve got two activities planned to occur in sequence, but you can actually do them at the same time. This is called fast tracking the project. On a software project, you might do both your user acceptance testing (UAT) and your functional testing at the same time, for example. This is pretty risky. There’s a good chance you might need to redo some of the work you have done concurrently. Crashing and fast tracking are schedule compression tools. Managing a schedule change means keeping all of your schedule documents up to date. That way, you will always be comparing your results to the correct plan.

    Status reports should always emphasize the anticipated end point in terms of cost, schedule, and quality of deliverables. Each project deliverable produced should be reviewed for quality and measured against the acceptance criteria. Once all of the deliverables have been produced and the customer has accepted the final solution, the project is ready for closure.

    Closing Phase

    During the final closure, or completion phase, the emphasis is on releasing the final deliverables to the customer, handing over project documentation to the business, terminating supplier contracts, releasing project resources, and communicating the closure of the project to all stakeholders. The last remaining step is to conduct lessons-learned studies to examine what went well and what didn’t. Through this type of analysis, the wisdom of experience is transferred back to the project organization, which will help future project teams.

    Archiving of Document:

    The documents associated with the project must be stored in a safe location where they can be retrieved for future reference. Signed contracts or other documents that might be used in tax reviews or lawsuits must be stored. Organizations will have legal document storage and retrieval policies that apply to project documents and must be followed. Some project documents can be stored electronically.

    Care should be taken to store documents in a form that can be recovered easily. If the documents are stored electronically, standard naming conventions should be used so documents can be sorted and grouped by name. If documents are stored in paper form, the expiration date of the documents should be determined so they can be destroyed at some point in the future. The following are documents that are typically archived:

    • Charter documents
    • Scope statement
    • Original budget
    • Change documents
    • DPCI ratings
    • Manager’s summary—lessons learned
    • Final DPCI rating

    Example: Project Phases on a Large Multinational Project

    A U.S. construction company won a contract to design and build the first copper mine in northern Argentina. There was no existing infrastructure for either the mining industry or large construction projects in this part of South America. During the initiation phase of the project, the project manager focused on defining and finding a project leadership team with the knowledge, skills, and experience to manage a large complex project in a remote area of the globe. The project team set up three offices. One was in Chile, where large mining construction project infrastructure existed. The other two were in Argentina. One was in Buenos Aries to establish relationships and Argentinian expertise, and the second was in Catamarca—the largest town close to the mine site. With offices in place, the project start-up team began developing procedures for getting work done, acquiring the appropriate permits, and developing relationships with Chilean and Argentine partners.

    During the planning phase, the project team developed an integrated project schedule that coordinated the activities of the design, procurement, and construction teams. The project controls team also developed a detailed budget that enabled the project team to track project expenditures against the expected expenses. The project design team built on the conceptual design and developed detailed drawings for use by the procurement team. The procurement team used the drawings to begin ordering equipment and materials for the construction team; develop labour projections; refine the construction schedule; and set up the construction site. Although planning is a never-ending process on a project, the planning phase focused on developing sufficient details to allow various parts of the project team to coordinate their work and allow the project management team to make priority decisions.

    The implementation phase represents the work done to meet the requirements of the scope of work and fulfill the charter. During the implementation phase, the project team accomplished the work defined in the plan and made adjustments when the project factors changed. Equipment and materials were delivered to the work site, labour was hired and trained, a construction site was built, and all the construction activities, from the arrival of the first dozer to the installation of the final light switch, were accomplished.

    The closeout phase included turning over the newly constructed plant to the operations team of the client. A punch list of a few remaining construction items was developed and those items completed. The office in Catamarca was closed, the office in Buenos Aries archived all the project documents, and the Chilean office was already working on the next project. The accounting books were reconciled and closed, final reports written and distributed, and the project manager started on a new project.

    Text Attributions

    This chapter of Project Management is a derivative the following texts:

     

    This page titled 5.3: The Project Life Cycle (Phases) is shared under a CC BY-SA license and was authored, remixed, and/or curated by Adrienne Watt (BCCampus) .

    • Was this article helpful?