Wednesday, September 14, 2005

The software wasn't late, it was supposed to take that long

Over time, new words keep getting introduced into the English language. It may take tens or hundreds of years of people using a particular term, but if it’s used enough, eventually it gets put in the dictionary. My spell-checker keeps telling me that verticalize isn’t a word, but enough business folks use it that I’m pretty sure some day it will be. Another term I think has a shot is: thesoftwareislateagain.

For the past year and a half, I’ve been working on a solution to that very problem. Unfortunately I can’t tell you about it yet because my company is still in stealth mode. But it is a multi-faceted solution, with one significant piece of the equation being time estimation.

People keep calling the software “late”. Of all the times we perceive a software project to be late, I submit to you that only half the time it actually is late. A software project can really only be late if it took longer than it should have. That “should have” part implies that we have some divine control over the duration, and we decide how long something should take like we decide what color it should be. Hate to burst the bubble, but we don’t. If a software project’s requirements (what it needs to do) and designs (how it’s going to be accomplished) stay reasonably fixed during the life of the project, and the team and platform are truly qualified for the job, then the duration is what it is. Our job as project managers (and developers) is to figure out that duration ahead of time - accurately. We estimate how long it should take – we don’t decide it.

If it didn’t ship on time and it wasn’t late, then what is it? It was estimated wrong. It’s that simple. If all other variables about a task were reasonably fixed, and it wasn’t done when you thought it would be, then it was estimated wrong. As a rule, we tend to underestimate things a lot. Software development in particular is difficult and complex (at least, to produce good software is – banging out crap is easy). That makes time estimation hard. Too hard to do with hallway conversations and incomplete requirements.

Most people think if a task was scheduled to take 10 days but really took 15, that it was 5 days late. In most cases, it wasn’t late, it was supposed to take 15 days. It was just underestimated by 5 days. Assuming everyone was working at capacity, and even if there were unforeseen technical difficulties along the way, the original estimate of 10 days was an illusion. The real duration of the task was 15 days, not 10. This is an important distinction because it determines your choices for action. If something was late, it’s tempting to start looking for ways to “make people work harder”, which often isn’t the solution. The only bad thing about the task taking the 15 days was that you thought it would take 10, so you planned around it. Then other parts of the organization got screwed up because you missed some deliverable to them. If you knew ahead of time that it was really going to take 15 days, there likely wouldn’t have been a problem. By shifting your thinking to time estimation instead, you can correct the problem at the source and insulate the rest of the organization from these costly inaccuracies.

People all over software-land would be better served by doing more of the homework upfront, so that their time estimates are more accurate. We've all heard the stories of big shaggy software projects never getting off the drawing-board because of too much design up-front. Does that really apply anymore? Seems to me that today, the trend has reversed. People rush ahead without knowing what they're trying to build. How the heck do you estimate the time required for something you haven't even written down in detail?

1 Comments:

About

I can't believe that 70% of software projects fail. It's embarrassing. Something is fundamentally broken here. Left to their own devices, people have a way of over-complicating things. It really doesn't have to be that hard. The trick is knowing what to look for and what key factors to manage. The rest is noise.

About Me

Hi, I'm Craig. I'm currently building a company called Devshop.com. Devshop has a new approach to bringing software in on time, and therefore helps eliminate the total cost of late software.
I started coding when I was knee-high to a grasshopper and I have worked for 5 different software companies in the last 12 years, as head of product development.
In early 2004, I became very frustrated with the fact that general purpose project management methodology is not working for the software industry. My personal belief is that to solve this problem, we need to start focusing on specific types of projects, rather than relying on age-old one-size-fits-all practices and techniques.