~ By Johanna Rothman
Great people, people with sufficient functional skills and domain expertise can trump process, good or bad. Good process, process appropriate for the context, will help those people. But great people can overcome bad process to deliver a good product.
Bad management, management incapable of understanding how to remove obstacles or how to see the project state, can trump good people and good process. Management that doesn't help is better than management that actually hurts a project. (I once worked for a manager who insisted on calling my customer. Every time he did, he created a crisis I had to resolve. I ended up spending about 50% of my time managing my manager, with the rest left over for the customer and the project. Luckily, the project staff were great, so I didn't have to pay too much attention to them. That manager's actions cost us months in extra project time. But we finally delivered - less than we could have and much longer than it should have taken.)
Good process helps even out the differences in capability among developers. In Peopleware: Productive Projects and Teams, DeMarco and Lister show that in their Coding War Games, there was a huge range in capability. Quoting from page 46,
The best performance was 2.1 times better than the average. The half about the median outperformed the half below the median by 1.9 to 1. When you define and use a good process (reasonable lifecycle and practice for your particular project and context), you can reduce the variation in developer capability, bringing the people originally below the median up closer to the performance of those above the median. But if people don't have the functional skills and domain expertise, they can't use the process the perform well. And, bad management can trump a reasonable process anytime.
So when I predict project success, I don't assume people, process, or management is the one key to success. I look to make sure the project hasn't already shot itself with inadequately-trained people, bad management, or bad process. Then I look for an adaptable project. Here are some things I look for:
These aren't the quantitative measurements I use as a project manager to know when the project will finish or how much rework we'll need; these are the qualitative measurements I use to see if there's any chance the project will succeed. I use the quantitative measurements to help the project stay on track or get back on track. I look for this evidence of adaptability and flexibility when trying to predict project success.
Johanna Rothman consults, speaks, and writes on managing high-technology product development. Johanna is the author of Manage It! 'Your Guide to Modern Pragmatic Project Management'. She is the co-author of the pragmatic Behind Closed Doors, Secrets of Great Management, and author of the highly acclaimed Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People. You can see Johanna's other writings at http://www.jrothman.com