View source for Project Scope Management

==Abstract== 
The basic concept of a Project Scope Management is defining and controlling what is included and what is not included in the project and ensure that all and only the work required to finish the project is completed. <ref name = "besefi">Project Management Institute (2013). ''A Guide to the Project Management Body of Knowledge (PMBOK® guide) 5th edition''. Newtown Square, Pennsylvania: Project Management Institute, Inc </ref>. It is vital for a project manager to have a scope, it defines the step the needs to be taken in ordered to achieve the project goals. It includes, but is not limited to, what the end goal is, how much the whole project and every segment of it will cost, how much work it will take and when the project is supposed to be finished. <ref>Project scope. (et. al). Retrieved 10. February 2018 from http://searchcio.techtarget.com/definition/project-scope</ref> 

The following processes are the main pillars of the Project Scope Management and whole chapters will be dedicated to each process in the following article. These processes are: Plan Scope Management, Collect Requirements, Define Scope, Create Work Breakdown Structure, Validate Scope and Control Scope. The processes all connect in some way. It is also important to mention that in the project framework, it is possible to define the scope in two different ways, one way is to refer to the scope as product scope and the other ways is called project scope. <ref name = "besefi"/> The product scope refers to how a product is made while a project scope would focus more on how to deliver the service or product. A product scope could therefore be included in the project scope. <ref>Product Scope vs. Project Scope. (et. al). Retrieved 10. February 2018 from https://www.villanovau.com/resources/project-management/product-scope-vs-projectscope/#.WoAY7ud0ZEY </ref> The Scope Baseline is considered as a sacred plan and is not to be changed unless it follows formal change control procedures. It is therefore important for a project manager to have a scope and manage it properly. <ref name = "besefi"/>

==Plan Scope Management== 
The first process according to the PMBOK is to create a scope management plan. The plan would record how the project scope should be defined, validated and controlled. <ref name = "besefi"/> The scope management plan locks down the roles and responsibilities of persons involved in managing the project scope and is therefore a guide aimed at managing and controlling the scope. <ref>Mark Piscopo. (et. al). Scope Management Plan Template.  Retrieved 12. February 2018 from http://www.projectmanagementdocs.com/project-planning-templates/scope-management-plan.html</ref> To start developing the scope management plan and specifying the project scope, one has to start examining the project charter, the latest approved subsidiary project management plan and other related business factors. The goal with this process is to reduce the risk of scope creep.

After analysing the data relevant to developing the scope management plan the project team would set up meetings with experts in the field in addition to regular team meetings. The experts in the meeting may be a group or a person with special skills or experience in the particular topic the project is about or it could be experts in developing a scope management plan. The regular project meetings have the goal of developing a scope management plan. Those who attend this meeting should be the project manager, the project sponsor, some team members and others as they are needed. <ref name = "besefi"/>

When the project team has finished it work it should have generated the scope management plan and a requirements management plan. As discussed briefly before, the scope management plan should define the process for creating a detailed project scope statement, process to create, maintain and approve the Work Breakdown Structure, process of how deliverables will be formally accepted. <ref name = "besefi"/> It should also have some guidelines in how to deal with scope creep and how to handle disagreements between the stakeholders. <ref name = "göndull"> Avantika Monnappa. (2017). Project Scope Management: What It is and Why It’s Important.  Retrieved 12. February 2018 from https://www.simplilearn.com/project-scope-management-importance-rar89-article </ref> The requirements management plan is a part of the project management plan, it defines how requirements will be analysed, documented and managed. <ref name = "besefi"/>


[[File:PlanScopeManagement.PNG||center|thumb|1000px|Figure 1 process for Plan Scope Management <ref name = "besefi"/>]]

==Collect Requirements== 
The stakeholder of project is highly vested in the outcome of the project. The goal with the process of collecting requirements is to determine, record and manage the stakeholder needs and requirements to complete the project objective. If the process is done well and with no major mistakes it should decrease the likelihood of something unexpected as the project progresses onwards <ref name = "göndull"/>The process gives the project manager the foundation of defining and managing the project scope. It is important to breakdown the stakeholder’s needs into requirement, needs are more of a broader term (ex. I need to buy a dog) while a requirement is defined as a condition or a capability required to solve a problem (ex. The dog should be a Border Collie, it should be black and white and a male dog). requirements are documented from the needs and expectations of the project stakeholders, these requirements should be thorough and in great detail as they are the basis of the Work Breakdown Structure as well as the cost, schedule and quality planning all rely heavily on the requirements. <ref name = "besefi"/> 

From figure 2 one can see the inputs, tools & techniques and outputs used in this process. The tools and techniques used in this process are many and not every one of them are essentially used every time. They all have the same goal, to obtain information, needs and expectations from various stakeholders in various ways and use them to construct the requirements for the project. The documents produced from this work are called Requirements Documentation Plan and Requirements Traceability Matrix.  <ref name = "besefi"/>

The Requirements Documentation could be a simple document with a list of the stakeholders, their requirement and the priority of it. It could also be a detailed document which contains a well detailed description of every stakeholder and their requirements. It is a general rule that the requirement must be measurable, testable, traceable, consistent and addressing the needs of the key stakeholders. The Requirements Traceability Matrix is a matrix that connects the requirement to the original needs or expectation and it also connects to the deliverable that will satisfy said requirement. It gives the project manager an easy way to observe the requirement throughout the project lifetime, ensuring that the requirement is always fulfilled. <ref name = "besefi"/>

[[File:CollectRequirements.PNG||center|thumb|1000px|Figure 2: The process of collecting requirements <ref name = "besefi"/>]]

==Define Scope== 
Defining the scope is the process of producing a well detailed description of the project and/or the product, the process will decide what requirement will be included or excluded in the project scope, as it is obvious that it is not always possible to include all the requirements because the number of stakeholders could be overwhelmingly large and in no way possible to satisfy all their needs.<ref name = "besefi"/> Based on the requirement that are included in the project scope, it will then describe the deliverables expected from the project. <ref name = "göndull"/>
Having a well-defined scope is a major contributor to the success of the project, it is vital to examine the known risks, assumptions and constraints to add to or update (if necessary) the project scope. <ref name = "besefi"/> 

In figure 3 it is possible to observe the process of Defining the Scope visually.

[[File:DefineScope.JPG||center|thumb|1000px|Figure 3: Process of defining the scope <ref name = "besefi"/>]]

The tools and techniques that are proposed in figure 3 are used to achieve the end results. The project manager can use these tools to generate the Project Scope Statement and Project Documents Updates. The tools range from getting expert judgement, that is someone (a person or a group) that is an expert in the field of the project, to having internal team discussion using general management techniques like lateral thinking and brainstorming for example. If the project includes a product as a deliverable it is possible to use the product analysis technique which includes techniques like Product Breakdown, Value Engineering and Value Analysis for example. <ref name = "besefi"/> 

One of the most important thing in a project is the project scope statement, which is generated in this process. Projects that lack a project scope statement are riddled with scope creep problems, by defining it in the early stages of the project the project manager and the team have set the boundaries of the project. Then by using the tools described in figure 3 the project team led by the project manager can make well informed decision on what to include in the project scope. <ref name = "skaufi"> Burek, P. (2006). Developing a complete project scope statement in 2 days. Paper presented at PMI® Global Congress 2006—North America, Seattle, WA. Newtown Square, PA: Project Management Institute. </ref>   The project scope statement is a comprehensive document that includes both the project scope and the product scope. It also includes indirectly or directly the acceptance criteria, deliverables, project exclusion, constraints and assumptions. In table 1 one can see a short description of the things included in the project scope statement.  The project team should be in a better position to control the project scope if the level of detail were the project scope statement defines the work that is supposed to be achieved and the work that is supposed to be excluded is higher. Project Document Updates could be produced in this process, the process would update existing documents, such as the stakeholder register, requirements documentation and the requirements traceability matrix. <ref name = "besefi"/> 

{| class="wikitable"
|+ Table 1:Summary and descriptions of what is included in the project scope statement 
|-
! Included 
! Description
|-
| Project/product scope
| A thorough summary that describes the features of the project and/or the product.
|-
| Acceptance criteria
| The list of conditions that deliverables must satisfy to be accepted are listed in this category. 
|-
| Deliverables
| Reports, products, results, documentation or anything that must be produced to complete a phase, process or a project.
|-
| Project exclusion
| Things that are not included in the project scope, it helps managing the stakeholder expectations.
|-
| Constraints
| Any restrictions or limitations that could affect the execution of the project somehow, for example scheduled milestones or predefined budget. 
|-
| Assumptions
| Conditions that are thought of being true without any proof. It also describes how it affects the project if said assumptions would turn out to be false. 

|}

==Create Work Breakdown Structure== 
Dividing the project into smaller and more manageable components is the key in creating a Work Breakdown Structure, therefore making complex projects more easily manageable. Figure 4 shows the inputs, tools & techniques and outputs used in this process. 

[[File:CreateWBS.PNG ||center|thumb|1000px|Figure 4: The process of creating a work breakdown structure <ref name = "besefi"/>]]

The decomposition technique mentioned in the figure is the heart of the Work Breakdown Structure process. This technique is used to divide and, in some cases, subdivide the project scope as well as the deliverables into smaller more manageable segments, giving it a structured view. It depends of the complexity of the project how much one needs to divide the project. The benefits of dividing the project up like this is that it is easier to assign responsibilities to the divided components of the project, makes the project structure more visual and more accurate cost and time estimation to name a few. <ref name = "besefi"/>

The decomposition technique is used to divide an upper-level component into segments and each segment will be a part of the Work Breakdown Structure. This might be understood better visually, figure 5 shows a template of a Work Breakdown Structure. There are a few guidelines on how to achieve the best results when constructing the Work Breakdown Structure. The guidelines can be viewed in table 2.  <ref name = "reður"> Getting Started with Work Breakdown Structures (WBS). (et. al). Retrieved 20. February 2018 from https://www.smartsheet.com/getting-started-work-breakdown-structures-wbs </ref>

{| class="wikitable"
|+ Table 2: Guideline of how to construct a work breakdown structure
|-
! Guideline for WBS
! Description
|-
| Focus on deliverables
| Defining the small deliverables that will end up forming the main deliverable. When creating a list like that, the project manager is less likely producing something that is not on the project scope. 
|-
| No overlap
| Making sure that there is no overlap in the scope definition. This can be managed by creating a Work Breakdown Structure dictionary.
|-
| The 100% rule
| The 100% rule states that the sum of all resources in the Work Breakdown Structure should add up to 100%, that is the resources used in lower levels should roll up to the higher level. For example, if the sum of level two work components should add up to 100%. (Figure 5 show this visually)
|-
| Level of detail
| Means that each component should be able to be completed within a reporting period. For example, if a team assigned to a component in the Work Breakdown Structure has a meeting every 10 days then the work should be completed within that period. 
|}  

[[File:WBS Demo.PNG ||center|thumb|1000px|Figure 5: A demo of how a work breakdown structure might look like.<ref> The 100% Rule. (et. al). Retrieved 23. February 2018 from http://www.productbreakdownstructure.com/the-100-rule.php </ref>]]


The results from this project should be a completed Scope Baseline. A Scope Baseline is an approved version of the Work Breakdown Structure, the Work Breakdown Structure dictionary and the scope statement. It is not possible to change the Scope Baseline unless it goes through a formal change procedure. The Scope Baseline includes the project scope statement generated in the Define Scope process, the Work Breakdown Structure and the Work Breakdown Structure dictionary. The Work Breakdown Structure dictionary is a detailed document describing the deliverable, activity and scheduling information about every component that is in the Work Breakdown Structure. <ref name = "besefi"/> Therefore the project managers use the Scope Baseline as a guide throughout the project lifecycle, constantly reviewing it to ensure that all components of the project are finished in prior to close the project completely. <ref>Tony Alby. (et. al). Scope Baseline.  Retrieved 20. February 2018 from https://project-management-knowledge.com/definitions/s/scope-baseline/</ref>

==Validate Scope== 
In the end of each phase the deliverables are inspected by either the stakeholders and/or customers to ensure that they are satisfied with the product or service, i.e. they must accept the deliverable. This is the Validate Scope process. <ref name = "göndull"/> Figure 6 shows the inputs, tools & techniques and outputs used in this process. The inspection process checks if the deliverable meets the requirements and the acceptance criteria. The Group Decision-Making Techniques are used to attain a concluding decision when the validation is being performed by the stakeholders and the project team. <ref name = "besefi"/>


[[File:ValidateScope.PNG ||center|thumb|1000px|Figure 6 The process of validating the scope <ref name = "besefi"/>]]

The deliverables that pass inspection and consequently meet the requirements and acceptance criteria are approved by the customer or a stakeholder. These Accepted Deliverables must be formally approved with formal documentation. If, however the deliverables are not accepted then a Change Request is formally requested to repair the defected deliverable. The Work Performance Information documents the information about the project progress. That could be which deliverables have been started, finished or accepted.<ref name = "besefi"/>

==Control Scope== 
The last process in the Project Scope Management. The purpose is to monitor the project and if there are any, manage the changes made on the Scope Baseline. <ref name = "göndull"/>Controlling the scope also used to manage the changes of a project when they happen. If a scope is uncontrolled it will lead to scope creep. That is the changes in time, cost and other resources are not adjusted to the project. Figure 7 shows the inputs, tools & techniques and outputs used for this process.  <ref name = "besefi"/>

[[File:ControlScope.PNG||center|thumb|1000px|Figure 7: The process of controling the scope <ref name = "besefi"/>]]

Performing a Variance Analysis is the technique used to measure the difference between the actual performance and the planned work defined in the Scope Baseline, from this the project manager could decide to take corrective or preventive action. The results from this process are listed in figure 7 with all but one defined before. The Organizational Process Assets Updates would document what did cause the difference between the actual and planned performance, the corrective and/or planned measures taken and the reason why they were chosen and other lessons learned from the control of the project scope. <ref name = "besefi"/>

==Comparison with the ISO 21500== 
Both the ISO 21500 and the PMBOK have chapters about Project Scope Management. While both being similar they are not the same, the PMBOK is considered a guide to project managers the ISO stands for International Organization for Standardization. There are some differences in the structure of Project Scope Management, for instance the Plan Scope Management process is not required as an isolated process in the ISO 21500. Another thing that is different is that the Define Scope process in the ISO 21500 includes what is known as the Collect Requirements process in the PMBOK. Both the PMBOK and the ISO 21500 have the Create Work Breakdown Structure process but then the ISO 21500 adds a process that is called Define Activities which is not in the PMBOK, that is because the ISO 21500 does not have the Validate Scope process which produces the Accepted Deliverables. Finally, both the PMBOK and ISO 21500 end with a process called Control Scope. <ref > Analysis of ISO 21500 and Its Comparison with PMBOK® Guide. (et. al). Retrieved 23. February 2018 from http://www.sybena.pl/iso21500PMBOK_ang.htm</ref>
==Conclusion== 
Clear communication between the project team and stakeholders is the key of an effective Project Scope Management. Both parties understand and agree on the project scope and how the project goals will be achieved. The project scope helps with the understanding of the requirements on what should be done. If a project does not have a project scope, there is no effective way of estimating the time or the cost of that project. If there must be any changes made on the project, it could upset the project schedule and affect the cost of the project. It is not hard to implement the Project Scope Management, therefore it could pay off to have a clear scope and a well-structured project resulting in a project with minimal overrun.
==Annotated Bibliography== 
 
'''Project Management Institute (2013). ''A Guide to the Project Management Body of Knowledge (PMBOK® guide) 5th edition''''': This book delivers a good understanding on the art of project scope management. 

'''Avantika Monnappa. (2017). ''Project Scope Management: What It is and Why It’s Important.'''''  An article that gives the basic understanding of Project Scope Management, it relies heavily on the PMBOK but it makes the topic more understandable for an outsider.

'''Analysis of ISO 21500 and Its Comparison with PMBOK® Guide. (et. al)'''  This article compares the ISO 21500 standard to the PMBOK. It shows visually the difference between the chapters an gives a brief explanation on the dissimilarities if there are any.

'''Getting Started with Work Breakdown Structures (WBS). (et. al)''' An article that explains in detail the purpose and how to construct the Work Breakdown Structure. It also gives a brief history of the topic and tips and trick on how to generate a good Work Breakdown Structure.

==References== 
 
<references/>