New Year Resolution – work with the big picture!

Picture courtesy Michael Henderson from Brisbane (Bardon), Australia [CC BY 2.0 (https://creativecommons.org/licenses/by/2.0)%5D

Life may be a bowl of cherries, but projects are much more dynamic!

Reading about the recent APM awards reminded me that managing a successful project isn’t about excelling at any one element, but about keeping all the many elements working together in concert. This reminds me of an act that was once popular on variety shows but seems consigned to history – spinning plates.

As you can see from the video, it’s comparatively easy to get the first few plates spinning, perhaps staffing the core team, roughing out a schedule and first cut of a cost estimate, but as more and more elements are added, the project leader has to keep pulling their attention back from the latest “plate” and make sure that all the other plates keep spinning.

It’s all about the big picture – though there’s a real temptation to get sucked down into details, taking your eye off the big picture leads to plates slowing, wobbling than falling and smashing.

To avoid this, it’s vital to understand the correct “big picture” early – in the Concept stage of its lifecycle – and Systems Thinking is a valuable approach to get that right. Getting the big picture wrong dooms you to endless changes, delays and cost over-runs.

In particular, it’s essential to verify that the proposed solution will satisfy the business outcomes intended as early as possible – there is no point delivering a solution on time and on budget if it’s not fit for purpose!

I once delivered a predictive dialler to the debt recovery team. Sadly (as predicted by one of my team) in the meantime some minor changes to the operating procedures of the team had so improved their performance the dialler delivered little business benefit.

Yes, the devil is in the detail, and these must be bottomed out as soon as possible, but the project leader must keep their eyes on the big picture too. If the Titanic had changes course just 2 minutes earlier, it would have missed the iceberg comfortably.

Confirmation bias – sleep-walking into the same old problems

I was watching an episode of “Air Crash Investigation”, a great programme for understanding what can go wrong and how, in the  very public and challenging world of civil aviation.

An airliner ran out of fuel and crash-landed more than 700 miles from its destination, having flow in the opposite direction to its destination.

The pilots blamed technical failure, but there was none – they had mis-set the autopilot and set off in completely the wrong direction, and when they realised they were really lost, instead of asking air traffic control for help, tried to sort it out themselves, making the problem even worse, because they interpreted what they saw as what they wanted to see, not what was really there (confirmation bias).

Many project teams start with a low expectation of success because they have always fallen short of delighting the customer. Repeated failures confirm their bias that they will always fail, so why bother?

Since they are not expecting to succeed, they don’t look how they could do things differently to improve their chances of success. I had a very serious argument with the existing team I inherited when asked to recover a failing programme. “We always do it this way” they said, to which I replied “and you always fail!”

I won the argument, losing one team member in the process, and we tried a completely different approach, very focused on customer experience, and succeeded beyond all expectations.

Taking a fresh look at the complete problem, understanding the true success criteria and designing the whole approach to achieve success, quickly transformed project performance, lifting the team’s self-esteem in a virtuous circle!

This isn’t a one-off – tackling the root causes of frequent problems in a railway infrastructure company saw a 25% reduction in recurrent problems in just 4 weeks!

Is there a problem with project quality? Let’s use a “canary” for early warning.

In general the quality of products is vastly better than in the 1970s – they do their job well , are reasonably reliable and tend to last, rather than not working at all, or breaking quickly, or just rusting away (in the case of cars). This is less true for projects, and my personal experiences make me concerned that today business leadership takes quality for granted, and in the continuing drive to cut costs and improve efficiency, has turned the tide against good quality by cutting investment in it.

To test this we need a “canary” (miners used this sensitive creature as an early warning of toxic gas) for projects to see whether a decline in quality focus is really happening, and what its consequences are.

I suggest we use the air transport industry for this, where quality and safety are tightly coupled, so is high-profile, transparent and familiar to nearly everyone.

This NOT an aviation-bashing article – air transport is still a  high-performing industry.  I want to use its experiences as a warning to the rest of us.

The Boeing 737 Max crashes seem to result from quality failures in Boeing design and test processes – it would appear that the system design that kept pilots from having to requalify for the Max version wasn’t fit for purpose (i.e. safe) and the training didn’t meet the requirements (i.e. for safety).

Sadly, that isn’t Boeing’s only major problem. It’s reported that:

  • Their 787 production line in South Carolina has attracted considerable criticism about manufacturing quality, with airlines complaining due to the high level of defects
  • The US Air Force’s KC 46 Pegasus tanker transport was first accepted  18 months after the first 18 aircraft were planned to be delivered, due to quality issues with the wiring and refuelling system, the key new parts in this 767 conversion
  • In recent structural tests, a 777X cargo door blew out from the fuselage, probably delaying the programme further (after engine-related delays)

It’s not just Boeing that are facing quality challenges. Rolls-Royce has suffered from chronic problems with its Trent 1000 engine family where innovative components haven’t met durability requirements, grounding many 787s and resulting in at least one serious in-flight failure.

Recently, Emirates’ President was highly critical about the lack of reliability of products it was receiving from Boeing, Airbus, Rolls-Royce and General Electric. As reliability is a requirement, this implies an industry-wide quality issue. All of these problems are taking $100 millions to resolve, and are potentially disastrous commercially.

There is always a tension between time, cost and quality in projects, but I suggest that the growth of monetarism has driven Executive focus onto cost without appreciating that the investment in quality up front is vital to delivering on time and budget. Good quality minimises redesign, rework and delays, with their attendant costs.

As our canary, the aviation industry, seems to warn us all, cost-cutting on quality results in delays, cost escalation and, potentially, fatalities.

I wish the aviation industry every success in recovering from these issues, and suggest they look at quality first.

Fitness for purpose and meeting the requirements: prerequisites for project success

Where has the last year gone? For me it’s been spent publishing a book on the need to re-balance the “iron triangle” in favour of quality i.e. getting things right to boost project success, and developing courses in that for Sellafield’s Project Academy and UCL.

The book illustrates the principles with real case studies, both personal experiences and public domain.

I recently watched a documentary, just 1 year after the tragic event,  on the collapse of the “Morandi” bridge in Genoa, killing 43 and injuring others. This is a case study I would have used in the book had it not been finalised then.

As with so many disasters, a number of quality failures conspired to result in death and destruction:

  1. The design was not fit for purpose – the design had a single point of failure; if one of the stays failed, the bridge would fail. By encasing the stay cables in concrete to “protect against” corrosion, it made visual inspection of corrosion impossible too.
  2. The build did not meet requirements – the steel stay cables were supposed to be completely embedded in highly alkaline grout that would prevent corrosion, but there were voids in the grout that left steel cables exposed to air and water, leading to corrosion.
  3. Maintenance did not meet the requirements – only two of the 3 pylons supporting the bridge were repaired, when corrosion in them was discovered to be dangerously advanced. The third was considered to be non-urgent due to the state of corrosion being under-estimated – the corrosion measuring techniques were inaccurate and not fit for purpose. This was the pylon that collapsed.

Getting things right is a prerequisite for project success; using completion on time and budget as primary KPIs for project success drives skimping and corner-cutting. These lead to rework, delays and subsequent failures, sometimes with tragic results.

Skimping on getting it right doesn’t save time and definitely doesn’t save money!

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.

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

The Perils of Over-Simplicity

For a week or more I’ve been working on an insight that struck me after watching 22 episodes of “House M.D.” over a long weekend (I signed up for Netflix). Torben Rick’s article on how to hold people accountable uses the mnemonic SIMPLE, which triggered me to start writing. This isn’t the end, it isn’t even the beginning of the end, but at least it’s the end of the beginning.

So why am I preaching about over-simplicity – surely simplicity is a good thing? Well yes, I think so, if it is  genuine.

Simplicity has many great values:

  • People can understand simple things
  • People can do simple things
  • People can explain simple things to others, without difficulty

So what’s the problem?

This is where House comes in  – often reality isn’t simple.

What happens when people try to apply a simple model to a complex reality?

  • It doesn’t work
  • People are disappointed it doesn’t work
  • The people who tried are castigated for failing in a “simple ” task
  • The people who proposed trying to use the approach are castigated for the failure of their approach to solve a “simple” problem
  • Future attempts to tackle the problem are poisoned by the “we tried already and failed” mentality

I’ve been working with a group over the last 18 months to distil the essence of systems thinking and systems engineering, with project management disciplines, to produce am integrated model. It’s been an eye-opening experience to see two groups of experts wrestling first to undertand each other, then build a shared model, then make it simple enough.

Simple enough, not simple. This is not a simple field, which is why 20 of the UK’s top professionals in their fields are passionate about doing it (pro bono publico i.e. in their own time, for free), but they have to find the right point where it is simple enough to share understanding while complex enough to actually work.

So back to House; this is a programme centred on diagnosis and treatment – after 22 episodes on the diagnostic process I was really relating it to solving business problems, and drew up my process model for diagnosis and correction of business problems, based on 20 years experience. I noted that:

  • The classic “Deming” cycle for continuous improvement has 4 stages in 1 cycle
  • The DMAIC cycle from Six Sigma has 5 stages in 1 cycle
  • My model has 11 stages,  1 main cycle and 3 sub-cycles

I know mine works, but could I convince others to use it? I hear many stories of Deming and Six Sigma being tried and failing. Is this because they are applied to situations that are too complex for their simple models?

I do not run simple models down – I apply them when I can! Unfortunately the pressure for a quick win can cause management to grab at anything with good press, however, applying an over-simple model to a complex situation is just asking for failure.