Bad Business Cases Cost Lives

A business case is meant to be a rational unbiased appraisal of a business change. It carefully weighs the balance of business benefits against the cost. It may appear a dry and fusty financial document, but the dull exterior can often hide the passion and emotion that contributed to it.

Resource in any organisation is carefully rationed, so a successful business case sign off, can mean that you win and someone else loses, and winning and losing is the body politic of any organisation. Winning is career enhancing, losing is not.

In our MOD case study there are not only ambitious individuals climbing the greasy pole, but there is fierce inter-service rivalry. Cash spent on a new Trident submarine for the Navy, can mean less helicopters in Afghanistan for the RAF, but failing to have adequate scrutiny of any of the projects means that the MOD becomes overstretched and fails to deliver :

This overheating arises from a mixture of incentives within the Ministry of Defence. In particular, the Armed Forces, competing for scarce funding, quite naturally seek to secure the largest share of resources for their own needs, and have a systematic incentive to underestimate the likely cost of equipment.

Unfortunately the current system is not able to flush out at an early stage the real costs of this equipment, nor does it make effective prioritisation or rationalisation decisions. As the MoD almost never cancels an equipment order, the process of over-ordering and under-costing is not constrained by fear on the part of those ordering equipment that the programme will be lost.

Equipment plan construction is dominated by a “bottom up” aggregation process, which makes it hard for “top down” strategic guidance to control the balance of investment. Effective forums do not currently exist to allow top down guidance to control the evolution of the equipment programme.

These forces and incentives create an over-large equipment programme, which contains within it a significant underestimate of the likely out-turn, making the programme even less affordable than it appears at any given moment in time. When this over-large and inflating programme meets the hard cash planning totals that the MoD can spend each year, the Department is left with no choice but to slow down its rate of spend on programmes across the board.

The result is that programmes take significantly longer than originally estimated, because the Department cannot afford to build them at the originally planned rate.

All this would be bad enough in any organisation, but cost cutting in the MOD can cost lives, as the report by Charles Haddon-Cave QC into the death of 14 service personnel who died in 2006, when a Nimrod crashed in Afghanistan, so clearly demonstrates. Unfortunately it does not stop there, as this excellent article from the Independent illustrates.

Project Managers Must Read This

A couple of weeks ago a report was leaked to The Times newspaper. The report was about MOD procurement. The report headline was that:

Across a large range of programmes, this study found that the average programme overruns by 80% or c.5 years from the time specified at initial approval through to in service dates. The average increase in cost of these programmes is 40% or c.£300m.

The report is over 300 pages and can be found from a link here. However, although this report contains a lot of acronyms and statistics it is written not by some retired judge or some fusty civil servant but by Bernard Gray, who in earlier life was a respected journalist.

So the report is not only immensely readable (if you happen to be a project geek) but has some fantastic insights into how and more importantly, how not to manage projects. Forget PRINCE, all project managers should read this.

What we will do over the next few weeks is extract some of the nuggets contained in the report. It will take a few weeks because the report is very long, but stick with us because this is a project management case study on an epic scale.

Y2.1K

It is all history now, but the millennium bug was a big scare in the late 1990's. It was a scare that seemed so 21st century, and encompassed all that was great, and all that was alarming about information technology. The information technology age was barely fifty years old. It had only been in the 1940’s that the first computer: Colossus had been built at Bletchley Park by the brilliant GPO engineer Tommy Flowers, and the first programs had been compiled by the mathematics genius Alan Turing.

It was those early days of programming that were ultimately at the core of the millennium bug. In the 1960's & 1970's, when computing really got underway, systems programmers tried to minimise code to save precious memory. As a result year dates were coded with two digits; e.g. 97, 98, 99, 00. Little thought was ever given to the year 2000. Back then the 21st Century would have seemed so far in the future, that by then even Dan Dare would have hung up his space suit. However, programs that were once developed on punch cards, were converted to paper tape, then magnetic tape. The ghost was in the machine.

To solve the problem, organisations around the world, investigated the code in every program ever written. Organisations that had developed their own software had to examine every line of code. Organisations that used proprietary software had to ensure that all the software they used was Y2K compliant. The alternative was that payrolls would not roll, that traffic lights would go on the blink, that planes would drop out of the sky, that missiles would leave their silos, and that the banking system would grind into meltdown.

The banking system did go into meltdown, but that was ten years later. In the late 1990’s all organisations instigated Y2K projects to stop these events happening.

Y2K was a change that affected every unit, every department, every business, every area, in every region, in every country within and outside an organisation. The notion of developing systems down stove pipes was no longer relevant. The need was to pull all Y2k projects together, and manage them together across all areas of business. The programme had come of age.

Y2K programmes blossomed in most organisations around the world, as organisations looked at one another and quickly adopted best practice. The situation was unique, for once any thought of competitive advantage was put on hold as the world worked together to avoid a digital catastrophe.

The benefits of making change happen through a programme of activity were quickly realised:

• Coordinate projects / work / activity across the space to focus on an overiding objective.


• The programme is given the same status as other functions or business units, even though it is a temporary entity.


• Its has its own dedicated leadership team, which is heavily and actively sponsored by the senior leadership team.


• Risk is managed centrally by the programme, and not fragmented across the enterprise.

Y2K was a success. There was virtually no digital disruption. The world was saved, but as important, the way in which that success was won became the way that organisations would approach future change. The legacy of Y2K in Y2.1K is programme management.

Layer Cake

The latest version of PRINCE2 (2009) introduces the concept of layering, i.e. tailoring the PRINCE2 methodology to the complexity of your project. Easy projects have some PRINCE2 and scary projects need lots of it. Evidently PRINCE2 is no longer just a project methodology, but more of a tool kit that the Project Manager can use to hammer their projects together.

Most likely most Project Managers will already use PRINCE2 in this way, and so will be well used to doing their own hammering and layering. Project Managers are usually quick on the uptake and will have learnt how to create a PRINCE2 compliant project with the minimum of documentation, bureaucracy and effort. If not, then they should take the advice of Eddie Temple a character in the film Layer Cake (2004) who said, 'You're born, you take shit. You get out in the world, you take more shit. You climb a little higher, you take less shit. Till one day you're up in the rarefied atmosphere and you've forgotten what shit even looks like. Welcome to the layer cake son'.

Not So Hot

No a lot of activity on this blog lately. Why?

Well to paraphrase Lyndon B Johnson. Writing a blog is a lot like pissing down your leg. It seems hot to you, but never does to anyone else.

Watch this space.

The Hedgehog and the Fox

Too often we are asked, 'Do we really need a Project Manager..........?' and then there is a some justification'............. because this project is: quite small / there is no rush / the technical team know what it is all about / Jason has been on a Prince course / Barry from Finance is leading on this etc etc.

Then that makes us think is a PM really necessary? What will they add?
When you look at a project team, do you ever think well that looks like a fox leading a bunch of hedgehogs.

"The Hedgehog and the Fox" is the title of an essay by Isaia Berlin. Berlin's essay essentially describes intellectuals and a fundamental difference that may divide human thinking. Some people think broad brush like foxes, while others are single minded and stubborn about detail and think like hedgehogs, they are the experts who know one big thing.

Berlin illuminated his analogy by explaining that hedgehogs "relate everything to a single, universal, organizing principle in terms of which alone all that they are and say has significance." Foxes, on the other hand, "pursue many ends, often unrelated and even contradictory, … their thought is scattered or diffused, moving on many levels, seizing upon the essence of a vast variety of experiences and objects."

The Project Managers role is about pulling disparate stuff together, dealing with stakeholders and suppliers, organising and motivating the team, planning the work, and sorting detail while also having the bigger view about how the project fits the business and how one project relates to others. Invariably the PMs are foxes managing an army of hedgehogs. Hedgehogs on the other hand have the detailed technical expertise in software development, security, networking, technical architecture or whatever. The role of the Project Manager and the individuals in the team they lead is very different.

So next time you have to work with a bunch of prickly bastards you will know.

High Speed Organisations Can Wait

Back in January we wrote about how experts were beginning to infiltrate their way into the ranks of ministers, in a madcap attempt by Gordon Brown to get things done. We have also frequently discussed the frustration that any government must have in trying to make things happen, and our pages are full of examples of stuff just not happening or JDDI (Just Don't Do It)

Will Hutton writing in the Observer today was writing about the the state of the country's transport infrastructure, and why it was so appalling that there were no high speed links between major centres. It is amazing how far the UK is behind the rest of Europe:

There are 3,480 miles of railway in operation in Europe where trains can travel at 150 miles an hour or more. Another 2,160 miles are under construction. Yet another 5,280 miles are planned. More than 10,000 miles in all. Britain has just 68 miles and the planning for more began a mere six months ago. It's humiliating. In this key 21st-century capability, Britain is a banana republic.

In the January article we also highlighted the Secretaries of State for Transport, and in particular the last incumbent Geoff Hoon, who Hutton describes as a 'do-as-little-as-possible politician'

His next point was most telling, and explains some of what is behind what we have called a 'crisis of delivery'. These are Hutton's words:

Few ministers do take the initiative. They are overwhelmed by the round of endless meetings, [and] officials who are more keenly aware of the risks than the rewards of any action and who want to keep their secretary of state out of trouble.

Leaders in too many organisations get dumbed down by too much day to day and then become unsure of themselves in an irresistible urge to be risk averse. It becomes easier to talk the talk rather than walk the walk, so they take the easy route. Senior management who advise Just Dont Do It are never held to account.

The average tenure of a CEO of a top 100 corporation in the States is three years and most are in their 50's when they take up the job. It is not very different in the UK, in any business or organisation. For example at the Department of Transport there have been ten Secretaries of State in the last twelve years.

So are these leaders going to rock the socks of their organisations with change. No way, nice and steady does it, high speed organisations can wait.