Software project management: managing scope

From March to May 2016, we are teaching the course Software Project Management at the Free University of Amsterdam. Each week we treat one aspect of project management, and last week we discussed project scope management. Managing project scope is crucial for project success, but unfortunately it is often neglected or undermanaged. In this article we explain why and how scope should be defined and managed.

This article is part of a series that accompanies the university course on software project management by Joost Schalken, Jeroen Arnoldus and Sieuwert van Otterloo. The series consists of  (1) creating a vision, (2) project scope, (3) managing non-fuctional requirements, (4) effort estimation, (5) risk management, (6) planning and scheduling, (7) organisational change,  and (8) recommended project management books and articles.

Why scope should be defined and managed

The official definition of a project that we use is ‘a temporary endeavor to create a unique product or service’. As the name suggests, the result of a project has three aspects: the time needed to create it, the effort/costs that go into the endeavor, and the ‘product’ that is created. In order to measure whether a project is on track, one needs to define these three aspects: budget, time and ‘scope’. ‘Scope’ is the definition of the end product.

To define scope, consider the painting of a fence as a very simple project. The scope should define where the part of the fence that should be paint starts, where it ends, and whether one should only paint the outside or also the inside, or even underside. If the fence has one.

The reason that scope is often under-managed is that it is harder to define than time and budget. We use the word features to describe the items that can be in scope or out scope. For many buyers and users for software these features are abstract and hard to understand before they are realized. Some projects therefore fail to completely define the scope: they only mention keywords or high level business goals. This is fine in the beginning, but is problematic during testing as this can lead to conflicts whether the team has delivered as promised: an argument will arise whether certain items were part of the project scope or not.

Scope is often informally defined: in terms of high level business goals or certain. Suppose a project is time-constrained and is struggling to deliver on time. It is important to know for the software development team to know what features are in scope and which are out scope, so that they only build features that are actually needed.

How to define software project scope

There are multiple ways to define project scope. Which one works best depends on the type of project. The format must be precise enough so that it can be used during testing, but simple enough to understand for the buyers and users of the system. In some very technical IT projects, such as building a technical interface between two existing IT systems, a technical design document could be used as scope. This situation should however be avoided: such a document is not readable for non-IT people, so as a communication device to the users of the software it does not really work.

In other projects it is possible to use screen designs as a definition of scope. The team and users of the software agree on which screens will be delivered, and it is clear from the design what buttons and other functions each screen contains. For many website-like projects this is a very simple and good way to define scope. The disadvantage of this method however is that it not only defines what functions a system has, but also exactly how it should look. It does not allow for creative better solutions that the software development team might find during the project.

In agile projects, teams use ‘user stories’ as the preferred format for defining scope. Each story is a 2-3 line sentence using the structure As a … I can …. so that …. . In the illustration below some examples are shown. These user stories define the user, the action he or she wants to do, and the goal that the user has in mind. This is normally enough for developers to come up with a suitable solutions. User stories have the advantage that they are easy to understand and therefore easy to validate for non-IT experts. This disadvantage of user stories is that they are extremely short and often require explanation. In agile projects this is solved by having the author and actual users involved in the project.

Making scope manageable

The biggest problem with project scope is that stakeholders are not aware of the scope, and are surprised at the end by what is and isn’t delivered. We have a few tricks to make sure this does not happen on your project:

• Define what is in scope and what is out scope. After making a list of user stories that are in scope, we recommend adding a short list of user stories that are out of scope and will not be delivered. This way, people are aware that choices have been made. It also make sure that the scope document is not one long good news story but a real discussion document
• Let the client choose the scope. Even though most project teams can derive a suitable scope from the project vision, it is a best practice to prepare a few options or scenarios and let the project board choose what they want exactly. This makes sure they feel responsible for getting the scope right.
• Reassess the scope after each delivery. To mitigate risk, make sure each project has multiple deliveries of working software. After each delivery, evaluate the user response and reassess the importance of each user story. This way, one can avoid making scope items that are not so important after all.