May 28, 2009

What Makes Projects Work

Tags: Software Project Management

Recently I got in a drunken conversation with another long time developer and consultant about what makes software projects succeed. We both had many years of experience with many different projects, so it was particularly gratifying that we largely agreed with each other (or was that the alcohol?). Having seen many people write their prescriptions to project success, I thought I’d add my 2 cents in the form of my observations. I would consider project success to be that the software is delivered, the clients are satisfied with the result and there were no surprises on time or budget (time/budget could be higher than initially planned, but any slippage was identified and explained well in advance). As a technical person, I also include the subjective measure that the codebase would not cause embarrassment (no WTFs here).

Below are the some characteristics of successful projects I have seen, in no particular order. None of them is sufficient by themselves and I’ve seen projects succeed when some of these characteristics were glaringly absent. However, I can’t remember seeing any project succeed without more than a few of these present.

  • Good People. If not the most factor important for success, certainly the most important for enjoyment. I actually think that smart, motivated people who want to get things done can ameliorate many project difficulties. Thus forming a team of good developers should be the first goal of any project. Note here I haven’t said “Smart People”. While being smart certainly helps it’s is not everything (I have a little disagreement with Google’s “only the best” hiring practices here). On more than one occasion I have seen some very smart people get tied up in irrelevancies and doing things “right” resulting in nothing being done at all!
  • Political Support or Cover. The senior management have to want the project to succeed (not always a given in some political firms!). Otherwise, the project will have problems getting the resources it needs. Similarly in larger organisations a project needs to have managerial support, both in terms of the problem being solved and the manner it will be solved. I was once at a place where the senior IT management were all old waterfall process COBOL coders and distrusted iterative development. There was so much friction and so many people just waiting to say “I told you so” (on both sides) that forward movement was difficult. At another place with similarly minded senior management, our immediate manager provided us with cover. To higher management he presented reports conforming to their waterfall style, but allowed us to run the project as we saw fit.
  • Well Understood Problem. The more similar the problem being solved is to previous problems the team has solved the more effectively pitfalls will be avoided. This is one of the premises behind prototyping - solve the exact same problem twice and the second time should be much easier.
  • Tight Iterations with End-user Interaction. I started commercial work just as iterative development was becoming popular (we were taught waterfall at university) and I’m a big believer. I have found iterations lasting just a week or so (or as short as possible while still getting some decent work in each iteration) and then deployed to an environment where an end-user can see it (and hopefully try it out) work best. The idea is to get regular and high quality feedback on whether the project is heading in the right direction as well as priorities for future work and changes required. Every project I have been on has significantly changed requirements from start to end. The chances for project success are greatly enhanced if change is accepted and handled. Indeed the best option is to proactively seek out the changes required and this is where short iterations with user feedback help immensely.
  • Small Teams. I was once on a project with over 100 other technical people. The back and forth of meetings and coordination was inordinately complex. I think Brooks had this right in The Mythical Man Month, and teams should be kept no larger than around 9 people. That number seems to work well and if they are good people, a great deal can be achieved. On that 100 person project, I strongly believe that the 9 best people in a single team would have done much, much better than the other 91 as a team.
  • Flexible Process. I wrote about this before, basically I think software projects work best where they are done by people who look to understand their environment and can adapt - not just retrying the same old thing that worked last time (for you or someone else).