A Commonplace

What is a commonplace?



Improvisational Theatre and Project Management - What the Hell have THEY got in Common?

- the need to make it up as you go along - Part 1

Be Good - Be Bad - BE CHANGED

So the plan (ha! ha!) is to write a blog post every day between now and the seminar I'm running on 12th November. Whether I will actually achieve that speed through the medium is a different question. But the hope is that by writing these posts I'll talk about some of the issues that I'm going to cover.

I started taking classes in improvisational theatre with Tom Salinsky and his company Spontaneity Shop way back in 2010. Why did I take an improv course? Because somehow, don't ask me exactly how, I'd come to read "Impro" by one of the grand-daddies of Improvisation, Keith Johnstone. I was probably about a page or two in before I was totally hooked. Anyone who is regarded as a theatrical guru who coaches is students by shouting "be more boring" is worthy of further attention.

When you take the Spontaneity Shop's second level course you get to take part in a show at the end. By total random chance, I was in the very first scene of my first improv show. It was the first time I'd performed on a stage for about 22 years. I played a carpenter negotiating the design of a coffin for a vampire. It was awesome.

Nobody wants to change

The most powerful human urge is to carry on doing what you're doing. The second most powerful urge is to do what everybody else is doing. These two things in combination are so powerful that they can kill you. Survival is a poor third. The utterly visionary psychologist Stanley Milgram points out that some people would rather die in a burning building that run out of it naked - running about naked simply isn't the done thing.

In improv this problem shows itself as blocking. Let's say Actor 1 walks into a scene with a pretend gun. Actor 1: [mimes gun] Stick 'em up! Actor 2: [mimes his own gun] No you stick 'em up! That's joining. The absolute worst sin you can ever commit in improvisation is what's called blocking - flatly rejecting the suggestion of your fellow improviser. Actor 1: [mimes gun] Stick 'em up! Actor 2: Looks bored that's not a gun - you're just miming one with your finger.

These are just two of the ways that people come up with in the heat of the moment and there are a bunch more. What's amazing is when you're sitting and watching it, is how fantastically creative people can be in avoiding being changed. And this is the kicker even though the change they are making is totally PRETEND.

What's that you say? "Yes, Mark this is all very interesting, but what the fuck has it to do with project management?"

OK, here goes. The same principle is at work with any group of people in any walk of life. Nobody wants to change. And what is a project? It's a change. And then what happens inside a project? Lots more change, changes in understanding, changes in specification, changes in technology, the list is endless. And in order for a project to be a success, everybody involved has to be changed - and they don't want to be and without evening thinking, literally, subconsciously, they will try every trick in book to stop themselves being changed. An example of blocking in project management?

Project Manager: According to our calculations this project is going to take twice as long as initially estimated.
Senior Stakeholder: I don't believe you - I want to see this prediction broken down into hourly tasks, preferably down to individual keystrokes.

How does joining to avoid change show itself project management? Well like this as a starter.

Agile Coach: We're going to use an Agile iterative approach to this project
Senior Stakeholder: Oh we're already pretty Agile here.

Which reminds me of the pure genius of this story about Peter Cook.

Peter Cook: What are you doing now that you've come down from University?
Some Person: I'm writing a novel
Peter Cook: Yes, neither am I.

What's that I here you say? *"OK, Stringer, we've read this far in the hope of some kind of insight, or even better some actually practical wisdom that we can use on our projects. Please tell me there's going to be some."

Well, some. I happen to think that it's really important to understand that people's first reaction when you give them important information (and remember one technical definition of information is surprise) will be an attempt to minimise it and block it. And once you've understood that, you can recast the job of project manager as being the job of figuring out how to tell the people that need to know, what they need to know without getting fired. How might you do that?

Say the same thing in lots of different ways. Fine, don't argue that this project is already doing Agile, but carry on suggesting that as improvements to their marvellous Agile process, they might like to add stand-ups, iteration planning, showcases, breaking work up into stories, planning using a product backlog.

Fine, they don't believe you that this project is going to take twice as long as estimated - how long did other projects like this take? Whoa three to four times as long? Really? Fine they don't understand a burn up chart - visualise the work in a different way. Show progress in a different way. Show it again in two week's time.