I’ve been thinking a lot about the comments people made on the Best Practices Don’t Predict Project Success post. (Thank you for your comments.) Here’s my experience.
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,” DeMarco and Lister show that in their Coding War Games, there was a 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:
- Before the project, does the project manager have the ability to select the people for the project with appropriate functional skills and domain expertise? If the project manager doesn’t know enough to select the people, does someone? Are people available when they are needed?
- Once the project starts, are people added to the project as needed? Delays in adding people delay the project.
- Is the planning iterative? Any project worth doing has risk associated with it. Planning the entire project in detail is a waste of time and does the project a disservice. Preplanning in detail (especially with an electronic tool) suggests to management that the project will unfold in the planned way. Nope. The schedule is the one way the project will not occur. I look for plans to replan, to take advantage of project advances and to deal with project delays.
- Is everyone watching for defects? Are people cleaning up as they go? This can be refactoring designs or code, or as simple as cleaning up the lab or other common work area. The messier the environment is, the more likely the work product is to be messy. If everyone isn’t watching for defects, it’s harder to clean up the work products later. (Yes, for me, these are interrelated.)
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 adapatability and flexibility when trying to predict project success.