How much will it cost?
This is by far the most frequently asked question that I encounter while talking to clients about running a project in AGILE methodology. In fact, it is hardly surprising – the market is constructed in such a way that most goods are bought at a fixed price. The possibility of comparing the final amount that we spend gives a sense of security. In the case of IT projects, which in most cases are dedicated solutions, often related to innovation, it is a very illusive sense, and what this article is about.
Who will earn and who will lose?
Above all, a fixed price means only that you will ultimately pay it, as long as the terms of the contract are fulfilled. About terms of a contract and substantive input in a moment. Consider a project estimated for a year of work of a three-person team. With such size of the project, one of two situations will certainly occur:
- the project has been overestimated cost-wise and the contractor will earn not only on current operations, but also on the difference resulting from the estimation,
- the project has been underestimated and the contractor will have to pay extra for it.
Contrary to appearances, the first scenario will bring you more benefits. To understand this well, there must be three words said about changes in the project. Namely – changes will happen. Right now you should get used to this idea.
Why this first scenario then? For a very simple reason – a company that implements your software, if necessary, will be more open to changes in the scope of the project because you remain the sponsor of the project. The company does not lose (assuming of course that the surplus from the estimation was not included in the profit).
In the second case, the contractor will be the sponsor of the changes, which he will be reluctant to accept. Then the dialogue is pushed to another plan, and the contract becomes “the minimum necessary and sufficient to close the project.” It is the word “sufficient” here that is the key, and its negative connotation is as intentional as possible here. This is where most of the mediocre projects come from, which fulfill their task and it is actually everything that can be said about them. The bigger the project, the more that mediocrity will sting in the eyes and leave a bad taste of badly invested capital in mouth.
There is no need to prove that both situations are bad for you. Either you overpay or you get something you did not quite expect.
The problem of incomplete specifications
In fixed-price projects, documentation is created before the project starts, and during its duration it is the main reference point of work progress.
I am the author of over a dozen business analyses and specifications of more or less complex IT projects. What I have learned above all is the fact that the specification will never fully reflect all expectations that are placed on the IT system.
For the purpose of the example, I will use the simplest contact form. A full description of how such a form should function can be easily blown to a dozen or so pages, starting from the description of the business needs it will carry out, through possible states, graphic mockups, use cases and functional requirements. If this is achieved by integration with RMA (Return Merchandise Authorization), we add more pages describing the way communication should work.
This leads to three basic problems:
- did I remember everything about everything? I will see in a half year when I will receive the module from the contractor.
- Am I sure now that the form in the requested shape will be exactly what I need in a half year?
- Am I sure that market trends will not change during the development period?
If the answer to any question is “yes”, a change will be necessary. Now we are going back to the first point – whether your changes will be incorporated depends on who will be sponsoring them.
Such a situation most often ends with the ruling on the analyst’s fault. You could not be more wrong. Such thinking only proves a bad understanding of the analyst’s work. First and foremost:
- the documentation should be written in a way that clearly and in detail describes what should work, and how;
- not every thought can be transferred to paper (I always call this as “the need to wave your hands”);
- often, a client unknowingly conceals business intentions, rather than an analyst forgets something in the documentation. You can find out about every need, if only the need is addressed.
Each time, after a documentation was finished, I was convinced that the volume could be doubled, because you can always describe something more precisely. Also, it always turned out that the client forgot to say something.
How to estimate the project cost then?
Values build projects
Instead of formalities, focus on values
The above problems are some of the reasons why we realize 90% of projects in the Scrum methodology. Often we have come a long way in order to convince companies, with whom we work, to such a practice. However, with a clear conscience, I can say that each time that decision turned out to be the right one.
Therefore, answering the question from this entry’s title, using an agile methodology, you will pay proportionally to the effort put in by the team to complete a project that precisely matches your expectations. By specifying the scope of individual elements during the development, you will have a full control over the entire project. What’s more, it means the possibility of correction when the need arises; not after the end of the project, which would involve additional costs.
Are you deciding on a cat in the sack?
Absolutely not! By no means is the valuation a secret. Just as you do not want to be surprised when you receive your project after a year of work, I know that you do not want to be terrified when you see billing amounts.
This is not what it is all about. Quite the opposite – expect an estimation and expect deadlines. However, it is important that the estimation is based on the level of detail of the project specification, and this was updated and clarified during the work. At any time during a project, a reasonable estimate is possible as long as the company has the relevant experience.
This principle is of particular importance in innovative projects where competition doesn’t sleep, and after a year it could turn out that you are one year behind market standards.
Is Scrum always a remedy?
I mentioned 90% of projects. These 10% are not due to the fact that they failed there. These are projects in which we act as an ad hoc expert or those in which the change takes place in a continuous manner. Then it’s hard to talk about sprints.
About where I would advise against an agile methodology, you will be able to read soon. In the meantime, if you have any questions, I invite you to the discussion.