Coping with uncertainty during a major project – climbing the mountain versus Brexit

IMAG0844I had a hip replacement last November, 27 years after I broke it in an accident. The surgeon who set it then explained that though they’d done a good job, it wasn’t a perfect job and eventually the hip would wear out.

Last week I was walking with friends in the Pyrenees, just 3 months after being discharged from the hip replacement. This was a tremendous occasion for me – would I still be a partial cripple, or would I find myself as good as new?

We set off to climb the pic de Saint-Barthélemy, at 2348m the second highest in the Corbieres region, ascending steadily through mist and low cloud from 1300m. We debated options – ascend by the “scenic” but rather harder route, or just go straight for the summit. Given the dull grey cloud we were in spoiling any view, and my natural concern about not overdoing things, we decided to split up; 2 of us went direct for the summit, the other 2 went the harder route (taking the guide book).

So two of us set out for the summit with 50m visibility and no guidebook or map. We just put our heads down and slogged upwards, eventually bursting through the top of the clouds into brilliant sunshine. As we continued up, we then saw the summit, and realised how far we still had to climb, but trudged on steadilyi

The view from the empty summit, when we finally got there , was breath-taking – the tallest summit was before us (just 20m higher) and other mountain tops peeking from the sea of cloud. 15 minutes later our friends arrived, seriously tired after an even harder grind, especially the final ascent.

What has this to do with project management?

Many projects hit a period in their life where leadership changes or vanishes, visibility of the overall objective is obscured or challenged and the team starts to fragment, pulling in different directions.  Brexit is a fine example of this happening from the very start!

When this period is entered, it is easy to panic and start a blame storm that quickly leads to the project stalling and potentially failing – David Cameron resigning and Theresa May stepping up to take the poison chalice was an example of this, the huge swing against the Conservative party at the subsequent election another.

What is needed is, as on my climb, to keep slogging on while things become clearer before making critical decisions, because hard work and progress almost always provide more clarity on the way forward. The objectives may flex, but a project that is making good progress in difficult circumstances is far more likely to succeed than one that stalls and flaps about.

Again, Brexit shows what happen when steady hard work is replaced by dogma, rhetoric and outright lies – the government “demanded” a deal that is worse than was already on the table from the EU when negotiating on citizens’ rights.

Where the Brexit project will end up, no one knows, but we must all keep slogging along to make the best of this farcical project.

 

 

Advertisements

The Elephant in the room – delay in project start

Isn’t it frightening that we take delays to project start so much for granted that we don’t recognize one of the most common causes of “failure” in projects?

Over the last 2 weeks I’ve been talking to many project professional, at the University of Manchester, in a major construction company and at the recent APM conference on Risk Management at Alderley Park (which was excellent, by the way).

We were all discussing the things that go wrong with projects, but the startling point that everyone was making is that late project start against an agreed plan is the most common problem, and that it usually threatens project success before it even starts.

It’s bad enough when the start date slips and the end date matches it, as the context of the project has changed (summer becomes winter, resource is redeployed while waiting etc) but what is even worse is that the target date often slips less than the start date, if at all.

As project professionals, we give realistic estimates for the cost and duration of our projects, only to find that we have to do most of them more quickly with less resource, in more demanding circumstances.

Late starts to projects are not a project management failure, they are a commercial issue, and project managers rarely have any influence over this, but we have to do the best we can and are accused of failure if we fail to do the impossible.

This is due to poor accountability within organisations – if Procurement were held to account for delaying the start of the project  and its consequent failure,  instead of being measured on penny-pinching and trying to squeeze out the last penny on price, things might get better. The cost or project delay needs to be understood and measured, and commercial teams held accountable.

None of that helps the project manager, of course. I’m currently working up my thoughts on this as part of a new programme for the University of Manchester and some industrial clients.

 

 

Simple or complex? The dilemma

Lysanne Currie’s editorial in the April 2016 issue of “The Director”, entitled “Keeping it Simple”, cites a TED talk by Harvard’s Professor George Whitesides, highlighting that the vast majority of people crave simplicity, and it’s mainly academics who relish complexity and emergence.

The article goes on to promote strategic simplification as a strategy to achieve great results, pointing to Sacha Romanovitch of Grant Thornton as a leading example of its success. My personal experience of this was at Centrica, where they executed a complete U-turn from acquiring multiple brands and business to divesting the AA, Goldfish and One.Tel UK to focus on British Gas.

This doesn’t mean being simplistic in your thinking, though. Churchill famously apologised for writing a long letter as he had no time to write a shorter one, and Lysanne quotes Steve Jobs; “Simple can be harder than complex. You have  to work hard to get your thinking clean to make it simple”.

Problems are often complex, and the reality only emerges with time and progressive analysis. The whole of Chaos Theory is about understanding how simplicity generates apparent complexity. When people are involved,  we need to add emotion, contrariness and sheer malice into the equation too.

Solutions are where the benefits of simplification really come in – solutions must be “sold” to, and applied by, many and so must be easy to communicate. Given most people’s need for simplicity, it becomes essential to present the solution as simple, even if it is complex.

There is a process here:

  • probe complexity and emergence during the investigation of the problem, to ensure you get your understanding right
  • invest time end effort to simplify the solution, making it robust
  • If the simple solution doesn’t match “the way we do things”, seriously consider changing the way things are done too

Trying to keep it simple throughout by simplifying the investigation and analysis of a problem creates a grave risk of getting it wrong. There is a sad trail of government initiatives that have had diametrically the opposite effect to that desired, not least government borrowing going UP under the last government.

Embrace complexity, but make it sound simple :o)

 

 

Agile – the way forward for projects?

One of the biggest flaws with the traditional “waterfall” model of software development is that the customer requirements are only validated at the end.

Of course this reveals two types of flaw in the documented requirements:

  1. They were simply wrong/inadequate in the first place
  2. They have been overtaken by events

This is particularly obvious in long defence projects like the F35 replacement for the Harrier, or public vanity projects like the Millennium Dome and Scottish Parliament Building.

Much of the cost-overrun of big projects results from the delays and rework costs of enhancing the finished product to meet the newly-clarified/revealed requirements.

So – if you get the requirements right and build to meet them right first time, the project will stand out as being cheaper than normal. The Rion-Antirrion Bridge in Greece is a fabulous example of getting it right first time, and Cross-rail is looking good too.

The huge strength of the Agile approach is that it validates requirements as it goes along, by integrating end users into the development team, and for software development projects this is great (with a couple of caveats). This means that Agile projects have a tendency to be more successful and better value for money.

So is it a no-brainer? Should we do all projects as Agile?

Agile isn’t necessarily cheaper – the Rion-Antirrion Bridge wasn’t Agile, and there are Agile projects that have gone badly wrong.

In my experience, the Achilles heel of Agile is that if the fundamental requirements are not adequately understood at the start, the wrong “architecture” of the solution can be selected and only when a lot of time and effort has been invested does it become clear that you’re on the wrong horse. Swapping horses in mid-stream is difficult and risky, and usually hugely expensive, so the pressure is on to struggle on and make do with what you’ve got.

I prefer a multi-stage approach with rigorous feasibility assessments in managing major strategic projects, where the architecture is really sorted out first. The Rion bridge needed to be tackled as a single entity, because that is the way it functions. Picking the wrong ERP system crippled the business and IT strategy of a FTSE 100 company, leading to a complete U-turn in its IT plans.

Agile approaches have some real benefits, but need using with care, and must not be used as an alternative to thinking the problem through first.

Good News – a learning organisation!

I posted back in April about how few organisations seem to learn from their mistakes, with the same errors happening time and time again as people rush into starting the next project.

I was delighted to meet the head of a business unit in a global organization who was not only fed up as well, but has done something about it.

He has introduced a step at the start of setting up a new project that requires the project team to research similar projects and read their “lessons learned” reports!  This is fairly recent, so he’s promised to keep me posted on how successful it is.

I may well have commented before that “Lessons Learned Report” is a misnomer, as very few of these lessons have been learned – they are more correctly labelled “Lessons identified and forgotten” reports.

I have had this discussion with many people over the years, and what I now advocate for the “learning organisation” is that they work out who needs to learn what, from whom, and incentivise people to do the relevant teaching and learning. This needs recognition that learning lessons takes time and effort, but saves far more time and money squandered on expensive mistakes.

Performance versus reliability – a people issue too

I was just watching an old TV programme, in which the central character is highly-driven, very effective but is not promoted because his superiors don’t consider him reliable. They don’t trust him to ALWAYS do the right thing.

The concept of “a safe pair of hands” is familiar to most, and seems to be a vital element of career progression.

The analogy to quality in products and services suddenly became blindingly clear – a “quality” person is someone who meets requirements and is fit for purpose, not necessarily a high performer.

I was first introduced to the eternal trade-off between absolute performance and reliability by a senior manager from a manufacturer of razor blades, over 40 years ago – he explained that their blades were quite intentionally not as sharp as their competitors, but were more consistent.  He claimed that a good blade from their competitor would give a better shave, but a poor blade would create havoc with the skin. Sooner or later, every customer of their competitor’s would get a bad blade, and swap brand! This company’s strategy was to catch the others’ customers “on the rebound” and never lose them again through a bad experience.

Likewise, individuals are walking a tightrope in their career; they continue to progress so long as they are reliable, but once they lose that reputation for reliability, their only hopes for progression are if they have an indispensable speciality they out-perform everyone else in.

My motto in stakeholder management is “no nasty surprises” – ensuring that all stakeholders are fully aware of risks, mitigating actions and contingency plans from the earliest opportunity. This isn’t just a project management approach – it’s a personal integrity approach, and builds trust!

Rule 10 – Never rush the planning!

Fail to plan – plan to fail!

A bit of a truism, I know, but valuable none the less. I don’t mean “take forever over the planning”, just don’t skimp it.

There is usually pressure to do things as quickly as possible, and to many executives, this means “start work now!”. This creates a dynamic tension between the need to report progress and the need to work out how to achieve the right progress.

Everyday English is full of sayings offering advice on this:

  • Look before you leap
  • More haste, less speed
  • Measure twice, cut once
  • A stitch in time saves 9
  • Nine women can’t make a baby in one month (Brooks)

and so on.

So why, in business, is this ignored? I wish I knew! I can only attribute it to said executives being out of touch with the reality of the situation at the coal face – what I call the “Excel Effect”.

As part of my teaching, I read many assignments about projects that have failed because the basic thinking-through of the problem was skipped at the beginning, and fundamental (and easily avoidable) errors were made that cost millions to fix. The build of Dungeness B nuclear power station was started well before the design was complete – unlike the other AGRs, it was 17 years in construction (10 years late) and way over budget. In a similar but smaller-scale project, a building was erected that proved too small to contain the plant intended to go inside!

How do I deal with this?

  • Insist on the irreducible minimum of planning time at the beginning
  • Get the design substantially complete before committing to build, then building the right thing quickly
  • Identify long-lead critical path items that we must start – this shows progress –  but continue planning in parallel
  • Log all planning assumptions as risks, and manage the hell out of them!

I’ve found this works well (unless the sponsor is unwilling to listen, and has committed to impossible deadlines!)

Case studies are NHS Direct website and THUS billing migration