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.

What Really Makes Change Fail?

This post by Steve Barlow intrigued me: I think he has some great insights, and the idea that we are not “change fit” is a new idea for me.

I agree completely that people are usually delighted with change they see as an improvement e.g. mobile phones, the Internet, on-line shopping, Sunday shopping etc (though you will find people who hate all of these things). Forcing change on people, when they don’t see the benefit, fear they will be worse off and don’t see why it should happen, quite naturally falls far short of a no-brainer!

I like the idea, though, that even desirable change fails because of mental flabbiness!

Looking at the metaphor Steve offers; I know why my New Year’s resolutions fail – the pain of changing my lifestyle in the short term outweighs the long-term benefit (no pain, no gain). It never ceases to amaze me the obsessional self-sacrifice it takes to become an Olympic athlete – how do they do it?

I think there are 2 key factors:

  • They invariably have a coach who eggs them on and sets just-achievable goals
  • They are able to visualize success in a very realistic way – what it will feel like to mount the podium and collect their gold medal – and how they will win – every move, muscle twitch, metre of track etc

Coming back to business change, what can we draw from the parallel?

  • I believe that project leaders need to act like coaches, encouraging the team and setting challenging but achievable goals
  • I believe that project leaders must support all stakeholders in understanding and feeling the benefits of the objective, explaining how they will get there and soothing fears of the unknown

These are 2 very different skills sets – planning and communication, but both are clearly essential for success in my experience.

Rethink on Leadership skills

I just read the following article on Skills that set the very best leaders apart.

It’s a fascinating take  on the culture changes that are occurring in business since the low point of Gordon Gekko’s “Greed is good!” and how these need to be reflected in leadership style.

Of these skills discussed, the one I most strongly relate to is “Stop the blame game”.

Fear of punishment is paralysing, and back-covering saps much time and energy (the “blood on the carpet” culture I’ve experienced a number of times) . To my mind there is only one real “sin” – covering up a risk or issue, so that it can’t be dealt with until it’s too late.

On one very urgent complex project I ran, the only way it could possibly succeed was welding together a project team across many participating groups that didn’t waste any time arguing, fighting or bickering, but just got on with the job at top speed. It was an award-winning outcome.

Building a culture of trust and openness is quite a challenge in some organizations, and requires actively leading by example – the other  skills in the article are all about being a real person that people can trust.

 

 

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.

Driving forwards just looking backwards?

I really like this article as it summarizes many of the problems with the hierarchical management approaches I see in larger clients:

Can you imagine getting into your car and trying to drive to work only looking out the back, not where you are going?  Terrifying thought, yet poor planning and communication means just that for many organizations – decisions are made purely on retrospective information (“fighting the last war”).

I’m currently setting up a new education programme in Nuclear Engineering, an area in which none of us can afford mistakes to be made – the driving philosophy is to teach engineers to think about what they are doing, not just mindlessly do as they are told.

In a completely different field recently, I saw a case in which  a design engineer had omitted a vital piece of information from a specification leading to a serious quality failure: when asked why, he retorted “Because the standard didn’t say I had to include it” – abdication of professional responsibility to mindless obedience.

In industry worldwide we employ a vast amount of brainpower and expertise, yet management usually spends much of its time suppressing it to maintain “control”. Paradoxically this means that the company has less control, because it has turned off the power steering, the headlights, the windscreen wipers and the brake servos.

Stretch targets – managing expectations

Setting stretch targets is a classic way of energizing a team, challenging them to think differently, to innovate and pull together.

The key thing to realize as a leader is that stretch targets are sometimes missed because they are impossible under the circumstances.

When that stretch target is externally imposed and genuinely immovable, people almost invariably respond to the best of their ability, and perform to their limit (and sometimes beyond).

When the stretch target is set internally, there are 2 scenarios:

  1. Firstly, that hitting the target is realistically achievable – in this situation, people tend to react as well as the externally set target, working hard together to deliver the result.
  2. The second scenario is that the target is NOT realistically achievable! This is frequently not obvious at first, so everyone sets off full of good intentions, aiming for the target. After a while, as the situation becomes progressively clearer, the uncertainties around the plan start to resolve, and timelines start to stretch out as the true scope of the work required is revealed.

When it becomes a probability that the stretch target will not be hit, what follows is usually very close to the “five stages of grief” described by Elisabeth Kübler-Ross in her book “On Death and Dying”, from working with terminally ill patients.

When a person is faced with the reality of their impending death, he/she will experience a series of emotional “stages”: denial; anger; bargaining; depression and acceptance (in no specific sequence).

We see these in leaders when their stretch targets will not be met.

The denial, anger and depression responses are destructive to the organization – for a leader to display these for more than a few moments is unprofessional.

  • Denial – this undermines the confidence of the team as their professional views are rejected and disparaged. It creates a break between the leader and the team members and is strongly demotivating
  • Anger – If the leader was genuinely involved, there would be no surprise and no anger, so it is proof of a hands-off management style
  • Depression – powerfully demotivating for the team, causing delays before contingency planning can start

Bargaining, if it drives the consideration of wider options and flexing the target, is laudable, but bargaining is not just the dogmatic repetition that the target must be hit.

Acceptance is vital – this allows full-hearted focussing on contingency planning and making the best of the situation as early as possible, rather than steaming full-tilt into the iceberg.

I always approach stretch targets through putting risk management as the primary management tool, with the project plan very much in second place. The project plan (in Gantt format) makes it look as though timescales and the scope of work is known, when often it isn’t – until enough work has been done to create a baseline plan, presenting a Gantt chart gives a false sense of security about the stretch target being hit.

Managing by risk foremost makes these uncertainties explicit. Some people don’t like this, but when they buy into it, it delivers much better results.