Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Project Management Project Scope Management Knowledge Areas Software Project Management 2 What is Project Scope Management? • Scope refers to all the work involved in creating the products of the project and the processes used to create them • A deliverable is a product produced as part of a project, such as hardware or software, planning documents, or meeting minutes • Project scope management includes the processes involved in defining and controlling what is or is not included in a project Software Project 3 Management Knowledge Area Processes Project Management Integration Project Management Process Groups Initiating Process Group Planning Process Group Executing Process Group Monitoring and Controlling Process Group Closing Process Group - Develop Project Charter - Develop Preliminary Project Scope Statement - Develop Project Management Plan - Direct and Manage Project Execution - Monitor and Control Project Work - Integrated Change Control - Close Project Project Scope Management - Scope Planning - Scope Definition - Scope WBS - Scope Verification - Scope Control Project Time Management - Activity Definition - Activity Sequencing - Activity Resource Estimating - Activity Duration Estimation - Schedule Development - Schedule Control Project Cost Management - Cost Estimating - Cost Budgeting - Cost Control Project Quality Management - Quality Planning - Perform Quality Assurance - Perform Quality Control Project Human Resources Management - Human Resources Planning - Acquire Project Team - Develop Project Team - Manage Project Team Project Communication Management - Communications Planning - Information Distribution - Performance Reporting - Manage Stakeholders Project Procurement Planning - Plan Purchase and Acquisitions - Plan Contracting - Request Seller Responses - Select Sellers - Contract Administration Project Risk Management - Risk Management Planning - Risk Identification - Qualitative Risk Analysis - Quantitative Risk Analysis - Risk Response Planning Software Project Management - Contract Closure - Risk Monitoring and Control 4 Project Scope Management Processes • • • • • Scope planning: deciding how the scope will be defined, verified, and controlled Scope definition: reviewing the project charter and preliminary scope statement and adding more information as requirements are developed and change requests are approved Creating the WBS: subdividing the major project deliverables into smaller, more manageable components Scope verification: formalizing acceptance of the project scope Scope control: controlling changes to project scope Software Project 5 Management Project Scope Management Summary Software Project 6 Management The Scope Management Plan • The scope management plan is a document that includes descriptions of how the team will prepare the project scope statement, create the WBS, verify completion of the project deliverables, and control requests for changes to the project scope • Key inputs include the project charter, preliminary scope statement, and project management plan Software Project 7 Management Sample Scope Management Plan Software Project Management 8 The Project Scope Statement • The preliminary scope statement, project charter, organizational process assets, and approved change requests provide a basis for creating the project scope statement • As time progresses, the scope of a project should become more clear and specific • It is one of the main inputs for creating a Work Breakdown Structure (WBS) Software Project 9 Management Project Scope Statement Content • description of the project • detailed descriptions of project deliverables • characteristics of products and services produced as part of the project • project success criteria and acceptance criteria • constrains and assumptions • defined risks • milestones • raw cost estimate • configuration management requirements, etc Software Project Management 10 The Work Breakdown Structure (WBS) • A WBS is a deliverable-oriented grouping of the work involved in a project that defines the total scope of the project • Decomposition is subdividing project deliverables into smaller pieces based on product characteristics OR project phases. • A work package is a task at the lowest level of the WBS Software Project 11 Management WBS – Basis of Many Things • • • • • • Network scheduling Costing Risk analysis Organizational structure Control Measurement Software Project Management 12 WBS • Hierarchical list of project’s work activities • 2 Formats – Outline (Indented format) – Graphical Tree (Organizational chart) • Uses a decimal numbering system – Ex: 3.1.5 – 0 is typically top level • Includes – Development, mgmt., and project support tasks • Shows “is contained in” relationships • Does not show dependencies or durations Software Project Management 13 WBS • List of Activities • List of items can come from many sources – SOW, proposal, brainstorming, stakeholders, team • Describe activities using “bullet language” – Meaningful but terse labels • All WBS paths do not have to go to the same level • Do not plan more detail than you can manage • WBS items trace back to scope statement items Software Project Management 14 The WBS Dictionary and Scope Baseline • Many WBS tasks are vague and must be explained more so people know what to do and can estimate how long it will take and what it will cost to do the work • A WBS dictionary is a document that describes detailed information about each WBS item • The approved project scope statement and its WBS and WBS dictionary form the scope baseline, which is used to measure performance in meeting project scope goals Software Project 15 Management Project Elements • A Project: functions, activities, tasks Software Project Management 16 WBS Chart Example Software Project Management 17 WBS Outline Example 0.0 Retail Web Site 1.0 Project Management 2.0 Requirements Gathering 3.0 Analysis & Design 4.0 Site Software Development 4.1 HTML Design and Creation 4.2 Backend Software 4.2.1 Database Implementation 4.2.2 Middleware Development 4.2.3 Security Subsystems 4.2.4 Catalog Engine 4.2.5 Transaction Processing 4.3 Graphics and Interface 4.4 Content Creation 5.0 Testing and Production Software Project Management 18 Partitioning Your Project • You need to decompose your project into manageable chunks • ALL projects need this step • Divide & Conquer • Two main causes of project failure – Forgetting something critical – Ballpark estimates become targets • How does partitioning help this? Software Project Management 19 WBS • Contract WBS (CWBS) – First 2 or 3 levels – High-level tracking • Project WBS (PWBS) – Defined by PM and team members – Tasks tied to deliverables – Lowest level tracking Software Project Management 20 A Full WBS Structure • Up to six levels (3-6 usually) such as • Upper 3 can be used by customer for reporting (if part of RFP/RFQ) • Different levels can be applied to different uses • Ex: Level 1: authorizations; 2: budgets; 3: schedules Software Project Management 21 WBS Types • Process WBS • a.k.a. Activity-oriented • Ex: Requirements, Analysis, Design, Testing • Typically used by PM • Product WBS • a.k.a. Entity-oriented • Ex: Development of the financial engine, Building the interface system, Creating the DB • Typically used by engineering manager • Hybrid WBS: both above • This is not unusual • Ex: Lifecycle phases at high level with component or featurespecifics within phases • Rationale: processes produce products Software Project Management 22 Product WBS Software Project Management 23 Process WBS Software Project Management 24 Outline WBS w/Gantt Software Project Management 25 WBS by PMI Process Groups Software Project Management 26 WBS Types • Less frequently used alternatives – Organizational WBS • Research, Product Design, Engineering, Operations • Can be useful for highly cross-functional projects – Geographical WBS • Can be useful with distributed teams • NYC team, San Jose team, Off-shore team Software Project Management 27 Work Packages • Generic term for discrete tasks with definable end results • Typically the “leaves” of the tree • The “one-to-two” rule • Often at: 1 or 2 persons for 1 or 2 weeks • Basis for monitoring and reporting progress • Can be tied to budget items (charge numbers) • Resources (personnel) assigned • Ideally shorter rather than longer • • • • • Longer makes in-progress estimates needed These are more subjective than “done” 2-3 weeks maximum for software projects 1 day minimum (occasionally a half day) Not so small as to micro-manage Software Project Management 28 WBS & Methodology • PM must map activities to the chosen lifecycle • Each lifecycle has different sets of activities • Integral process activities occur for all methodologies: planning, configuration, testing, etc • Operations and maintenance phases are not normally in plan (considered post-project) • Some models are “straightened” for WBS: – Spiral and other iterative models – Linear sequence several times • Deliverables of tasks vary by methodology Software Project Management 29 WBS Techniques • • • • Top-Down Bottom-Up Analogy Rolling Wave – 1st pass: go 1-3 levels deep – Gather more requirements or data – Add more detail later • Post-its on a wall Software Project Management 30 WBS Techniques • Top-down – Start at highest level – Systematically develop increasing level of detail – Best if • The problem is well understood • Technology and methodology are not new • This is similar to an earlier project or problem – But is also applied in majority of situations Software Project Management 31 WBS Techniques • Bottom-up – Start at lowest level tasks – Aggregate into summaries and higher levels – Cons • Time consuming • Needs more requirements complete – Pros • Detailed Software Project Management 32 WBS Techniques • Analogy – Base WBS upon that of a “similar” project – Use a template – Analogy also can be estimation basis – Pros • Based on past actual experience – Cons • Needs comparable project Software Project Management 33 WBS Techniques • Brainstorming – Generate all activities you can think of that need to be done – Group them into categories • Both Top-down and Brainstorming can be used on the same WBS Software Project Management 34 WBS Guidelines Part 1 • Should be easy to understand • Some companies have corporate standards for these schemes • Some top-level items, like Project Mgmt. are in WBS for each project; others vary by project • Break down until you can generate accurate time & cost estimates • Ensure each element corresponds to a deliverable Software Project Management 35 WBS Guidelines Part 2 • How detailed should it be? – Not as detailed as the final MS-Project plan – Each level should have no more than 7 items – It can evolve over time • What tool should you use? – Excel, Word, MS Project – Org chart diagramming tool (Visio, etc) – Specialized commercial apps • Re-use a “template” if you have one Software Project Management 36 Advice for Creating a WBS and WBS Dictionary* • A unit of work should appear at only one place in the WBS • The work content of a WBS item is the sum of the WBS items below it • A WBS item is the responsibility of only one individual, even though many people may be working on it • The WBS must be consistent with the way in which work is actually going to be performed; it should serve the project team first, and other purposes only if practical *Cleland, David I. Project Management: Strategic Design and Implementation, 1994 Software Project 37 Management Advice for Creating a WBS and WBS Dictionary (continued)* • Project team members should be involved in developing the WBS to ensure consistency • Each WBS item must be documented in a WBS dictionary to ensure accurate understanding of the scope of work included and not included in that item • The WBS must be a flexible tool to accommodate inevitable changes while properly maintaining control of the work content in the project according to the scope statement *Cleland, David I. Project Management: Strategic Design and Implementation, 1994 Software Project 38 Management Scope Verification • It is quite difficult to create a good scope statement and WBS for a project • It is even more difficult to verify project scope and minimize scope changes • Scope verification involves formal acceptance of the completed project scope by the stakeholders • Acceptance is often achieved by a customer inspection and then sign-off on key deliverables Software Project 39 Management Scope Control • Scope control involves controlling changes to the project scope • Part of the overall integrated change control (see PIM) • Goals of the scope control are to: – Influence the factors that cause scope changes – Ensure changes are processed according to procedures developed as part of integrated change control – Manage changes when they occur • Variance is the difference between planned and actual performance Software Project 40 Management Best Practices for Avoiding Scope Problems 1. Keep the scope realistic: Don’t make projects so large that they can’t be completed; break large projects down into a series of smaller ones 2. Involve users in project scope management: Assign key users to the project team and give them ownership of requirements definition and scope verification 3. Use off-the-shelf hardware and software whenever possible: Many IT people enjoy using the latest and greatest technology, but business needs, not technology trends, must take priority 4. Follow good project management processes: there are welldefined processes for managing project scope and others aspects of projects Software Project Management 41 Suggestions for Improving User Input • Develop a good project selection process and insist that sponsors are from the user organization • Have users on the project team in important roles • Have regular meetings with defined agendas, and have users sign off on key deliverables presented at meetings • Deliver something to users and sponsors on a regular basis • Don’t promise to deliver when you know you can’t • Co-locate users with developers Software Project Management 42 Suggestions for Reducing Incomplete and Changing Requirements • Develop and follow a requirements management process • Use techniques such as prototyping, use case modeling to get more user involvement • Put requirements in writing and keep them current • Create a requirements management database for documenting and controlling requirements Software Project Management 43 Suggestions for Reducing Incomplete and Changing Requirements (continued) • Provide adequate testing and conduct testing throughout the project life cycle • Review changes from a systems perspective • Emphasize completion dates to help focus on what’s most important • Allocate resources specifically for handling change requests/enhancements Software Project Management 44