Time estimation. Done.
When I started my career as a freelancer, I used to recur to ordinary techniques of the good old waterfall-style project management. It is not surprising that I also scrupulously tried to determine the time and the cost of a project before starting one. Not that it was a pleasant task or that I wasn’t noticing that the real time I was spending on a project had nothing to do with the evaluations. While I understood that it doesn’t make too much sense to evaluate a task I never done before, based on a one page long non-spec written by a person who seemed that he have no idea what the future project is about; it’s just that I thought I have no choice, and that this is a game we all have to play. After all, what would be a different alternative? Asking the customer to give a blank check?
Reading for a few hours about Agile was largely enough to learn that no, we, project managers, don’t have to play the stupid game. The game is essential for waterfall projects, where, indeed, an unfinished project is a useless project. But who would be so dumb to use waterfall for a project which is just described in a few badly written paragraphs, and where the customer in person has no idea about the actual needs? Well, it appears that lots of companies do that, but I digress.
The idea of evaluating time for an IT project makes no sense. It makes sense outside IT industry. For example, a company who built a bridge can be asked to build another bridge which is very similar to the first one. There would be room for randomness, like a larger river, or large building nearby, or softer coasts, but still, it would be close enough to the previous project to be able to give an estimate. A company who built forty bridges had done enough estimation mistakes to be able to asset something precise enough, based on the gaps between the estimation and the real cost, observed in the forty projects done in the past.
Now, what would happen if a company which built small bridges across rivers for fifty years is asked to build the five kilometers long bridge across an ocean? How precise would be the estimate now? Would it really make sense?
In IT, there are no identical projects. If the same team is asked to do a project they already did, they will simply take what’s already done. The same cannot be done with bridges: you can’t copy-paste a bridge to another location: building the same thing still requires time and money. In IT, every project is new; otherwise, it’s not a project, but a clone of a previous one. Since the project is new, the estimate can’t be based on facts and hard data. Let’s say a team created an app for iOS. Now, it’s time to create the same app for Android. Would it take exactly as long as it took to create the iOS app? Would it be shorter, because all the architecture is already done? Would it be longer, because the team is composed of iOS developers who don’t know Android well enough?
Time estimation of an IT project is quite random. It’s less random for some projects which are well-defined, with clear and complete requirements and a no changes to the requirements policy. It’s more random for other projects where the whole description is two or three paragraphs of text written by somebody who really wanted to avoid thinking a bit about the different aspects of the project.
This means that whenever somebody agrees to do a weakly-defined project for a given amount of money, there is something wrong. In the past, I gave two-numbers estimate: the average price—the price I expect the project would cost, and the maximum price—the price the customer will pay no matter what. There was something wrong with that. Every time. One of those wrong things was that it made it totally impossible to let the customer adjust the requirements over time, and changes to the requirements would be accepted only at the “end of the project”. Waterfall? Anybody?
In Agile world, there is still agreement upon cost, but instead of agreeing what the entire project would cost, the customer agrees that a given amount of hours of a team will cost a given amount of time, and that the team expects to deliver specific features for the first sprint. This makes the project extremely flexible for the customer. A six-months project can stop after three months, because the customer believes that the project is mature enough, or because the customer doesn’t have enough money, or because priorities changed, or… whatever. Instead of a waterfall blackout with a dilemma between continuing a project no matter how much does it cost, and cancelling it without having anything concrete, the customer is now confronted to hard data and the possibility to take a decision to end the project at any time, while having a working piece of software.
An IT project is not something which has a well-defined end of life. Unlike a bridge, whose building process terminates exactly when the bridge is ready to be used, a software product evolves. This makes its end highly unpredictable most of the time. Some projects end because the customer doesn’t have money. Others—and this is the case of too many products—end because they are a complete failure. In very rare cases, projects end because the customer considers that there are no more features to implement, and more importantly, no bugs left.
The unpredictability of a project lifespan is an additional indicator that it doesn’t make sense to estimate the overall time it would take to accomplish it. We can’t accomplish a project, since in order to do it, we must first be able to predict when the project will be finished.
Conclusion:
As a freelancer or an IT company, have a decency to be frank with your customers, and don’t estimate how much a project would cost. Unless, of course, the project follows strict waterfall model and has functional and non-functional requirements which span thousands of pages, making it extremely clear and predictable, without even a need for prototypes.
As a customer, use the fact that a freelancer or an IT company is ready to give an estimate as a hint that you’re dealing with inexperienced persons. If those persons talk about Agile, flee; find someone who will do the project without staying at 90% for months and without asking you to pay ten times the original estimate.
Why, as a customer, you don’t want to deal with someone who claims he can estimate your project?
Because people who claim they can estimate the unknown are very probably either lying or not knowing what they are talking about.
If the project follows waterfall model, you won’t be able to add or change the requirements before the end of the project (unless, of course, you’re ready to pay much, much more for the additional cost of changing the requirements themselves). In a non-Agile project, changes are complicated, so either they are done at a high cost (including the renegotiation of the contract), or they are postponed until the project is finished.
The estimate will be wrong. If it’s not, either your project was a good candidate for waterfall model, and the requirements were very detailed and clear, or you’re just lucky. You may be less luckily, and find yourself paying, say, ten times more compared to the original quote. Business-wise, this is not a risk you want to take for every IT project.
If you cancel the project before it finishes, then you find yourself with a useless bunch of lines of code which can be only thrown. Agreed, you can go to another IT company and ask to modify the code. It will cost you less to just start the project again. In Agile projects, this doesn’t happen: you can cancel a six-month project after two months of work; this would result in a working product which doesn’t have too many features. You can then continue to add features, if not painlessly—since it’s always a pain to maintain a product made by somebody else—at least more easily than waterfall projects, since here, what you get after two months is a piece of working software, covered with tests and correctly refactored.