Another chance to lower the price on an IT project is to change the method of cooperation from Fixed Price to Agile.
Fixed Price — we estimate the total price before the start of the project.
Very often, before making a decision to implement an IT project, the management board wants to know its total price — sometimes even spread over 48 months in advance.
First of all, this generates the need to create an extensive specification (see the previous article), and secondly, it causes Software House to add abstract, impossible to precisely determine costs, such as:
setting up a package of hours for the future, overestimating functionality, taking into account changes, fixes, bug fixes over a long period of time.
The more imprecise the functionality is, the more difficult it is to estimate. Paradoxically, the more precise it is, the greater the chance that it will be changed many times in the life cycle of the project, especially after first presented to public or end users.
The best solution that we have managed to work out is cooperation under the Agile contract. We already do this with most of our clients.
What is Agile Collaboration?
The main assumptions of Agile cooperation are:
- division of work into short, two-week sprints, during which we implement a fragment of functionality;
- each sprint is preceded by planning session with the client, during which we determine the functionality that we plan to implement and estimate the programmers’ time allocated quite precisely;
- after two weeks we present the results on the demo;
- we account for the actual hours worked.
So we implement the project incrementally, deciding during the process how the final functionalities will look like. We don’t stick to the specification. Sometimes we do not implement certain functionalities at all, and instead design others, better suited to the needs of users and customers.
What are the benefits of Agile collaboration?
Customer benefits:
- implementation of the main functionalities at a minimum price;
- the ability to add features that no one thought of at the beginning of the project;
- implementation of only those functionalities that are important;
- during the development of function A, code may be created that will make it very easy to create function B, which will make the real cost of implementation much lower than the original estimation predicts;
- the ability to easily terminate the contract or cut costs — just do not add anything to the plan of subsequent sprints.
What are the downsides?
The biggest downside, of course, is the lack of certainty about the total budget needed for the project.
We always try to estimate price ranges, but the final cost of the project depends on the introduced functionalities and changes during sprints. Also, we are not able to say for 100% what the real value of the project will be.
Another “downside” is the need for regular cooperation with the contractor for the duration of the Agile contract. In fact, it is a plus that has a positive impact on the final effect of the IT project, but it requires the time commitment of significant people from the ordering team.
The third element is the low popularity of this type of contracts outside of IT. This results in fear of making a try.
The cure for this is a good approach to the specification and the project plan. The implementation should be divided into certain phases (Demo, MVP, Version 1.0). You can start by implementing the very basic Demo functionality in the Agile way. This will allow you to see at a low cost whether this is the right way and whether this model of cooperation suits you.
We’re glad you came to this place.
If you are planning an interesting IT project and are considering choosing a contractor, we will be happy to take a look at the specification. Maybe SmartShack will turn out to be a good choice 🙂 I encourage you to contact us.
Recent Comments