Monday, November 14, 2005

Trick Question: Could You Manage a Space Shuttle Launch?

A few months ago I spent a couple hours with a project manager who by all accounts, is rather good at her job (I know several people that know her professionally and did some background checking). We were discussing domain (software) specific project management techniques, like tracking Time Estimation Error, Distraction Rates, and keeping requirements in-sync with schedule. As our meeting was ending, she mentioned that someone had asked her a while ago whether or not a good project manager (or a project manager with a good project management methodology) could manage any type of project – like a space shuttle launch. She quickly said yes, because the basic elements are the same in any project. It occurred to me on the drive home that this is not an uncommon belief – that a project is a project is a project...

So – why we are we (the project management discipline at large) so terrible at running software projects specifically? It’s a well known fact that the majority of software projects globally are considered failures (Standish Group’s Chaos Report) – failure being defined as: late, off-spec, and/or over budget. If general purpose project management methodologies aren’t making software projects slam dunks, then either the methodology isn’t all it’s cracked up to be, or there’s something about software projects in particular that continues to trip us up. I say both.

Here’s a trick question. I will read all sorts of things into your answer to this question and tell you about them in a minute: If you were the head of NASA, responsible for choosing the project manager for the next space shuttle launch, and you had 3 candidates to choose from, which would you choose? Here are the candidates:

“Newbie PM (Project Manager)” – has accreditation from a leading project management school; graduated top of class; knows the PMBOK (Project Management Body of Knowledge) like nobody’s business; can quote the process to you word for word; never managed a project.

“General purpose PM” – has accreditation, and has 10 years experience managing all sorts of projects (but never any 2 of the same type); sample projects ranged from: building a new home, a Windows 2003 server rollout, a training program for a new software system in an organization with 10,000 employees, planning a sales conference, etc.

“NASA veteran PM” – has accreditation, 2 years experience managing a variety of projects (similar to candidate #2), but has been managing space shuttle launches for the last 6 years.

Which would you choose? You’d probably want to know their track record too, but for the purpose of this little game, that information is not available. I’d bet dollars to donuts you’d pick #3 – the NASA veteran. But if you also started this article thinking that with a good process you can manage any type of project, then something is at odds – those 2 opinions are inconsistent with each other. If you truly believed that the process was the key, then technically any of those 3 candidates should do fine, because they all have the process down pat (the accreditation). And candidate #2 actually has more years experience overall. Reading between the lines, here’s what I think is going on:

Managing isn’t a true/false binary thing. Of course you can manage any project with any project management methodology, but the real question is: what would your success rate be? If you chose candidate #3, it’s because your instincts told you that experience with that particular type of project (a space shuttle launch) counts for a lot. Most people would intuitively believe that candidate #3 has something above and beyond the other 2 candidates.

Most project management methodologies are general purpose. For whatever reason, they continue to embody the opinion that all projects are the same – and should be managed the same. They are specifically designed to take the human element out of the equation – to say that anyone following the process can manage a project well – it’s the process that counts. For software projects en-mass, this approach clearly isn’t working, as evidenced by the poor success rates.

Today’s project management methodologies are useful for teaching someone the ABC’s of project management. There certainly is a lot of useful stuff to be learned. Unfortunately, there’s also a lot missing. Just like in school, consider that the typical project management accreditation is like a Bachelor’s degree. And we all know how dazzled prospective employers are when we tell them that we have a Bachelor’s degree right? Well, maybe not so much. Current project management methodology is the scholastic equivalent of reading and writing. You may need it, but you only learn the good stuff after you learn to read and write.

The real power (of success) – the advanced stuff - comes from some degree of specialization. If you want to go beyond the basics of project management, and hike up your success rate, you’ve got to focus on a particular type of project. Most of us do at some point in our careers anyway, because the organizations we work for are somewhat specialized: IT, Construction, Legal, whatever. What isn’t typically specialized however, is the methodology we use to manage those different types of projects. Our organizations specialize in some type of business, we specialize in some kind of project, and then we go use a general purpose methodology – no wonder software projects are late most of the time.

Specializing a project management methodology simply means looking for factors that typically affect a certain type of project (example: software projects), and modifying the methodology to account for those factors. (This is another way of saying: leveraging domain specific experience.) For software projects, some of the top factors that throw them off the rails are:

Time estimates are wrong – granted it’s difficult to produce accurate estimates, but few actually try anything more scientific than gut feel estimates, so we haven’t quite exhausted the possibilities here.

Distraction is rampant – software projects are long term (6 to 12 months) by nature, and are planned to have teams work on them near full-time, but the actual amount of time they get to spend on them is typically far less than near full-time; such is the nature of business.

Requirements consistently fall out-of-sync with schedules – we’ve somehow convinced ourselves that we can continue to evolve requirements and designs all the way through the project, but somehow the initial (gut feel) time estimate should stick.

If we know that these are the biggest common factors that throw a particular type of project off the rails, then what have we done to our methodology to account for them? Not much. Typically, most project managers of software projects are still trying to get away with that plain vanilla (“goes with everything”) project management methodology. It’s never going to work. It’s only half the solution.

Veteran project managers that have a high success rate typically use domain specific tips and best practices to run their projects. They’ve developed their own checks and balances to alert them when something is sliding off track. They’ve learned over the years, what the common factors influencing their particular type of projects are, and how to manage them effectively. Mostly, they do it in their head – they rely on experience and intuition to side-step the common pitfalls. For example, a veteran software project manager keeps tight control over requirements and schedule – keeping them constantly synchronized. He or she knows enough to take developer time estimates and pad the heck out of them, because there is typically an error margin with them. He or she also knows that on any v2 of some project, there had better be some time built in to fix bugs from v1, based on experience.

It stands to reason that these domain specific habits of the successful veterans would be of tremendous value to all other project managers in that particular domain. The trouble is, currently, it takes years to develop that experience and success rate. Wouldn’t it be great if this stuff was sharable, given to each newbie project manager in a particular field, and more widely and explicitly adopted? I think it would have a dramatic impact on the software industry’s track record as a whole. In fact, wouldn’t it be great if that acumen, those tips, tricks and experiences were built into your project management tool so that tracking, trending and reporting on all of it was automatic?! (Blatant plug: My company[Devshop.com], still in stealth mode, is working on a solution to this very problem – stay tuned!)

If you want to improve your success rate with project management, specialize. If you’re taking on projects of similar types (all software projects for example), don’t automatically look to more accreditation or general purpose PM methodology for the answer. First look for the patterns that throw your particular type of project off the rails, and manage those factors first.

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.