Estimation

The other day while talking to a new project team, I asked a simple question.
“How many defects (ok, critical defects) do you estimate in this project?”

The blank stares effectively told me that I was coming from another profession. After all we do not quantify such things in the software industry. Reality check, dude! You would be lucky if you got an answer to that question in the past tense.

OK, let’s try the corollary question. In this project, how much time do you expect to spend on resolving defects? Before release and/or after release?
There is a high probability that I get some kind of an answer here. It does not matter, if you are not the paying customer, how accurate this answer is.

So a certain amount of time is estimated for defect fixing; but there is no quantitative justification. Whether you have 20 defects or 2000 they all got to be resolved in the allocated time……or as is most usually the case…the project takes the stake holders for a ride!

There is a lot of talk of how difficult estimation is for a software project. This statement holds whether the organization is doing the 1st project of its kind or the 100th. But then we are a unique industry. We are the only industry (that I know of, and my knowledge of non-software industries is limited) which does appraisals and increments for the individuals without quantifiable data. A salesman is usually rewarded based on meeting specific, quantified, targets….or he is fired. So is a production manager, so is a, never mind…
Only in the software industry are increments given not for quantified deliverables, but for trying or better still perceptions of competence. “Oh, its OK the project was delayed by 3 months. Its not your problem that you only introduced 342 bugs. These things hapoen. So you get a 300% raise. Thank you for staying with us and not looking for another job.

There is only one thing wrong with a project plan which is not adhered it. Just one small thing. It was badly planned. But why do we repeat the same mistakes over and over again? Must be something to do with the fact that we are ‘intellegent workers’.

How many project managers take the effort to track actual time against estimated time? Not many.
But this, I now realize, has to be tracked. You estimate that a particular module will take 1 week = 8 * 5 = 40 man hours to complete. It takes 1 week and 1 day = 40 + 8 man hours. (OK, you are still on ‘schedule’ in terms of time, because the said engineer came in over the weekend to complete the assignment.). Now the reality is that your estimate is already off by (48 X 100) / 40 = 19.2 %; either for a particular resource or for the project as a whole. In 1 week, if you are awake to the reality, you need to raise a red flag regards a change in schedule.
I make the humble assumption here that a deviation of ~20% is worth a mention. Actually, since deviations tend to grow exponentially, the project is more than 20% off schedule.

If I were to ask another question of the said project manager – Of all the activities on the project plan, which activities are such that you may NOT need to do them? By this question, I am sure the above project manager is convinced that I am talking to the wrong person – I should be talking to a shrink!

Assume the assumption is correct that each and every activity will have to be done for the project to be completed. This implies that there is no scope for any deviation in the project schedule. No slack what so ever in the project. But deviations are what ‘Risk Estimation’ is all about. For example, if the third party codec binaries do not work as expected then the additional work to be done is … Does this ever show up in a project plan ?– sorry project estimate. Hardly ever!!

So even though everyone talks of risks and the criticality of monitoring them, it rarely ever percolates down to the mpp level. That being the case, it does not make rational sense to expect the estimate to be adhered to.

Another question: What is the basis for all these task estimates on a project? The answer is usually experience. And how many projects have you handled? And how many of these were successful, by any measure of success? Experience is great, but why can’t we have quantified data to back up this so called experience. Without the data, its just the same 1 project experience repeated 10 times. With data collected on every project executed, the experience really matures and judgment ripens.

For any organization there is nothing better than past performance to guide future execution. This is the basic thumb rule used in most manufacturing organizations. But then these organizations have the fortune to employ blue collar workers. Paucity of retrievable past experience is a forte of the ‘intelligent worker’, software community.

We just have to get over the inertia of not collecting accurate data on projects executed. It is a much better and accurate yardstick for improving estimation than function point analysis!