Monday, October 24, 2005

Stephen makes a point illustrating the 80/20 rule, including 80% of the beer being consumed by 20% of the drinkers!

He's commenting on a survey that asked successful business leaders about their success. They said they focussed on simplicity in everything they did. The study concluded that focused companies were more profitable.

It's so easy to make things complicated for ourselves. In so many cases, the things you only spend 20% of your time on will account for 80% of your success. Doing a "lot" of things makes us feel productive, but doesn't necessarily increase our chance of success.

This is also true in managing software projects. There are only a handful of factors that throw most software projects off the rails - not hundreds. Manage these, and you'll do just fine.

Here are the ones I focus on:

1. Time Estimation Error - If you can't trust the estimates coming from the team, the project plan will never be accurate. There are ways to manage this.

2. Team Distraction Rates - If your plan doesn't account for the times the team is going to inevitably be pulled off the project, your plan will never be accurate.

3. Requirements - If you can't keep a handle on the requirements for the product you're building, or can't express the true impact of changing requirements while you're making those decisions to approve the change, your plan will never be right.

These ones are the secret to delivering software on time. Forget about critical path analysis, Pert charts and automated workload balancing. Projects don't fail because you didn't spend enough time looking at the critical path. They fail because the time estimates were wrong, people got pulled off the team, or requirements changed too much. Manage those.

0 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.