Ensuring Project Complexity has been Properly Assessed and Acted Upon

We've had an initial look at how we typically understate risks, but there's another question:  Are you implementing into a stable organisation?

It's a bit of a trick question, isn't it?  You'd love to say "yes", but you know the more accurate answer is "no". You know you live and work in an evolving and changing organisation in which any structure that you can clearly perceive is already the past, and what instead matters most may be the "perturbations" on the edge of the current structure, which have the potential to manifest a substantive change.  But will that change your implementation plan?  The temptation to make the assumptions that the organisation is simple, linear, equilibrium-seeking and isolated is extraordinarily strong, because it gives you the feeling of control.  But it is illusory.

For the sake of this discussion, let's define a scale of complexity to describe the organisation as a system (in the engineering sense):

• Simple  - Least complex
• Complicated
• Complex - Learning to predict outcomes is expensive
• Chaotic - Practically unpredictable (but not technically random)

If the organisation was a Simple system, changes would be easy - you would simply categorise the problem and apply a best practise that addressed the issue.  Experience tells me that this works occasionally, usually on a very small scale.  On the other hand, I've seen many implementations of ERP systems trying to apply "best practises". Typically the organisation finds its own approach once the consultants leave.  So once the implementation group exceeds about a dozen, then it is no longer appropriate to describe the organisational behaviour as Simple.

Some organisations can be categorised as Complicated systems.  Such organisations respond well to expert intervention; examples of these organisations are certain kinds of industrial operations.  In these organisations toolkits such as Six Sigma and the Theory of Constraints (Lean) work well.  If the organisation can be disassembled into components, optimized, and then reassembled to create a better functioning whole, then this is the domain you are in, and you should follow the Six Sigma mantra of "DMAIC" - Define, Measure, Analyze, Improve, Control.  But remember that manufacturing and distribution is only a component of what the organisation does, and these tools may not be appropriate elsewhere in the organisation.  And how can you tell in advance whether your industrial operation is suitable for intellectual disassembly?

I hate to think of organisations as Chaotic, because it's possible I'm being led by fashion, however in my opinion most sizable organisations are certainly Complex, and possibly Chaotic in their behaviour.  They respond to changes in ways that aren't obvious.  And when you change a component of the organisation defined by the scope of the project, it has interfaces into the rest of the organisation:  The scope is not the change!

We often hear quoted the idea that "insanity is doing the same thing again and again and expecting different results" - variously attributed to Albert Einstein and Benjamin Franklin.  However, for organisation systems with high degrees of complexity, insanity may well be doing the same thing twice and expecting the same results - because you make the changes at different times, the system you are changing is different!  Because you've already made a change to a part of the system, then the system you are changing is different!  This is the domain for which the famous "butterfly effect" is a metaphor.  Tiny changes in initial conditions may (or may not) yield substantially different end results.

In such complex organisational systems, the expert is powerless, and you are left with testing, piloting, rolling-out and correcting - an organic, evolutionary approach to change, in which you attempt to learn as you go along, but should not be surprised that you fail!

— Philip Greenwood

Tags: Project, Leadership, Black, Book, Complexity, Chaotic

Ensuring Project Complexity has been Properly Assessed and Acted Upon

We've had an initial look at how we typically understate risks, but there's another question:  Are you implementing into a stable organisation?

It's a bit of a trick question, isn't it?  You'd love to say "yes", but you know the more accurate answer is "no". You know you live and work in an evolving and changing organisation in which any structure that you can clearly perceive is already the past, and what instead matters most may be the "perturbations" on the edge of the current structure, which have the potential to manifest a substantive change.  But will that change your implementation plan?  The temptation to make the assumptions that the organisation is simple, linear, equilibrium-seeking and isolated is extraordinarily strong, because it gives you the feeling of control.  But it is illusory.

For the sake of this discussion, let's define a scale of complexity to describe the organisation as a system (in the engineering sense):

• Simple  - Least complex
• Complicated
• Complex - Learning to predict outcomes is expensive
• Chaotic - Practically unpredictable (but not technically random)

If the organisation was a Simple system, changes would be easy - you would simply categorise the problem and apply a best practise that addressed the issue.  Experience tells me that this works occasionally, usually on a very small scale.  On the other hand, I've seen many implementations of ERP systems trying to apply "best practises". Typically the organisation finds its own approach once the consultants leave.  So once the implementation group exceeds about a dozen, then it is no longer appropriate to describe the organisational behaviour as Simple.

Some organisations can be categorised as Complicated systems.  Such organisations respond well to expert intervention; examples of these organisations are certain kinds of industrial operations.  In these organisations toolkits such as Six Sigma and the Theory of Constraints (Lean) work well.  If the organisation can be disassembled into components, optimized, and then reassembled to create a better functioning whole, then this is the domain you are in, and you should follow the Six Sigma mantra of "DMAIC" - Define, Measure, Analyze, Improve, Control.  But remember that manufacturing and distribution is only a component of what the organisation does, and these tools may not be appropriate elsewhere in the organisation.  And how can you tell in advance whether your industrial operation is suitable for intellectual disassembly?

I hate to think of organisations as Chaotic, because it's possible I'm being led by fashion, however in my opinion most sizable organisations are certainly Complex, and possibly Chaotic in their behaviour.  They respond to changes in ways that aren't obvious.  And when you change a component of the organisation defined by the scope of the project, it has interfaces into the rest of the organisation:  The scope is not the change!

We often hear quoted the idea that "insanity is doing the same thing again and again and expecting different results" - variously attributed to Albert Einstein and Benjamin Franklin.  However, for organisation systems with high degrees of complexity, insanity may well be doing the same thing twice and expecting the same results - because you make the changes at different times, the system you are changing is different!  Because you've already made a change to a part of the system, then the system you are changing is different!  This is the domain for which the famous "butterfly effect" is a metaphor.  Tiny changes in initial conditions may (or may not) yield substantially different end results.

In such complex organisational systems, the expert is powerless, and you are left with testing, piloting, rolling-out and correcting - an organic, evolutionary approach to change, in which you attempt to learn as you go along, but should not be surprised that you fail!

— Philip Greenwood

Tags: Project, Leadership, Black, Book, Complexity, Chaotic

Change Management Isn't a Methodology!

A few years ago I worked on a project with a client (global, ~140,000 people) that had an in-house change management methodology.  I expected that this would make the job easier – after all, they must recognise the value of change management and know how to use it, surely. 

I was astounded to discover that very few people in the company knew how to apply the methodology – I found nobody who even knew where to start!  After hours of studying the methodology I figured out why:  There was no starting point. I was just a cluster of loosely connected tools.

Brain Lessons

Do Project Leaders need to understand the way brains work?  When I read Brain Lessons I was surprised how many of these neuroscience authors  focussed on, or displayed compassion – often self-compassion.  Is compassion a leadership quality?  Ask the Dalai Lama!

Since I’m fond of saying that “you can’t learn Project Leadership from a book”, I’ve copied another comment that focussed on learning below:

Daniel Levitin, author of This Is Your Brain on Music: The Science of a Human Obsession.
I spend a lot of time in my job learning new things, and I spend a lot of my leisure time learning how to play new pieces on the piano or guitar. What I know about the brain has changed my life by teaching me that with learning, "slow and steady wins the race." A few minutes of practice each day is better than several hours all at once, once a week, because of the neurochemical and neurodynamic processes involved in memory consolidation. I also know that practicing—whether it's a new Bill Evans solo or cracking a multivariate differential equation—is best done every day at the same time.

I was also very interested in this comment, regarding our ability to problems solve:

David Linden, author of The Accidental Mind: How Brain Evolution Has Given Us Love, Memory, Dreams, and God.
The brain is not a generic problem-solving machine—rather, evolution has shaped it into a strange edifice that is very proficient in dealing with a particular subset of problems.

—Philip Greenwood

Tags:  Neuroscience, Cognition, Leadership, Dalai+Lama, Compassion, Mind, Brain

Why Project Leadership Books Suck!

Seeking inspiration for this blog, I’ve been re-reading all the books in my library on Project Leadership, Project Management and Leadership.  I’ve come to a few startling conclusions:

• There are surprisingly few books specifically on the subject of Project Leadership.  I find this odd because Project Leadership is a practical application of leadership.  Perhaps it’s easier to write about leadership in an abstract way than deal with the practicalities?
• There’s even less content than you might expect in those books on Project Leadership that do exist – a lot of duplication, and a lot that is impractical. Specifically:
• There’s an awful lot of writing about character types. Although it’s interesting, in the real world it’s an irrelevant distraction. You never get the choice of your own behavioural inclinations, and you rarely get enough choice of team members to select on this basis. (Caveat for clarity: You always get the choice of your own behaviour and any suggestion that you don’t is sheer manipulation!)
• None of the books talk about leadership from the perspective of enhancing team behaviours and performance.
• Their treatment of how to deal with organisational politics is feather-weight!
• None of the authors on Project Leadership have been prepared to level criticism at traditional Project Management.  The strongest criticism I’ve found is that it is necessary, but not sufficient.

My main conclusion is that you can’t learn Project Leadership from any of these books!  It’s like trying to learn to swim by reading about dolphin behaviour and hydrodynamics.  Maybe we need to start writing!

Perhaps, dear reader, you can tell me: What do you think needs to be included in an effective Project Leadership Development tool?  What form should it take?

— Philip Greenwood

Tags:  Project, Project+leadership, project+management, book+review, Leadership, Management, team, teamwork, teaming, team+behaviour, team+behavior

Just Rewards

I saw an interesting quote on Alexander Kjerul’s great blog: Chief Happiness Officer…

“One of the most thoroughly replicated findings in the field of social psychology states, the more you reward people for doing something, the more they tend to lose interest in whatever they had to do to get the reward.” - Alfie Kohn

An animal trainer friend told me that when she works with dogs that annoy their owners with random barking, she trains those dogs to bark on cue (using  rewards)… and then never gives the cue to bark.

Pow!… No more barking!…. think about that for a moment.

What does that say about incentivisation of the work environment. Let’s say that you have a new knowledge management system that you want your department to use. You decide to incentivise its use with some great rewards, and for a time it works really well! Congratulations! Now… what happens when you stop the initial reward scheme?

No more barking ;o)

— Jason Bates

Tags: Kjerul, Happiness, training, motivation, incentivise