As software project managers we have a reputation for delivering poor quality products, finishing late or over running our budget. Is this because as project managers we are deficient in some way, or is it the nature of our projects that makes it so hard? How do project managers in other fields get on? Can we learn something from them?

I was pondering these questions when I spoke with someone in a non-software company about how their projects are run. I’ll compare what they told me with the way we run our projects in the software world.

They work for a national charity who run projects from government and similar public sector organisations.  Before a project starts it must have received funding, usually as the result of a bid process. This necessitates a certain level of understanding of what is involved in the project and the cost of performing that work. However, it does add a level of competition that perhaps leads to over optimism and cost cutting.

The projects they run all tend to be very similar in nature even though they may have very different goals and be of very different sizes.  A project usually starts with some desk research; examining the previous work in this area and setting the context for the rest of the project.

Next comes a phase of original research; producing questionnaires, arranging interviews or focus groups, and gathering the results.

The project ends with the analysis of the new research and some form of dissemination of those results; a publication, a conference paper or other specific event.

At this level of abstraction it could be argued that producing software also has a repetitive pattern to it; we specify what we wish to build, we do some work to produce it and then we test and release it.  However, I think one of the key differences between the two types of project is in the details. Let’s explore some of those details so you can see what I mean.

Desk research has been transformed over the years and is now almost exclusively searching on the Internet for information. This can be easily time-boxed and a certain level of diminishing returns will apply (thanks to Google page rank) – after all if you can’t find something after several days of trying, how important is it?

The risks here are the same, you find something or you don’t. You are unlikely to overrun your timescales as you can simply stop when time is up and use whatever has been found so far.

The next stage of original research is again well understood. There are only so many ways in which data can be gathered. Questionnaires tend to follow a similar pattern, use a standard method of scoring the answers and suffer the same problems in analysis. The same can be said of focus groups and interviews, it is always difficult to find the right people, encourage participation and keep the discussions on track.

The final stage of analysis, presentation and dissemination is again well understood, with similar risks to be considered each time the project reaches this stage.

So what about software? Well, the things we are asked to develop can vary greatly, they are nearly always unique and often not very well understood. So we have to think uniquely about each project and be aware of the risks that apply to that particular project. We can use our previous experience as a guide, but there will always be surprises.

This pattern of pioneering continues into the development and testing stages. As we are designing something unique, we are therefore building and testing something unique. We can make use of re-usable components, we can build at a higher level of abstraction in order to reduce the timescales and risks, but the risks are still there – chances are no-one has ever used those components in the same way and in the combinations you are using them and expecting the results you are expecting.

The final part of our software project is the release stage. This stage has improved greatly over the years and is now perhaps an area with the least amount of surprises. You will almost certainly be deploying using a technique done many times before and so should contain minimal risk and be easier to plan for.

As we can see, running a software project contains many more risks and would appear to be a more difficult prospect to manage. So, we can at least feel a little better about our failures. 😉

What I really wanted to know was there anything we could learn from other industries, and in particular from this conversation?

Here’s the bit that surprised me. Our software projects were already way ahead in being able to recognise risk, deal with change and deliver results. Software project managers appear to be leading the field!

Perhaps we need to be ahead of the game, not just in our implementation of a methodology, but in our understanding of why it is important.  If our projects are to stand any chance of success we need to do all we can to help.

Being able to embrace change and focus on the customer should be something everyone benefits from. These things shouldn’t be limited to software projects, but perhaps without the bad press other industries don’t feel the same need to change.