In the previous lessons in this module, we've learned about the scope development process, including identifying the requirements, and developing the project scope statement. We have discussed scope validation and the importance of having a complete and unambiguous project scope statement, as part of this process. In this lesson we want to discuss scope control process itself, and why it is important in managing your project. We've reviewed the role scope control plays in the scope validation process, however, scope control also plays a role throughout the project. Remember that scope is one of the three legs of the iron triangle. If the scope changes, then either the schedule, or the costs, or both must change. In order to deliver our project on an agreed schedule and budget, we must control the scope. As it says here, scope control is an established work process to identify, evaluate, control and approve changes on a project. We've talked about how uncontrolled scope impacts cost and schedule. But it will also effect the morale and smooth function of the project team. We have all been part of one of those teams where we felt like we were shooting at a moving target, the requirements were always changing. This is a result of poor scope control. This constant search for the real requirements on a project will also damage our relationship with the customer. Without scope control, the reasons behind changes to the schedule and costs will not be clear. The customer can easily blame poor performance on our part, but we will be constantly arguing about the scope, neither result is good for the project. Good scope control processes include these key attributes. The process is well documented and understood by all. It is included in the scope management plan, and is approved all key stakeholders. The project process includes multiple layers of approval authority. These layers are separated based on the size and impact of the proposed changes. Smaller changes can be approved at the project level. Middle size changes are approved by an agreed change board, that has been granted authority by the customer to modify the scope, schedule and budget of the project. And larger changes should be approved by the executive management of the governing organization. These changes are typically outside of a predetermined band, and may impact the overall business plan for the project. The process has been custom fit to the needs of the project, and associated organization. The plan you used on the last project, may not fit the current project environment, it should be adapted to the current need. Finally, the process should be based on the approved project scope statement, and the scope management plan. It should also include the roles or responsibilities of key players, including level of authority, proposed, and approved changes. This is a good start, however, good change process also includes the following attributes. All changes must be documented in writing accompanied by a justification and why they will benefit the project and the organization. As stated earlier, they must layout a process of authority levels and roles and responsibilities. All changes must be incorporated in the baseline plan to establish a new basis for evaluating future changes. The scope, schedule and cost documents must be updated. And there must be a method for communicating the approved change, that will be implemented or a proposed change, that has been rejected. We need to eliminate any confusion on the status of the scope, schedule and cost. Any good change process includes a listing of the key roles in the process and who fills those roles. Most good project organizations have a change coordinator appointed. This is the one person responsible for collecting proposed changes, and making sure they go throughout the change control process, and communicating the status and results of each. Any one on the project who is either wants to propose a change, or suspects there is a proposed change, to contact the change coordinator to start the process. On large projects, this may be a dedicated role. On smaller projects, this role is given to someone on a project that's a portfolio assignment. It should be someone who has a broad view of the project, and is familiar with the scope, schedule, and costs for the project. This knowledge will allow them to help with the change identification process and incorporate the changes. Another key role in the process is the assessment body. This is a part of the project team that evaluates the proposed change, documents the impact on the project, documents the benefits, and makes a recommendation on how to proceed in the decision. This group typically includes both technical and business related members. The other key roles listed here are pretty self evident in their purpose. The typical change control process is a fairly straightforward process, although, in practice, it can be very time consuming disruptive if not managed properly. First, a proposed change is identified, next it is assessed by the assessment team and the impacts, benefits and recommendations on how to proceed are documented. Depending on the size and impact of the change, it's submitted to one or more levels of authority, to decide on whether to implemented change or reject it. If the change is approved, then the baseline documents are updated and the change is implemented. No matter what the proposed outcome, the proposed change and its documented outcome is recorded in the change log for future reference. The change log is an important document. It contains a record of all the proposed changes, who originated them, a description of the impact and the disposition. It should also include the date the change was proposed, and when it was decided and implemented along with the approving authority. It's a good idea to publish the updated change log in each monthly report. This allows stakeholders who are not part of the process, to understand what changes have been made, and which ones have been decided against. This will potentially save a lot of confusion at the end of the project and during the scope validation process. As a side benefit the change log documents the amount of proposed and actual change on the project. An extensive amount of change can indicate that the scope development process should have been better, or it could indicate a changing environment. An extensive change log can also be an indicator of potential issues in schedule and cost performance as high levels of change can be disruptive. Hope you have a better understanding of the importance of scope management process. The project scope statement describes the fundamental goals of the process, it describes the benchmark again we are going to be judged. The scope control process is a way we continually compare ourselves to that benchmark and make adjustments to the projects scope management plan. To accommodate changes, to communicate the impacts `of scopes schedule, and costs to the project stakeholders. All these activities are key to setting clear expectations for the project, and to finding success. In the next module, we'll take the next step in the scope management process, defining and creating the work breakdown structures. We will define the work packages and learn how they relate to work breakdown structures. Finally, we'll set up control accounts in preparation for monitoring, controlling our project. In the meantime, let's practice putting together a project scope statement, as part of the assignment presented in the next lesson.
