Getting Better to Stay the Same?
So, the latest Standish Report is out. The figures in it are depressingly familiar. More projects are failing. Only about a third of projects are succeeding – on time, on budget, on scope.
Now, there are a lot of reasons to be dubious about the CHAOS report statistics. The categories are fairly vague, and don’t appear to look in any depth about whether (for example) a project being cancelled was a good project management decision or not. The methodology they have chosen for the study is unclear. So as an absolute measure, they’re not up to much.
But because the report has been produced for a number of years now, with, presumably, the same methodology, we can get some value from using them as a relative measure – are things getting worse, or are they getting better?
Well, in fact, the figures for project success seem to be holding roughly level over the past few years. There has been an improvement from the original report back in 1994, which suggested a success rate of 16%, but we seem to have been hovering around the 30% mark for many years now.
And this is worrying, considering the amount of effort that has gone into developing better and stronger project management methodologies, techniques, tools and so forth. Taken at face value, the CHAOS report would suggest that we needn’t have bothered!
That suggests a couple of possibilities. The first one is that as a group, project managers have simply got it wrong. Perhaps the tools we are using to manage projects, the methodologies and techniques, simply have no effect. All we have done is made our own lives harder, but at least we haven’t damaged the projects we work on.
I’m not really inclined to believe this possibility. (Though, of course, as a project manager, I have a vested interest in saying a methodology is needed…) The reason I’m not convinced is that the methodologies have been developed from the experiences of many project managers. They are finding new ideas that work for them in their projects – they are seeing an improvement in the project management process by using these techniques.
The other possibility is the one I am interested in. It’s loosely based on the Red Queen Hypothesis. What if project management is getting better, but projects are also getting more complicated? What if we’re running just to keep still?
Think about the IT projects you’ve been involved with over the years. Have they become more complicated? Have our ideas of what we can achieve become bigger? Do projects now pull in many more aspects of the business than they used to?
I’m not even entirely sure how you would test this idea. (Always a hallmark of a less than perfect hypothesis…) It would require some way of evaluating the complexity of a project against a baseline – a baseline that needs to stay steady as the world changes around it, and as new technologies may make some of the assumptions in the baseline wildly incorrect. Now that would be a study worth doing.
I genuinely don’t know. My personal feeling is that, yes, IT departments are willing to take on more complicated projects these days. But I’m wary of drawing a conclusion from my own, purely anecdotal, experience. Others may have had very different experiences.
But certainly when we think of how much more we can do with IT than we used to be able, of the added complexities of what it can achieve, there is a certain attraction to the Red Queen idea. But maybe it’s just wishful thinking and self-justification on the part of a project manager…
What do you think? Are we getting better? Are projects getting more complicated? Or have we just overloaded ourselves with methodologies we should dump? Let me know!
Interesting comments. My background is slightly different coming from business side (rather than IT) project management within Financial Services, where projects tend not be massive. However, one theme I have seen is a correlation between success and those projects where business and technology work together throughout the project life cycle. E.g. if the project is primarily a business change/process improvement one then the business is responsible for the success of the project and lead-manages the overall project. I am interested in other views on how much of project failure is not just because we are doing more complex things but is also down to lack of / inappropriate: (i) project ownership; and (ii) rigorous analysis of what we want to do and how we want the process to be once it is changed. Or put another way, are we disappointed with the family outing because we all got in the car without thinking where we wanted to go or what we wanted to do when we got there?
I’m not buying the Red Queen theory. If any trend has emerged, it is that we do a lot less custom software and a lot more COTS implementations.
When we did Custom systems, there were a great many skilful people involved who primarily followed SDLC processes designed to deliver systems that met busyness requirements. That part of projects worked pretty well, it was the time to test and stabilise them that caused problems.
Today we have no process to do any of this and no few skilled people involved.
Project managers can’t deliver software without a proper software training any more than butchers can fly to the moon and that is the big mistake.
Much of the cause is the relationships developed between business and suppliers who are adept at driving a wedge between businesses and their IT staff in order to serve their own ends.
If project managers are to take responsibility for the problems and start fixing them then first they need to either be trained or properly advised and secondly they need to have the power to make those decisions.
Currently neither case are generally the case.
Things don’t look better and I don’t expect they will anytime soon. PM tools aren’t the problem. People are.
From my perspective the basic thing which drove, drives and will drive results like those in last CHAOS report is people mentality. We accept mediocrity. When we install new software we expect to find bugs there. Heck, we believe our operating systems should be restarted from time to time and fully reinstalled every couple of years.
Do we expect our vacuum cleaners or cars sometimes won’t work like they should? Do we expect food we buy to turn out crappy on occasions? We don’t.
With software it is different. And since “everyone delivers crappy software projects” and “everyone lies in schedules” and “everyoneover-promise and under-deliver” we won’t be appalling if we do too.
Even when people don’t admit that I believe it’s common way of thinking. And it doesn’t surprise me in any way to see poor statistics as a result.