This is a post about a pattern which I’ve been noticing for quite a while on a subconscious level, but which recently became painfully obvious. It happened, as usual, at a client location.
I’m talking about the fact that completing a project ahead of schedule is bad. Very bad. Let me explain.
We all already know (and love) the typical atmosphere that management at most organizations create – an atmosphere that is super-conducive to getting real work done. Not. Further, from a project management perspective (and I’m not being facetious anymore), estimation is hard. It just is. Whatever methods and models you employ to try and make estimates accurate (how’s that for an oxymoron?), you just have to ultimately rely on heuristics. Bring in a bunch of experienced programmers/architects (after all, architects know best) into the room and have them give you an idea of how long the project will take and how many people need to be on it.
Despite my biting sarcasm, I’m actually being serious about one thing – the fact that programmer heuristics is the best way to estimate. I say this more than just because I think that the people who are actually going to do the job should say how long it will take, but because they factor in the environment they’re working in.
Load factors or project velocity depends on more than just the skills of the team members. If the environment (management, company policies, politics, “the system”) make it hard to get work done, well then – less of it will get done.
People working in such typical soul-crushing environments adapt to it – as any human will when faced with something less than perfect (and unchangeable.) They throw in the towel, and become part of the system. They behave the same way the system wants them to – and become risk averse and rule-following sheep with no enthusiasm left for anything other than doing what makes them look best for the year-end review. They adapt to the measurement process and also to the rule-keeping process.
If this were an IT department of a large company (who would have made that connection?), what do you think will happen when a project comes in ahead of the schedule?
Let me tell you what happened at a recent client – they were crucified. Why? Because it was clearly a case of rigging the schedule. Dishonesty. Everyone knows that projects can either be late, or they can be on time. Early? What? Huh?
Everyone knows what early means – the project manager (and therefore the team) had bloated the estimates to begin with so that they can look good to upper management when they complete “on time”. They should now be crucified because of this sin. And they do.
So what happens next? The adaptation process kicks in. A project just can not come in early – a couple of days late (just fashionably so, leaving scope for last minute “heroics”) becomes the norm. Or late, of course, for that is always allowed and accepted (with a knowing, friendly shrug and perhaps a nod). Scheduling and estimates are still bloated, but work expands to fill the available time, and the finish lines are always met appropriately. Works out nicely.
Just never forget the old software development pattern – being efficient and coming out ahead of the schedule is considered harmful.