Project Management

Don’t ignore the gorilla in the room

QA's Head of Organizational Consultancy, Dr Ian Clarkson, applies the classic gorilla experiment to project management, and argues that focusing on achieving the project output should not interfere with seeing the gorilla in the room.

I am going to start this article by asking you to watch a short video. It’s all fine to watch – I have watched it myself – and it only lasts 1 minute 21 seconds. I promise you it is nothing untoward – just follow the instructions on the video – and don’t read on until you have watched it (source: www.dansimons.com/videos).

STOP! Have you really watched the video?

How did you get on? Did you count the correct number of passes? 15. Did you see the gorilla first time around? It is a classic experiment and one you may well already have heard about. It’s also great to try on your family, friends and colleagues.

My 13-year-old son saw the gorilla. My 9-year old son did not. My wife voided her attempt by arguing that some people in the black T-shirts were wearing white trainers and, therefore, the instructions were confusing (watch it back – she has a point).

I saw the gorilla – but I was looking for it so I wasn't an innocent participant. I first came across a reference to it while reading 12 Rules for Life: An Antidote to Chaos by Jordan B. Peterson.

Now, I like my books on psychology and behavior (or whatever genre they are) and this one is a bit special. It is quite full-on: funny and controversial at times – I don’t mind a bit of controversy.

The chapter I am referring to here is “Rule 4: Compare Yourself To Who You Were Yesterday. Not To Who Someone Else Is Today”, and it’s talking about (as I understand it) how to be a better version of yourself by not trying to be like someone else, as this could be an unbridgeable gap between you and your target of comparison. It's better to rather move towards a point which we deem better in accordance with our explicit and implicit values. Powerful stuff.

Peterson talks about aiming for this point by aiming small and changing incrementally, and each change provides a slightly higher baseline of comparison towards your better point. He rather eloquently states it as: “Now you’re aiming for something higher. Now you’re wishing on a star.”

What you aim at determines what you see

He continues: “What you aim at determines what you see,” and leads into a discussion on dependency on sight and how the gorilla experiment (as I’m now calling it) illustrated how vision is expensive – psychophysiological expensive, and neurologically expensive.

That is, there is so much to see in the world that we cannot process it all, and so we focus our attention and sight on things we are aiming at, and let everything else – which is almost everything – fade, unnoticed into the background. Most of our vision is peripheral and low resolution.

This explains why a large number of people (does this include you?) did not see the gorilla – as you aimed or focussed on the white T-shirts throwing the ball to each other.

Is a project the same? Our aim is on the project output – does this mean that our attention is focussed on achieving this, and everything else about the project fades unnoticed into the background... or the project periphery, if you like?

It's an interesting idea and one I can see is true from working with lots of organizations on their projects. Let me give an example.

We all know from good project management training, literature and experts that we should always have a risk register or log on a project. Moreover, this is a fundamental tool for success and should be regularly reviewed and kept up to date.

I am still amazed when projects don’t have a risk register or log – let alone reviewing it regularly and keeping it up to date. How many of you reading this are having an awkward moment right now? When I ask why a risk register/log doesn’t exist on a project, I often get the reply, “We’re busying delivering the project.”

What you aim at determines what you see. 

Are you so busy being “busy fools” (I did say I liked a bit of controversy) that you can’t see the big project primate beating its chest in front of you? In this case, the big project primate is the risk register/log.

What you aim at determines what you see.

The question I have to you all is: How many other big project primates beating their chests in front of you can you not see? 

What you aim at determines what you see.

Yes, you need to focus on achieving the project output – yet not at the expense of how you get there, which has to include being able to see all of the project primates. As Peterson says (again rather eloquently) at the end of Rule 4: “To journey happily may well be better than to arrive successfully…”

To find out more about how QA can help build your capability and capacity in project management, drop me a line at QAL.OrganisationalConsultancy@qa.com.

[This article was first published on pmtoday.co.uk on 07/01/20]

Related Articles