Strategic Scope Management
The underestimated leverage in the project business.
What do we absolutely have to implement in the project and which aspects can we ignore? These are important questions at the beginning of a project and even more so later when we realise that we cannot keep to the time or cost plan. These are questions that revolve around the scope of a project. The scope is one of the central variables in project management. The agile approach is characterised among other things by the fact that the scope is no longer fixed but negotiable. If time is tight, we prefer to forego a few features rather than exceed the deadline. The same applies to resources: we delete scope instead of deploying more people than planned. Finally, quality is also non-negotiable; it is maintained at a consistently high level with continuous integration and automated testing, among other things.
Tactical and strategic alignment
There is plenty of tactical scope management: before each iteration it is decided which user stories (or features, depending on how the work is structured) are to be processed. Considerations between different user stories are made ad-hoc, especially in Scrum – one trusts that the product owner already knows which priorities he or she has to set. User stories are considered to be largely independent of each other; this is a useful fiction to avoid overengineering.
Strategic scope management often only takes place at the beginning of a project: large groups of features are selected, and after the first rough estimate has been made, if necessary, it is cut down. If a project gets into difficulties, it’s usually too late for real scope management, rather one has to “save what can be saved” and grudgingly do without many things that were classified as “absolutely essential” at the start of the project. Also many started features, which were perhaps already to 80% finished, must be deleted, since the remainder budget is sufficient only for the most necessary. Strategic scope management tries to avoid such predicaments and touches on further questions:
- How can you develop cheaper alternatives, e.g. by slightly changing the department’s requirements?
- Where are the possibilities to decide “make or buy” in favour of “buy”?
- How can larger clusters of requirements be meaningfully structured?
- How do you avoid stakeholders only pursuing their local optimisation and losing sight of the business benefits?
The ideal image of scope corresponds approximately to this box of chocolates. I can eat the pralines in any order, and with each praline my benefit increases evenly. There is no need to say that I have to eat the piece in the middle first, otherwise all the others won’t benefit me.
Structuring the scope
The well-known “Iron Triangle of Project Management” states that the three criteria time, cost, and scope are interdependent. If you want to make changes in one corner (e.g. shorten the time to completion), you have to accept consequences in the other corners (e.g. higher costs or less functionality).
In agile projects scope is used as a buffer for uncertainty. To do without scope is usually better than the alternatives:
- Extending the project over time causes additional costs and delays feedback.
- You could increase costs by increasing the size of the team. However, Brooks’ Law is against this: Putting more people on a delayed project only delays the project more.1
- Can’t you save on quality and meet the deadline? This is tried again and again, but is very difficult, among other things because reduced quality quickly leads to expensive improvements.
So we simply reduce the scope as soon as our prediction shows that we will miss the deadline, and everything is fine…isn’t it?
It only gets unpleasant if we can’t delete anything, because there wouldn’t be enough useful stuff left. If a decisive step is still missing in the workﬂow, while the other steps already fulfill 95% of the wishes. If a team cannot deliver, although its contribution is crucial for the overall result. Or when all features are 80% complete but none of them are really usable. This results in the first principle of strategic scope management:
Good scope management means structuring the scope in such a way that it can be easily reduced later.
A more realistic image for Scope. The parts of the “harbour” system are interdependent. It is not clear whether and how individual parts could be dispensed with. Is it possible to omit a crane and still save a large part of the customer benefit? Or save costs by not building the hall?
Before we turn to the goals of scope management, I would like to describe a few approaches:
We cannot ignore the dependencies in the scope, so it is important to work out a good model for it. The best way to do this is to visualise the entire scope, which can also be hung on a wall in large format.
Let’s take a small company as an example: MisterFixit mediates smaller services around the house (“About for caretakers”). If your bathtub leaks on Sunday evening, you could hire the plumber’s emergency service, but that will be expensive. Or you can call the MisterFixit call centre, where one of hundreds of helpers is immediately sent by to take a look. The helper can probably repair your bathtub just as well as a master plumber, but at a fraction of the cost.
For the placement, the MisterFixit call center employee must of course know who has the necessary skills in the helper pool and who is available. The drive should also not be too long. The company engages the customers by an annual membership, of course you can also become a member at the first appointment. So far, all this has been done in the Hamburg city centre area using a combination of Excel spreadsheets, yellow stickers and a lot of experience in the call centre. The management wants to extend the successful business model on further locations, within one year at least Berlin, Leipzig, Munich and Stuttgart are to be added. For this reason, an investment is now to be made in a web application that speeds up the workflows involved in booking appointments and avoids errors. Then, of course, it would make sense for club members to be able to book appointments directly via the web. In addition, the marketing wants to promote vouchers and free memberships. Ideally, club members should pay directly at the appointment by credit card, PayPal, or the MisterFixit app (still to be developed). Alternatively, an invoice is also possible. In addition to the actual appointment booking, there should also be a possibility for billing, e.g. for working hours, travel and club membership. And of course the helpers must be able to log into the system in order to enter their availability (for example: next week always from 9 a.m. to 5 p.m., in the centre of Berlin).
The dependencies of the planned web application can be found in the following graphic. The dependencies are visualised by arrows.
Everything that I think is not necessary in a first version, I have dashed. In this way, we could abandon functionality and at least retract part of the benefit: Services can be booked and billed in any case.
- If we don’t make appointments self-service via the website, we can also save on the authentication of customers.
- For a start, we can live with it if the helpers themselves assess their abilities (“self-declared skills”), certificates can be added later if necessary.
- If we only pay by invoice, we can do without a lot of payment methods.
- Finally we could start without marketing campaigns (vouchers, free memberships).
All these reductions in functionality naturally lead to losses in the value of the project result.
Characteristics for structuring
There are a number of features that can be used for structuring:
- scope of functions,
- costs of delays.
We have just seen the structure according to functional scope in the example of MisterFixit: we deliver in several expansion stages, whereby the first stage already delivers a usable result, but can still be a long way from the actual project goal.
It is also possible to break down the functional scope according to variant-creating characteristics. These are characteristics whose characteristics change the process flow of the business process under consideration. If, for example, we have to handle purchase orders from abroad differently, the customer’s location is a variant-creating characteristic. In the example, the characteristic could have the values “Germany”, “European Union” and “Third country”.
Ideally, you know how much sales volume (or profit) is generated with each variant, which then creates the link between scope and benefit. A large number of variant-forming characteristics provide enough room for manoeuvre to develop meaningful expansion stages. For example, the first version could only support customers in Germany and thus already cover 80% of the sales volume. At this point, one can often also discover possibilities for permanently reducing the scope: business transactions that only occur in the per mille range may not have to be supported with software at all.
Delay costs is well suited for prioritising features. Delay costs answer the question: How does the overall result (profit of the project over the whole lifecycle) change if we deliver this feature one month later? With MisterFixit, for example, you would estimate the cost of delay for the self-service appointment like this: With self-service we get 10% more appointments, with 5% less costs for the call center. So the delay costs are 10% of a monthly profit plus 5% of the call center’s monthly costs for each month the feature is later delivered. Prioritisation should take into account the amount of time (in calendar months) spent on the feature, details can be found at Don Reinertsen2.
Combinations of the structuring options mentioned here are of course also useful: For example, if version 1 only considers domestic customers and includes features with very high delay costs.
Now we come to features that are not quite so well suited for scope management:
- the maturity level of a requirement
- the classification according to effort
- technical dependencies
- the organisational structure
The maturity level of a requirement can be used occasionally: If the specialist department does not yet know exactly what it wants, we can reject or postpone the request. Of course, this involves a risk, because even immature requirements can bring great benefits. The point here is rather to be able to quickly reject wishes.
The structure according to effort can be tempting, why not harvest the “low hanging fruits” first and quickly get something up and running with little effort? This is misleading if you ignore the benefits.
Sorting scope according to technical dependencies is also obvious, but unfortunately the business benefit almost never runs parallel to technical dependencies. If, for example, we first complete the backend, the realised benefit will still be zero. The exaggerated weighting of technical dependencies often occurs when you try to minimise the overall effort (“While we are at it, we can solve it correctly and generally”).
Sometimes we also attempt to follow the organisational structure: Why not do everything first, what department X needs? Unfortunately, the benefits are often cross-departmental, so that the result remains at zero for a long time. If not, you better do a smaller project for a specific department. Conway’s Law says that the architecture of the system will reflect the structure of your organisation anyway, so a certain amount of “structuring” in this way will be unavoidable.
Scope management goals
When you think about structuring scope.
- to present options for project termination,
- to maximise feedback,
- to enable parallel working,
- and create an evolutionary path.
What could we deliver if the project had to be finished next week? This is equivalent to overspending or an overoptimistic estimate: we have to finish before we are “done”. Which features would be ready (or at least usable), which business processes could we support? So how can we structure the options or the scope in such a way that it can be reduced later without too much collateral damage?
- Structure features according to customer benefit. This means putting the features in a sequence in which as much of the planned customer benefit as possible can be realised as early as possible. For each feature that has not yet been started, we then have the option not to deliver it.
- Deliver features in expansion stages. If a feature already makes sense in the basic version, we can complete the basic version and then turn to other features. So we get the option to deliver the feature partially.
This is how the advantages of the agile approach can be expressed:
Do you want the surprises all at once or do you want them one at a time, ireratively?3
When it comes to nasty surprises in the project, we prefer not to want any at all. And the unavoidable ones should come little by little, please. One of the most embarrassing surprises is for sure:
We did everything right, but the end user doesn’t want the project result.
This was the case with the major project ROBASO of the German Federal Employment Agency. On a single IT platform, 16 existing applications were to be combined in order to enable and simplify processing without duplicate entries and program changes. After 5 years of development, a pilot phase in 2015 revealed that the employees did not want to or could not use the software: Practical use in customer business showed that the software was too little ﬂexibel to do justice to the complexity of the customer’s concerns.4
It was reported in the press that it was not possible to correct an account number without re-entering all the data of the service recipient. After the pilot phase had revealed serious deficiencies, the agency commissioned an external project audit. The result: Deﬁzite could not have been corrected promptly and economically. The agency has therefore decided to terminate the project, in which a total of 60 million euros have been invested since its start in 2010.5
As far as I can tell, there has already been occasional feedback from users during the course of the project. Only a real release, and thus real feedback, came too late.
Good scope management means structuring the scope in such a way that realistic feedback can be obtained as early as possible.
In addition to the valuable feedback from end users on requirements and usability, we also want as early feedback as possible on
- internal fit, i.e. does the interaction of subprojects or modules work?
- external fit, for example: can the system interact with the surrounding IT landscape via the intended interfaces?
For this purpose, integration points are available: defined points or releases at which the interaction of the components is tested under conditions that are as realistic as possible. Ideally, we can also find out more about the customer benefits at an early stage, and the best way to do this is of course to deliver the components into productive operation.
Enabling parallel work
How can we divide and arrange the scope so that as many people as possible can work on it at the same time? We try to minimise friction losses, but have to accept dependencies and interfaces. Maximum parallelism is achieved when everyone is working on independent parts of the system. This is usually not compatible with the goal of delivering valuable parts first. The architecture of the system can strongly support or even slow down parallel work.
Creating an evolutionary path
By this I mean that the further development of the system (possibly even beyond the time horizon of the project) is taken into consideration at an early stage. Of course, this is primarily the task of the architecture, but scope management can stimulate the development of the appropriate architecture. Think of a system consisting of a core and many plugins. Then it is a good idea to develop a primitive version of the core and a few plug-ins first, whereby the plug-ins already cover a large part of the spectrum of later requirements. Or think of an API: it is recommended to develop the API together with a first realistic client.
The Make-or-Buy Test
Who can provide good scope management? Which skills should we look for, and with which decision-making powers should we equip the role of “Scope Manager”? As we have seen above, you need a deep and cross-departmental understanding of the customer value that the project outcome is intended to achieve. This includes professional competence and experience.
Strategic scope management is also about balancing interests and sometimes painful compromises that disadvantage individual stakeholders in favour of the overall result. To determine whether there is sufficient authority and understanding for scope management, I like to use the make-or-buy test. It reads:
If scope management cannot bring about make-or-buy decisions, then it is not set up high enough in the hierarchy.
A make-or-buy decision forces us to discuss the value of a project. Only then can we decide whether we could achieve the desired result (at least partially) better with the help of purchased components. There is no shortage of promising offers: everything is available via API, as Software as a Service (SaaS), or as Open Source, from product search to content management systems to credit checks.
If the discussion about make or buy is not possible, or if a decision in favor of “buy” is not possible, this can have various causes:
- The scope is fixed “from above” and must not be questioned.
- The tasks are formulated too small, so that the options for “buy” are no longer recognisable.
- There is not enough insight into the value, therefore no cost-benefit analysis is possible.
- There is no sufficient decision-making authority.
- The professional competence is not sufficient to evaluate the offers for “buy”.
These are general warning signals that something is not going optimally with scope management, regardless of whether we would ever decide in favour of “buy”.
If you can’t negotiate make or buy, you can’t negotiate the scope well enough in other situations either. This makes the scope too rigid, and the uncertainty in the project will look for another way out: somewhere between costs, time and quality.
By the way: Also the alternative “doing it by hand” is often prematurely excluded, analogous to the make-or-buy test we can formulate: If scope management cannot decide in favor of a manual solution, then it is not high enough.
The Scope Manager
I see the role of the scope manager as one person, because the considerations are challenging, decisions will sometimes be unpopular, and information from different areas must be integrated into an overall picture. This person may come from IT or business and should acquire the necessary background knowledge from the other area.
If you are looking for exemplary people for this role, you will rather find them in product management than in project management. At Toyota, for example, there is the role of Chief Engineer, who bears overall responsibility for a new model, including economic responsibility. It is traditionally an engineer who knows car production from his own experience and has worked his way up the engineering hierarchy. On the other hand, the Chief Engineer is expected to gain an equally deep understanding of customer needs. This was the case with the relaunch of the Toyota Sienna in the North American market, where Chief Engineer Yuji Yokoya drove for months through Canada, the USA and Mexico to better understand the wishes of North American customers. One of the many findings from 53,000 miles on the road is that the Sienna, as a minivan, must be geared to the needs of parents and their children. So, among other things, it was equipped with a “conversation mirror” that allows parents to keep an eye on the rear seats.
Strategic scope management requires overall responsibility in one person who
- combines in-depth technical knowledge with an understanding of the benefits,
- knows the dependencies and consequences of decisions,
- can recognise the potential of new technologies and approaches,
- can control the interaction of organisation, business and IT,
- understand decision makers and can influence them.
Strategic scope management means understanding the benefits and aligning them with the costs and technological opportunities. It doesn’t just belong at the beginning of a project, but must be operated continuously from the idea to the use. All too often, the scope of the project is accepted as being predetermined in terms of content. Strategic scope management, on the other hand, consistently understands the scope as a variable and creates therefore valuable options, be it for premature project termination, make-or-buy, or the development of sensible alternatives.
My conclusion is therefore: strategic scope management is worthwhile.
 Brook’s Law
 The Principles of Product Development Flow: Second Generation Lean Product Development
 Michael de la Maza on Twitter
 and  Press release of German Federal Employment Agency from 15 February 2017
Dr. Matthias Berth
Dr. Matthias Berth studied mathematics and computer science in Greifswald, Germany and Amsterdam, Netherlands. After a doctorate in computer algebra, he founded a bioinformatics startup together with colleagues from biology, mathematics and economics, to which he belonged for many years as CTO.
He then moved on to freelance work as a consultant and software developer. He is particularly interested in the sustainable improvement of the software delivery process of teams and organizations in the context of the digital transformation of business models.
He prefers to apply principles from Lean Thinking to establish agile approaches. In doing so, he draws on a broad repertoire of methods. The aim is to convey perspectives, mentalities and ways of thinking that enable teams to deliver better and more valuable software faster and more frequently. As a basis in these processes, it is important for him to understand and focus on the respective economic context and the business benefits for the entire company.
Since 2018 he has been working with Christoph Lefkes on the holistic optimisation of software delivery processes at SoftwareLiefern.de.