Establishing Project Scope 1

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 2

Project Scope Resources Time Deadline Scope 3

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. 4

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. 5

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. 6

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. 7

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? 8

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 9

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 features should be identified for any application). 10

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.) 11

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. 12

Scope Prioritization Techniques AttributesConsider Priority: Critical Effort: High Risk: High Alarm! Establish immediate risk-mitigation strategy; resource immediately; focus on feasibility with architecture. Priority: Critical Effort: High Risk: Low A likely critical resource-constrained item; resource immediately. Priority: Critical Effort: Low Risk: Low Resource as a safety factor, or defer until later 13