1 Team Skill 4 Managing the scope Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and Information Technology Based on “Software Requirements Management, A use case approach”, by Leffingwell and Widrig

2 Establishing Project Scope

3 Key Points  Project 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 baseline.

4 The Problem of Project Scope  Project scope is a function of:  The functionality that must be delivered to meet the user's needs  The resources available to the project  The time available to achieve the implementation

5 The Problem of Project Scope  Resources represent the labor from developers, testers, tech writers, quality assurance personnel, and others  Time, a "soft" boundary that is subject to change if the available resources are inadequate to achieve the desired functionality.

6 Requirements baseline  The Requirements Baseline: A primary technique in scope management consists in establishing a high-level requirements baseline for the project  The baseline is “ the set of features intended to be delivered in a specific version of the application ”.

7 Requirements baseline

8  The baseline must be agreed on by both the customer and the development team: Be at least "acceptable" to the customer Have a reasonable probability of success, in the team's view

9 Setting Priorities  Establishing the relative priorities for the feature set is integral to scope management.  For prioritization: the customers and users, product managers, or other representatives (not the development team) set the initial priorities!  Technical input will come at later phases of the prioritization process.  Basically: If we could do all the work, the prioritization would be unnecessary. If we can't do all the work, we will prioritize …

10 Assessing Effort  We still haven't figured out how much work we can do  we do not yet know where to draw the baseline for the project.

11 Assessing Effort  We need to have a rough estimation of the effort required (we can use for example the FP estimation method … even we have nave not yet enough information about the project)

12 Adding the Risk Element Risk is the probability that the implementation of a feature will cause an adverse impact on the schedule and/or the budget (using any heuristic the team is comfortable with )

13 Adding the Risk Element There is often little correlation between priority and effort or between priority and risk.

14 Reducing Scope

15 Reducing Scope  A First Reasonable Estimate

16 Managing customer and scope

17 Key Points  Managing your customers means engaging them in managing their requirements and their project scope.  Customers who are part of the process will own the result.  Getting the job done right means providing enough functionality at the right time to meet the customers' real needs.  Negotiating skills are an invaluable aid to the scope management challenge.

18 Engaging Customers to Manage Their Project Scope  Reducing project scope has the potential to create a difficult relationship between the project team and the customers  We should actively engage our customers in managing their requirements and their project scope to ensure their satisfaction.

19 Engaging Customers to Manage Their Project Scope  Project team are the humble technological servants of the customers … It is the project of customers!  Delivering a high-quality and, if necessary, scope- reduced application—on time and on budget—is the highest overall benefit the team can provide.  We need customers' input to make the key decisions, and only the customers can really determine how to manage scope and achieve a useful deliverable.

20 Communicating the Result  If the project scope must be reduced, make sure that the customer is a direct participant.  A customer who is part of the process will own the result …  A customer who is excluded from the process will be unhappy with the result and will naturally tend to blame the developers for not trying hard enough.  Engaging the customer in this dialogue helps to address the problems of scope management in a better way.

21 Negotiating with the Customer  Start high but not unreasonable.  Separate the people from the problem.  Focus on interests, not positions.  Invent options for mutual gain.  Apply objective criteria. The guiding principle for scope management: under-promise and over-deliver.

22 Managing the Baseline  Successful development managers create margins for error in estimating effort and allow for time to incorporate legitimate changes during the development cycle.  These managers also resist feature creep, which can increase scope by as much as 50 percent to 100 percent after the start of a project.

23 Managing the Baseline  Change Management Official Changes “ Any change to the baseline must affect the resources, the schedule, or the features set to be delivered in the release” Unofficial Changes - More difficult to manage - Impact can be important

24 Summary  Managing the scope of an application is one of the important challenges faced by every application development team.  Doing so effectively requires reasonable estimating ability, negotiating skills, and some political abilities — three skills that are often rare in technical people!