 Welcome to the Unit 2 review for strategic project management. My name is Dr. Lucinda Stanley. We're going to go into more detail about the project management process in this unit, but first, a bit of a reminder about how this works. There are seven units in this course. In Unit 1, we learned what a project is, who makes the decision to take a project on, and what the triple constraint theory is. In Unit 2, we're going to look at the project life cycles so we can see project management as a whole. Now that we know what the focus of the course will be, let's look at what you should understand when you complete Unit 2. Our first learning outcome for this unit is to differentiate the work completed during each phase of the project. So we're going to go through each phase of the project life cycle and discuss what happens during that phase. Our second outcome is to apply appropriate project management techniques to each project phase. So we'll look at some of the techniques project managers use to manage each phase of the project life cycle. Our third objective is to demonstrate the proper use of project management documents throughout the project management life cycle. So we'll look at how a project team will create and use documents to help them keep a project on target for being successful. Just a reminder about why these learning outcomes are important. Every resource in the course can be tied back to one of the learning outcomes, which means that all assessments, including the final exam, are directly linked to the learning outcomes. Once you get to the end of the course, review the learning outcomes and see which ones you feel confident about. And if there's some that you're not sure about, it's a good idea to go back to the units that cover that outcome and review that material. This will ensure that you have all the knowledge you need to be successful in the exam. So here are our objectives and questions we hope to answer as we complete this unit. We're going to look at some definitions. We're going to define the work completed during each phase of the project life cycle and what the goals are of the project team. We're going to identify several project management techniques used during each phase of the project, how or when the project phases overlap, what the significant work effort in each project phase is, relate the triple constraint that we learned about in Unit 1 to each phase of the project, what the document outputs are for each phase, and how those documents help guide the team through project execution. While you'll find many more vocabulary words in the study guide, in this review, we're going to concentrate on these few, so keep an ear out for them as they come up. EMI, or the Project Management Institute, defines five process groups and 10 knowledge areas for project management. The process groups are initiating, planning, executing, monitoring, and controlling, and closing. These process groups are not necessarily phases of the project because at some points during the project, the processes within these groups may overlap. So while I'm showing the groups in a linear layout, they may not be linear in actual practice. Let's talk about each one of these processes and what you can expect to happen in each one. Let's start with initiating because, you know, without initiating, we don't have a project. In Unit 1, we learned about the process of how a project begins. Someone thinks they have an idea that will generate some sort of benefit to the organization that fits within its strategic goals. Then someone, probably someone else, makes the decision that the project will benefit some aspect of the organization and the project is launched. The next step is to outline what the project will entail, what are its needs and characteristics. This will generate the project charter, which is a statement of the scope, objectives, and participants in a project. This is the fundamental document for the project and one that is referred to throughout the life of the project. The business case is the justification for the project. It answers the question, why do we need to do this project? The scope statement is probably the most crucial part of the project charter. It has a detailed description of all the elements of a project, basically what needs to be done and what the deliverables are. Deliverables are the end result of a project. In order to make sure the scope statement, business case, and project charter documents are as comprehensive as possible, the project sponsor will meet with the project manager and any stakeholders who have any interest in the outcome of the project known as the stakeholders. The project manager and their team will gather as much information as they can to help build the project document so they have a good idea or as good idea as possible of the cost, scheduling, and exact scope of the project. Do these sound familiar? They should. Those represent the triple constraint elements we learned about in Unit 1. Another element we learned about in Unit 1 are the decision making tools such as the net present value and the decision matrix, which will help fill out the business case and are used to justify the project. If the project sponsor can show how the project will contribute to the organization's reaching their strategic goals, that is a definite way to increase the chance the project will be implemented. The next phase of the project lifecycle is planning. Now that the project has been justified and data has been collected about costs, schedule, and scope, triple constraints, the project manager will add this information to the project charter updating it to make it more comprehensive. The project manager will then build their team. In other words, they will find the people inside and outside the organization who can help complete the project. With the team, the project manager will begin to develop detailed project management plans, such as an exact schedule of tasks and processes for procurement. Within the project management plans, as specific people are hired to complete tasks in the project, the project manager will create a work breakdown structure. This is often a visual representation of the tasks of the project. The project manager may also use a Gantt chart, which can help them track the completion of project tasks and where tasks overlap. Supplementing the work breakdown structure will be a responsibility matrix, so that the project manager knows who is responsible for each task or element of the project. At this stage of project development, the project management team and the key stakeholders will develop a list of potential risks associated with the project. Risks are anything that can keep a project from moving forward or completing the project altogether. The team can't hope to know all of the risks, but by coming up with some possible risks, they can also be thinking about solutions that will mitigate those risks. As the project management team fills in the responsibility matrix, they may find other stakeholders who need to be brought into the project, possibly because they have an area of expertise that will benefit the project. There's a lot that happens in the planning phase, and to be honest, often not all of it is completed before the project actually begins. There may be some final elements of the project plan that need to be completed, usually related to tasks later in the project, and there may need to be adjustments made as the project develops. Here we are in the execution phase of the project. Here's where the project tasks actually begin. Just remember the work of a project may begin before the project plans have been completed. At this point, they may still be a work in progress. The execution phase is pretty self-explanatory. The project tasks are implemented according to the project plans. As we've discussed when reviewing the triple constraint theory, it's up to the project manager and their team to keep track of the scope, the budget, and the schedule of the project to make sure those areas don't deviate completely from the planning documents. The project manager may create a change control board where they can keep track of any requested changes to the project plan. The project manager will note how each change in the project scope will impact the budget for the project schedule. If a change is going to make big changes to either of those, the project manager may need to go back to the project sponsor and request extra funds or more time. Trust me, that's not something to be done lightly. For example, if a key stakeholder now decides they need 10 additional completed prototypes from the original mount, that will add significantly to both the schedule and the budget. Another example might be that one key stakeholder would like to change the color of the finished product so they put in a change request. Changing the color doesn't necessarily add anything to the project budget or the schedule, but the project manager notes it anyway. You might wonder why they would make a note if it isn't going to impact the completion of the project. It's called scope creep. When small changes are made, they can all add up, and someone, namely the project manager, has to keep track of them. As a matter of fact, many project contracts include an extra fee for every change order. This keeps the stakeholders or project end users from asking for a lot of extras after the project planning documents have already been created. Next, let's talk about the monitoring and controlling processes in the project management lifecycle. It's important to understand that this phase of our process happens at the same time as the exit phase. Remember, we talked about the process as not necessarily being linear. While implementation is going on, it's extremely important to keep track of what is happening in all aspects of the project and look ahead to the next task or task so that required materials are available when they're needed. In order to properly monitor the control project, the project manager and their team need to analyze the status of the project execution. Oftentimes, they will use some form of project management software, such as Microsoft Project or Monday. If properly set up, these project management software applications can let the project manager see at a glance what the status is of each part of the project. Project managers create a variety of reports to the different stakeholders of the project. They will report to the procurement department what's happening with the budget and when funds need to be released. They'll report to the project's sponsor if additional resources are needed. They will even report, usually once a week, sometimes more often, to the project team on how the project as a whole is going so the team has a good understanding of where their part of the project fits in the overall completion of the project. In all of this reporting, it's important for there to be a communication plan. Who communicates to whom? How is that communication made? By telephone? By email? A formal report? Those sorts of things. Different stakeholders may prefer different communication methods. Having a plan helps to make sure no one is left out of these status reports. In all of this, in order for the project manager to create and distribute the reports and to ensure the reports are accurate, the project management software must be updated frequently. Failure to update the software means the project manager is using faulty information to perform their analysis and disseminate information. Finally, the monitoring and controlling process of the project lifecycle means after reviewing the information and sharing it with the relevant stakeholders, it might be determined that changes to the project must also be made. These could take the form of a more thorough risk analysis and plan to mitigate known and unknown risks. Early on, there was likely an understanding of the level of quality that the project should be completed at. If the project manager is monitoring the quality of the project, they will notice if quality is not where it needs to be and will take corrective action. Finally, the work of the project is complete. The project manager has conducted project audits and sure enough, all aspects of the scope of the project have been completed. But that doesn't mean that things just stop. The closing phase of the project lifecycle is just as important as the other phases. There are processes that have to be completed in this phase as well. To be honest, this is the phase of the lifecycle that many project managers pay the least attention to. But as you'll see, completing the activities in this phase can make the next project one works on simpler. Of course, the project sponsor and stakeholders have to sign off that they agree with the project manager's assessment that the project is complete. The final approval will also include the end user's acceptance that the project deliverables meet their expectations and they are satisfied with the result. This is also the time that any contracts that were made with the vendors are closed out and that all monies have been paid. Closing the procurement indicates to the organization that no more money will be spent on this project. Vitally important analysis of what went right on the project and what went wrong. Typically, the project manager will hold a final meeting with the team and some of the key stakeholders to get their input on this and generate a report. The report can then be used should another similar type of project be initiated in the future or if a project team needs to be created again. The project team has worked hard for what could be months or even years. Let them take some time to celebrate the completion of the project. Some project managers would schedule a team party or some sort of relaxing event to congratulate the team on their accomplishments. Don't stint on this. The team has earned a celebration. Finally, the project team is sent on their way to other projects or back to their regular responsibilities. Many people make lifelong friends while working on a project or at the very least they have learned about the skill sets of their team members and can use that information in the future should they need assistance with another project. We have talked a lot about how the life cycle of a project is not necessarily linear despite how it's been presented in this course. Here's a simple gantt chart showing a visual of the overlap of project phases. Let's say the project from start to finish will take six weeks. In week one, we're getting the project initiated. So getting an idea of what the project will be. In week two, we begin working on the planning phase. Notice that the planning phase overlaps with the execution phase because projects often begin before the plans are all in place. In week three, we start the project execution phase. Notice that the controlling and monitoring phase begins at the same time. Once a project begins, it must be constantly monitored and adjustments made. The planning phase is also included as adjustments may need to be made to the scope of the project. We'll talk about that in a later. Weeks four and five are all about executing the project. Week six contains all of the closing activities. And here we are back at the beginning. The five processes of the project lifecycle. Initiating, planning, executing, monitoring and controlling and closing. In this unit, we learned quite a bit about the lifecycle of a project. We've looked briefly at each of those phases. Some of the techniques a project manager uses to keep the project on target for a successful completion. And we've looked briefly at some of the documents that were created and used during the different phases of the project. In the next few units, we'll look at each of these phases in a lot more detail. In the next unit, unit three, we'll look more closely at the first phase of the project lifecycle. The initiating.