Programmes are the reason so many projects are deemed to have failed.

Build a dungheap and the insects will come

I just left a meeting where we discussed a large and complex programme of work and my mind kept going back to recent discussions about why projects fail. We have been talking about project managers who stay in the office playing with gantts and charts and PMs who know nothing about their subject matter, but see themselves as traffic coordinators. These are real concerns and they are at epidemic level at least and need to be discussed and resolved.

Take one step back from this discussion,however and place yourself in the average programme office

If the Project manager rarely sees the battlefield, and spends his time constructing fantasy plans without ever checking with reality and assuming that things will stay the same, then imagine how far removed the average programme manager is.
Today I watched just such a Programme manager going through a programme plan and showing the position of each project and of each tranche and giving a thoroughly convincing performance, but based on a few conversations with project managers before I went in, things were not at all like the programme manager’s presentation suggested. Not only was he highly removed from the truth about the various projects, the truth of which was obscured behind vague and even pointless KPIs, but he had no idea of the true situation within any of these projects. One project had reached it’s milestone just ahead of the presentation by launching something totally flawed in the knowledge that it would not be found out for a while and if they hadn’t fixed it in the meantime they would deal with it then and feign ignorance of it. The KPI was declaring completion, not passing though any realistic test of completion.

How can you risk manage a programme without total honesty and a powerful beam of light?

I dread to think of the consequences for his programme of a key project on the critical path getting into serious trouble. If he is measuring the programme with this type of metrics and this lack of control, what chance is there of coming anywhere close to success?
As it happens that project is a critical one and it can stop the entire programme., it should be the focus of major attention until it is out of trouble or the whole thing is abandoned.

There is no difference between this handling of projects and programmes and the commercial practices of reporting false profits to keep shareholders happy and  keep the capital flowing your way.  We have created the conditions for failure and it will continue to happen regularly just as a pile of compost left in the garden will attract plant life.
Is there a realistic answer on either front? I will have to think about this one.

One note in my notebook is quite revealing, no member of the board was present to learn how things were going.



Agile Agile the rumblings continue. .

Had another heated discussion with a self professed agile Guru who declined the offer to take the conversation public and place his arguments here, so I will do it on his behalf, but allow him the anonymity he desires. I will refer to him as John for argument’s sake and leave out some of the less important stuff.

The argument went like this:

John:  Your perception of agile is not right, you just don’t see the real benefits of agile because you are not a true agile practitioner, you just use it as a looser form of waterfall when it suits you, but you never really took the faith. We are delivering year in and year out in a way we never could with a traditional approach.

Ed: I’m inclined to take that as a compliment. I hold deep suspicion of anyone who takes a methodology too seriously above and beyond the actual delivery of an end. I have indeed used agile to great effect, but wouldn’t use it except in situations where I believe it is the better approach.

John: That’s just it, you believe you know better, but if you tried it in this other situations you would find , like we do that it delivers more every time.

Ed: I would be interested to see the definition of delivers for the sake of comparison. I won’t discount the possibility that you are right, because like you, I don’t have facts and figures with which to make a real argument, but I do have compelling reasons for my decisions that I am happy to share with you.

John: And they are. .


1. Given and ideal world, the shortest and cheapest way to an end result in software is to know exactly what you want to achieve in advance, then know exactly  how is best to deliver it via software, have experienced people to do it, test rigorously against your acceptance criteria and roll out it once working perfectly.   I doubt anyone would argue with that.  I do accept that it probably has never happened and possibly never will, but it is the perfect scenario.
If we both started together and you used agile while I used a waterfall cycle, there’s little doubt that I would finish first and come in cheaper, though given the smoothness of the task, you would also perform well.

I would expect in that scenario, to get the business design right first time and agreed, to get the system design right first time and to have a very low level of defects in testing and instant acceptance by the client. Your trial and error approach would waste precious time and produce unnecessary artifacts.

2. The reason a business and I include in this definition the majority of public bodies, invests in IT is to save money or earn money. A commercial operation needs a return higher than the cost of capital as a fundamental criteria and it must also qualify as best use of limited capital.

The toughest part of a business case is nailing down the cost. If you don’t know the cost with a level of confidence, you can’t estimate the return confidently and you don’t have a case.

The agile argument about  “fit for purpose at  maximum cost” works well provided “fit for purpose can be relied on to deliver the expected returns and assuming that  it can be achieved, but ultimately, unless you can define the requirement well enough in advance to estimate the cost within reasonable boundaries and prove a business case, you are unlikely to ever get off the ground and probably should not.



I don’t believe there would be a great deal of difference between the two performances is that case.

Anyhow, that’s all well and good, but there are many other scenarios where the business case is proven by the do nothing scenario alone E.G. defence, environment etc where the costs cannot be calculated accurately, but there is no argument about whether it should be done other than to figure out what will work best.

Ed: I agree with this entirely and in any of these many situations, I too would use an agile approach to remove the likelihood of a colossal error by learning as we go along.

It went on further but the point has already been made

This conversation went on a little longer and covered more ground, but I do feel that a lot was revealed about the importance of using the right approach for the right situation.

I do believe that a good business analyst with strong consulting skills can still earn his keep time and again by getting the requirements defined , understood , tested, verified and agreed at the outset so that accurate costing and planning can occur and the most cost efficient route can be taken.

I often see an agile approach taken as a substitute for consulting skills rather than as a good strategic decision and I do believe that this does nobody any favours least of all the agile approach itself.

About the author

What every business should know about agile

When is a business case not a business case

Agile- is this a short lived fad?