How to manage your budget in Agile IT projects? Part 1
“Creating superb software makes the world a better place” — when hearing this phrase, how many times have you asked yourself: What went wrong? Do you recall dozens of emails exchanged with the project manager, exceeded project budgets or a badly managed team in which there were no developers at a key moment?
Welcome to the club: we’ve all been there. So why is it that similar scenarios are repeated all the time and it’s difficult to find an effective and experienced software house? We have analyzed our own history of collaboration and made a sincere retrospective; we’ve taken into account many factors affecting client and subcontractor cooperation, and we have drawn conclusions — now we want to share them with you.
We are beginning the series ‘Honestly about IT’.
We will talk about the most common challenges faced by a client looking for a software development company.
Our first topic is the issue of budgeting Agile-based projects. It is commonly believed that all (or at least most) of the budgetary risk in Agile-based projects must be taken on by the client. We want to dispel this myth and show that also in Agile projects it is possible to control the budget.
Read on!
In order to implement a project, one has to acquire funds and establish a budget. It is rarely unlimited — most often the client has a well-defined budget for product implementation. It is limited due to many unavoidable factors. Cooperation with investment funds, budget plans for subsequent years, the break-even point of a given product, market forecasts — even the most promising projects have a break-even point for profitability whose crossing makes their sense questionable. The manager must therefore manage the project in such a way as to achieve the business objective using the assigned resources.
When a client goes to a potential IT system provider, a certain “conflict of interest” emerges: the provider is reluctant to carry out the project within a fixed budget, and proposes work on the basis of “agile” methodologies and Time&Material settlement. Why is it so? Let’s take a look into this.
“Fixed price” + “fixed scope” = trouble
Why are providers so reluctant to work on “fixed price” projects? There are several reasons, but two stand out:
- Most often the project description provided by the client is in fact only an outline. It may be difficult to believe, especially given that the client usually spends a lot of time elaborating their vision and describing the project. However, if one compares an IT project to the construction of a house, the description the client usually provides is so general that it is analogous to saying: I want to build a house that has windows in this place and doors in that place, a garage, rooms like this, and fulfils various functions. No contractor will undertake building such a house or even provide a valuation based on such a project. To some degree, this issue stems from the fact that most clients do not realize that designing the system involves more than writing a few pages of requirements. Not everyone is able to do the preparation. Without relevant experience, knowledge of tools, the specifics and complexity of IT projects, one cannot design an IT system (just as without appropriate knowledge, one cannot design a house).
- Every contractor is aware that “change” in IT projects is not an exceptional situation. IT projects evolve over time. In the case of IT systems, it is unreasonable to assume that the accepted initial scope will not change over the course of project implementation. Moreover, experience shows that ignoring these changes can significantly reduce the chances of success (realization of business value). For example, say we have designed a project, and suddenly the letter of the law has changed, which requires significant modification of our project features. Should we implement the system according to the previously accepted plan? Or should we modify the plan so that the system is compliant with the law? The answer is simple. And this is only one of the thousands of situations that can affect the project’s scope.
To put it simply: “In case of fixed price projects, the contractor agrees to implement at a certain price something that he knows very little about, and what he already knows may change in various ways”. Therefore, by agreeing to implement the project in a fixed price system, the contractor takes on a huge risk, which he naturally tries to avoid.
You may then say the following: “Fine, but such an agreement reduces the risk for the client”. This may be true if one considers only the budgetary aspects. However there is always a “but”… or like in this case, several of them.
But…
When estimating a fixed price project, the contractor usually assumes a huge security buffer in order to minimize the financial risk. In the end, the client may pay more for the system than if the same system was implemented on the basis of Time&Material,
But…
Undertaking such a project most often begins with writing a minutely detailed system specification, which:
- is very costly and does not account for any changes,
- prolongs the project implementation, as most often the contractor will not do any real work related to the system before accepting the specifications,
- causes the contractor to cling to the specifications and reject any changes in the subsequent implementation stages (“We are very sorry, but unfortunately it is beyond the scope of the work”), which ultimately reduces business value or makes it impossible to achieve,
But…
When budget/time problems arise, the quality of the solution is most likely to suffer. Additional features are prepared in the simplest way possible, often relying on far-reaching concessions, which at a later stage may, among other things:
- make it difficult or impossible to further develop the system,
- lead to problems with the solution’s stability,
- increase the solution’s maintenance costs,
- decrease the usefulness of the solution (thus, its business value)
But…
A communication barrier is built between the contractor and client. After all, good communication is essential for the project to succeed. Unfortunately, fixed price contracts often lead to parties not working together to achieve the project’s success, instead being divided into “you” and “us”. The contractor’s goal is to fulfil the contract at the lowest possible cost, not to deliver business value.
Using the language of negotiations — in case of fixed price contracts, the aim of the parties is not to achieve a win-win scenario, but to gain more than the other party. This means that in most cases, one of the parties is/feels harmed, reducing the chances of success or even making it impossible to achieve,
But…
Experience and statistics indicate that even projects with closed budgets are not without the risk of their being exceeded and failing.
Why agile ?
So, is there a way to mitigate or eliminate the risks described above? Can we provide value in a different, better way? Answers to these questions were probably the basis for creating Agile Manifesto.
If I had to characterize Agile in one sentence, I would say, that it’s the approach that focuses on providing the value instead of handling the processes of providing the value. Small, but meaningful difference.
What does the client gain by implementing a project based on agile methodologies? In order to answer this question, let’s consider the aims of the project. To put it bluntly, the client strives to achieve financial benefit. This may be achieved through sales, cost optimization, sometimes through increased customer satisfaction, etc. This aim can only be achieved if the project delivers the expected business value. If we have created a system that does not meet expectations and does not provide the desired value — we’ll only lose out on it.
Okay, but how does this relate to agile methodologies? Projects in their initial phase are largely based on assumptions. During the course of project implementation, they are more or less verified, and very often it turns out that they need to be modified. These modifications translate into changes in the project requirements and scope. Handling these changes in the traditional (cascade) approach to project management is very restricted. In agile methodologies, on the other hand, ability to react to changes is one of the main assumptions. Thanks to that, the project based on Agile has a bigger chance to provide a value and thus — to succeed. Naturally, this is not the only advantage of agile, but presenting all of them would require a separate article.
Does this mean that Agile is the only way to success? Definitely not. There is no silver bullet to make every project a success. Projects based on agile methodologies are also at risk of failure. However, mechanisms of agile methodologies (if applied correctly) allow one to increase the probability of success, as they increase the chances of delivering business value.
The question then arises as to whether agile-based projects must always involve financial risk. Well, agile methodologies, contrary to the prevailing opinion, are not conducted outside of budget management and do not always have to be based on Time&Material. So how can we approach them? We will try to answer this question in the next section of the article.
