Some habits are never questioned. And wrongly so. Take estimates for software development projects. Estimating workloads to predict costs, and estimating deadlines via the "sacrosanct schedule", are the bedrock of project management.
The tradition is such that we consider it an imperative, an obligation. But the question deserves to be asked.
Doubts about the relevance of estimates
Estimates are everywhere:
- Even before the start of a project, every service provider undertakes to respect costs and deadlines in order to secure a sale;
- during the contracting phase, with the setting of penalties for late payment;
- and at the end of the project, when compliance with commitments is verified.
The main criterion for the success of a project is whether the initial commitments are met. Were the initial estimates right?
So the success of a project is not linked to how well the deliverable works? Or the mass adoption of the tool by users? Or to the financial aspect of a strong and rapid return on investment?
Would a project that ran over time and over budget, was widely adopted by users and had an exponential ROI, really be a failure?
There is a plethora of methods for making estimates
For more than half a century, realising that previous methods were unreliable, everyone has come up with their own. They all have one thing in common: they are all predictions about the future... Irrational activities.
One of the best-known is when, after reading the specifications, the estimator uses the only two intellectual processes available at the time: the "wet finger" and the "guesstimate", to give you a precise number of working days and a precise schedule.
Some estimation methods are very elaborate, such as COCOMO, which includes a lot of mathematical formulas to make it seem eminently scientific. However, this presupposes that these computer scientists know, before they start developing, how many lines of code there will be at the end of the project... A challenge that neither fortune tellers nor oracles would deny.
Agile methods have also brought their own forecasting methods, such as planning poker, making them less risky:
- Estimates are made by developers who are experts in the work to be done;
- by talking directly to the customer;
- on a very limited functional perimeter.
However, planning poker cannot be used until the project has begun. It is time-consuming, and therefore costly. Besides, what's the point of guessing what's going to be delivered in a fortnight' time?
The disadvantages of estimates
When the deadline is reached and the work has only been partially completed, developers have two options: announce that they need more time, or deliver to the customer as is, with all the bugs that implies. The longer the deadline, the lower the quality.
As for the technical debt, if the work cannot be done properly, many shortcuts will be taken. Results :
- fewer software upgrades;
- loss of technical and functional knowledge ;
- longer, more costly and risky developments;
The best comes when the customer is told "it's cheaper to redevelop everything than to make any changes to the software", a symptom of the complete loss of control over the project.
The environment in which organisations operate is constantly changing.
A competitor launches a new product, the implementing decrees for a new law are published, an opportunity for external growth arises, and so on. These are all unplanned events that can require applications to be adapted quickly.
At the same time, a customer who has expressed a desire for software with such and such functions may change his mind, because he will have to think about his needs, consult with others and develop them further.
While the estimates may seem reassuring at first, and give an impression of control, they are a trap that gradually closes in on the customer. In the end, the service provider rejects any proposal to upgrade the software on the pretext of honouring its commitments.
Is the need for estimates not so much a business necessity as a sign of mistrust (on the part of the customer towards his service provider or the manager towards his teams)?
If the "deadline", the fatal limit, is not respected, "murderous" e-mails will go out because people "have their heads on the chopping block". A deadly culture, where fear is the foundation of management.
This is the opposite of a culture based on individual initiative, on desire, on the positive reinforcement that companies so desperately need in their organisations.
The "no estimate" movement
The "no estimate" movement is no utopia, and those who practise it on a daily basis know it.
What's important is the relevance of the functionality for users and the value created by the software for the customer.
But this requires courage to challenge the established order and a great deal of imagination to reinvent everything: sales, contractualisation, interactions between customers and service providers, but also the management of developers and project management.
With "no estimate", customers will be able to manage their projects very precisely so that they get the functionality they really need. They will benefit from support throughout the life of the project, whatever direction it takes.
Let's give customers back the power they've been denied for too long: to change their minds about their project.
Author: Frédéric Leguédoisagile evangelist, Director of the agile division at Cloud Temple Grand Ouest
See the Echos.fr on this subject