29. January 2024 By Ellen Volkert and Sarah Röhe
Requirements engineering in a fixed-price context - Negotiate the scope and manage the budget
‘Fixed price’ are two words that contractors working on software projects never like to hear, especially in connection with agile software development. In theory, the scope must be clearly defined when the price is being negotiated. In real life, however, the core objective is defined, even if this is rarely the case with all the requirements. The requirements are subject to change as well, which is by design under the agile approach. This in turn leads to different interpretations regarding the scope and a high degree of uncertainty, which in the worst case can cause the project to fail. However, the budget serves a central role not only in fixed-price projects. It is also of critical important in every software project, regardless of what type of contract is ultimately chosen.
In this blog post, we look into expectation management and explore the term ‘scope’. Along with that, we will also explore several requirements engineering methods that allow you to remain on budget and describe possible solutions in cases where your project is at risk of going over budget.
Communication as a factor for success
One of the main sources of error – and the primary reason for the need to make changes – is miscommunication. Disagreements and different interpretations of the project objective can lead to budget overruns, delays and a general sense of dissatisfaction.
Figure 1 Communication interfaces used by a requirements engineer
As the number of people involved in a project grows, so too does the number of communication interfaces and the risk of the project failing.
The requirements engineer plays a central role in software projects and acts as the go-between for all stakeholders. As such, one of his or her main duties is to distribute information and issue decisions to the various stakeholder groups and promote communication between the groups in order to limit the room for interpretation.
Expectation management
The expectations and having them be met are both critical to ensuring that the stakeholders are able to work well and effectively together. If they are met, this makes people happy. And if they are exceeded, it is a pleasant surprise for everyone. However, failure to meet them could lead to unhappy or even dissatisfied customers.
Figure 2 Expectations and how the degree of fulfilment affects the overall level of satisfaction
In the project context, expectations are synonymous with the scope. The earlier they are defined and more thoroughly they are communicated, the more effectively one can manage the customer’s expectations. Having regular reviews to assess the scope documented at the beginning and a harmonised approach is key to the success of complex IT projects.
Negotiate the scope and manage the budget
According to the PMBOK Guide issued by the Project Management Institute, the scope is ‘the work that needs to be accomplished to deliver a product, service or result with the specified features and functions’. (Note: PMBOK is a project management standard.) However, this definition runs counter to the agile software development approach, where the scope is only vaguely described and not broken down into specific requirements (functions). How can a requirements engineer (RE) manage the scope under these conditions to ensure that it can be achieved within the allotted budget? This is essentially impossible, because what is not defined cannot be managed.
For that reason, having a clearly defined scope (in the form of acceptance and approval criteria, to give an example) that fits within the allotted budget is a basic requirement to successful complete a fixed-price project. Which is why the RE has to first define a scope that can be realistically achieved together with the client. Failure to do so will produce a schedule that is unrealistic and lead to budget overruns. As a result, the project will run into all sorts of problems.
Unlike the scope, however, the budget is precisely defined, with no room for negotiation outside of change requests. In summary, one could say that the scope is negotiated while the budget is managed.
Feature budget mapping
There are other reasons for why a budget gets out of control beyond a poorly defined scope. These could include:
- Unstructured or incomplete documentation of requirements
- Additional new requirements or additional changes to the requirements
- Golden handshakes, or requirements that do not make financial sense and consume a lot of the budget but deliver little added value
- The original quotation, including the estimated budget once the project has started, is not taken into consideration
How do we bring the defined scope in line with the allotted budget?
There are different ways to manage the budget. One method developed at adesso is feature budget mapping. Similar to agile working, the budget is broken down into small, manageable units and distributed to the features, epics or other items that are to be implemented. The allotted budget is in turn distributed amongst the stories below it, which are sorted in descending order based on priority. If the budget is fully expended, no further stories can be developed for this feature.
Figure 3 Feature budget mapping
No other funds from the budget may be used, since otherwise there will not be enough money left over for features that are to be developed later on. This would have the effect of reducing the benefits achieved by choosing this method. However, there is no reason why you cannot set aside funds if it turns out that a feature could be developed for less money than you originally thought.
Using feature budget mapping, it is possible to identify early on if a feature will be more complex – and therefore more expensive – than originally assumed. This allows you to take measures in response in good time.
Design to budget
Always seek to achieve an MVP and omit anything that is not absolutely necessary (a minimum viable product (MVP) is an initial working version of a product that only contains the most important features at the start).
Targeted questions can be asked to determine just how important a function is:
- How often is the function required?
- How many users use the function?
- Is there a workaround, and if so, what are the costs and risks involved?
If it becomes clear over the further course of the project that additional requirements or changes to the requirements will be needed, this must be done in a cost-neutral manner. It is necessary to clarify what can be omitted or what can be replaced. Otherwise, the customer will have submit a change request and budget for this.
The 80/20 rule
But what should you do if you realise that a function is more expensive than you originally thought?
First off, it is important to be open about this and inform the project management team. You can then go from there and develop a proposed solution in consultation with the development team and the specialist department. The number one goal, after all, is not necessarily to implement the specific requirements, but to help the customer meet their objectives. The team can therefore propose a more cost-effective solution that also achieves this goal.
This can be done under the Pareto principle (also known as the 80/20 rule), which states that 80 per cent of the outcomes result from 20 per cent of the total effort. The remaining 20 per cent accounts for 80 per cent of total costs, pointing to an inefficient use of resources. This principle can be used to identify requirements whose implementation can be postponed or omitted altogether because they are inefficient from a cost perspective.
Figure 4 The Pareto principle
Negotiations with the customer are then conducted on the basis of the solution developed based on the 80/20 rule and the originally agreed scope.
Analysis sprint
If the project is massively over budget and far out of schedule, it is essential that you stabilise the requirements framework and adjust the planning accordingly. Implementation is put on hold in order to devote time to an in-depth phase of analysis. Under the agile approach, this is referred to as an analysis sprint. The aim of this is to create a stable framework that defines the limits of the functionalities that still need to be implemented.
In small, cross-functional teams, the open requirements are analysed and described in such a way that implementation risks and limitations are clear to see. A critical assessment of what should and should not be given priority is also performed, and items that could possibly be omitted are identified. An estimate of how much it will cost to implement the requirements is then produced for each individual requirement, which also includes the risks involved. Based on this estimate, a new project scope is agreed upon in the final phase of the analysis sprint. Development then proceeds under an adapted agile approach.
To learn more about how an analysis sprint can be used to get a failing project back on track, take a look at this blog post titled ‘How to stabilise troubled agile projects’ (in German).
Conclusion
A requirements engineer has a part to play nonetheless, even if some of the tasks described here would not at first glance appear to fall within the duties typically performed by this person. The requirements engineer is the central go-between in the project, often knows the current status of the project better than the project management team does and is able to address any issues quickly if everything is not going to plan. To be able to identify deltas, you first need to define a baseline (here: the customer expectations) in the form of the scope and document this in a structured way at an early point in the process. Over the course of the project, it is essential that you keep a close eye on the budget and prepare cost projections using suitable methods such as feature budget mapping. If it becomes clear that you are at risk of going over budget, it is important that you promptly take action to rectify the situation. Two ways to do this are to negotiate a solution under the 80/20 rule or carry out an analysis sprint. It is important that you consistently pursue the strategy of developing an MVP in order to avoid designing a product that exceeds the requirements (‘design to budget’). Each of the steps outlined here apply in particular in the fixed-price context, though they can also be adapted for use in other types of project as well.
If you would be interested in discussing the topic of requirements with us, feel free to get in touch. You can reach us by e-mail at ellen.volkert@adesso.de and sarah.roehe@adesso.de.
Would you like to learn more about exciting topics from the world of adesso? Then check out our latest blog posts.
