GPO_VIP#09-11 Scope

GPO_VIP#09-11 Scope

1. The Scope Management Plan

   • Describes how you write down the scope, make sure it’s right, and keep it up to date.
   • The six Scope Management processes
     • Control Scope
       • We already know how important it is to control changes on your project. When scope changes aren’t controlled, it leads to the most frustrating sort of project problems. Luckily, you already know about change control, and now you can use it to manage your project’s scope.
         • Change requests
     • Define Scope
       • Here’s where you write down a detailed description of the work you’ll do and what you’ll produce. When you do this right, the stakeholders are never unpredictable because you already understand their needs.
         • Project scope statement
     • Plan Scope Management
       • Here’s where you write down the subsidiary plan for the project management plan that we talked about in the last chapter. You plan out all of the work you’ll do to define your scope, make sure the team is planning to do the right work, and control it.
         • Project Management plan
         • INPUTS
           • Project charter
           • Organizational process assets
           • Enterprise environmental factors
           • Project Management plan
         • OUTPUTS
           • Requirements Management plan
           • Scope Management plan
       • The Plan Scope Management process helps you think through everything you’ll need to do to keep your project focused on the right work from beginning to end.
     • Collect Requirements
       • In this process, you find out all of the stakeholders’ needs and write them down so that you know what to build and your requirements can be measured and tracked.
         • Requirements documentation
         • INPUTS
           • Stakeholder Management Plan
           • Requirements Management Plan
           • Stakeholder Register
           • Scope Management Plan
           • Project charter
         • OUTPUTS
           • Requirements Traceability Matrix
           • Requirements Document
             • Functional requirements
               • Are most of the kinds of things that you think of right away: new features, bug fixes, and new or different behavior.
             • Non-Functional requirements
               • Sometimes called quality attributes because they’re things that you expect from your deliverables, but aren’t specific features. Some examples of nonfunctional requirements are performance, reliability, error handling, and ease of use.
     • Create WBS
       • The work breakdown structure (WBS) organizes all of your team’s work into work packages—or discrete pieces of work that team members do—so that you can keep the momentum of the project going from the start.
         • Work breakdown structure
     • Validate Scope
       • Once the work is complete, you need to make sure that what you’re delivering matches what you wrote down in the project scope statement. That way, the team never delivers the wrong product to the customer.
         • Accepted deliverables

2. PROJECT SCOPE

   • All of the work that needs to be done to make the product.

3. PRODUCT SCOPE

   • The features and functions of the product or service that you and your team are building.