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:


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.


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.



The role of consultancy in strategic planning

For many years I’ve found strategic planning to be a rare skill; most people struggle with it.

When discussing my approach (which is pretty standard) with a client recently, I split the problem down into 3 parts:

  1. Knowing where you are
  2. Knowing where you want to get to
  3. Constructing the road map to get from one to the other

Looking at these, I would argue that most business people, with a bit of teaching, are quite able to do part 3 – it’s a core human skill, quite logical, analytical and not demanding much creativity (though detailed planning of large projects is highly skilful).

This leaves parts 1 and 2 where the problem lies, and they are problematic for quite distinct reasons.

1. Knowing where you are is a problem for many people as they are too close to things and prejudiced by assumptions. It may even be that they are a part of the problem, so self-justification will distort and cloud their analysis.

It requires cold, dispassionate assessment.

The other key factor is that an accurate situational analysis requires integrating the perspectives of all stakeholders, something difficult to achieve for someone inside most organizations, as structure and hierarchy stand in the way of honesty and completeness.

An external person can provide clear insights that no internal person is able to offer, through confidentiality and mobility.

2. Knowing where you want to get to is a real challenge when your nose is to the grindstone – it requires quality thinking time, plus releasing the imagination. Most of us have to work very hard, frequently 50 – 70 hours a week, making mundane decisions – lots of analysis, but little creative thinking. This means our creative muscles get flabby and wasted.

The hardest aspect of this is that when we are facing gritty reality hour by hour, envisioning an ideal world where everything is great is not a simple event but a journey – we need support when trying to be creative.

Human beings are rather good at learning by analogy (abductive reasoning) but getting first-hand that wider view of what others are doing is often a luxury.

An external expert can provide insights from your competitors, and best practice from other industries to stimulate the imagination, and help form that “ideal world”  vision.

As a business owner, do I practise what I preach? Well, I haven’t always done so effectively, but I’m getting better; I don’t want to be “penny-wise, pound-foolish”.

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

Rule 8 – Always keep an audit trail for all decisions, and keep up to date with the paperwork

This is the one I find hardest to keep to!!!

The sad truth of the matter is that no matter how hard we work to build trust and sincerity in a business relationship, there are those who will renege on an oral promise if it saves them money and there is no record.

I still remember vividly working for a client whose customer assured him that he would pay for a certain piece of work, and when it came to the crunch, denied that he’d ever said it, and expected a company with fewer than 30 employees to pick up a huge bill for some “vanity” work that was a useless dead-end, done by a City web design agency. I felt bad because I hadn’t managed to document it. As luck would have it, the project outcome was so successful that the sum involved was minor, but the principle holds true.

The counter-case was a joy from many years ago where a difficult and challenging project led to great customer satisfaction and easy sign-off, simply because the change control was rigorous and clearly documented – acceptance consisted of running through the updated requirements spec, line by line, and since we’d agreed all changes and logged them explicitly, the customer was delighted to sign off their acceptance.

I find that documentation is the first thing to suffer when i get overloaded, so it’s a great barometer of work pressure. It’s symptomatic of my way of working that I rarely have an assistant in these projects – something i really need to address!

There is a fine line to draw between being distrustful/pedantic and keeping the relationship moving – in both cases the project was a success, even though there was a very different level of documentation cover.

Sadly, keeping good audit trails cannot always prevent project failure. In my career I’ve been involved in 2 projects where the supplier ended up in court. When this happens, audit trails are essential!


Lessons half forgotten need remembering (before it’s too late)!

Earlier this week I nearly succumbed to breaking my own “Rule 1” – briefly considering being away for part of a crucial business audit.

Fortunately I rallied and came back to decide firmly to “Be There”.  It does highlight how we can all slip from the disciplines that we’ve learned the hard way when the last failure to apply them slips outside the pain memory.

I’ve blogged most of my golden rules before, individually, but I thought now was the time to refresh them, all together:

Rule 1 – Be There!

Rule 2 – Stop blame if humanly possible

Rule 3 – Be easy and rewarding to help

Rule 4 – Don’t RELY on people showing initiative

Rule 5 – When the pressure looks like rising, manage YOUR workload – the 3 Ds

Rule 6 – Keep communicating

Rule 7 – Don’t let your performance in your own role slip because you’re covering for someone else

Rule 8 – Always keep an audit trail for all decisions, and keep up to date with the paperwork

Rule 9 – If there isn’t enough resource, say so! Don’t struggle on in silence

Rule 10 – Never rush the planning!

Rule 0 – Always apply the other rules!!!

I now realize that I need to cover rules 7 – 10; should keep me busy for another week or two.

Just re-reading these has shown that I’m on the slippery slope – I need to apply them to my current assignments before it’s too late!

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.