What does project management mean to me – a Project Manager’s sermon

What does project management mean to me?

Well if you want me to give you the ‘glass half empty’ perspective, it’s easy. What project management means to me is a confused discipline where practitioners routinely do really dumb shit in its name.

Sermon over – go forth and spread the word…

Okay so that was fairly blunt, so I had better elaborate and perhaps take a more positively framed ‘glass half full’ approach to this sermon. To do that, I need to tell you about the legacy that Cleo magazine has left on society.

When I was younger, I used to skim through magazines like Cosmopolitan and Cleo while waiting in line at the checkout. Now you might think that I must really be in touch with my feminine side in admitting this, but no: the reality is that raw testosterone was the motivator. You see, Cleo would have headline articles like “10 great sex tips (in 50 words or less)” Or “The 10 things he doesn’t want in bed.” Titles like that dangled the possibility in front of me of finally understanding women, with the added bonus of developing Olympic class skills in the bedroom. Of course, each and every time the actual article never lived up to the catchy title. I rarely learnt anything new and in fact the “10 things” were usually pretty banal, self-evident and left me none the wiser.

So as our collective attention spans diminish via constant exposure to “5 steps to success with [insert buzzword here]” articles (articles designed more for search engine placement than actually informing an audience), the curse of Cleo-like catchy titles telling you stuff of little value is now so commonplace that it is hard to suss out the stuff that really makes a difference in outcomes.

So where does one go to find out the answers in project management? Should aspiring Project Managers master the dark arts of their craft by learning everything there is to learn from one or more of the bibles that contain the word “BoK” in them? On the surface it would seem so, given all of the past collective wisdom that is claimed to be codified therein – as well as shiny certification proving that one has passed the multi-choice exam on its contents.

But wait…which BoK is best? After all, we have multiple to choose from, with each making their own claims to the truth. Some BoKs even reject the key tenets of other BoKs, arguing that theirs offers a better answer. Of course, this leads to an endless stream of debate by their respective proponents as to which is really best and who is really the wisest. Not to mention that over time, new and updated BoKs emerge like phoenixes from the ashes of older BoKs. (Sometimes they are so cool that they don’t even claim to be a BoK at all).

It’s little wonder that Project Management is a confused discipline. No matter where you turn, someone is bound to tell you that you are doing it wrong.

While I am on the subject of doing it wrong, let’s poke a stick in one of the well-known project management hornets-nests: the “Waterfall vs. Scrum” argument. We all know that any self-respecting Scrum guy will not miss an opportunity to tell you about the evils of Waterfall – and for the most part they are right too, as Waterfall has a dubious history of which most people are not aware.

But that is not the reason I chose this particular topic, even though it is much loved by PMs who spend endless hours filling up the forums of various LinkedIn groups with discussion. I chose it simply because it’s fun to mess with Scrum guys – particularly the zealots. So if you have a “scrumdamentalist” in your midst, try this question on them:

Would Waterfall work if one could create an environment where all parties—as soon as they become aware of something that might affect a project materially—communicate it to all other parties involved in the project in a full, sincere and open way?

I have posed this question to many Scrum people. Most will think about it for some time, before answering a grudging “possibly” or “I don’t see why not.” Try it yourself… it’s fun pulling the rug out from under their firmly held convictions.

The best answer I have ever got to this question was from Chris Chapman – an Agile coach from Toronto. He gave me what I think is the perfect answer when he astutely observed that in the environment I described, Waterfall would actually not exist in the first place!

Therein lies the heart of my sermon. I contend that the endless debates over the efficacy of methods, tools and even BoKs are answering the wrong question! Don’t worry though, Project Management is not the first, nor the last discipline to lean their ladder against the wrong wall in this regard. To explain, let me introduce you to the work (and genius) of J Richard Hackman.

From the late sixties, Hackman spent his career researching and teaching about team performance, leadership effectiveness, and the design of self-managing teams and organizations. He died in 2013 and one of his last papers he published was called “From causes to conditions in group research.” In this swansong paper, Hackman explained how he spent years examining the factors that made teams work really well. He studied hundreds of teams (not just project teams mind you, but sporting teams, orchestras and flight crews), with the aim to distil the causes of success. Each time Hackman thought he had the causes figured out he would create a model, plug his model into a stats program, and work with real teams to see if the application of his model led to better performance.

On the surface, this approach seems like a logical thing to do. After all, if we can work out the magic levers that cause team success, then organisations would surely work better because they can start to pull those same levers. This is precisely the value proposition offered by the aforementioned BoKs as well.

When Hackman applied the models he lovingly researched and developed, he found they did not make a significant difference in outcomes. Being an academic, he did what most academics do: he spent years trying to refine his models and then re-tested them against real life teamwork situations. But this didn’t work either; his models got no closer to predicting or influencing outcomes in a reliable fashion. Reality it seemed, never fitted the models he developed.

At this point, Hackman began to question whether he was looking at the problem through the right lens. He wondered if trying to determine the causes of team efficacy by looking at successful teams retrospectively and then codifying these into causal models was the best approach. So he changed his focus and asked himself a very different question – a question that every project management practitioner (and project team member) should be asking themselves:

What are the enabling conditions that need to exist that give rise to great outcomes?

Now if, at this point, you think that this is the same question as “What are the causes of successful projects” you would be mistaken. Think about the BoKs and consider this: if you have ever argued with someone about whether a tool, methodology or some process is great or completely sucks, eventually someone will say something like “Well it can work for the right organisation.”

The implicit point here is that depending on the conditions, something that works for one organisation may completely suck for another (thereby invalidating the notion of a “best” practice). The genius of Hackman is that he challenges us to stop arguing about whether one methodology or model is better than the other and focus on what the enabling conditions are instead. Think about it – if project managers and developers did this, we would be able to avoid low value arguments like earned value management versus burndown charts.

In the case of Hackman, he re-examined all of his work on teams and boiled it down to six essential conditions, arguing that irrespective of what else you did or what methodology you used, having these conditions tended to lead to better results. Hackman did not rank any one condition over any other, instead arguing that all were needed for teams to have a greater chance of being high performing. The conditions are:

1. A real team: Interdependence among members, clear boundaries distinguishing members from non-members and moderate stability of membership over time
2. A compelling purpose: A purpose that is clear, challenging, and consequential. It energizes team members and fully engages their talents
3. Right people: People who had task expertise, self-organised and skill in working collaboratively with others
4. Clear norms of conduct: Team understands clearly what behaviours are, and are not, acceptable
5. A supportive organisational context: The team has the resources it needs and the reward system provides recognition and positive consequences for excellent team performance
6. Appropriate coaching: The right sort of coaching for the team was provided at the right time

There is more to that list than what I am covering here, and it is important to note that I’m not saying that Hackman’s conditions are *the* conditions. But I would contend that they are a pretty good start. Look at Hackman’s conditions for teams above and think about your projects and how you manage them. Did you have these conditions in place when you started? If you had them, would it have led to better outcomes?

I believe that it is a huge mistake to attribute success or failure of projects to methods, processes and models used to manage them rather than the conditions in which those processes operate. As long as this attribution error persists, people will continue to get suckered into B-grade verbal-slugfests about whether method X is better than method Y.

What exacerbates this “causes over conditions” problem is that enabling conditions rarely get codified in procedures, governance models, bodies of knowledge or certifications. As a result, the very factors that leads to success (the conditions) are entirely absent from the models that we use. My contention is that most organisations, when delivering projects, do not have the right enabling conditions in place to begin with. If your organisation has a blame culture, then chances are that any process, no matter how noble its design or intent, has the potential to become a blame apportionment mechanism or a responsibility avoidance mechanism.

So Hackman, despite looking at a different discipline of teamwork and leadership, gives us an important clue about what ails project management and how to we might improve it. Focus on enabling conditions rather than attributing causes!

Let’s get back to Chris Chapman’s answer to my Waterfall question. His assertion that Waterfall would not exist in the conditions I described holds a less obvious lesson. That is, the way project management tools or methods are used will affect conditions as well. So if you have ever said to yourself “I can’t believe that I am being forced to follow this wrong-headed process” chances are you have been on the receiving end of negative conditions created by application of a process. (So in this sense the agile dudes have it right.)

So what does project management mean to me? In short, focusing on creating the enabling conditions for great performance, and then getting out of the way!

Thanks for reading

Paul  Culmsee

Epilogue:

In this sermon I cannot hope to cover all of the things I would like to cover but never fear, Kailash Awati and I already piled some of our thoughts into 420 pages of goodness known as the book “The Heretics Guide to Best Practices” – so if you like what you read here, you will really like what is in there.

Acknowledgements:

As usual I have to thank Kailash for reviewing this post and making it suck much less than it did 🙂

Further reading:

1. My series on rethinking SharePoint maturity: Don’t let the title put you off – the material here further explores the conditions for great project performance: http://www.cleverworkarounds.com/2013/08/19/rethinking-sharepoint-maturity-part-1-conditions-over-causes/
2. Jon Whitty’s brilliant work on memeplexes and reconceptualising project management: http://espace.library.uq.edu.au/eserv/UQ:8801/sjw_ijpm_05.pdf
3. Pretty much anything on Kailash Awati’s blog, but in particular his sermon in this flashblog: http://eight2late.wordpress.com/2013/09/25/what-project-management-means-to-me-a-metalogue/
4. Stephen Duffield’s work on project knowledge management and risk: http://www.invictaprojects.com.au/pmlessonslearnedblog/?p=850

p.s: This post is published as part of a first ever project management related global blogging initiative to publish a post on a common theme at exactly the same time. Over seventy bloggers from Australia, Canada, Colombia, Denmark, France, Italy, Mexico, Poland, Portugal, Singapore, South Africa, Spain, UK and the USA have committed to make a blogging contribution and the fruit of their labor is now (literally NOW) available all over the web. The complete list of all participating blogs is found here so please go and check them out!