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)

 

 

Advertisements

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.

 

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.

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!

Business Processes; the good, the bad and the ugly

I’ve recently had a series of discussions with colleagues, clients and other professionals that I respect, on the subject of business processes. They are all strongly in favour of them, and I know why, they:

  1. systemetise the work flow, making it more predictable and manageable
  2. assist in delivering consistency
  3. encourage the right people to be included in decisions
  4. make it easy to measure performance (and diagnose issues with performance too)
  5. can prevent individuals making serious errors
  6. make training new staff (and handling staff turn-over) relatively straight-forward
  7. allow straight-forward IT automation

and have many other positive aspects that make them ideal for the more straight-forward jobs.

So are they a panacea? Sadly not, as they have serious weaknesses that can compromise more complex types of work. The key issues are that they:

  1. tend to serialize workflows, slowing them down by introducing bottlenecks
  2. become inflexible and over-prescriptive to prevent a small minority abusing the system, preventing justifiable initiative being taken
  3. become over-dependent on IT performance (which is driven by a completely separate budget)
  4. become more complex to handle extreme cases, causing following them to become a chore that is skipped if possible
  5. remove the spirit to think amongst some staff
  6. generate “malicious compliance” amongst other staff
  7. provoke rebellion from a tiny minority
  8. become a strait-jacket that prevents business agility
  9. eventually break when they no longer reflect business needs

People are not machines, and their greatest asset is their versatility and intelligence – watch a plumber at work!

Of course, the greatest free-thinkers of all are the salesmen, so if we can design for salesmen, we’ve cracked it!

A colleague raised a hugely valuable point – what is needed is something that ensures that all aspects are considered, without forcing mindless compliance, while harnessing the best aspects of human behaviour: checklists.

Yes, checklists – so simple, so easy to maintain, yet so powerful – it’s what saved the lives of all  on board US Airways Flight 1549 when it crashed into the Hudson River (Thanks, Neil)!

So how can we get the benefits of checklists in lieu of hard-coded business processes? Redesigning ICT to provide real-time decision support around a checklist front end could do the job nicely. I know it’s very “Mission: Impossible”, but with 4G, Internet-enabled cameras, tablets and mobile comms, we really do have the technology to build a real-time decision-supported salesman!

What do I mean?

I mean that the salesman can collect information from the client that is immediately transferred back to base, where the team (and IT systems) analyse that information and offer up both validated options and further information to gather.

Such technology has been available in a limited way for contact centre staff for many years  as “case-based reasoning” tools, but we need to include the option of expert advice from real people if the sale is valuable.

Most salesmen can cope with the freedom of the checklist – making sure that they have the right information to correctly tick the box in real time would massively improve both sales and sales quality.

And if it works for salesmen, it can work for everyone.

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.