Please, not more of the same (1 of 3)

Last month Paul Tudor alerted me to a 2012 McKindsey report Delivering large-scale IT projects on time, on budget, and on value.  I pulled it out yesterday as I wanted to read it for my opening keynote at the Global Scrum Gathering in Berlin next week.  In that keynote I plan to talk about issues of scaling a complex system and how to engage the 'C' level beyond IT management.   The report is two years old but I doubt things have changed that much so it gives me some key data.  What it doesn't do is really given any idea as to a solution.  In the manner of too many consultant reports it's good on diagnosis, poor on solution.   In effect it simply proposes doing the old things better along with the usual platitudes of securing the right talent, engaging stakeholders, aligning incentives and rigorous quality checks.   

Given the amount of money people pay the large consultants you would have thought that if that were the solution by now we would have achieved a satisfactory outcome.   I remain frankly amazed at the money people will pay to simply get a collection of same again platitudes trotted out as the solution to life the universe and everything.  At one level the easiest answer to that question (and one that is as effective as the platitudes) is forty two at a more profound level we need to ask if we shouldn't, after decades of repeated failure, think differently about the problem.  That is something complexity allows us to do.

Let's start with some highlights from the report, four are direct quotes, the fifth is my summary of one table:

1. “On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted.”
2. “17 percent of IT projects go so bad that they can threaten the very existence of the company”
3. “unpredictable high-impact events—“black swans” in popular risk parlance—occur significantly more often than would be expected under a normal distribution'
4. “the longer a project is scheduled to last, the more likely it is that it will run over time and budget, with every additional year spent on the project increasing cost overruns by 15 percent.”
5. The average cost overrun is higher for software than non-software projects (66% to 43%) as is the schedule overrun (33% to 3.6%) but the benefits short fall is significantly less (33% to 133%)

The last is interesting and I think backs up a key phrase I have been using a lot lately, namely that we need to stop using manufacturing metaphors and methods in software development and start thinking more about service.   Service is either to retrieve success or gain benefit with failure, in practice planning for early safe-to-fail experiments would make a virtue out of what is an obvious necessity.

So that's the problem, what approach should be adopt to a solution which is not simply more of the same?   I'll return to that tomorrow and conclude it after the keynote on Monday.

But by way of a trailer, and a link to the Gaping Void cartoon that opens this post, please read and reflect on the following:

Economists and workplace consultants regard it as almost unquestioned dogma that people are motivated by rewards, so they don’t feel the need to test this.  It has the status more of religious truth than scientific hypothesis.”

“The facts are absolutely clear.  
There is no question that in virtually all circumstances in which people are doing things in order to get rewards, extrinsic tangible rewards undermine intrinsic motivation”

New Scientist 9th April 2011 pp 40-43