Monthly Archives: June 2012
A late project? Well, it has been known to happen. According to my wife (who has got a far better memory than me), almost all my projects are late.
I attempt to explain that they are not really late, someone has just decided to add more features. Or we all decided to postpone the release, to make sure the delivery had the required quality. Then she goes “But the project was supposed to be done last tuesday, right?” and I’m like “Yes, but..” and she cuts me off “So that makes it late.”
A popular term is “definition of done“. Maybe we should also discuss another: “Definition of late”. The definition of done may be challenging to define, and across an organization it’s very likely to mean different things to different people. One would think that definition of late should be easier to define.
“The project should be done by November 1st. If it isn’t, then it’s late!” Right. But wait. Done? If the project isn’t done until September 1st it’s late. Suddenly avoiding being late relies on something being done – and we just agreed that “done” is a tricky topic. Or is it?
When we postpone the release to production in order to do some additional QA, we’re not really late right? We’re done with the project, we just haven’t released it yet. That must be okay? Or does the lack of quality mean that we tried to deliver too much in too little time?
And if the project owner asks you to add more features, surely that’s no problem. He is the boss, after all. I suggest you explain to him that it will postpone the delivery of all the value created so far. A better solution would be to deliver what we agreed, so that the project outcome will benefit the customer as soon as possible. Then we can add more stuff in the next round.
So, back to being done and late. You see, the thing is that the customer rarely considers a project as done before he can create value from the result. So if your customer can’t create the expected value from whatever he ordered from you, then you are not done.
And if the customer can’t create the aforementioned value by the agreed delivery date, then my friend..
You are late.
As I’ve mentioned before, accurate estimates are hard. To make matters even worse, you will never become an expert at it.
It’s just not possible. If you practice enough, you may become an expert at playing chess or tennis. Why? They are both activities with predictable rules and clear consequences to any action. The concept isn’t difficult to grasp, in order to master it you just need to practice (a lot).
The saying goes that no chess game is ever the same, but an expert chess player will still have an intuitive feel for the game. Looking at a chess board in the middle of a game, she can immediately tell you the preferred moves and the likely outcome of the game.
Estimating complex projects is another story. You probably have to deal with unknown uknowns. There are the stuff you know, and the stuff that you know that you don’t know. But what usually kick you in the groin, are all the things that you don’t know that you don’t know. Any number of things may happen during the project that will dramatically affect the outcome.
To make matters worse, our brain has a nasty habit of completely ignoring unknown information. In the context of estimating, that means unless you know absolutely everything about the task at hand, you will underestimate the work required. You have to force yourself to consider the known unknowns, and include them in your estimate.
Your brain also loves replacing a hard question with a simpler one. And most of the time, you won’t notice. “Will it be a good investment to buy this house?” is a complicated question, that most people readily replace with “Do I like this house?”. Much easier.
The same thing happens when someone asks you to estimate a complex system based on some simple drawings of the user interface. Your brain goes into lazy mode, and attempts to replace the difficult question “How long would it take to design, build and test all the logic behind that system while working in a team of several people?” with the much simpler “How long would it take me to build a system that looks like that?”
And the answer to that question, as we all know, results in a useless estimate.
The third problem is that we are all too confident in our own abilities, and in hindsight we are usually convinced that we had a hunch or gut feeling about the true outcome of the project. So whenever a project goes over budget, we usually “knew” deep inside. We just need to follow our gut the next time! And whenever a project is actually on time, we have probably added features until we spent the available time. And whenever a project is delivered before the deadline…just kidding, that never happens.
So the next time you are asked to estimate something: Pay attention to your gut feeling, that is your experience talking. But force your brain to keep working. Consider what you don’t know, and be honest with yourself and everyone else about the fact that your estimate will never be 100% accurate. The larger the project, the more uncertain your estimate will be.
If you want to know more about how your brain works in relation to decision making and predicting the future, I strongly recommend “Thinking, Fast and Slow” by Daniel Kahneman.