Factors Affecting Project Scope • The functionality that must be delivered to meet the user’s needs • The resources available to the project • The time available in which to achieve the implementation
Project Scope Resources Scope Time Deadline
Resources • Labor from developers, testers, tech writers, quality assurance personnel, etc. • Adding resources to a late software project may make it later. • At the very least adding resources causes a decrease in productivity. • We will assume resources are fixed for the purposes of scope analysis.
Time/Deadlines • This may be a “soft” boundary. • History shows that delivering software late is the norm. • However, some projects have firm deadlines. • We will assume time is fixed for the purposes of scope analysis.
Scoping Facts • If the effort required to implement the system features is equal to the resources available during the scheduled time, the project has a achievable scope. • Typically projects begin with scopes that approach 200% of what is doable with available resources and time.
Problems with 200% Scoping • At most half the features will be implemented by the deadline. • If application features are highly interdependent, nothing may work. • If QA steps are skipped to meet the deadline, the quality of the product suffers. • Customers are unhappy. • The development team is frustrated and demotivated.
The Hard Question • It may be necessary to reduce the scope by as much as a factor of two. • How does one manage to reduce scope and keep the customers happy?
The Requirements Baseline • The 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 view
Creating a Requirements Baseline • We want to manage the scope before significant efforts are made in requirements refinement, design, coding, testing, or other project activities. • List the features that have been defined for the application at a level of detail that is not too detailed (no more that 25-30 features should be identified for any application).
Creating a Requirements Baseline (Cont’d) • Set priorities for the identified features. (Stakeholders must drive the setting of priorities.) • Assess the effort required for each feature. (Although difficult at this early stage of the project, “rough order of magnitude” level of effort must be estimated for each feature.)
Creating a Requirements Baseline (Cont’d) • Estimate the “risk” associated with each feature. • Use priority, effort, and risk to reduce the scope of the project. • Establish the baseline by including as many features, in priority order, as can be accomplished within the available resources.