Archive for the ‘Project Management’ Category
There are two facets to the operation of IT systems and processes in organisations: governance, the standards and regulations associated with a system or process; and execution, which relates to steering the actual work of the system or process in specific situations.
An example might help clarify the difference:
The purpose of project management is to keep projects on track. There are two aspects to this: one pertaining to the project management office (PMO) which is responsible for standards and regulations associated with managing projects in general, and the other relating to the day-to-day work of steering a particular project. The two sometimes work at cross-purposes. For example, successful project managers know that much of their work is about navigate their projects through the potentially treacherous terrain of their organisations, an activity that sometimes necessitates working around, or even breaking, rules set by the PMO.
Governance and steering share a common etymological root: the word kybernetes, which means steersman in Greek. It also happens to be the root word of Cybernetics which is the science of regulation or control. In this post, I apply a key principle of cybernetics to a couple of areas of enterprise IT.
An oft quoted example of a cybernetic system is a thermostat, a device that regulates temperature based on inputs from the environment. Most cybernetic systems are way more complicated than a thermostat. Indeed, some argue that the Earth is a huge cybernetic system. A smaller scale example is a system consisting of a car + driver wherein a driver responds to changes in the environment thereby controlling the motion of the car.
Cybernetic systems vary widely not just in size, but also in complexity. A thermostat is concerned only the ambient temperature whereas the driver in a car has to worry about a lot more (e.g. the weather, traffic, the condition of the road, kids squabbling in the back-seat etc.). In general, the more complex the system and its processes, the larger the number of variables that are associated with it. Put another way, complex systems must be able to deal with a greater variety of disturbances than simple systems.
The law of requisite variety
It turns out there is a fundamental principle – the law of requisite variety– that governs the capacity of a system to respond to changes in its environment. The law is a quantitative statement about the different types of responses that a system needs to have in order to deal with the range of disturbances it might experience.
According to this paper, the law of requisite variety asserts that:
The larger the variety of actions available to a control system, the larger the variety of perturbations it is able to compensate.
V(E) > V(D) – V(R) – K
Where V represents variety, E represents the essential variable(s) to be controlled, D represents the disturbance, R the regulation and K the passive capacity of the system to absorb shocks. The terms are explained in brief below:
V(E) represents the set of desired outcomes for the controlled environmental variable: desired temperature range in the case of the thermostat, successful outcomes (i.e. projects delivered on time and within budget) in the case of a project management office.
V(D) represents the variety of disturbances the system can be subjected to (the ways in which the temperature can change, the external and internal forces on a project)
V(R) represents the various ways in which a disturbance can be regulated (the regulator in a thermostat, the project tracking and corrective mechanisms prescribed by the PMO)
K represents the buffering capacity of the system – i.e. stored capacity to deal with unexpected disturbances.
I won’t say any more about the law of requisite variety as it would take me to far afield; the interested and technically minded reader is referred to the link above or this paper for more (full pdf here).
Implications for enterprise IT
In plain English, the law of requisite variety states that only “variety can absorb variety.” As stated by Anthony Hodgson in an essay in this book, the law of requisite variety:
…leads to the somewhat counterintuitive observation that the regulator must have a sufficiently large variety of actions in order to ensure a sufficiently small variety of outcomes in the essential variables E. This principle has important implications for practical situations: since the variety of perturbations a system can potentially be confronted with is unlimited, we should always try maximize its internal variety (or diversity), so as to be optimally prepared for any foreseeable or unforeseeable contingency.
This is entirely consistent with our intuitive expectation that the best way to deal with the unexpected is to have a range of tools and approaches at ones disposal.
In the remainder of this piece, I’ll focus on the implications of the law for an issue that is high on the list of many corporate IT departments: the standardization of IT systems and/or processes.
The main rationale behind standardizing an IT process is to handle all possible demands (or use cases) via a small number of predefined responses. When put this way, the connection to the law of requisite variety is clear: a request made upon a function such as a service desk or project management office (PMO) is a disturbance and the way they regulate or respond to it determines the outcome.
Requisite variety and the service desk
A service desk is a good example of a system that can be standardized. Although users may initially complain about having to log a ticket instead of calling Nathan directly, in time they get used to it, and may even start to see the benefits…particularly when Nathan goes on vacation.
The law of requisite variety tells us successful standardization requires that all possible demands made on the system be known and regulated by the V(R) term in the equation above. In case of a service desk this is dealt with by a hierarchy of support levels. 1st level support deals with routine calls (incidents and service requests in ITIL terminology) such as system access and simple troubleshooting. Calls that cannot be handled by this tier are escalated to the 2nd and 3rd levels as needed. The assumption here is that, between them, the three support tiers should be able to handle majority of calls.
Slack (the K term) relates to unexploited capacity. Although needed in order to deal with unexpected surges in demand, slack is expensive to carry when one doesn’t need it. Given this, it makes sense to incorporate such scenarios into the repertoire of the standard system responses (i.e the V(R) term) whenever possible. One way to do this is to anticipate surges in demand and hire temporary staff to handle them. Another way is to deal with infrequent scenarios outside the system- i.e. deem them out of scope for the service desk.
Service desk standardization is thus relatively straightforward to achieve provided:
- The kinds of calls that come in are largely predictable.
- The work can be routinized.
- All non-routine work – such as an application enhancement request or a demand for a new system- is dealt with outside the system via (say) a change management process.
All this will be quite unsurprising and obvious to folks working in corporate IT. Now let’s see what happens when we apply the law to a more complex system.
Requisite variety and the PMO
Many corporate IT leaders see the establishment of a PMO as a way to control costs and increase efficiency of project planning and execution. PMOs attempt to do this by putting in place governance mechanisms. The underlying cause-effect assumption is that if appropriate rules and regulations are put in place, project execution will necessarily improve. Although this sounds reasonable, it often does not work in practice: according to this article, a significant fraction of PMOs fail to deliver on the promise of improved project performance. Consider the following points quoted directly from the article:
- “50% of project management offices close within 3 years (Association for Project Mgmt)”
- “Since 2008, the correlated PMO implementation failure rate is over 50% (Gartner Project Manager 2014)”
- “Only a third of all projects were successfully completed on time and on budget over the past year (Standish Group’s CHAOS report)”
- “68% of stakeholders perceive their PMOs to be bureaucratic (2013 Gartner PPM Summit)”
- “Only 40% of projects met schedule, budget and quality goals (IBM Change Management Survey of 1500 execs)”
The article goes on to point out that the main reason for the statistics above is that there is a gap between what a PMO does and what the business expects it to do. For example, according to the Gartner review quoted in the article over 60% of the stakeholders surveyed believe their PMOs are overly bureaucratic. I can’t vouch for the veracity of the numbers here as I cannot find the original paper. Nevertheless, anecdotal evidence (via various articles and informal conversations) suggests that a significant number of PMOs fail.
There is a curious contradiction between the case of the service desk and that of the PMO. In the former, process and methodology seem to work whereas in the latter they don’t.
The answer, as you might suspect, has to do with variety. Projects and service requests are very different beasts. Among other things, they differ in:
- Duration: A project typically goes over many months whereas a service request has a lifetime of days,
- Technical complexity: A project involves many (initially ill-defined) technical tasks that have to be coordinated and whose outputs have to be integrated. A service request typically consists one (or a small number) of well-defined tasks.
- Social complexity: A project involves many stakeholder groups, with diverse interests and opinions. A service request typically involves considerably fewer stakeholders, with limited conflicts of opinions/interests.
It is not hard to see that these differences increase variety in projects compared to service requests. The reason that standardization (usually) works for service desks but (often) fails for PMOs is that the PMOs are subjected a greater variety of disturbances than service desks.
The key point is that the increased variety in the case of the PMO precludes standardisation. As the law of requisite variety tells us, there are two ways to deal with variety: regulate it or adapt to it. Most PMOs take the regulation route, leading to over-regulation and outcomes that are less than satisfactory. This is exactly what is reflected in the complaint about PMOs being overly bureaucratic. The solution simple and obvious solution is for PMOs to be more flexible– specifically, they must be able to adapt to the ever changing demands made upon them by their organisations’ projects. In terms of the law of requisite variety, PMOs need to have the capacity to change the system response, V(R), on the fly. In practice this means recognising the uniqueness of requests by avoiding reflex, cookie cutter responses that characterise bureaucratic PMOs.
The law of requisite variety is a general principle that applies to any regulated system. In this post I applied the law to two areas of enterprise IT – service management and project governance – and discussed why standardization works well for the former but less satisfactorily for the latter. Indeed, in view of the considerable differences in the duration and complexity of service requests and projects, it is unreasonable to expect that standardization will work well for both. The key takeaway from this piece is therefore a simple one: those who design IT functions should pay attention to the variety that the functions will have to cope with, and bear in mind that standardization works well only if variety is known and limited.
An irony of organisational life is that the most important decisions on projects (or any other initiatives) have to be made at the start, when ambiguity is at its highest and information availability lowest. I recently gave a talk at the Pune office of BMC Software on improving decision-making in such situations.
The talk was recorded and simulcast to a couple of locations in India. The folks at BMC very kindly sent me a copy of the recording with permission to publish it on Eight to Late. Here it is:
Based on the questions asked and the feedback received, I reckon that a number of people found the talk useful. I’d welcome your comments/feedback.
Acknowledgements: My thanks go out to Gaurav Pal, Manish Gadgil and Mrinalini Wankhede for giving me the opportunity to speak at BMC, and to Shubhangi Apte for putting me in touch with them. Finally, I’d like to thank the wonderful audience at BMC for their insightful questions and comments.
Last week, my friend Paul Culmsee conducted an internal workshop in my organisation on the theme of collaborative problem solving. Dialogue mapping is one of the tools of the tools he introduced during the workshop. This piece, primarily intended as a follow-up for attendees, is an introduction to dialogue mapping via a vignette that illustrates its practice (see this post for another one). I’m publishing it here as I thought it might be useful for those who wish to understand what the technique is about.
Dialogue mapping uses a notation called Issue Based Information System (IBIS), which I have discussed at length in this post. For completeness, I’ll begin with a short introduction to the notation and then move on to the vignette.
A crash course in IBIS
The IBIS notation consists of the following three elements:
- Issues(or questions): these are issues that are being debated. Typically, issues are framed as questions on the lines of “What should we do about X?” where X is the issue that is of interest to a group. For example, in the case of a group of executives, X might be rapidly changing market condition whereas in the case of a group of IT people, X could be an ageing system that is hard to replace.
- Ideas(or positions): these are responses to questions. For example, one of the ideas of offered by the IT group above might be to replace the said system with a newer one. Typically the whole set of ideas that respond to an issue in a discussion represents the spectrum of participant perspectives on the issue.
- Arguments: these can be Pros (arguments for) or Cons (arguments against) an issue. The complete set of arguments that respond to an idea represents the multiplicity of viewpoints on it.
In Compendium, IBIS elements are represented as nodes as shown in Figure 1: issues are represented by blue-green question marks; positions by yellow light bulbs; pros by green + signs and cons by red – signs. Compendium supports a few other node types, but these are not part of the core IBIS notation. Nodes can be linked only in ways specified by the IBIS grammar as I discuss next.
The IBIS grammar can be summarized in three simple rules:
- Issues can be raised anew or can arise from other issues, positions or arguments. In other words, any IBIS element can be questioned. In Compendium notation: a question node can connect to any other IBIS node.
- Ideas can only respond to questions– i.e. in Compendium “light bulb” nodes can only link to question nodes. The arrow pointing from the idea to the question depicts the “responds to” relationship.
- Arguments can only be associated with ideas– i.e. in Compendium “+” and “–“ nodes can only link to “light bulb” nodes (with arrows pointing to the latter)
The legal links are summarized in Figure 2 below.
…and that’s pretty much all there is to it.
The interesting (and powerful) aspect of IBIS is that the essence of any debate or discussion can be captured using these three elements. Let me try to convince you of this claim via a vignette from a discussion on risk.
The Risk – a Dialogue Mapping vignette
“Morning all,” said Rick, “I know you’re all busy people so I’d like to thank you for taking the time to attend this risk identification session for Project X. The objective is to list the risks that we might encounter on the project and see if we can identify possible mitigation strategies.”
He then asked if there were any questions. The head waggles around the room indicated there were none.
“Good. So here’s what we’ll do,” he continued. “I’d like you all to work in pairs and spend 10 minutes thinking of all possible risks and then another 5 minutes prioritising. Work with the person one your left. You can use the flipcharts in the breakout area at the back if you wish to.”
Twenty minutes later, most people were done and back in their seats.
“OK, it looks as though most people are done…Ah, Joe, Mike have you guys finished?” The two were still working on their flip-chart at the back.
“Yeah, be there in a sec,” replied Mike, as he tore off the flip-chart page.
“Alright,” continued Rick, after everyone had settled in. “What I’m going to do now is ask you all to list your top three risks. I’d also like you tell me why they are significant and your mitigation strategies for them.” He paused for a second and asked, “Everyone OK with that?”
Everyone nodded, except Helen who asked, “isn’t it important that we document the discussion?”
“I’m glad you brought that up. I’ll make notes as we go along, and I’ll do it in a way that everyone can see what I’m writing. I’d like you all to correct me if you feel I haven’t understood what you’re saying. It is important that my notes capture your issues, ideas and arguments accurately.”
Rick turned on the data projector, fired up Compendium and started a new map. “Our aim today is to identify the most significant risks on the project – this is our root question” he said, as he created a question node. “OK, so who would like to start?”
“Sure,” we’ll start, said Joe easily. “Our top risk is that the schedule is too tight. We’ll hit the deadline only if everything goes well, and everyone knows that they never do.”
“OK,” said Rick, “as he entered Joe and Mike’s risk as an idea connecting to the root question. “You’ve also mentioned a point that supports your contention that this is a significant risk – there is absolutely no buffer.” Rick typed this in as a pro connecting to the risk. He then looked up at Joe and asked, “have I understood you correctly?”
“Yes,” confirmed Joe.
“That’s pretty cool,” said Helen from the other end of the table, “I like the notation, it makes reasoning explicit. Oh, and I have another point in support of Joe and Mike’s risk – the deadline was imposed by management before the project was planned.”
Rick began to enter the point…
“Oooh, I’m not sure we should put that down,” interjected Rob from compliance. “I mean, there’s not much we can do about that can we?”
…Rick finished the point as Rob was speaking.
“I hear you Rob, but I think it is important we capture everything that is said,” said Helen.
“I disagree,” said Rob. “It will only annoy management.”
“Slow down guys,” said Rick, “I’m going to capture Rob’s objection as “this is a management imposed-constraint rather than risk. Are you OK with that, Rob?”
Rob nodded his assent.
I think it is important we articulate what we really think, even if we can’t do anything about it,” continued Rick. There’s no point going through this exercise if we don’t say what we really think. I want to stress this point, so I’m going to add honesty and openness as ground rules for the discussion. Since ground rules apply to the entire discussion, they connect directly to the primary issue being discussed.”
“OK, so any other points that anyone would like to add to the ones made so far?” Queried Rick as he finished typing.
He looked up. Most of the people seated round the table shook their heads indicating that there weren’t.
“We haven’t spoken about mitigation strategies. Any ideas?” Asked Rick, as he created a question node marked “Mitigation?” connecting to the risk.
“Yeah well, we came up with one,” said Mike. “we think the only way to reduce the time pressure is to cut scope.”
“OK,” said Rick, entering the point as an idea connecting to the “Mitigation?” question. “Did you think about how you are going to do this? He entered the question “How?” connecting to Mike’s point.
“That’s the problem,” said Joe, “I don’t know how we can convince management to cut scope.”
“Hmmm…I have an idea,” said Helen slowly…
“We’re all ears,” said Rick.
“…Well…you see a large chunk of time has been allocated for building real-time interfaces to assorted systems – HR, ERP etc. I don’t think these need to be real-time – they could be done monthly…and if that’s the case, we could schedule a simple job or even do them manually for the first few months. We can push those interfaces to phase 2 of the project, well into next year.”
There was a silence in the room as everyone pondered this point.
“You know, I think that might actually work, and would give us an extra month…may be even six weeks for the more important upstream stuff,” said Mike. “Great idea, Helen!”
“Can I summarise this point as – identify interfaces that can be delayed to phase 2?” asked Rick, as he began to type it in as a mitigation strategy. “…and if you and Mike are OK with it, I’m going to combine it with the ‘Cut Scope’ idea to save space.”
“Yep, that’s fine,” said Helen. Mike nodded OK.
Rick deleted the “How?” node connecting to the “Cut scope” idea, and edited the latter to capture Helen’s point.
“That’s great in theory, but who is going to talk to the affected departments? They will not be happy.” asserted Rob. One could always count on compliance to throw in a reality check.
“Good point,” said Rick as he typed that in as a con, “and I’ll take the responsibility of speaking to the department heads about this,” he continued entering the idea into the map and marking it as an action point for himself. “Is there anything else that Joe, Mike…or anyone else would like to add here,” he added, as he finished.
“Nope,” said Mike, “I’m good with that.”
“Yeah me too,” said Helen.
“I don’t have anything else to say about this point,” said Rob, “ but it would be great if you could give us a tutorial on this technique. I think it could be useful to summarise the rationale behind our compliance regulations. Folks have been complaining that they don’t understand the reasoning behind some of our rules and regulations. ”
“I’d be interested in that too,” said Helen, “I could use it to clarify user requirements.”
“I’d be happy to do a session on the IBIS notation and dialogue mapping next week. I’ll check your availability and send an invite out… but for now, let’s focus on the task at hand.”
The discussion continued…but the fly on the wall was no longer there to record it.
I hope this little vignette illustrates how IBIS and dialogue mapping can aid collaborative decision-making / problem solving by making diverse viewpoints explicit. That said, this is a story, and the problem with stories is that things go the way the author wants them to. In real life, conversations can go off on unexpected tangents, making them really hard to map. So, although it is important to gain expertise in using the software, it is far more important to practice mapping live conversations. The latter is an art that requires considerable practice. I recommend reading Paul Culmsee’s series on the practice of dialogue mapping or <advertisement> Chapter 14 of The Heretic’s Guide to Best Practices</advertisement> for more on this point.
That said, there are many other ways in which IBIS can be used, that do not require as much skill. Some of these include: mapping the central points in written arguments (what’s sometimes called issue mapping) and even decisions on personal matters.
To sum up: IBIS is a powerful means to clarify options and lay them out in an easy-to-follow visual format. Often this is all that is required to catalyse a group decision.
As narrated by Dr. John Watson, M.D.…
As my readers are undoubtedly aware, my friend Sherlock Holmes is widely feted for his powers of logic and deduction. With all due modesty, I can claim to have played a small part in publicizing his considerable talents, for I have a sense for what will catch the reading public’s fancy and, perhaps more important, what will not. Indeed, it could be argued that his fame is in no small part due to the dramatic nature of the exploits which I have chosen to publicise.
Management consulting, though far more lucrative than criminal investigation, is not nearly as exciting. Consequently my work has become that much harder since Holmes reinvented himself as a management expert. Nevertheless, I am firmly of the opinion that the long-standing myths exposed by his recent work more than make up for any lack of suspense or drama.
A little known fact is that many of Holmes’ insights into flawed management practices have come after the fact, by discerning common themes that emerged from different cases. Of course this makes perfect sense: only after seeing the same (or similar) mistake occur in a variety of situations can one begin to perceive an underlying pattern.
The conversation I had with him last night is an excellent illustration of this point.
We were having dinner at Holmes’ Baker Street abode when, apropos of nothing, he remarked, “It’s a strange thing, Watson, that our lives are governed by routine. For instance, it is seven in the evening, and here we are having dinner, much like we would on any other day.”
“Yes, it is,” I said, intrigued by his remark. Dabbing my mouth with a napkin, I put down my fork and waited for him to say more.
He smiled. “…and do you think that is a good thing?”
I thought about it for a minute before responding. “Well, we follow routine because we like…or need… regularity and predictability,” I said. “Indeed, as a medical man, I know well that our bodies have built in clocks that drive us to do things – such as eat and sleep – at regular intervals. That apart, routines give us a sense of comfort and security in an unpredictable world. Even those who are adventurous have routines of their own. I don’t think we have a choice in the matter, it’s the way humans are wired.” I wondered where the conversation was going.
Holmes cocked an eyebrow. “Excellent, Watson!” he said. “Our propensity for routine is quite possibly a consequence of our need for security and comfort ….but what about the usefulness of routines – apart from the sense of security we get from them?”
“Hmmm…that’s an interesting question. I suppose a routine must have a benefit, or at least a perceived benefit…else it would not have been made into a routine.”
“Possibly,” said Holmes, “ but let me ask you another question. You remember the case of the failed projects do you not?”
“Yes, I do,” I replied. Holmes’ abrupt conversational U-turns no longer disconcert me, I’ve become used to them over the years. I remembered the details of the case like it had happened yesterday…indeed I should, as it was I who wrote the narrative!
“Did anything about the case strike you as strange?” he inquired.
I mulled over the case, which (in hindsight) was straightforward enough. Here are the essential facts:
The organization suffered from a high rate of project failure (about 70% as I recall). The standard prescription – project post-mortems followed by changes in processes aimed at addressing the top issues revealed – had failed to resolve the issue. Holmes’ insightful diagnosis was that the postmortems identified symptoms, not causes. Therefore the measures taken to fix the problems didn’t work because they did not address the underlying cause. Indeed, the measures were akin to using brain surgery to fix a headache. In the end, Holmes concluded that the failures were a consequence of flawed organizational structures and norms.
Of course flawed structures and norms are beyond the purview of a mere project or program manager. So Holmes’ diagnosis, though entirely correct, did not help Bryant (the manager who had consulted us).
Nothing struck me as unduly strange as went over the facts mentally. No,” I replied, “but what on earth does that have to do with routine?”
He smiled. “I will explain presently, but I have yet another question for you before I do so. Do you remember one of our earliest management consulting cases – the affair of the terminated PMO?”
I replied in the affirmative.
“Well then, you see the common thread running through the two cases, don’t you?” Seeing my puzzled look, he added, “think about it for a minute, Watson, while I go and fetch dessert.”
He went into the kitchen, leaving me to ponder his question.
The only commonality I could see was the obvious one – both cases were related to the failure of PMOs. (Editor’s note: PMO = Project Management Office)
He returned with dessert a few minutes later. “So, Watson,” he said as he sat down, “have you come up with anything?
I told him what I thought.
“Capital, Watson! Then you will, no doubt, have asked yourself the obvious next question. ”
I saw what he was getting at. “Yes! The question is: can this observation be generalised? Do majority of PMOs fail? ”
“Brilliant, Watson. You are getting better at this by the day.” I know Holmes does not intend to sound condescending, but the sad fact is that he often does. “Let me tell you,” he continued, “Research suggests that 50% of PMOs fail within three years of being set up. My hypothesis is that failure rate would be considerably higher if the timeframe is increased to five or seven years. What’s even more interesting is that there is a single overriding complaint about PMOs: the majority of stakeholders surveyed felt that their PMOs are overly bureaucratic, and generally hinder project work.”
“But isn’t that contrary to the aim of a PMO – which, as I understand, is to facilitate project work?” I queried.
“Excellent, my dear Watson. You are getting close to the heart of the matter.
“I am?” To be honest, I was a little lost.
“Ah Watson, don’t tell me you do not see it,” said Holmes exasperatedly.
“I’m afraid you’ll have to explain,” I replied curtly. Really, he could insufferable at times.
“I shall do my best. You see, there is a fundamental contradiction between the stated mission and actual operation of a typical PMO. In theory, they are supposed to facilitate projects, but as far as executive management is concerned this is synonymous with overseeing and controlling projects. What this means is that in practice, PMOs inevitably end up policing project work rather than facilitating it.”
I wasn’t entirely convinced. “May be the reason that PMOs fail is that organisations do not implement them correctly,” I said.
“Ah, the famous escape clause used by purveyors of best practices – if our best practice doesn’t work, it means you aren’t implementing it correctly. Pardon me while I choke on my ale, because that is utter nonsense.”
“Well, one would expect after so many years, these so-called implementation errors would have been sorted out. Yet we see the same poor outcomes over and over again,” said Holmes.
“OK, but then why are PMOs are still so popular with management?”
“Now we come to the crux of matter, Watson,” he said, a tad portentously, “They are popular for reasons we spoke of at the start of this conversation – comfort and security.”
“Comfort and security? I have no idea what you’re talking about.”
“Let me try explaining this in another way,” he said. “When you were a small child, you must have had some object that you carried around everywhere…a toy, perhaps…did you not?”
“I’m not sure I should tell you this Holmes but, yes, I had a blanket”
“A security blanket, I would never have guessed, Watson,” smiled Holmes. “…but as it happens that’s a perfect example because PMOs and the methodologies they enforce are security blankets. They give executives and frontline managers a sense that they are doing something concrete and constructive to manage uncertainty…even though they actually aren’t. PMOs are popular , not because they work (and indeed, we’ve seen they don’t) but because they help managers contain their anxiety about whether things will turn out right. I would not be exaggerating if I said that PMOs and the methodologies they evangelise are akin to lucky charms or fetishes.”
“That’s a strong a statement to make on rather slim grounds,” I said dubiously.
“Is it? Think about it, Watson,” he shot back, with a flash of irritation. “Many (though I should admit, not all) PMOs and methodologies prescribe excruciatingly detailed procedures to follow and templates to fill when managing projects. For many (though again, not all) project managers, managing a project is synonymous with following these rituals. Such managers attempt to force-fit reality into standardised procedures and documents. But tell me, Watson – how can such project management by ritual work when no two projects are the same?”
“That is not all, Watson,” he continued, before I could respond, “PMOs and methodologies enable people to live in a fantasy world where everything seems to be under control. Methodology fetishists will not see the gap between their fantasy world and reality, and will therefore miss opportunities to learn. They follow rituals that give them security and an illusion of efficiency, but at the price of a genuine engagement with people and projects.”
“ I’ll have to think about it,” I said.
“You do that,” he replied , as he pushed back his chair and started to clear the table. Unlike him, I had a lot more than dinner to digest. Nevertheless, I rose to help him as I do every day.
Evening conversations at 221B Baker Street are seldom boring. Last night was no exception.
This tale was inspired David Wastell’s brilliant paper, The fetish of technique: methodology as social defence (abstract only).
In their book, Waltzing with Bears, Tom DeMarco and Timothy Lister coined the phrase, “risk management is project management for adults”. Twenty years on, it appears that their words have been taken seriously: risk management now occupies a prominent place in BOKs, and has also become a key element of project management practice.
On the other hand, if the evidence is to be believed (as per the oft quoted Chaos Report, for example), IT projects continue to fail at an alarming rate. This is curious because one would have expected that a greater focus on risk management ought to have resulted in better outcomes. So, is it possible at all that risk management (as it is currently preached and practiced in IT project management) cannot address certain risks…or, worse, that there are certain risks are simply not recognized as risks?
Some time ago, I came across a paper by Richard Barber that sheds some light on this very issue. This post elaborates on the nature and importance of such “hidden” risks by drawing on Barber’s work as well as my experiences and those of my colleagues with whom I have discussed the paper.
What are internally generated risks?
The standard approach to risk is based on the occurrence of events. Specifically, risk management is concerned with identifying potential adverse events and taking steps to reduce either their probability of occurrence or their impact. However, as Barber points out, this is a limited view of risk because it overlooks adverse conditions that are built into the project environment. A good example of this is an organizational norm that centralizes decision making at the corporate or managerial level. Such a norm would discourage a project manager from taking appropriate action when confronted with an event that demands an on-the-spot decision. Clearly, it is wrong-headed to attribute the risk to the event because the risk actually has its origins in the norm. In other words, it is an internally generated risk.
(Note: the notion of an internally generated risk is akin to the risk as a pathogen concept that I discussed in this post many years ago.)
Barber defines an internally generated risk as one that has its origin within the project organisation or its host, and arises from [preexisting] rules, policies, processes, structures, actions, decisions, behaviours or cultures. Some other examples of such risks include:
- An overly bureaucratic PMO.
- An organizational culture that discourages collaboration between teams.
- An organizational structure that has multiple reporting lines – this is what I like to call a pseudo-matrix organization 🙂
These factors are similar to those that I described in my post on the systemic causes of project failure. Indeed, I am tempted to call these systemic risks because they are related to the entire system (project + organization). However, that term has already been appropriated by the financial risk community.
Since the term is relatively new, it is important to draw distinctions between internally generated and other types of risks. It is easy to do so because the latter (by definition) have their origins outside the hosting organization. A good example of the latter is the risk of a vendor not delivering a module on time or worse, going into receivership prior to delivering the code.
Finally, there are certain risks that are neither internally generated nor external. For example, using a new technology is inherently risky simply because it is new. Such a risk is inherent rather than internally generated or external.
Understanding the danger within
The author of the paper surveyed nine large projects with the intent of getting some insight into the nature of internally generated risks. The questions he attempted to address are the following:
- How common are these risks?
- How significant are they?
- How well are they managed?
- What is the relationship between the ability of an organization to manage such risks and the organisation’s project management maturity level (i.e. the maturity of its project management processes)
Data was gathered through group workshops and one-on-one interviews in which the author asked a number of questions that were aimed at gaining insight into:
- The key difficulties that project managers encountered on the projects.
- What they perceived to be the main barriers to project success.
The aim of the one-on-one interviews was to allow for a more private setting in which sensitive issues (politics, dysfunctional PMOs and brain-dead rules / norms) could be freely discussed.
The data gathered was studied in detail, with the intent of identifying internally generated risks. The author describes the techniques he used to minimize subjectivity and to ensure that only significant risks were considered. I will omit these details here, and instead focus on his findings as they relate to the questions listed above.
Commonality of internally generated risks
Since organizational rules and norms are often flawed, one might expect that internally generated risks would be fairly common in projects. The author found that this was indeed the case with the projects he surveyed: in his words, the smallest number of non-trivial internally generated risks identified in any of the nine projects was 15, and the highest was 30! Note: the identification of non-trivial risks was done by eliminating those risks that a wide range of stakeholders agreed as being unimportant.
Unfortunately, he does not explicitly list the most common internally-generated risks that he found. However, there are a few that he names later in the article. These are:
- Resource allocation (see my article on the resource allocation syndrome for much more on this)
- Inadequate sponsorship (see my post on the systemic roots of project failure for more on this)
I suspect that experienced project managers would be able to name many more.
Significance of internally generated risks
Determining the significance of these risks is tricky because one has to figure out their probability of occurrence. The impact is much easier to get a handle on, as one has a pretty good idea of the consequences of such risks should they eventuate. (Question: What happens if there is inadequate sponsorship? Answer: the project is highly likely to fail!). The author attempted to get a qualitative handle on the probability of occurrence by asking relevant stakeholders to estimate the likelihood of occurrence. Based on the responses received, he found that a large fraction of the internally-generated risks are significant (high probability of occurrence and high impact).
Management of internally generated risks
To identify whether internally generated risks are well managed, the author asked relevant project teams to look at all the significant internal risks on their project and classify them as to whether or not they had been identified by the project team prior to the research. He found that in over half the cases, less than 50% of the risks had been identified. However, most of the risks that were identified were not managed!
The relationship between project management maturity and susceptibility to internally generated risk
Project management maturity refers to the level of adoption of standard good practices within an organization. Conventional wisdom tells us that there should be an inverse correlation between maturity levels and susceptibility to internally generated risk – the higher the maturity level, the lower the susceptibility.
The author assessed maturity levels by interviewing various stakeholders within the organization and also by comparing the processes used within the organization to well-known standards. The results indicated a weak negative correlation – that is, organisations with a higher level of maturity tended to have a smaller number of internally generated risks. However, as the author admits, one cannot read much into this finding as the correlation was weak.
The study suggests that internally generated risks are common and significant on projects. However, the small sample size also suggests that more comprehensive surveys are needed. Nevertheless, anecdotal evidence from colleagues who I spoke with suggests that the findings are reasonably robust. Moreover, it is also clear (both, from the study and my conversations) that these risks are not very well managed. There is a good reason for this: internally generated risks originate in human behavior and / or dysfunctional structures. These tend to be a difficult topic to address in an organizational setting because people are unlikely to tell those above them in the hierarchy that they (the higher ups) are the cause of a problem. A classic example of such a risk is estimation by decree – where a project team is told to just get it done by a certain date. Although most project managers are aware of such risks, they are reluctant to name them for obvious reasons.
I suspect most project managers who work in corporate environments will have had to grapple with internally generated risks in one form or another. Although traditional risk management does not recognize these risks as risks, seasoned project managers know from experience that people, politics or even processes can pose major problems to smooth working of projects. However, even when recognised for what they are, these risks can be hard to tackle because they lie outside a project manager’s sphere of influence. They therefore tend to become those proverbial pachyderms in the room – known to all but never discussed, let alone documented….and therein lies the danger within.
Much can be learnt about an organization by observing what management does when things go wrong. One reaction is to hunt for a scapegoat, someone who can be held responsible for the mess. The other is to take a systemic view that focuses on finding the root cause of the issue and figuring out what can be done in order to prevent it from recurring. In a highly cited paper published in 2000, James Reason compared and contrasted the two approaches to error management in organisations. This post is an extensive summary of the paper.
The author gets to the point in the very first paragraph:
The human error problem can be viewed in two ways: the person approach and the system approach. Each has its model of error causation and each model gives rise to quite different philosophies of error management. Understanding these differences has important practical implications for coping with the ever present risk of mishaps in clinical practice.
Reason’s paper was published in the British Medical Journal and hence his focus on the practice of medicine. His arguments and conclusions, however, have a much wider relevance as evidenced by the diverse areas in which his paper has been cited.
The person approach – which, I think is more accurately called the scapegoat approach – is based on the belief that any errors can and should be traced back to an individual or a group, and that the party responsible should then be held to account for the error. This is the approach taken in organisations that are colloquially referred to as having a “blame culture.”
To an extent, looking around for a scapegoat is a natural emotional reaction to an error. The oft unstated reason behind scapegoating, however, is to avoid management responsibility. As the author tells us:
People are viewed as free agents capable of choosing between safe and unsafe modes of behaviour. If something goes wrong, it seems obvious that an individual (or group of individuals) must have been responsible. Seeking as far as possible to uncouple a person’s unsafe acts from any institutional responsibility is clearly in the interests of managers. It is also legally more convenient…
However, the scapegoat approach has a couple of serious problems that hinder effective risk management.
Firstly, an organization depends on its frontline staff to report any problems or lapses. Clearly, staff will do so only if they feel that it is safe to do so – something that is simply not possible in an organization that takes scapegoat approach. The author suggests that the Chernobyl disaster can be attributed to the lack of a “reporting culture” within the erstwhile Soviet Union.
Secondly, and perhaps more important, is that the focus on a scapegoat leaves the underlying cause of the error unaddressed. As the author puts it, “by focusing on the individual origins of error it [the scapegoat approach] isolates unsafe acts from their system context.” As a consequence, the scapegoat approach overlooks systemic features of errors – for example, the empirical fact that the same kinds of errors tend to recur within a given system.
The system approach accepts that human errors will happen. However, in contrast to the scapegoat approach, it views these errors as being triggered by factors that are built into the system. So, when something goes wrong, the system approach focuses on the procedures that were used rather than the people who were executing them. This difference from the scapegoat approach makes a world of difference.
The system approach looks for generic reasons why errors or accidents occur. Organisations usually have a series of measures in place to prevent errors – e.g. alarms, procedures, checklists, trained staff etc. Each of these measures can be looked upon as a “defensive layer” against error. However, as the author notes, each defensive layer has holes which can let errors “pass through” (more on how the holes arise a bit later). A good way to visualize this is as a series of slices of Swiss Cheese (see Figure 1).
The important point is that the holes on a given slice are not at a fixed position; they keep opening, closing and even shifting around, depending on the state of the organization. An error occurs when the ephemeral holes on different layers temporarily line up to “let an error through”.
There are two reasons why holes arise in defensive layers:
- Active errors: These are unsafe acts committed by individuals. Active errors could be violations of set procedures or momentary lapses. The scapegoat approach focuses on identifying the active error and the person responsible for it. However, as the author points out, active errors are almost always caused by conditions built into the system, which brings us to…
- Latent conditions: These are flaws that are built into the system. The author uses the term resident pathogens to describe these – a nice metaphor that I have explored in a paper review I wrote some years ago. These “pathogens” are usually baked into the system by poor design decisions and flawed procedures on the one hand, and ill-thought-out management decisions on the other. Manifestations of the former include faulty alarms, unrealistic or inconsistent procedures or poorly designed equipment; manifestations of the latter include things such as unrealistic targets, overworked staff and the lack of funding for appropriate equipment.
The important thing to note is that latent conditions can lie dormant for a long period before they are noticed. Typically a latent condition comes to light only when an error caused by it occurs…and only if the organization does a root cause analysis of the error – something that is simply not done in an organization takes a scapegoat approach.
The author draws a nice analogy that clarifies the link between active errors and latent conditions:
…active failures are like mosquitoes. They can be swatted one by one, but they still keep coming. The best remedies are to create more effective defences and to drain the swamps in which they breed. The swamps, in this case, are the ever present latent conditions.
“Draining the swamp” is not a simple task. The author draws upon studies of high performance organisations (combat units, nuclear power plants and air traffic control centres) to understand how they minimised active errors by reducing system flaws. He notes that these organisations:
- Accept that errors will occur despite standardised procedures, and train their staff to deal with and learn from them.
- Practice responses to known error scenarios and try to imagine new ones on a regular basis.
- Delegate responsibility and authority, especially in crisis situations.
- Do a root cause analysis of any error that occurs and address the underlying problem by changing the system if needed.
In contrast, an organisation that takes a scapegoat approach assumes that standardisation will eliminate errors, ignores the possibility of novel errors occurring, centralises control and, above all, focuses on finding scapegoats instead of fixing the system.
Figure 1 was taken from the Patient Safety Education website of Duke University Hospital.
The Swiss Cheese model was first proposed in 1991. It has since been applied in many areas. Here are a couple of recent applications and extensions of the model to project management:
I’ve long been thinking about initiating an ongoing series of conversations with sensemakers – a term I define, very broadly, as people who help us make sense of the things we do at work. So I’m absolutely delighted to kick-off the series with Dr. Jon Whitty, who teaches project management at the University of Southern Queensland.
In an hour-long conversation, Jon shared his unique perspective on project management, seasoning his insights with anecdotes ranging from the Simpsons to medieval rituals and fairs.
Intrigued? Then read on…
KA: Good morning, Jon! It’s great to have you as the first guest on my sensemakers series. To get things going, please tell us a bit about yourself.
JW: Thanks for that – I’m always glad to be a guinea pig [laughs]
Actually, I see myself as being a little selfish because much of what I do is about explaining stuff to myself. Then I realise that if I write it down, other people might find it useful too. But largely it’s about me trying to solve problems and explain stuff to myself.
Specifically, one of the things I find myself doing is looking at topics like project or program management using an evolutionary approach, which is a Darwinian framework in which one looks at things through the lens of competition, adaptation and selection, and see how they play out in the real world.
KA: Your paper on the memetic paradigm of project management exemplifies this approach. Incidentally, that was the first work of yours that I read and it completely blew me away. Among other things, one of the things that struck me when I read it is that a project should be treated as a system – you can’t treat parts of it in isolation. (Editor’s note: see this article for a summary of Jon’s paper)
JW: Yeah, that’s very much in my way of thinking. One of the things about taking an evolutionary view is that you can’t “half swallow the pill” – you’ve got to swallow the whole thing. And when you look at the whole thing, what strikes you is that it is actually rather meaningless; meaning is something we impose on it.
This might sound somewhat radical so let me elaborate by drawing on the great philosopher Homer…I mean Homer Simpson, of course…
I think it’s in the episode in which he donates blood for Mr. Burns. Towards the end of the show Mr. Burns gives him a gift, and it’s this big carved stone head (something like an Easter Island statue). So you have this head is sitting in the Simpsons’ lounge, and they’re all trying to make sense out of it. Marge goes through all the possible morals that one can get out of the episode – may be it is this and may be it’s that and so on. So, there is much debate but no consensus. Finally, Homer interrupts and says, “Marge, there is no purpose to any of this…it’s just a bunch of stuff that happened.”
(Editor’s note: The Simpson episode is The Blood Feud)
That really goes to the heart of the evolutionary framework – which is, to see things as they actually happen, without any presumption of purpose. As soon as you start putting purpose in there, you start clouding your perception of what is going on. What you have to look at instead is the notion of selection. Some people criticize the evolutionary framework because they see it as randomness. Although there is an element of randomness to it, it is selection that is the key.
So you have this system, as you put it, and there are all these people caught up in it – project managers, teams, sponsors etc. –interacting with each other and also with various artefacts (Gantt charts, status reports, plans etc.). The point is, stakeholders and artefacts all have different purposes: artefacts aren’t there because they work, and neither are people there because they are committed to the objective. Purposes and meanings differ. The utility of the evolutionary framework is that it exposes the system for what it really is, without being clouded by the meanings that are imposed upon projects by standards and frameworks.
(Editor’s note: for example, a project manager may craft a status report in such a way as to reassure a sponsor (actual purpose) rather than reveal the real status of a project (espoused purpose). As another, a team member may be in a project because she wants to improve his skills (actual purpose), not because she’s interested in the objective of the project (espoused purpose)).
As another example, take the iron triangle – you know, the time, cost, quality triple constraint. It’s been around for a long time, so people say, “if it didn’t work, it wouldn’t still be around, would it?”
The answer to that is, “That depends on what you mean by, ‘it works’!”
In reality, the triple constraint is a good answer to a very specific question, which is: “what are the major variables or drivers of a project?” As an answer, you can even draw a really simple diagram to explain what it’s about. It survives because of its simplicity, rather than its correctness or utility.
KA: This challenges basic, taken-for-granted concepts in project management, and I think it is why your work resonates with practitioners. However, I’m curious about the kind of reaction you get from standards bodies and institutions when you talk about things such as these.
JW: Hate mail…no, not that [laughs]. Look, they have trouble inviting me to events. I’m not on their list of mainstream invitees. However, I still manage to get invited to PMI-run conferences because people I know often coordinate these events and invite me to them.
Going back to what you said– that some of what I said resonates with practitioners. I think it resonates because some people find it hard to figure out how something that they are reading in a textbook or learning in the classroom can be relevant in real projects.
KA: That’s true…it’s the issue of the practical utility of concepts. For example, what use is the iron triangle, apart from being a pat answer to a question? Many of the things found in texts are formulaic concepts that are trotted out in class or in training courses, but are not so useful in the day-to-day running of projects.
In my experience, the day-to-day work of a project manager is largely about reacting to stuff that happens on the ground. It’s about improvisation rather than planning. I see it all the time in real-life projects – all this stuff you do at the start, scoping planning etc. is useful, but when you are thrust into the nitty-gritty of a project, you have to make decisions on the fly, react to things that you hadn’t anticipated and so on. To me, that’s an equally real, and perhaps more fascinating part of project management…but nobody ever talks about it. No textbook does at any rate. Philosophers do delve into this kind of stuff, but definitely not project management academics or professionals!
JW: Well, this is where books like yours, The Heretic’s Guide to Best Practices, help. They help people look behind the façade – the false shells of ideas about things. You know, people really beat themselves up about this kind of stuff.
One of the things I do is I run postgrad workshops where I bring in high flier PMs from industry – the kind of people who build big hospitals, infrastructure etc. Many of them are from the construction industry, but not all. So these people come in and tell us their war stories, and often I notice that they say things like, “We got a quality control system in place” or “We have a change management system in place” and so on. Then they add, almost apologetically, “It’s not like it is in the books, but we are trying…” And I’m always thinking to myself, “Why do they feel like they have to apologize for that?”
What they do not understand is that the things described in the PMBOK and other guides are “stick man-like” idealisations. Someone probably looked at 20 different ways to do something, found a common theme and then made up a model. The problem is that the model is just a high-level abstraction; you won’t actually find it anywhere because it doesn’t exist. So all these poor guys are working towards something that doesn’t exist and probably doesn’t work!
KA: Yes, that is definitely the case. I like to use the map versus territory metaphor when talking about this with practicing PMs. Textbook knowledge of PM is a bit like the knowledge that a map conveys. When you’re working on a project, however, you’re actually in the territory. When I explain it to people in this way, they often go, “Yeah, that makes sense: so the PMBOK is actually a map.” Then I warn them, “It is, but beware for it may not be as accurate as you think, so you’ve got to be careful”
JW: Yeah, that’s the point: you’re helping people I suppose. Most project managers simply do not have the time to think about these kinds of things. What they end up doing instead, is joining some kind of PM institution – the APM or PMI or whatever. They then keep getting this information that is pushed out to them through these bodies, and the hidden theme running through all of it is that they (the PMs) somehow aren’t “doing it right.”
I wrote a paper on this a while ago, talking about the almost Puritan influence that these institutions have on their members. There is this Jeremiad type story telling that goes on in professional PM circles. The message is: you shouldn’t do this and you shouldn’t do that; and if you strive, one day you may be as good as us. This sort of talk doesn’t make people feel good about themselves at all.
I see this in another context, when people talk to me as an academic, they sometimes feel like they have to apologize for not doing things “by the book.” As if I’ve got this Golden Book that has all the “right answers”…
KA: I’d like to change tack here a bit, if I may. Over the last few years, PMI and other standards bodies have sort of embraced Agile methodologies and have attempted to bring them into their fold. What are your thoughts on this?
JW: Well, I like to think of it as domestication – they’ve domesticated Agile. Indeed, the PMI and other bodies have no choice; they have to embrace Agile. The Agile community is big and is more cooperative and will continue to adapt and change with the times. They frankly couldn’t care less about the PMI and what it thinks. The standards bodies can’t just stand by and do nothing, they have to grab on to this movement somehow, and that’s what they’ve done. And I say, watch out; as the Agile folks move up the PMI hierarchy, there could be further disruptions on the way.
KA: So, the institutes have to adapt too, in order to survive…
JW: Indeed, and they do it in many ways. Let me tell you about something else that is going on: the lead project management body in UK, the APM, is trying to get chartered status. If that happens, it would mean that a PM could work towards a Chartered Project Manager qualification. In my opinion that would be a dangerous development because it would, in effect, force people to go for the APM qualification. Any freedom for a practitioner to get any other certification would be lost.
KA: That’s true, but someone might counter that by saying, “We have Chartered Engineers and Chartered Accountants, so why not Chartered Project Managers?” I think I know the answer to that, but I’d like to hear your view on it [laughs]
JW: [laughs]…and I think my answer would be the same as yours. The engineering and accountancy “body of knowledge,” if one can call it that, is evidence-based. The same is true of medicine. In comparison, project management (and management in general) is stuck in the medieval era.
For instance, I could claim that a success factor for a project is this bag of lavender – you know, you sort twirl it around three times, lay it on the floor and jump over it. It’s almost at the level that people were at when they cooked up rituals to stave off the Black Death. If the project succeeds, I attribute success to the bag of lavender ritual, if it fails, well… I can always attribute the failure to something else.
KA: [laughs] I’ve got to use that bag of lavender for my next kickoff meeting…
JW: Seriously, this is where we are…all those things that are in various bodies of knowledge are like that. One person actually said to me, “Ah well, wait a minute Jon, the APM’s body of knowledge isn’t a body of knowledge at all – it is a glossary of terms.”
So I said, “Why on earth didn’t you call it that!”
Well, I suppose they couldn’t because you can’t well ask people to get a certification on a glossary of terms now, can you? For crying out loud, this is ridiculous isn’t it?? I guess my point is that these are all good reasons why the profession shouldn’t be chartered.
What we really need to do is start looking at how projects are managed across different domains instead of looking for a lowest common denominator. This is far more than research based on a survey of a small bunch of people, written up for publication in an academic journal.
Most academic articles are written in impenetrable academic language for a small bunch of people to read. And to be honest, most people don’t even read them. In most cases, if you read them carefully and take them apart, however, you realize that they are based on not very much at all.
KA: Yes, I’ve noticed…
JW: …and you know, it is actually worse than that. I started teaching a good number of years ago, and I started out as an electronics instructor. It’s a very practical domain where physics and maths come together in a physical device.
One of the things I used to teach was TV repair – in the days when you could actually repair TVs yourself. The thing about TV repair is that you can’t sit around and discuss whether a TV’s been repaired, it isn’t a matter of opinion; you simply switch it on and see if it works. You can see where I’m going with this…
You were talking about how the map’s an abstraction of the territory. The dangerous thing is that one can get caught up in abstractions that never make contact with reality. This happens in maths quite a bit: mathematicians invent new concepts – multidimensional spaces etc. – and spend their entire working lives in these abstractions. That may be OK for maths, but it’s not OK for management.
The problem is, many management academics are actually specialists in abstractions. Moreover, this is what they teach in their courses because it is all they know. So now you have all these senior managers who’ve been through an MBA; they have a wealth of abstract knowledge, but they can’t actually do anything. They have no practical skills at all. This is why there is a gap between strategy development and strategy implementation.
KA: Yeah, I’ve read some interesting work by William Starbuck on the gap between strategy formulation and implementation (Editor’s note: see this paper for example). So I think this issue is recognized in academia. The problem is that strategy is usually in terms of causal models: if we do this, then that will happen. The real world is complicated and isn’t straightforward to figure out what causes what. Instead, managers need to develop certain sensibilities – like being attuned to what’s actually happening in their organisations. To use a term I’ve used before, it is about developing a systemic view. But how do you teach that?
JW: I could actually think of some practical ways in which one could teach that. Every university ought to have a couple of corner shops or even blacksmithing shops, say. Students should be asked to run these. If you reckon you can run a multi-million dollar business then surely you can run a corner shop, right? We don’t do that because it costs and it’s difficult to do. But more important, you can’t sell an MBA based on corner shops, although I think students would learn a lot more from it.
As a result people walk out with MBAs they can’t use. And academia becomes more and more detached. We’ve made a commodity out of education, particularly in management because we can get away with it. You can’t get away with this kind of thing in engineering schools.
KA: I think you’re absolutely right. There’s this big con trick pulled by business schools over the last so many years about selling model-based learning.
I think a lot of influential management academics have lamented this over the last decade or so – Warren Bennis, for example – but nothing seems to have changed.
JW: Changing this would destroy the business model of all these schools, so nobody’s going to volunteer to be the first to do this. They’d be wiped out.
Let me give you an example. The PMI accredits universities. Effectively, this amounts to you paying them to advertise your courses in their literature. They’re not really accrediting you; all they check is whether you’re using their name and materials in your courses. Once they are satisfied that you are doing that, you pay the fee and you are accredited. Schools have to go along because if they don’t, their competitors will, and they’ll get all the students.
So we all end up playing this ridiculous education “arms” race. You can’t opt out even if you want to.
KA: Yes, you can’t opt out. However, the one thing I’ve realized is that the best way to challenge the system is from within…and you certainly do that through your writing.
JW: Yeah, and I’m sure you must’ve got some feedback on your work as well. I think your book would have resonated well with practitioners because it speaks to the kinds of things that people actually do. There is a sort of “self-help” aspect to it.
KA: It’s interesting you put it that way, because that’s exactly what a few people have said to me after reading it…although I should add that I don’t particularly like the term “self- help” [laughs]
Seriously, though, the feedback has been the most gratifying part of the whole thing. We really had no idea what kind of reception we’d get so it’s been absolutely fantastic to hear from some folks that the book has made a difference to the way they look at things.
JW: I don’t know if there’s anything more in the pipeline, but I would suggest that a continuation in that sort of light would be useful. That is what I mean by self-help – in that it is helpful. Even if it is not helpful in actual practice, it might be helpful in the way they think and feel about their practice.
KA: Yes, well it’s been a couple of years now. Over the last year or so Paul and I have been talking and thinking about what comes next. The ideas and material are there, and there’s at least a couple of directions in which we can take them. Paul has developed a bunch of practical techniques through his consultancy work, and I’ve gained some insights through experience and my somewhat random reading on topics from management to philosophy. It’s really a question of finding the time to put it all together in a book that people will find interesting and useful.
JW: That reminds me of what you said before: that many of these things aren’t dealt with in management texts, but philosophers do have something useful to say about them. That is why I spend some of my time looking back to those works, because they are incredibly insightful about human practice. I also get some of my postgrads to read these works, so as to challenge the way they look at things.
There’s a book chapter I wrote entitled, “Thinking in slow motion about project management.” It deals with thinking about thinking about project management. That is, to question the way we actually think about the discipline. It is about questioning the the [tacit] assumptions we make when we think about projects.
Here’s an example: one of my students wrote to me the other day saying that he’d sketched out a couple of papers on thinking critically (see note below) about project management – the kind of work done by Damian Hodgson and others. One of the major themes underlying critical work in project management is project failure – you know, why projects fail etc. If one “thinks about this thinking” one realizes that there is a tacit assumption here that failure is a bad thing. However, from an evolutionary point of view, failure occurs more often than success does!
(Editor’s note: Jon uses the word critical in a technical sense here. As per my understanding, critical studies are aimed at critiquing a practice (project management, in this case) with the aim of changing it in such a way that it benefits the largest number of people possible. See this paper review for an example of a critical study in project management.)
KA: Yes, that’s true. However, one can also see the rationale for focusing on failure. There is an economic driver here; one can’t go to a project sponsor and say, “this project failed because of evolution.” I can’t see that going down too well [laughs]
JW: True, but then again it’s about selecting the stories we tell. When you look at the personal development literature, it’s not put together to describe success stories, but to describe strategies that people have used to overcome failure. So, if we were to try and put together a set of stories about how failures or potential failures were overcome by evidence based means – that is, not by using rituals such as bags of lavender [laughs] – then people would be more comfortable about talking about failure.
Indeed, if you look at the great stories of management, they are all about how adversity was overcome or how innovations arose from failures. People say, “Yes we failed, but we learnt something from it. We now know how to do it better.” And that’s a lesson that won’t be forgotten.
KA: That’s absolutely right, and it brings to mind a related point. The fortunate thing for those who work in information technology is that it is relatively easy to fail quickly and learn something from it. Indeed that’s what Agile is largely about – flushing out the difficulties early in the game. And even if one does not use the full machinery of an Agile methodology, it is easy enough to work in an incremental way: you know, do a quick prototype and run it past the business to flush out hidden requirements.
JW: Yes, but it’s not just in IT; one can do it in customer service or even construction – things like role-playing, building a façade, these kinds of things are in fact agile approaches relevant to those domains. One doesn’t have to wait for feedback from real customers or commission an architect to do these kinds of things. So the idea of mistaking-making and overcoming mistakes is actually a process of building new knowledge about how things work in that domain. These are the sorts of stories we should be sharing more and telling more.
KA: Yes, you’re right…and one could even get people to think about what could go wrong by asking questions like, “what could come back to bite us if we did this?” The advantage is that this can be done by simply thinking through scenarios with a group of people, prior to problems actually occurring.
JW: Yes, but the trouble is that it is difficult capture any intellectual property around this kind of thinking. If you want to build a critical mass around these sorts of ideas, you have to be able write them down and market them. The problem is, they change from domain to domain and they are difficult to write down into something like a BOK. The PMI, on the other hand, have a well-defined product which they can build branding around. . They have the stories to tell as to why you should become a member- all the great benefits you would enjoy and so forth.
It’s a bit like the atheists versus the church: one side has the full machinery of religion the other has nothing. You know, I’m an atheist, but I could go into Notre Dame cathedral on a late afternoon when the sun is shining through that massive window, and lighting up all those dust particles in that spectacular way, with the guy playing the organ the background. I take all that in and think to myself, “You know, there might be something in this.”
KA: [laughs] Yes, that’s an excellent point.
JW: Yeah, the whole structure around you can make you feel as though, “Hey, I can for a moment entertain the thought of being a part of this.” Now, when you’re at a PMI meeting, with all those people in suits and ties and those badges with their names and titles on, you could well think that there is something in it. But when I’m in a supermarket, pushing a trolley around, I simply can’t entertain such a thought.
KA: You know, I think it is more of a security blanket than anything else. One thinks that by joining a professional organization and getting a certification, one somehow becomes more professional. There is this myth (or idea) floating around that certifications are good because employers like them. I don’t know how true that is, I haven’t really tested that; but right now, in this tight job market, people will do whatever they think will give them an edge.
JW: Yes, and the evolutionary framework would see this as a device to get selected – to keep your job (or get a new one)…and also to feel good about yourself.
There is this wonderful medieval fete that takes place in Queensland every year. It’s an event that takes place in this huge field. People come from all over; they descend for a week and set up this medieval camp. It’s like a scene out of a Harry Potter film or a camp in King Alfred’s time – and with all those tents, smoky ambience from fires, people walking around in armour and costumes etc, one can really get immersed in the scene and feel that one is actually there.
Now, just towards the end of the camp there’s a set of stalls – trading stalls – there’s the blacksmith, for example and others. Then there is a stall that sells replica medieval weapons and costumes. When I was there, I was thinking to myself that if I were really in a medieval setting, I would actually have to buy a weapon to protect myself. And then I realized that this is precisely what the exhibition hall in the PMI Global Congress is like, right?
JW: Seriously, that’s exactly what is going on. On the one side you have people selling certifications, university degrees or books like “55 Ways to get Certified in 35 Seconds”, and on the other you have practitioners who feel they must choose a certification, university or a book. All the vendors and universities claim that their “weapons” are better than the other ones on the market.
However, these vendors will never show you how to actually use their “weapons.” If they were to show you how to use them, you’d probably find out that they don’t work… and that won’t do at all, would it? Nevertheless, you are made to feel that you must have these “weapons” because you know you will be up against others who have them.
KA: [laughs] That’s brilliant!
JW: When I go to these chapter and branch meetings, I’m always amazed at how oblivious some project managers are about what’s going on here (and I don’t mean this in an unkind way at all). They see themselves as active participants in this group that they have joined, whereas really what they are is simply a market for the standards and the institutions. They are somebody to sell to.
KA: Yes, they’re somebody to sell to, and somebody to propagate the message.
JW: You know what I would really like to do? Well, one of the ways of undermining what the standards bodies are doing is through humour. One way to do this is through cartooning scenarios that highlight some of the ludicrous things that happen in the project management workplace. Dilbert is an excellent example. I’d really like to explore this way of getting people to look at project management through an evolutionary lens because I think it would be much more effective and useful than writing for an academic audience.
KA: Yes, a “Dilbert for PM.” I like that!
JW: I think this would help engage project managers. Actually, in some ways it is a bit like what you’re doing with your blog.
KA: Yes, but humour and satire are so much better; there’s no better way to undermine over-seriousness and pompousness.
JW: Yeah, there’s a long history to that kind of stuff – Voltaire for instance. But you’ve written a bit along those lines, haven’t you?
KA: Yes, I’ve written a few satirical pieces (Editor’s note: see this piece, for example). Unfortunately, that kind of writing doesn’t come naturally to me. It is a surprise even for me when I come up with something like that.
JW: One of the things I’m going to try and do is to push this “bag of lavender” metaphor further; I haven’t exercised it fully as yet. I think I’ll do a short blog post on it soon. (Editor’s note: This conversation was recorded a few days before Jon published his brilliant post on medieval management balms. Don’t miss it!)
KA: Ah, that idea’s got great potential. I look forward to reading it, Jon.
Well, I think I’d better let you go back to your work now…we’ve been talking for over an hour. Thanks so much Jon, it’s been wonderful talking to you.
JW: It was good, and I hope there’s something useful in there.
KA: There’s plenty, all I have to do now is transcribe it! I look forward to chatting with you again sometime in the near future. Thanks again.
JW: No worries; always good to chat.