Recall The Team SkillsTeam Skill 4: Managing scopeChapter 18 Establishing Project ScopeThe Problem of Project ScopeSlide 5Slide 6Slide 7The Hard QuestionSolution: Managing scopeThe Requirements BaselineSetting PrioritiesAssessing Required EffortAdding the Risk ElementExample: Prioritized Features List with Effort and Risk EstimatesReducing ScopeExample: Final Prioritized Features ListMaking the cutReading AssignmentKey PointsRecall The Team Skills1. Analyzing the Problem (with 5 steps)2. Understanding User and Stakeholder Needs3. Defining the System•A Use Case Primer•Organizing Requirements Information•The Vision Document4. Managing Scope5. Refining the System Definition6. Building the Right SystemTeam Skill 4: Managing scopeCh 18: Establishing project scopeCh 19: Managing your customerChapter 18Establishing Project Scope • Project scope problem• The Requirements Baseline• Setting Priorities• Assessing Effort• Adding the Risk Element• Reducing ScopeThe Problem of Project ScopeProject scope (complexity) depends on:•The functionality that has to meet the user's needs•The resources available to the project•The time available for the implementationProject scope derives from the following elements.•Resources consisting of the labor: developers, testers, tech writers, quality assurance personnel, and others.•Time is perhaps a "soft" boundary that is subject to change if the available resources are inadequate to achieve the desired functionality.The Problem of Project ScopeIf the effort required to implement the system features is equal to the resources available during the scheduled time, the project has an achievable scope, and we have no problem. But what if not ...?The Problem of Project ScopeWhat happens when a project proceeds with a 200% initial scope? If the intended features of the application were completely independent, which is unlikely, only half of them will be working when the deadline passes.If some of the application features do depend on others, at deadline time nothing useful will work.The Problem of Project ScopeWhat happens to software quality during either of these outcomes? The code, which is rushed to completion near the end, is poorly designed and bug-ridden; testing is reduced to an absolute minimum or skipped entirely; and documentation and help systems are eliminated.The Hard QuestionThe hard question: How does one manage to reduce scope and keep the customers happy? Brooks' law states that adding labor to a late software project makes it even later. We need another way to solve the scope problemSolution: If we truly begin the development effort with an expectation of 200% scope, it will be necessary to reduce the project scope by as much as a factor of two in order to have any chance of success. ... But how?Solution: Managing scopeFeature 1Feature 2 to be implementedFeature 3..-------------- Requirement baseline ------------...Feature 4Feature 5 to be postponed for futureFeature 6The Requirements BaselineThe requirements baseline is the itemized set of features intended to be delivered in a specific version of the application.The baseline must …•Be at least "acceptable" to the customer•Have a reasonable probability of success, in the team's viewHow do we define it?Setting PrioritiesDuring prioritization, it is important that the customers and users, product managers, or other representatives — not the development team — set the initial priorities.Assessing Required Effort The next step is to establish the rough level of effort implied by each feature of the proposed baseline. The best we can do is to determine a "rough order of magnitude" (High, Medium, Low) of the level of required effort for each feature. Why?•Little useful information is available yet on which to estimate the work•No detailed requirements or design output on which to base an estimate.Adding the Risk ElementThe Risk associated with each feature is the probability that the implementation of a feature will cause an adverse impact on the schedule and/or the budget. A high-risk feature has the potential to impact the project negatively, even if all other features can be accomplished within the allotted time. The development team establishes risk based on any heuristic it is comfortable with, using the same low-medium-high scale used to assess effortExample: Prioritized Features List with Effort and Risk EstimatesReducing ScopeScope Prioritization TechniquesExample: Final Prioritized Features List Features below the baseline are now future features and will be considered in later releases.Making the cutIs it enough to do all critical features?Can we include some important ones?Are there any dependent features?Useful usually can be cut out.Many possible future cuts. Cuts can be changed as project progress.Reading AssignmentRead the scope management for HOLIS in pages 218-222.Key PointsProject scope is a combination of product functionality, project resources, and available time.Brooks' law states that adding labor to a late software project makes it even later.If the effort required to implement the system features is equal to the resources available during the scheduled time, the project has an achievable scope.Over scoped projects are typical. In many projects, it will be necessary to reduce the scope by as much as a factor of two.The first step in establishing project scope is to establish a high-level requirements