DISCUSSION QUESTION:
Why is it critical for the WBS to be as complete as possible?If you were explaining a WBS to someone new to project management, can you give an analogy or example to help clarify it’s importance?
PowerPoint Presentation MGT 680 Project Management SCOPE Donna W. McCloskey, Ph.D., PMP Knowledge Area: Project Scope Management What do you need to do? How will you know you did it? 4 Project Scope Management Plan scope management Collect requirements Define scope Create work breakdown structure (WBS) Validate scope Control scope Monitoring & Controlling Planning 1. Plan scope management How to…create/maintain/approve a WBS, obtain formal acceptance of deliverables, control requests for change How to…plan track and report requirements, prioritize requirements, use product metrics, trace requirements 5 Scope Management 5.1: Plan Scope Management Planning how scope will be managed throughout the life of the project Scope management plan How to…create/maintain/approve a WBS, obtain formal acceptance of deliverables, control requests for change It does NOT describe what is in or out of scope It is NOT the scope baseline or part of the scope baseline It IS a subset plan of the project management plan I swear, every time we try to play Risk my son changes the rules. Things I did before are suddenly not allowed. Hasbro printed pages and pages of rules and we really should take the time to read them. The game would be so much easier if we all knew the rules. Every knowledge area has a ‘Plan X Management’ process and I think of it as the ‘rules of the game’. It doesn’t actually cover the X for the project – just how X is going to be handled. Scope Management 5.2: Collect Requirements Determining, documenting and managing stakeholder wants, needs and expectations to meet project objectives What are requirements? Enterprise requirements What stakeholders will be able to do in the future with the project’s deliverables Project requirements Business, project management and delivery requirements Product requirements Technical, security and performance requirements Functional requirements specify what a product or service must do Non-functional requirements are the characteristics or qualities that product/service should have to do what it must do Kind of funny. Kind of true. SO many problems can be avoided if scope is clearly defined, controlled and communicated! How are requirements collected? Requirements need to quantifiable and documented Defining and managing customer wants, needs and expectations Sponsor, customer and other stakeholders Facilitated workshops / group session Interviews Observation Questionnaires Prototypes Business process diagramming Visual documentation of value added activities Use case scenarios Shows the interaction of individuals and business processes 10 Business Process Diagramming Wysocki, p. 71 A visual representation of business processes and information flows. Use Case Diagram Wysocki, p. 71 Shows user interactions with the system. A graphical representation of what the system must actually do. There is a need to document detailed requirements from the 3-4 participants Facilitated group session Interviews Observations Questionnaires Prototypes Business process diagramming Use case scenarios The appropriate technique to use to gather requirements depends on many factors. Let’s try some examples. More than one answer can be appropriate. There is a need to document detailed requirements from 30-40 participants Facilitated group session Interviews Observations Questionnaires Prototypes Business process diagramming Use case scenarios While the goal is known, the solution is less obvious. Idea generation will be a part of requirement documentation Facilitated group session Interviews Observations Questionnaires Prototypes Business process diagramming Use case scenarios Project implementation is cross functional and offers the possibility of process improvement. Facilitated group session Interviews Observations Questionnaires Prototypes Business process diagramming Use case scenarios Requirements Gathering StrengthsRisks Facilitated workshopsDetailed requirements can be documented and verified immediately with the help of an independent facilitator to resolve issues. High commitment for time and cost InterviewsCan result in high levels of participation and detailed requirementsWithout structure, stakeholders may not know what to provide. If done in isolation, lack a cross functional perspective QuestionnairesCan result in high levels of participation and detailed requirements and faster/cheaper than interviewsResponse rate is a concern and if done in isolation, lack a cross functional perspective ObservationCan result in specific and complete descriptions of actions. Effective when activities are difficult to describeHigh commitment for time and cost with potential privacy and bias implications 17 Requirements Gathering StrengthsRisks PrototypesClient-focused approach that offers clarification, proof of concept, innovation/idea generationPrototype ≠ product May be difficult to know when to stop. Lack of documentation Business process diagrammingVisual communication that is excellent for cross functional processesImplementation of improvement is dependent or organization being open to change. Can be time consuming Use case scenariosImproved client satisfaction and design since scenarios clearly identify state of the systemTime commitment is high and training may be necessary Requirements Traceability Matrix A table that links requirements to their origin and traces them throughout the project life cycle Links requirements to the deliverables that satisfy them Ensures requirements adds business value by linking it to the business and project objectives It can trace a variety of requirements Project objectives Project scope / WBS deliverables Product design and development Test strategy and scenarios Scope Management 5.3: Define Scope Detailed definition of the work required for the project The project scope statement defines: The project deliverables and the work required to create those deliverables The process that enables the creation of the WBS The process that specifies how formal verification and acceptance of the complete project deliverables will be obtained The process to control change requests to the scope statement Project Scope Statement (or Statement of Work –SOW) States what work is to be accomplished and what deliverables need to be produced Scope description Business value – leading metric What will be measured, when and how Product acceptance criteria Project deliverables Project exclusions Project constraints Project assumptions Responsibility Assignment Matrix (RAM) or RACI (responsible, accountable, consult, inform) chart clarifies who is involved in what parts of the project We’ll talk about this again in Resource Management. Sometimes a RAM or RACI chart is used at this point to start to define who has responsibility for which project parts. Scope Management 5.4: Create WBS The WBS is a deliverable oriented grouping of the work involved in a project A deliverable is a product produced as part of a project All of the work is broken down into discrete tasks and grouped into a logical hierarchy This is a foundation document that provides the basis for planning and managing project schedules, costs, resources and changes WBS in two words? ‘Project Outline’ What is the WBS? What is the schedule? In MS Project the WBS is used to create the schedule…and then the budget! Approaches to Developing WBS Guidelines Some organizations (ex/ DOD) prescribe the form and content of WBS for particular projects Analogy Approach Use similar project’s WBS as a starting point Top Down Approach Start with the largest items of the project and break them down into greater levels of detail Bottom-up Approach Team members identify as many tasks as possible and then organize them into summary activities Mind Mapping Uses radiating branches MindManager can export to MS Project Mind Mapping Mind Mapping software lets you graphically diagram a project. It can then be “read” in MS Project to form the WBS. In the ___ you use a similar project’s WBS as a starting point Top-down approach Bottom-up approach Mind-mapping approach Analogy approach Decomposition of the WBS should be done to what degree? The same level for all deliverables The greatest level possible Until the work can be assigned to a specific performing organizational unit Until the work can be assigned to an individual How much detail? Not too hot. Not too cold. Just right. 8/80 rule Tasks should be between 8 and 80 labor hours Reporting period No task should be longer than the distance between status reports If its easier …to estimate …to assign …to track DISCUSSION QUESTION: Why is it critical for the WBS to be as complete as possible? If you were explaining a WBS to someone new to project management, can you give an analogy or example to help clarify it’s importance? WBS Dictionary A companion to the WBS, it provides the content of the components Statement of work Responsible organization/person Resource requirements Estimated costs Which of the following is the correct definition of a WBS dictionary? It describes the technical terms used for scope management It describes the detail for each component in the WBS It translates essential WBS terms for global project teams It helps translate functional requirements into technical requirements All of the following are part of the scope baseline EXCEPT Scope management plan Project scope statement Work breakdown structure (WBS) WBS dictionary Project Scope Management Plan scope management Collect requirements Define scope Create work breakdown structure (WBS) Validate scope Control scope Monitoring & Controlling Planning YOU ARE HERE 1. Plan scope management How to…create/maintain/approve a WBS, obtain formal acceptance of deliverables, control requests for change How to…plan track and report requirements, prioritize requirements, use product metrics, trace requirements 37 Scope Management 5.5: Validate Scope Formalizing acceptance of the completed project deliverables Review deliverables with the customer or sponsor to ensure that they are completed satisfactorily and obtain formal acceptance of deliverables Related to quality control Relationship between scope and quality Control Quality Deliverable When you finish a piece of a project, the project team makes sure it meets the quality standards. Think of it as checking that you’ve met the rubric requirements before submitting an assignment Relationship between scope and quality Control Quality Validate Scope Deliverable Verified Deliverable Once the project team has “checked” the deliverable, it becomes a verified deliverable. At this point it is given to the customer/project sponsor to ensure it was completed satisfactorily Relationship between scope and quality Control Quality Validate Scope Deliverable Verified Deliverable Accepted Deliverable Once the customer/project sponsor gives their formal sign-off, it becomes an accepted deliverable How many multiple choice questions could we write about this process?!? Scope Management 5.6: Control Scope Monitoring the status of the project and product scope and managing changes to the scope baseline Variance analysis Used to assess the magnitude of variation from the original scope baseline Determine the cause and degree of variance to the scope baseline Decide whether corrective or preventative action is required You are managing a 6 month project and have held bi-weekly meetings with your project stakeholders. After 5.5 months of work, the project is on schedule and budget but the stakeholders are not satisfied with the deliverables. This situation will delay the project completion by one month. The MOST important process that could have prevented this situation is Monitor and control risks Control schedule Define scope Control scope PowerPoint Presentation There is a need to document detailed requirements from the 3-4 participants Facilitated group session Interviews Observations Questionnaires Prototypes Business process diagramming Use case scenarios It’s more feasible to use these techniques with smaller groups. There is a need to document detailed requirements from 30-40 participants Facilitated group session Interviews Observations Questionnaires Prototypes Business process diagramming Use case scenarios There isn’t a magic number but at some point the number of participants is too large for interviews and observations. Questionnaires allow you to get input from a larger number of people. While the goal is known, the solution is less obvious. Idea generation will be a part of requirement documentation Facilitated group session Interviews Observations