What project management means to me – a metalogue

Salviati: Hello Simplicio, I haven’t seen you for a while. Where have you been?

Simplicio: Salviati!  It is good to see you.  I’ve been busy learning about project management.

Salviati: That is good news indeed, Simplicio.  How are you learning? Are you working on a project?

Simplicio: No, of course not; I’m still learning. I don’t think  my boss would let me work on a real project until I’ve completed my certification.

Salviati: Certification? Now I’m really curious.

Simplicio: Oh yes, and as a part of it I’m reading this wonderful book that is the authoritative guide to project management. I’m also attending an  evening discussion group twice a week where I get to  explore the finer details of “The Book”. It’s great! We have some experienced project managers in the group who tell us stories.

Salviati:  That’s good, and I would pay more attention to their stories than the tools and techniques in “The Book”.

Simplicio: Really? Why would I want to listen to a bunch of stories about old projects? Surely it’s the tools and techniques that are more important. Stories are….well, just stories.  Half of them are probably embellished anyway.

Salviati:  May be so, but the fact is, project managers often make sense of their work by constructing stories about it.

Simplicio: What do you mean “make sense of their work?”

Salviati:  Well, despite project managers’ best efforts, things never quite go as planned: team members fall sick or leave the company; vendors do not deliver on time; users change their requirements on a daily basis…I could go on.  When these things happen, project managers need to  understand  what has happened so that they can devise appropriate responses.   They often do this by building narratives of what happened or, in simple terms, by telling stories.

Simplicio: To be perfectly honest I think the real reason things go wrong is that people  do not   follow processes properly. It seems to me that storytelling is just a means to cover up the truth, a rationalisation.

Salviati: Ah, truth. You see, Simplicio, truth in such situations is often a matter of opinion. Different stakeholders will have different views on what happened. Say a vendor is late in delivering something – the customer may see it as gross incompetence whereas the vendor will, no doubt, have a perfectly reasonable explanation. So, whose truth is the truth?  And even if you were able to answer that, does it really matter? As a project manager, you’re on the spot; you have to move ahead despite the setback. The truth doesn’t help you here, and neither does process. In fact trying to get to the truth and insisting on process may only end up exacerbating the problem.

Simplicio: Hmm, OK, you may have a point there, but are you suggesting there is nothing of value in “The Book?” Is it all just impractical theory?

Salviati:  Oh don’t get me wrong, it is necessary to know the stuff in that’s in “The Book”. But it is also important to remember that there is a gap between theory and practice.

Simplicio:  Gap between theory and practice?

Salviati:  Yes there is a significant gap between what is taught in business schools (or written in “The Book”) and the way managers actually do their jobs. The former is called espoused theory and the latter, theory in use (Editor’s note: see this article for more on espoused theory vs theory in use). Espoused theory works in an ideal world where cause-effect relationships are unambiguous, and uncertainty can be predicted and planned for. This is the sort of world that is depicted in those pretty process diagrams that people draw on a whiteboard. In the real world, however, causes aren’t always apparent and best laid plans often go awry. Managers have to deal with this. When doing so, they often improvise on what they have learnt through experience. What books and project theorists tend to overlook is that planning and improvisation are complementary facets of project work. Indeed the most compelling project management stories are about improvisation; about what people did when theory or process was no help at all.

Simplicio:  So you’re saying that theory is incomplete…

Salviati:   Absolutely! Theory cannot teach you what experience does. You see, many project management skills are tacit, they can only be learned by doing. Would you pick up a book about guitar and music theory and expect to play like a virtuoso in an afternoon… or even a month or a year?  .  So it is with project management.   But, look,  tacitness is not the only issue. Another major shortcoming of project management, as it is taught, is that it overlooks the fact that every project is invariably part of a larger system: namely, the hosting organisation and its environment. Understanding this is critical to the success of a project.

Simplicio:  I’m not sure I understand  what you mean by “a larger system”.

Salviati: Consider  the question of project failure. Many experts will tell you that the top causes of project failure are things like “lack of executive support” or “lack of user input” or even “incomplete requirements.” What these experts do not understand is that these are  symptoms rather than causes.  The true causes of failure invariably lie in the hosting organisation, not the project. For example, “lack of user input” often occurs because users typically work on projects in addition to their normal duties. It is but natural that they will therefore view projects as  burdens rather than initiatives that might benefit them in the future. The fault here lies beyond the project. These kinds of issues need to be negotiated through open dialogue between all affected stakeholders rather than via top-down decrees .

Simplicio:  OK, I understand the importance of taking a system-based view, but what is “open dialogue”?

Salviati:   Ever worked for a team or organization where there are some things  that can never be discussed? Ever had bosses who only want to know the good news? Most projects have many different stakeholder groups, each with their own view of the project and motivations. Sponsors, managers, project teams and users – all have their own view on a project’s objectives. As strange as it may sound, these viewpoints are  often divergent, but are never reconciled until its too late. …

Simplicio:  [interrupting] That’s crazy! Why would project managers allow themselves to get into a situation where they are managing  projects in which  stakeholders hold different views on things like scope? That is completely against what “The Book” says! According to it, things such as scope  issues should not be ambiguous at all.

Salviati: Ah, now we get to the heart of the matter! Yes, it is crazy when you think about it, but we are dealing with office hierarchy and politics, as well individual rationality. Many organisations have a blame culture – and as a result, people tend to position themselves for blame avoidance. This creates all sorts of dysfunctional behaviours, and makes it very difficult to discuss things openly. The trick – and why you need to listed to the stories – is to break down these barriers so that a group can engage in open dialogue that will bring such issues out into the open. There are ways to do this, a couple of guys have even written a book on it. (Editor’s note: Perhaps he’s referring to this book?)

Simplicio: OK, I see your point, but what about the unknown unknowns – issues  that no one can foresee at the start.

Salviati:   That’s where trust comes in. The point is, if key stakeholders have a relationship based on trust, they will feel comfortable about informing each other of potential uncertainties as they emerge. They can then work together to address the uncertainty without the usual finger pointing and blame shifting that typically occurs in organisations. They will be no better than anyone else at predicting the future, but they will be able to deal with whatever comes up because they will face it as a group.

Simplicio: Sounds good, but how does one get stakeholders  to trust one another and discuss issues openly?

Salviati:  Well, as I mentioned earlier, much of present-day project management practice operates within a cause and effect paradigm…do this and that will happen. Instead the focus  ought to be on creating the right  conditions or environment in which a group of people can collaborate and work together as a genuine team.   There’s a ton of interesting work on this – some of it dating back to the 1950s

Simplicio: Why hasn’t anyone mentioned this in our discussion group? This is really important!

Salviati: The conditions over causes argument is yet to make an impact on mainstream practice – particularly in project management. Unfortunately,  those who wrote  the “The Book” (and those who update it) seem to  be unaware that conditions are more important than causes. It is a completely different way of looking at projects, so it may take a while for aficionados of “The Book” to make the change. That said, I’m an optimist so I believe that it  will eventually catch on; it is just a matter of time …

[ Salviati’s watch alarm goes off, cutting him off mid-sentence. He  glances at it]

Speaking of time, we’re all prisoners of time, it seems. I’ve got to go; I’m late for a meeting. We’ll continue our conversation later.

Simplicio: Thanks Salviati. I’d very much like that as I’m curious to hear more about your thoughts on this.

Salviati (turning to leave): Sure, I’ll be delighted to chat about it. Let’s meet on the weekend. Catch you later.

Simplicio: See you later.

[The two depart, going their separate ways]

—-

Postscript

A metalogue is a real or imaginary conversation whose structure resembles the topic being discussed. This piece is inspired by Gregory Bateson’s metalogues in Part 1 of his book, Steps To an Ecology of Mind.

The characters in the above metalogue are borrowed from Galileo’s  Dialogue Concerning The Two Chief World Systems in which the character Salviati is a proponent of the Copernican “heresy” that the Earth is not at the centre of the universe whereas Simplicio favours the Geocentric view proposed by the Greek philosopher Ptolemy.

This post is a part of the first ever  #PMFlashBlog initiative which involves over 70 bloggers from  Australia, Canada, Colombia, Denmark, France, Italy, Mexico, Poland, Portugal, Singapore, South Africa, Spain, UK and the USA, all posting a piece on “What Project Means to Me” on their blogs @ 01:00 GMT on 25^th September 2013. A complete list of participants can be found here

Acknowledgements

My thanks go out to Shim Marom for coming up with the wonderful idea of a project management flashblog  and for  the opportunity to participate in it.

I’m indebted to Paul Culmsee  for feedback on a draft version of this post and for countless conversations  over the years on  the philosophical and practical aspects of projects, organisations and systems.   Be sure to check out his blog, in particular his PMFlashBlog post which provides a practical (and very entertaining!) perspective on the “conditions over causes” principle mentioned in this metalogue.