Project Scope Control Management

From apppm
Revision as of 14:57, 2 March 2019 by Srdjangluhovic (Talk | contribs)

Jump to: navigation, search

Developed by Srdjan Gluhovic

Contents

Abstract

In an ideal world, once a scope has been defined and moved into prototyping and construction, no changes will be made to the requirements or the extent, but in reality, project scope is continuously evolving over the entire lifecycle of the project. Therefore, it is significantly important that the scope identifies all the work that the project will accomplish to achieve its final goal and have a clear and easy scope management process that refers to the set of various processes that ensure a project's scope is accurately defined and mapped. [1] It is essential at the start of the project scope that it consists of sufficient detail to determine the purpose of the project with the expected benefits and any constraints such as time and budget. The Project Scope Management (PSM) processes consists of six parts, where control scope is the last part and is the process of monitoring and controlling the status of the product and project scope including managing changes to the scope baseline. [2] The product scope refers to how a product is made while a project scope focusses more on how to deliver the service or product. [3] The advantage of control scope is that it allows the baseline to be maintained throughout the entire project. Without a well-defined project scope, the time and cost of the project cannot be an estimation and obtained due to a lack of communication, which applies that the scope needs to be changed. This immediately affects the cost and disrupts the schedule of the project generating losses. This article focuses on achieving a successful project with the six main aspects of project scope management and including the scope change control and what changes may need to be proceeded to have a great scope. These aspects will be discussed in detail alongside the general guidelines of project scope management.

Introduction

Project Scope Management

Figure 1: Project Scope Management Overview and their tasks, inspired from the PMBOK® Guide [3]

The appearance from the abstract is that the controlling changes of the project scope are output from the control scope process which is a part of the project scope management process. The purpose of Project Scope Management is to assure that the results and the outcome of a project are successfully achieved by merely incorporating the necessary work to complete the project. Managing the project scope is mainly refers to defining and controlling what is included in the design and what is not.[4] Therefore, project scope management can be defined as a set of processes that requires to be done in order to complete a product with the described functions and features to achieve the desired project. [4]

The six processes described underneath do associate and interface with each other which address an appearance described as Scope Creep. Scope Creep also referred to as requirement creep in project management is defined as changes which are a continuous or uncontrolled increase in the scope of a project, at any point after the project starts. In early stages of design and development of the project, it can be challenging to determine whether or not there is a potential of incremental change in the project scope by adding elements to the project, or it has not been completely defined due to poor design of the project. Figure 1 provides an overview of the six important processes of the Project Scope Management with their task’s description highlighted by the PMBOK® Guide:[4]

1. Plan Scope Management

The first process is the plan scope management which is producing a scope management plan. The plan describes and documents how the project scope will be defined, validated and controlled. The essential part is that plan scope process helps and contributes guidance and orientation on how the scope will be managed throughout the entire project. Furthermore, the scoping plan also includes the different roles of people involved in managing the project scope and their responsibilities regarding the areas. Therefore, a guide helps to manage and control the scope. [4]

2. Collect Requirements

The collect requirements are an important process which is referred to as determining, documenting, and managing stakeholder demands and needs, but also requirements regarding the project objectives are met. From the stakeholder point, it is essential to breakdown their needs into a requirement. The element becomes the foundation for the WBS, which includes and referring to cost, schedule, planning, procurement which are all relying on the conditions. [4] Furthermore, the process provides the general definition of managing the project scope, these definitions are part of the scope baseline and are selected by the different stakeholders, project sponsor, project manager, who consider the requirements to be important.

3. Define Scope

The third process of the project scope management is to define the scope which consists of developing a well-detailed description of the project. The primary benefits of building a sufficiently detailed description of the scope is that it provides the foundation in the future for making project decisions. But this also provides a commen understanding of what the project scope is between the stakeholders. Besides having an explicit description of the project scope, it is also essential to include the different requirements from the stakeholders that have been developed in the collect requirements process and chosen to be the preferred requirements of the scope [5]. Furthermore, it is necessary to consider the known risks, constraints and assumptions to add the project scope.[4] All these points will have a significant contributor to the success and achievement of the project.

4. Create Work Breakdown Structure (WBS)

Now that the plan, collect requirements and the definition of the scope has been established, creating a Work Breakdown Structure (WBS). WBS is the process of subdividing the various major deliverables into smaller and manageable sizes which provides a structured view of what has to be delivered. Depending on the size and complexity of the given project, the degree of dividing the project can vary. The advantages of splitting the project into smaller tasks to make it more manageable to assign several responsibilities to the responsible people of the project. The additional benefits of applying the work breakdown structure are the duration time, and cost easier can be managed, and the accuracy can increase.

5. Validate Scope

In order to validate the scope, obtaining formal approval of the various deliverables need to be examined by the stakeholders (Sponsor, client, customer, etc.) and accepting of the completed project deliverables. This process checks if the separate deliverables match the requirements to increases the chance of the final project.

6. Control Scope

Control scope is the last process in project scope management. The purpose of this process is not only to monitor and maintain the project's baseline throughout the entire project but also to managing changes as they happen along the way which ensures that the scope changes are useful and beneficial for the project. [6] (p.167) Handling the changes is also a part of the project when they occur and as mentioned earlier if the uncontrolled scope increases of a project it will lead to scope creep. [7] The project scope changes can have a direct or indirect impact on the various factors of the project like cost, schedule, quality and other parameters. [8] (p.57) These changes are therefore essential to secure that any others indications of change are considered, to make sure that it is the accurate one, and no other surprises can occur. Figure 2. illustrates the process stream of the Scope Change Control with the input, tools & technique and output.

Figure 2: Project Scope Change Control Process, inputs, tools & techniques, and outputs inspired from the PMBOK® GuideI [8] [9]

The first column refers to the inputs of the scope change control process, as they seem in the PMBOK® Guide: [8] (p.57)

  1. Work breakdown structure (WBS) - The work breakdown structure is addressed as the project components that are deliverable-oriented arranged that organize and defines the total scope project. The objective is to establish a common perception of the project scope baseline. [8] (p.57)
  2. Performance Reports - Performance reporting gives information on the scope performance, comparing which deliverables have been completed and which is still behind, but the performance reporting also contributes to the different issues that can cause problems in the future, which help to warn the project managers or the team regarding scope performance. [8] (p.57)
  3. Change Request - Change requests can come in different forms, but the common one used is proceeded through the IT system, where a written change request is made depending on the scale of the project. Some of the change requests are results of an error in defining the scope of the project fx failure to include a required feature in the design, or a change which adds more value to the project. The project owner does these changes where everyone can send the change request for review. [8] (p.57)
  4. Scope management plan - From the scope management plan, the report describes which scope changes will be integrated and how they will be implemented into the project including how to manage the project scope. In the document, the description always needs to be clear and always include how the scope change will be identified and classified. [8] (p.57)


The second column refers to the tools & techniques applied in the scope change control process, as they seem in the PMBOK® Guide: [8] (p.58)

  1. Scope Control Change System - Scope change control is described as the procedures of the system by which the project can change, and this includes the various levels of approval that are required for authorizing the change. This procedure will further be explained in the application of the scope change. [8] (p.58)
  2. Performance measurement - The performance measurement techniques help to estimate the extent of the variations that happen. Therefore, it is crucial to determinate the causes of variation and if it is relevant to the baseline of the project and if there requires a corrective action which is a part of the scope change control. [8] (p.58)
  3. Additional planning - The last point is the additional planning which refers to proposed scope change needs extra planning which may be required preferentially to modification of the WBS or other alternative interpretation that could be used as an approach to have a successful transformation. [8] (p.58)


The third column refers to the output of the scope change control process, as they seem in the PMBOK® Guide: [8] (p.58) [9] (p.63)

  1. Scope changes - From the techniques and tools that have been used above, the scope change control includes the modification to the accepted scope that is determined by the approved WBS which refers to any changes to the scope project. [8] (p.58)
  2. Corrective action - The corrective actions are used to make sure that all the deliverables are satisfied by ensuring that the project performance is on the right track according to the project plan. [8] (p.58)
  3. Budget change - As any scope changes happen, it typically has an impact on the budget which requires an adjustment to the cost, quality or other relevant project objectives for the scope. [10] (p.3)
  4. Schedule change - As the budget changes, the impact of the schedule can also change to the different adjustment of the project scope which refers to the time. Some of the elements can meet the deadline which makes lateness. [10] (p.3)
  5. Lessons learned - Lessons Learned reflects on the reasoning behind the actions that have been corrected through the scope change control process by the project team. All the lessons learned through the project requires to be documented, and this information should be available to improve other projects in the future and probably not make the same mistakes or the same change next time. The knowledge should be stored in a database, so everyone has access to the documents. [8] (p.58)
  6. Adjusted baseline - The corresponding baseline document for the project needs to be reviewed and replicated to reflect on the approved changes in order to form a new baseline for future changes and to make the right decisions when supporting modifications of the scope change control processes. [9] (p.63)

Project Scope Change

Change is something that happens in projects across all industries at a given point in time, experience a change or a difference in the original project scope management plan. Furthermore, it is essential to recognize that there are multiple types of changes and it is difficult to distinguish between the kind of change types. Regarding the industry, there is not entirely guideline on how to manage the changes, and everybody has their specific approach, but in the end, the outcome of the difference is the same. In figure 3 the description of the different type of project scope changes with an explanation and an example represented.[10] (p.2)

Figure 3: Shows the various Project Scope Change based on the medical industry inspired from the QMS.[10] (p.2)

There is some initial requirement of a project change which refers that clarity and transparency are present throughout the entire change which is associating with cost, time plan, and quality. In terms of change, it could refer to the poor engineering design made by an internal engineer or an external supplier which requires to be re-designed to fulfill necessary regulations or requirements that is in the instructions. But there can also be an occasion where an unexpected change request appears due to a new industry regulation, which can refer to the companies in the medical industry that produces, e.g., hearing aids equipment and need to live up to the standards. [10] (p.2) Therefore it is a significant factor that project managers have the capability and knowledge of managing project scope and the relevant changes. As mentioned before the size of the project can directly or indirectly affect stakeholder due to the change, and it is the project manager responsibility to manage the changes well and keep the satisfaction of the stakeholders high. In the application section, there will be looking toward applying the scope change method with a guide from the change request and through the entire flow of the processes to the actual change in the project scope.

Application of Scope Change

Introduction

The description from the abstract associates to applying the change method into developments projects within the medical companies and in this case, it regards the hearing aids industries. In order to finalize the procedures of change in the sectors, there has been established a meeting with the with the Operations Department and interviewed the Director, Project Manager, and several Engineers including applied the company’s procedure documents that change are built upon together with their experience in change. [11] (p.1) In the following section an example of a flowdiagram that contain a design change regarding a component in a hearing aid device need to be replaced, and the process of the change with the overall control. Furthermore, there has been illustrated in figure 4 the various roles and responsibilities of the stakeholders involved in the scope change process from the project owner to the change control board (CBB). [Glossary 1] [10] (p.1)

Figure 4: Shows the various roles and responsibility based on the medical industry inspired from the QMS.[Glossary 2][10] (p.1)

Change Request

Figure 5: Shows the Project Scope Change flowdiagram based on the medical industry inspired from the QMS. [11] (p.11)

The structure of the process is represented in 11 steps shown in figure 5. [11] (p.11) The whole procedure and method are initiated by the Engineer that requested the change of the scope project regards a modification to the design of the project and to deliver a better product if the change is made. The Engineer or Change Originator is the one how is responsible for creating the Engineering Change Order (ECO) [Glossary 3] which is a form and process used to review and approve the document. In the document there needs to be sufficient technical content are substantiated appropriated in terms of test date, supporting reports, update the cost, scope, impact and the documentation of all the necessary steps required for implementation of the change order. [11] (p.1) All change request is going through the IT-system to have complete control, and nothing can be changed if the Change Request is not approved, but it can still depend on the size of the project.

Now that the Change Originator has obtained and fulfilled all the requirements the document is submitted to the Change Analyst how is going to review the proposal. If the proposal is without an Engineering Change Request (ECR) [Glossary 4], the ECO returns to the originator otherwise if the proposal is with an ECR and has the right change plans which ensure sufficient information. The Change analyst ensures that all the submitted change order are reviewed and approved and is routed for approval appropriate in accordance with policies and procedures. The analyst also assigns the proper approvals from the Change Control Board (CCB) is regards to the ECO. [11] (p.4)

The Change Analyst approves the ECO, and it continues to the Engineering review which also is a part of the CCB, but they need to accept the ECO first; otherwise, it cannot proceed. Engineering reviews all the design changes in the form of fits and functions and technical appropriateness and completeness. Furthermore, review the risk analysis regarding the functional design and for impact on safety testing.[11] (p.4) If there is any concern in the engineering review, the ECO will return to the originator. Otherwise, it will continue to the CCB review where the other departments as Operations, Manufacturing, Quality, and Finance.[11] (p.1)

The operations review the changes for impact in the current process, schedule and establishing the effective date of the proposed change and evaluating changes in regards for material disposition requirement, whether it both in-house or with the supplier but also ensure that if any changes affect purchased parts or assemblies include notification to the supplier. [11] (p.5) Finance is the one that reviews the project scope, budget, and schedule and accepts that the budget is going to increase and get the approval to change the budget.[11] (p.5)

The Quality Assurance (QA) [Glossary 5], evaluate the request whether it is a significant change if the change is substantial than the Regulatory Affair (RA) [Glossary 6], Authorities review and make sure it supports by regulatory clearance, but this is in tremendous changes that RA are involved. [11] (p.5) Otherwise, the ECO is released the ECO implementation activities can be assigned. Now that the ECO is published and ready for implementation all the internal and externals stakeholders from the different departments that have reviewed and approved the changes are legally obligated to implement the recommended change which also includes the updating the cost and schedule of the project.[11] (p.5) It is essential that the project manager continuously monitor and the change but also register the cost and schedule of the actual project to ensure that the deliverables are achieved.

Limitations

Throughout the description of the project scope control management and the application of the scope change, the procedure seems evident in some cases to follow. Furthermore, in the real world across different industries, the complex subject involves multiple stakeholders which reveals in the application. However, there are also various kinds of limitations regarding the scope change control which is the significant and detailed knowledge that goes into the changing procedures requires a lot of people involved in the project can be challenging with a lot is regulations. One of the challenges regarding the project change control is that long process time to get permission to implement the changes, from sending the change request to actual implementation takes time, and if the application is not sufficient, it returns directly to the originator. Therefore, one of the limitations is long process time which can move the schedule and perhaps have a more significant cost of the finished project. In general, the project scope can be complicated to define. At the beginning of the project scope where the definition is not completed yet it is possible to correct and adjust during the early stages of the design phase of the project, but when the scope has been approved, is not always obtainable to correctly define the baseline of the project at another point of the project lifetime. Therefore, these results are referred to as re-design changes in the Research & Development department (R&D) which cannot re-correct the design immediately but first through the change process.

There is also another limitation when discussing management of change that does not take employees' viewpoint into account when changing project which can result in the behavioral change in peoples. People get emotionally affected and dealing with different issues with change, and this is not considered and supports. The procedure is focusing mainly on the technical elements of the change. In order to manage the scope control right and achieve success, it is essential to take other aspects into account as the management of change from people’s perspective because in the project deliberation multiple stakeholders are involved in the process and project.

Great collaboration throughout the departments and the necessary stakeholder involved in approving the project changes is essential in order to succeed the change acceptance to implement the changes. This refers to have a good project manager that has the overview to deliver efficient work and to manage the control scope and the change.

Glossary

  1. ↑ Change Control Board (CBB): Designated individual responsible for reviewing and approving all change orders prior, to release for different departments.
  2. ↑ Quality Management System (QMS): It is the documentation forms that refer to as QMS.
  3. ↑ Engineering Change Order (ECO): The change order form and process used to review and approve the Quality Management System (QMS) Documentation.
  4. ↑ Engineering Change Request (ECR): The document where the proposer or originator explains the changes and which parts of the project/ product are affected by the change.
  5. ↑ Quality Assurance (QA): Reviewing changes for impact and ensuring that all steps needed to implement the change orders are correctly included and controlled.
  6. ↑ Regulatory Affair (RA): Reviewing for impact on Regulatory agency compliance and evaluating all product claims.

References

  1. ↑ Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 5th edition. Page 105
  2. ↑ Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 5th edition. Page 136
  3. ↑ 3.0 3.1 William R. Duncan. (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 5th edition. Pennsylvania: Project Management Institute.
  4. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 6th edition. Page 105
  5. ↑ Margaret Rouse. (January 2018). Project scope. [online].Available at: http://searchcio.techtarget.com/definition/project-scope
  6. ↑ Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 6th edition. Page 167-171
  7. ↑ https:http://www.project-management-skills.com/project-management-scope.html Project Management Skills. Retrieved 22 September 2017.
  8. ↑ 8.00 8.01 8.02 8.03 8.04 8.05 8.06 8.07 8.08 8.09 8.10 8.11 8.12 8.13 8.14 William R. Duncan. (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 5th edition. Pennsylvania: Project Management Institute. Page 57-58
  9. ↑ 9.0 9.1 9.2 Project Management Institute, Inc (2000). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Newtown Square Pennsylvania: Project Management Institute. Page 62-64
  10. ↑ 10.0 10.1 10.2 10.3 10.4 10.5 10.6 Quality Management System (QMS) – 003666 – "Change Control Approval Matrix Rev C". Page 1-3
  11. ↑ 11.00 11.01 11.02 11.03 11.04 11.05 11.06 11.07 11.08 11.09 11.10 Quality Management System (QMS) – 000017 – "Design Change Order Procedure. Rev M". Page 1-11


Annotated Bibliography

Project Management Institute (2016). A Guide to The Project Management Body of Knowledge (PMBOK® Guide), 6th edition. The guide delivers a good understanding of project scope management and provides the necessary guidelines for managing projects for all of the steps.

William R. Duncan (1996). A Guide to The Project Management Body of Knowledge. The guide from William R. Duncan presents a profound insight into the Project Scope Management. Furthermore, it provides an excellent overview of how the scope change control is structured and what needs to be included in order to change the scope and to provide additional information into the process of Scope Management.

Retrieved from "http://wiki.doing-projects.org/index.php?title=Project_Scope_Control_Management&oldid=69472"
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox