How to manage your budget in Agile IT projects? Part 2

In the previous section of the article we explained the biggest issues with fixed-price/fixed-scope projects. To be completely honest, we don’t believe that it is necessary to avoid such agreements at all costs. There are some situations where it is the perfect solution (e.g. in cases with small well defined changes or changes satisfying only one need — such as law compliance). In most cases though, putting the project in a fixed frame will put you at risk of failure.

In this part we want to shed some light on how to deal with your budget during agile projects.

First of all, think for a second about how you manage a budget in real life. Let’s say you want to go on vacation. You can of course contact a travel agency, stating all of your requirements for your trip, but the valuation you will get in response can blow you away. You can of course do a lot of things (save up money for a long time, get an extra job, etc.) to make all of your travel dreams come true. However, usually you have a limited budget and you want to make the most of it. So you start to prioritize and think of the things that are most important for you. For some people the most important thing will be the destination, for someone else — the standard of accomodation. Some will appreciate historical heritage while others will value the bar service on the beach. You choose what is most important to you and try to find the offer that fits best within the budget you have. If you travel with other people (eg. family or friends) — you have to include their needs, even at the price of compromising on some of your own. To summarize — you adjust the requirements to the budget you have, trying to maximize the value you’ll get. The same mechanism is applied in other aspects of life (eg. buying a car, buying a flat, or building a house). The only difference for an IT project is that it’s usually not something off-the-shelf. The value provided by a project needs to be built over time.

This leads to the question of how to approach it?

You can start by asking your provider ”How much would it take to implement the system and fulfil all the requirements I have” — it’s always good to know if what you’re asking for is far more expensive than you expected :) But don’t worry as that doesn’t necessarily mean that you (and others that have some interest in the system) can’t achieve the goals within the budget you have (the same as when planning your vacation).

The secret of managing the scope in Agile projects and thus the budget is prioritization. If you build your system in a way that it provides value incrementally, starting from fulfilling the most important needs, there is a great chance that you will provide crucial values before your budget runs out. To simplify — if you divide your work into small increments and you start by implementing crucial things and your budget runs out after 20 iterations — even if you haven’t implemented everything you wanted in the first place — you maximized the value provided by the project within the budget you had.

Is it simple ? No. Is it necessary to succeed ? Yes. Even if your budget is huge, without appropriate planning for value delivery, there is a good chance that you will fail.

Now, how to approach the settlement of such a project with the supplier ? Let us present some of the most popular solutions.

Time&Material

This is the most popular way of settlement within Agile projects. The client agrees to pay for the time and materials used to complete the project. Time cost is based on a provider time unit rate (usually hour or day). Materials are all of the costs incurred by the provider (such as software licences, bought images, etc.) during the project.

Although this offers a lot of advantages — it also has some pitfalls that can negatively affect a project.

Advantages:

1. Gives the client full control over the project,
2. Allows the focus of the team to change swiftly,
3. Usually allows the size and the competences of the team to be adjusted,
4. Gives the client the possibility to influence the project direction at any time,
5. It doesn’t require detailed specification to be created up-front,
6. It allows better quality to be achieved, since the team is usually given greater autonomy in selecting solutions,
7. Usually it allows a faster start and thus delivers faster because there is no need for negotiations over the offer(s),
8. Provider rates are more beneficial for the client compared to the rates for any fixed price offers, because the provider doesn’t have to calculate the risk,

Pitfalls:

1. It requires mutual trust between the provider and the client. Without it — it may lead to communication problems and mutual accusations and the result of that is a less than happy end to the cooperation,
2. The entire financial risk is put on the client,
3. Probably the biggest problem of T&M agreement is that providers use it as an excuse for not estimating and planning any changes, which leads to a lack of budget control and thus decreases budget usage optimization,
4. Without appropriate effort put into the control/supervision of a process, a lot of space for scope creep and overengineered solutions.

Sprint based settlement

If you have already started to work on prioritization (by yourself or with your provider), then you know what you want to do in the next period of time (sprint). If you know that — it is possible to attach a valuation to it and do it in a fixed-price deal. There are 2 ways of approaching fixed price sprints:

1. A fixed team working on a project and fixed price for a sprint (e.g. 2 weeks). With that in place, you need to agree with the provider what the sprint deliveries will be (what work will be performed by that team within the sprint?). In this case — the cost of every sprint is the same and you negotiate the scope of the sprint,
2. Determine the work that should be performed within the sprint, then select the team that is suitable for the job and calculate a price for the sprint. In this case, the cost of the sprint may vary.

The first solution gives some predictability of the costs at the expense of flexibility (please note that the work that brings value does not have to always be performed by developers writing code). The second solution provides much greater flexibility in planning, but also requires much greater flexibility from the provider regarding the people dedicated to the project (which can become an impediment).

Advantages:

1. It incentivises the prioritization of the work in a way so that it provides value within short periods of time,
2. Financial risk is somewhat divided between the client and the provider (the provider commits to delivering what was agreed within the sprint at the agreed price),
3. Provides better budget predictability than T&M.

Pitfalls:

1. It requires more attention as the work must be divided into sprints and negotiations about the scope of the sprint must take place,
2. It may negatively affect the quality of the solution since every sprint is implemented within a fixed scope,
3. It doesn’t offer as much flexibility as T&M — work planned for a sprint should not be changed during the sprint.

Feature based settlement

Another way of organizing the settlements within the project is to arrange a fixed price for a particular feature. If you have decided about the priorities — you can ask the provider to provide you with offers for consecutive features that will be implemented. Based on the offer you can agree on a fixed price/fixed scope for this particular feature. The important thing is to do it incrementally as the project goes on. That way you will give youself room for maneuveur and the ability to change the priorities when needed. Otherwise it’ll become a fixed-price/fixed scope agreement for the project with all its disadvantages.

Advantages:

1. Predactibility of cost,
2. Offers delivered by the provider may allow the priorities to be adjusted, if it appears that the value to cost ratio is not good enough,
3. Financial risk is divided between the client and the provider (the provider commits to delivering what was agreed on at the agreed price).

Pitfalls:

1. Requires more attention and effort during planning, work must be divided into features and negotiations over the scope/price of each feature,
2. There is a risk that the method will shift the project’s focus towards providing the features, not providing the values,
3. It may negatively affect the quality of the solution since every feature is implemented within a fixed scope,
4. It doesn’t offer as much flexibility as T&M — work planned for functionality cannot be changed.

Choose the best one

Which of the above is the best ? Well, as usual, it depends on the situation. We successfully use all of them. In some cases we have even mixed them together (for example: sprint based settlements for the research phase of the project and when we have earned the trust of the client — implemenation in T&M). The most important thing is to understand and remember that the project should maximise the value within the planned budget and time; the appropriate method should be selected to make this possible.