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!

Deadlines – the great motivators

I went to “Joint School” on Friday, our local pre-surgery induction for hip replacement patients.  I came away really fired up with all the things I need to get done before I go in for surgery in 2 weeks.

So what is it that this deadline has triggered?

  1. Priority – I now have a list of things that must be done, a list of things that should be done, and a list of things I’d like to do.
  2. Focus – I’ve immediately cancelled all the “nice to haves” that require significant time and distract me from hitting the deadline
  3. Timeliness – I’ve already done lots of things that I’ve known needed doing for months but kept postponing due to “high priorities”
  4. Energy – I will be the one to suffer if I don’t hit the deadline, and  I’ve discovered that lots of “huge” tasks have been finished pretty quickly and easily because they have to be done now, rather than shuffled off into the future
  5. Personal effectiveness – because a change is BETTER than a rest. Swapping to another task when I run out of steam re-energises me while doing something useful

Setting deadlines is a key skill in project management, and if done well can stimulate the team very powerfully.

Are deadlines always so effective?

Well, no. Deadlines can be hugely demotivating when:

  • They are not real – they have been created by an executive or manager to “motivate” the team
  • They are too tight:
    • perhaps they are labelled “stretch” but failure to achieve them is unacceptable
    • perhaps they’re simply impossible
  • They are too far in the future:
    • breeding complacency and indolence
    • relying on staff to create their own interim deadlines and motivate themselves
  • They are too abstract – the team can’t relate emotionally to hitting or missing the deadline, so their energies are not tapped into.

Ensuring these do not happen is the responsibility of business leadership, portfolio and programme management, and a critical requirement for such leaders is to have their fingers on the pulse of reality, and occasionally lift their noses from Excel spreadsheets and abstract numbers.

Over the last few years I have seen 2 glaring examples of deadlines being set without a sound justification for considering them viable, then the leaders going ballistic on being told, when the feasibility studies were completed, that the targets were not achievable.

The other end of the spectrum is as bad – many years earlier, I saw a project team that had been set up 6 years before the regulatory deadline, and had spent 5 years making very limited progress. This demanded a huge effort to rescue the project at the last moment

Business leaders need to think very hard about using deadlines to motivate teams – they can work very powerfully both towards success and right into failure!

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.

Coaching Project Managers is great value

Business coaches are legion, executive coaches are everywhere, so why is almost no one coaching project managers, the people delivering the vision?

I’ve compiled some case studies of the work I’ve done with project managers in a wide range of industries and the huge benefits resulting.

I’ve done a comparative analysis of  traditional face-to-face training courses, e-learning and coaching:

Picture1

Ah, I hear you think, coaching is much more expensive! Some of the executive coaches (and some of the business coaches) may be; I was shocked to hear the fees charges by one franchise.

It’s not the case for our offering, certainly – some project management courses are very expensive for the limited value they deliver.

It seems a no-brainer to me!

If I’ve got it wrong, please tell me.

 

Workload management – the 3 Ds

It’s a common saying that if you want something doing, give it to a busy person, but accepting work can quickly take you beyond your capacity for sustained performance, disappointing everyone and making you ill.

As we surge back into the whirlwind of work after the relative peace of the Christmas break, I thought it would be a good idea to recap on my disciplines for holding workload in control, the 3 Ds:

  1. Decline: the simplest, though not the easiest, is to say “No” to extra work. If you are not accountable for this work, and don’t have the best specialist skills, you should reject responsibility for it and recommend who it should go to
  2. Delegate: if the work naturally sits with your responsibilities, ask whether it needs your personal input, or whether it can be delegated (limiting your input to tasking and monitoring).  Teaching one of your team to do it may be the right strategic choice, but that is more time-consuming, so do that when you have the chance
  3. Defer: be effective in prioritising work – when does it really need to be done by? When can you realistically do it?  I worked in one organization where all IT work was prioritised “1” i.e. all top priority, so they introduced the “1*” priority – higher than “1”. Within a month, all requests were priority “1*”.  Work must be spread out over time when there are finite resources – push back those tasks that can be

Of course, this doesn’t mean what is left is always achievable, but if you don’t try, things go pear-shaped much quicker!