5.1 Plan Scope Management

In this process the Scope Management Plan is created. It documents the projects scope how it is defined , validated and controlled.  The Plan Scope Management process spells out the directions on how scope management will take place through the project including identifying needs, and developing a work breakdown structure. Other process that affect the scope management process listed on this page are:

• 5.2 Collect Requirements
• 5.3 Define Scope
• 5.4 Create WBS

Figure 5 below illustrates the inputs, tools and techniques and output for this process.

Figure 5. 5.1 Plan Scope Management: Inputs, Tools & Techniques, and Outputs . Reprinted from "A Guide to the Project Management Body of Knowledge (PMBOK Guide), 5th Edition" by Project Management Institute, 2013, p.107. Copyright 2013 by Project Management Institute, Inc. Reprinted without permission.

Process Definition

The Plan Scope Management Process helps keep the project on task.  As projects develop often thing come up that may improve the output of the project.  This processes defines the requirements, overall project scope and work to be accomplished.  Within this process we have the following sub-processes:

• Collecting Requirements
• Defining the Scope
• Create WBS (Work Breakdown Structure)

Process Assessment

Before you begin a project you need to know where you want end up.  The Plan Scope Management Process helps to definitively identify that end result.  In away setting the target for the project manager to aim for. Part of the overall confusion with this process is that you must develop the components in conjunction with the Plan Scope Management Process.  for example you have to define the scope before you can plan the management of it.  The scope is defined as part of the Project Management Plan within the Scope Management Plan when you complete the Define Scope output of a Project Scope Statement.   

Artifacts 

Inputs

 The Project Scope Statement is an agreed upon document that exists as part of the project Scope Management Plan within the Project management plan.  It must be coordinated and agreed upon by the project team and the project initiator or customer.  below is a Project Scope Statement used in one of my courses. see 5.1.1

Tools & Techniques

Meeting are critical as a tool to discuss the requirements for the project.  Meetings can be productive and must be documented for future reference to develop an archive of verbal agreements and statements.  meeting minutes also become part of the final project archive.  see 5.1.2

 Outputs

Requirements Management Plan identifies how project requirements will be evaluated, documented, scheduled and controlled.  Often requirements will have a prerequisite requirement, some maybe accomplished simultaneously.  The order of execution becomes part of the requirement management plan.  Below See the Requirement Management Plan essay. see 5.1.3

5.2 Collect Requirements

In the collecting requirements process the project requirements are identified and documented based upon stakeholder needs and costumer requirements.  The project charter and stakeholder register are two sources for gathering information.  The stakeholder management, scope management and requirements management plans are also input based upon the iterativity of these processes.  Table 6 illustrates the components of this process.

Figure 6. Collect Requirements: Inputs, Tools & Techniques, and Outputs . Reprinted from "A Guide to the Project Management Body of Knowledge (PMBOK Guide), 5th Edition" by Project Management Institute, 2013, p.111. Copyright 2013 by Project Management Institute, Inc. Reprinted without permission.

Process Definition

To collect project requirements a project Manager use the project charter, statements of work, requirement plan interviews with subject matter experts, brainstorming Group discussion, surveys, product analysis, similar products etc. to obtain as many of the requirements as needed to meet project objectives.  Stakeholder management can also be a key element of the this process to ensure that inputs are from appropriate sources.  As the project documentation proceeds this process is revised based on inputs and changes to the Scope, Work requirements, and evaluation process.  Collecting requirement should not exceed the project scope without appropriate coordination.      

Process Assessment

There are several types of requirements to be collected; 

• Business: define high-level organizational needs like objectives and opportunities which establish the reasons for the project.
• Stakeholder: things need from each stakeholder, i.e.  forecasting requirements, inspection certification etc.
• Solution: define the characteristic of a project or project item, service or product it is also broken down into two other requirements 
  • Functional: how a product reacts, this includes processes, data, and interactions with other products or processes with in the completed project.
  • Nonfunctional: identifies environmental issues such as safety factors, performance levels, ecological considerations and reliability etc.
• Transition: temporary requirements such as training, conversions, or transitions to meet project expectations
• Project: actions, processes, products or other consideration that must be met and directly affect the project outcome
• Quality: conditions or criteria which confirm the successful completion of the project deliverable or requirement.  

Collection of requirements goes hand in had with establishing the project scope.  It sets the criteria for how much effort is put into each portion of the project to meet the requirements.  

Artifacts 

Inputs

The project charter can identify many of the project requirements. As a class each group assignment was part of a class project for one specific assignment we were establish a charter based upon the stakeholder or team member needs for the project.  It was unique in that it wasn't typical of a normal project charter but fulfilled the needs of developing team requirements and reporting for the group assignments.  see 5.2.1

Tools & Techniques

One of the tools for the Collect Requirements process is a focus group.  Focus group's are a informal network which allow for more free flowing discussion.  Often the best result for creativity are these type of focus groups they allow a more comfortable an honest flow of information without fear of managerial reprisal.  In our learning we discussed the benefits of informal networks in PMGT672.  see 5.2.2

Outputs

 A requirement document that may be used, and even better reused, in project management is a requirements template.  There are several examples, all unique to the requirements of the project team or manager.  We developed a simple requirement template in PMGT614.  See 5.2.3

5.3 Define Scope

The Define Scope process is where the details, parameters and limitations of the product or services provided by the project are set.  This can be based on time, quality and quantity.  Because the project requirements are often still in the finding phase this process deals with the final product not the particulars.  See figure 7 for the Inputs, Tools & Techniques, and Outputs for this process. 

Figure 7. Define Scope: Inputs, Tools & Techniques, and Outputs . Reprinted from "A Guide to the Project Management Body of Knowledge (PMBOK Guide), 5th Edition" by Project Management Institute, 2013, p.120. Copyright 2013 by Project Management Institute, Inc. Reprinted without permission.

Process Definition

The Define Scope process like much of the other scope management processes is iterative.  Initially a high level vision of the project is provided by the project originators but, as the Define Scope process continues the scope becomes better defined and more specific.  As more requirements are identified the scope may be redefined, broadened or lessened based upon the mission needs and strength, weakness, opportunities, threats inherent in the project. 

Process Assessment

Each iterative cycle brings the overall scope to focus. risks, assumptions and constraints are evaluated for accuracy and updated during the process.  Planning for the next version or iteration of the project scope continues as the current iteration of the scope and deliverables is being conducted. At this point all available input documents are used.  Judgement, analysis, alternative generation and facilitated workshops provide the means for developing the project scope statement as well as updates to the original input documents.   

Artifacts

Input

Organizational Process Assets are categorized into one of two categories: processes and procedures and corporate knowledge base.  These include such things as standards and policies, guidelines, control procedures, templates, registers, schedules, work breakdown structures, etc. Most anything that has been used in previous projects becomes an asset and can be used in future projects.  This may prevent the project team from reinventing the wheel.  see 5.3.1

Tools & Techniques

Part of the scope definition includes analyzing the project schedule, statements of work and the critical path.  Prioritizing and schedule steps to more effectively utilize assets reducing cost and making the project more efficient. This will in turn facilitate the development of a more realistic Work Break Down Structure.  In PMGT614 we used these tools to create a compression schedule to reduce our project by 162 hours.  A narrative of our final analysis can be found in this artifact.  see 5.3.2

Outputs

Combining the inputs and using the tools and techniques to develop the over all project scope you end up with some iteration of that scope, whether it is the initial or one of the many updates. The output of the Define Scope Process is the Project Scope statement or updates to project documents.  see 5.3.3

5.4 Create WBS

This step divides the projects requirements into workable steps making each deliverable more manageable.  You've heard the joke, How do you eat an elephant?  One bite at a time.  The Create WBS process identifies those bites, priorities and puts them into a logical order to compete the project. It provides a road map for completing deliverables and the project as a whole. Figure 8 illustrates the Inputs, tools & techniques and outputs for this process.

Figure 8. Create WBS: Inputs, Tools & Techniques, and Outputs . Reprinted from "A Guide to the Project Management Body of Knowledge (PMBOK Guide), 5th Edition" by Project Management Institute, 2013, p.125. Copyright 2013 by Project Management Institute, Inc. Reprinted without permission.

Process Definition

The work breakdown structure or WBS is a hierarchal breakdown of the work to be accomplished to complete the project from start to finish.  It includes project initiation through closeout. The WBS represent project all the work contained in the most current iteration of the project scope statement.   

Process Assessment

Breaking the work down into its lowest levels called work packages allows the project manger to schedule, monitor and control the project progression.  WBSs help to build an accurate estimate of the project timeline and evaluate if a project will meet its deadlines or not based on scheduled milestones.  Completed work or the result of the work is referred to as deliverables. Tracking the completed deliverables based on the timetable establish in the WBS creates a value based analysis to monitor the overall projects progress.       

Artifacts

Input

The scope statement and management plans provide the initial starting point for developing a complex WBS.  It provides major deliverables, timeline and overall initial cost estimates or goals.  Constraints may also be addressed.  The scope statement below was developed for an IT project during PMGT 611. see 5.4.1

Tools & Techniques

One of the first WBS exercise we did was to decompose a camera build.  This simple project best illustrates the complexity of this step.  Having very little experience with cameras you can see my decomposition is crude and I require some help from others with more knowledge of the subject.  For this decomposition requires expert judgement from and outside source as well. see 5.4.2

Outputs

The project scope baseline is an agreed upon statement which includes the Project Scope Statement, WBS and The WBS Dictionary.  Because this is an agreement it can only be changed through formal changes processes that requires all signatories to be part of.  We have discussed the Scope statement and WBS Below is attacked an example of a WBS dictionary.  Initially this may only have the work component but as the project plan develops. resources, costs and time schedules are added as you can see in this one. see 5.4.3