Eight to Late

Sensemaking and Analytics for Organizations

Archive for the ‘Project Management’ Category

The danger within: internally-generated risks in projects

with 2 comments

Introduction

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:

  1. How common are these risks?
  2. How significant are they?
  3. How well are they managed?
  4. 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:

  1. The key difficulties that project managers encountered on the projects.
  2. 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:

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.

Discussion

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.

Conclusion

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.

Written by K

December 10, 2014 at 7:23 pm

Scapegoats and systems: contrasting approaches to managing human error in organisations

with 5 comments

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:

  1. 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…
  2. 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:

  1. Accept that errors will occur despite standardised procedures, and train their staff to deal with and learn from them.
  2. Practice responses to known error scenarios and try to imagine new ones on a regular basis.
  3. Delegate responsibility and authority, especially in crisis situations.
  4. 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.

Acknowledgement:

Figure 1 was taken from the Patient Safety Education website of Duke University Hospital.

Further reading:

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:

  1. Stephen Duffield and Jon Whitty use the Swiss Cheese model as a basis for their model of Systemic Lessons Learned and Knowledge Captured (SLLKC model) in projects.
  2. In this post, Paul Culmsee extends the SLLKC model to incorporate aspects relating to teams and collaboration.

Written by K

July 29, 2014 at 8:43 pm

Making sense of project management – a conversation with Jon Whitty

with 6 comments

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 her 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?

KA: [laughs]

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.

Written by K

May 19, 2014 at 8:42 pm

Sherlock Holmes and the case of the failed projects

with 5 comments

….as narrated by Dr. John H. Watson M. D.

Foreword

Of all the problems which had been submitted to my friend, Mr. Sherlock Holmes, for consideration during the years of our friendship, there has been one that stands out for the sheer simplicity of its resolution.  I have (until now) been loath to disclose details of the case as I felt the resolution to be so trivial as to not merit mention.

So why bring it up after all these years?

Truth be told, I am increasingly of the mind that Holmes’ diagnosis in the Case of the Failed Projects (as I have chosen to call this narrative), though absolutely correct, has been widely ignored. Indeed, the writings of Lord Standish and others from the business press have convinced me that the real lesson from his diagnosis is yet to be learnt by those who really matter:  i.e. executives and managers.

As Holmes might have said, this is symptomatic of a larger malaise: that of a widespread ignorance of elementary logic and causality.

A final word before I get into the story. As most readers know, my friend is better known for his work on criminal cases. The present case, though far more mundane in its details, is in my opinion perhaps his most important because of its remarkable implications. The story has, I believe, been told at least once before but, like all such narratives, its effect is much less striking when set forth en bloc in a single half-column of print than when the facts slowly emerge before one’s own eyes.

So, without further ado, then, here is the tale…

The narrative

Holmes was going through a lean patch that summer, and it seemed that the only cases that came his way had to do with pilfered pets or suspicious spouses.   Such work, if one can call it that, held little allure for him.

He was fed up to the point that he was contemplating a foray into management consulting.  Indeed, he was certain he could do as well, if not better than the likes of Baron McKinsey and Lord Gartner (who seemed to be doing well enough). Moreover his success with the case of the terminated PMO  had given him some credibility in management circles.   As it turned out, it was that very case that led Mr. Bryant (not his real name) to invite us to his office that April morning.

As you may have surmised, Holmes accepted the invitation with alacrity.

The basic facts of the issue, as related by Bryant, were simple enough: his organization, which I shall call Big Enterprise, was suffering from an unduly high rate of project failure. I do not recall the exact number but offhand, it was around 70%.

Yes, that’s right: 7 out of every 10 projects that Big Enterprise undertook were over-budget, late or did not fulfil business expectations!

Shocking, you say… yet entirely consistent with the figures presented by Lord Standish and others.

Upon hearing the facts and figures, Holmes asked the obvious question about what Big Enterprise had done to figure out why the failure rate was so high.

“I was coming to that,” said Bryant, “typically after every project we hold a post-mortem.  The PMO  (which, as you know,I manage)  requires this. As a result, we have a pretty comprehensive record of ‘things that went well’ on our projects and things that didn’t.  We analysed the data from failed projects and found that there were three main reasons for failure: lack of adequate user input, incomplete or changing user requirements and inadequate executive support.”

“….but these aren’t the root cause,” said Holmes.

“You’re right, they aren’t” said Bryant, somewhat surprised at Holmes’ interjection. “Indeed, we did an exhaustive analysis of each of the projects and even interviewed some of the key team members. We concluded that the root cause of the failures was inadequate governance on the PMO’s  part,” said Bryant.

“I don’t understand.  Hadn’t you established governance processes prior to the problem? That is after all the raison d’etre of a PMO…”

“Yes we had, but our diagnosis implied those processes weren’t working. They needed to be tightened up.”

“I see,” said Holmes shortly. “I’ll return to that in due course. Please do go on and tell me what you did to address the issue of poor…or inadequate governance, as you put it.”

“Yes, so we put in place processes to address these problems. Specifically, we took the following actions. For the lack of user input, we recommended getting a sign-off from business managers as to how much time their people would commit to the project. For the second issue – incomplete or changing requirements – we recommended that in the short term, more attention be paid to initial requirement gathering, and that this be supported by a stricter change management regime. In the longer term, we recommended that the organization look into the possibility of implementing Agile approaches. For the third point, lack of executive support, we suggested that the problem be presented to the management board and CEO, requesting that they reinforce the importance of supporting project work to senior and middle management.”

Done with his explanation, he looked at the two of us to check if we needed any clarification. “Does this make sense?” he enquired, after a brief pause.

Holmes shook his head, “No Mr. Bryant the actions don’t make sense at all.  When faced with problems, the kneejerk reaction is to resort to more control. I submit that your focus on control misled you.”

“Misled? What do you mean?”

“Well, it didn’t work did it? Projects in Big Enterprise continue to fail, which is why we are having this meeting today.  The reason your prescription did not work is that you misdiagnosed the issue. The problem is not governance, but something deeper.”

Bryant wore a thoughtful expression as he attempted to digest this. “I do not understand, Mr. Holmes,” he said after a brief pause. “Why don’t you just tell me what the problem is and how can I fix it? Management is breathing down my neck and I have to do something about it soon.”

“To be honest, the diagnosis is obvious, and I am rather surprised you missed it,” said Holmes, “I shall give you a hint: it is bigger, much bigger, than the PMO and its governance processes.”

“I’m lost, Mr. Holmes.  I have thought about it long enough but have not been able to come up with anything. You will have to tell me,” said Bryant with a tone that conveyed both irritation and desperation.

“It is elementary, Mr. Bryant, when one has eliminated the other causes, whatever remains, however improbable, must be the truth. Your prior actions have all but established that the problem is not the PMO, but something bigger. So let me ask the simple question: what is the PMO a part of?”

“That’s obvious,” said Bryant, “it’s the organization, of course.”

“Exactly, Mr. Bryant: the problem lies in Big Enterprise’s organisational structures, rules and norms. It’s the entire system that’s the problem, not the PMO per se.”

Bryant looked at him dubiously.  “I do not understand how  the three points I made earlier – inadequate user involvement, changing requirements and lack executive sponsorship – are due to Big Enterprise’s structures, rules and norms. “

“It’s obvious,” said Holmes, as he proceeded to elaborate how lack of input was a consequence of users having to juggle their involvement in projects with their regular responsibilities. Changes in scope and incomplete requirements were but a manifestation of  the fact that users’ regular work pressures permitted only limited opportunities for interaction between users and the project team – and that it was impossible to gather all requirements…or build trust through infrequent interactions between the two parties. And as for lack of executive sponsorship – that was simply a reflection of the fact that the executives could not stay focused on a small number of tasks because they had a number of things that competed for their attention…and these often changed from day to day. This resulted in a reactive management style rather than a proactive or interactive one.  Each of these issues was an organizational problem that was well beyond the PMO.

“I see,” said Bryant, somewhat overwhelmed as he realized the magnitude of the problem, “…but this is so much bigger than me. How do I even begin to address it?”

“Well, you are the Head of the PMO, aren’t you?  It behooves you to explain this to your management.”

“I can’t do that!” exclaimed Bryant. “I could lose my job for stating these sorts of things, Mr. Holmes – however true they may be. Moreover, I would need incontrovertible evidence…facts demonstrating exactly how each failure was a consequence of organizational structures and norms, and was therefore out of the PMO’s control.”

Holmes chuckled sardonically. “I don’t think facts or ‘incontrovertible proof’ will help you Mr. Bryant. Whatever you say would be refuted using specious arguments…or simply laughed off.  In the end, I don’t know what to tell you except that it is a matter for your conscience;  you must do as you see fit.”

We left it at that; there wasn’t much else to say. I felt sorry for Bryant. He had come to Holmes for a solution, only to find that solving the problem might involve unacceptable sacrifices.

We bid him farewell, leaving him to ponder his difficult choices.

—-

Afterword

Shortly after our meeting with him, I heard that Bryant had left Big Enterprise. I don’t know what prompted his departure, but I can’t help but wonder if our conversation and his subsequent actions had something to do with it.

…and I think it is pretty clear why Lord Standish and others of his ilk still bemoan the unduly high rate of project failure.

 Notes

  1. Sherlock Holmes aficionados may have noted that the foreword to this story bears some resemblance to the first paragraph of the Conan Doyle classic, The Adventure of the Engineer’s Thumb.
  2. See my post entitled Symptoms not causes, a systems perspective on project failure for a more detailed version of the argument outlined in this story.
  3. For insight into the vexed question of governance, check out this post by Paul Culmsee and the book I co-authored with him.

Written by K

April 15, 2014 at 8:28 pm

Rituals in information system design and development

leave a comment »

Introduction

Information system development is generally viewed as a rational process involving steps such as planning, requirements gathering, design etc. However, since it often involves many people, it is only natural that the process will have social and political dimensions as well.

The rational elements of the development process focus on matters such as analysis, coding and adherence to guidelines etc. On the other hand, the socio-political aspects are about things such as differences of opinion, conflict, organisational turf wars etc.  The interesting thing, however, is that elements that appear to be rational are sometimes subverted to achieve political ends. Shorn of their original intent, they become rituals that are performed for symbolic reasons rather than rational ones. In this paper I discuss rituals in system development, drawing on a paper by Daniel Robey and Lynne Markus entitled, Rituals in Information System Design .

Background

According to the authors, labelling the process of system design and development as rational implies that the  process can be set out and explained in a logical way. Moreover,  it also implies that the system being designed has clear goals that can be defined upfront, and that the implemented system will be used in the manner intended by the designers. On the other hand, a political perspective would emphasise the differences between various stakeholder groups (e.g. users, sponsors and developers) and how each group uses the process in ways that benefit them, sometimes to the detriment of others.

In the paper the authors discuss how  the following two elements of the system development process are consistent with both views summarised above.

  1. System development lifecycle.
  2. Techniques for user involvement

I’ll look at each of these in turn in the next two sections, emphasising their rational features.

Development lifecycle

The basic steps of a system development lifecycle, common to all methodologies, are:

  1. Inception
  2. Requirements gathering  / analysis
  3. Specification
  4. Design
  5. Programming
  6. Testing
  7. Training
  8. Rollout

Waterfall methodologies run through each of the above once whereas Iterative/Incremental methods loop through (a subset of) them as many times as needed.

It is easy to see that the lifecycle has a rational basis – specification depends on requirements and can therefore be done only after requirements have been gathered and analysis;  programming can only proceed after design in completed, and so on It all sounds very logical and rational. Moreover, for most mid-size or large teams, each of the above activities is carried out by different individuals – business analysts, architects/designers, programmers, testers, trainers and operations staff.  So the  advantage of following a formal development cycle is that it makes it easier to plan and coordinate large development efforts, at least in principle.

Techniques for user involvement

It is a truism that the success of a system depends critically on the level of user interest and engagement it generates. User involvement in different phases of system development  is therefore seen as a key to generating and maintaining user engagement.  Some of the common techniques to solicit user involvement include:

  1. Requirements analysis: Direct interaction with users is necessary in order to get a good understanding of their expectations from the system.  Another benefit is that it gives the project team an early opportunity to gain user engagement.
  2. Steering committees: Typically such committees are composed of key stakeholders from each group that  is affected by the system. Although some question the utility of steering committees, it is true that committees that consist of high ranking executives can help in driving user engagement.
  3. Prototyping:  This involves creating a working model that serves to demonstrate a subset of the full functionality of the system.  The great advantage of this method of user involvement that it gives users an opportunity to provide feedback early in the development lifecycle.

Again, it is easy to see that the above techniques have a rational basis: the logic being  that  involving  users early in the development process  helps them become familiar with the system, thus improving the chances that they will be willing, even enthusiastic adopters of the system when it is rolled out.

The political players

Politics is inevitable in any social system that has  stakeholder groups with differing interests.  In the case of system development, two important stakeholder groups are users and developers.  Among other things, the two groups differ in:

  1. Cognitive style: developers tend to be analytical/logical types while users come from a broad spectrum of cognitive types. Yes, this is a generalisation, but it is largely true.
  2. Position in organisation: in a corporate environment, business users generally outrank technical staff.
  3. Affiliations: users and developers belong to different organisational units and therefore have differing loyalties.
  4. Incentives: Typically member of the two groups have different  goals. The developers may be measured by the success of the rollout whereas users may be judged by their proficiency on the new system and the resulting gains in productivity. 

These lead to differences in ways the two groups perceive processes or events. For example, a developer may see a specification as a blueprint for design  whereas a user might see it as a bureaucratic document that locks them into choices they are ill equipped to make. Such differences in perceptions make it far from obvious that the different parties can converge on a common worldview that is assumed by the rational perspective. Indeed, in such situations it isn’t clear at all as to what constitutes “common interest.” Indeed, it is such differences that lead to the ritualisation of aspects of the systems development process.

Ritualisation of rational processes

We now look at how the differences in perspectives can lead to a situation where processes that are intended to be rational end up becoming rituals.

Let’s begin with an example that occurs at the inception phase of system development project: the formulation of a business case. The stated intent of a business case is to make a rational argument as to why a particular system should be built. Ideally it should be created jointly by the business and technology departments.  In practice, however, it frequently happens that one of the two parties  is given primary responsibility for it.  As the two parties are not equally represented, the business case ends up becoming a political document:  instead of presenting a balanced case, it presents a distorted view that focuses on one party’s needs. When this happens, the business case becomes symbol rather than substance – in other words, a ritual.

Another example is the handover process between developers and users (or operations, for that matter). The process is intended to ensure that the system does indeed function as promised in the scope document.  Sometimes though, both parties attempt to safeguard their own interests:  developers may pressure users to sign off whereas users may delay signing-off because they want to check the system ever more thoroughly.  In such situations the handover process  serves as a forum for both parties to argue their positions rather than as a means to move  the project  to a close.  Once again, the actual process is shorn of its original intent and meaning, and is thus ritualised.

Even steering committees can end up being ritualised.  For example, when a committee consists of senior executives from different divisions, it can happen that each member will attempt to safeguard the interests of his or her fief.  Committee meetings then become forums to bicker rather than to provide direction to the project.  In other words, they become symbolic events that achieve little of substance.

Discussion

The main conclusion from the above argument is that information system design and implementation is both a rational and political process.  As a consequence, many of the processes associated with it turn out to be more like rituals in that they symbolise rationality but are not actually rational at all.

That said, it should be noted that rituals have an important function:  they serve to give the whole process of systems development a veneer of rationality whilst allowing for the  political manouevering that is inevitable in large projects.  As the authors put it:

Rituals in systems development function to maintain the appearance of rationality in systems development and in organisational decision making. Regardless of whether it actually produces rational outcomes or not, systems development must symbolize rationality and signify that the actions taken are not arbitrary but rather acceptable within the organisation’s ideology. As such, rituals help provide meaning to the actions taken within an organisation

And I feel compelled to add:  even if the actions taken are completely irrational and arbitrary…

Summary…and a speculation

In my experience, the central message of the paper rings true:  systems development and design, like many other organisational processes and procedures, are often hijacked by different parties to suit their own ends.  In such situations, processes are reduced to rituals that maintain a facade of rationality whilst providing cover for politicking and other not-so-rational actions.

Finally, it is interesting to note that the problem of ritualisation is a rather general one: many allegedly rational processes in organisations are more symbol than substance.  Examples of other processes that are prone to ritualisation include performance management, project management and planning. This hints at a deeper issue, one that I think has its origins in modern management’s penchant for overly prescriptive, formulaic approaches to managing organisations and initiatives. That, however, remains a speculation and a topic for another time…

Written by K

February 25, 2014 at 9:08 pm

On the inherent ambiguities of managing projects

with 9 comments

Much of mainstream project management is technique-based – i.e.  it is based on  processes that are aimed at achieving well-defined ends. Indeed, the best-known guide in the PM world, the PMBOK, is structured as a collection of processes and associated  “tools and techniques” that are categorised into various “knowledge areas.”

Yet, as experienced project managers know, there is more to project management than processes and techniques: success often depends on a project manager’s ability to figure out what to do in unique situations.  Dealing with such situations is more an art rather than science. This process (if one can call it that) is difficult to formalize and even harder to teach. As Donald  Schon wrote in a paper on the crisis of professional knowledge :

…the artistic processes by which practitioners sometimes make sense of unique cases, and the art they sometimes bring to everyday practice, do not meet the prevailing criteria of rigorous practice. Often, when a competent practitioner recognizes in a maze of symptoms the pattern of a disease, constructs a basis for coherent design in the peculiarities of a building site, or discerns an understandable structure in a jumble of materials, he does something for which he cannot give a complete or even a reasonably accurate description. Practitioners make judgments of quality for which they cannot state adequate criteria, display skills for which they cannot describe procedures or rules.

Unfortunately this kind of ambiguity is given virtually no consideration in standard courses on project management. Instead, like most technically-oriented professions such as engineering,  project management treats problems as being well-defined and amenable to standard techniques and solutions. Yet, as Schon tells us:

…the most urgent and intractable issues of professional practice are those of problem-finding. “Our interest”, as one participant put it, “is not only how to pour concrete for the highway, but what highway to build? When it comes to designing a ship, the question we have to ask is, which ship makes sense in terms of the problems of transportation?

Indeed, the difficulty in messy project management scenarios often lies in figuring out what to do  rather than how to do it.  Consider the following situations:

  1. You have to make an important project-related decision, but don’t have enough information to make it.
  2. Your team is overworked and your manager has already turned down a request for more people.
  3. A key consultant on your project has resigned.

Each of the above is a not-uncommon scenario in the world of projects. The problem in each of these cases lies in  figuring out what to  do given  the unique context of the project. Mainstream project management offers little advice on how to deal with such situations, but their ubiquity suggests that they are worthy of attention.

In reality, most project managers deal with such situations using a mix of common sense, experience and instinct, together with a deep appreciation of the specifics of the environment (i.e. the context).  Often times their actions may be in complete contradiction to textbook techniques.  For example, in the first case described above, the rational thing to do is to gather more data before making a decision. However, when faced with such a situation,  a project manager might make a snap decision based on his or her knowledge of the politics of the situation.  Often times  the project manager will not be able to adequately explain the rationale for the decision beyond knowing that “it felt like the right thing to do.” It is more  an improvisation than a plan.

Schon used the term reflection-in-action to describe how practitioners deal with such situations, and used the following example to illustrate how it works in practice:

Recently, for example, I built a wooden gate. The gate was made of wooden pickets and strapping. I had made a drawing of it, and figured out the dimensions I wanted, but I had not reckoned with the problem of keeping the structure square. I noticed, as I began to nail the strapping to the pickets that the whole thing wobbled. I knew that when I nailed in a diagonal piece, the structure would become rigid. But how would I be sure that, at that moment, the structure would be square? I stopped to think. There came to mind a vague memory about diagonals-that in a square, the diagonals are equal. I took a yard stick, intending to measure the diagonals, but I found it difficult to make these measurements without disturbing the structure. It occurred to me to use a piece of string. Then it became apparent that I needed precise locations from which to measure the diagonal from corner to corner. After several frustrating trials, I decided to locate the center point at each of the corners (by crossing diagonals at each corner), hammered in a nail at each of the four center points, and used the nails as anchors for the measurement string. It took several moments to figure out how to adjust the structure so as to correct the errors I found by measuring, and when I had the diagonal equal, I nailed in the piece of strapping that made the structure rigid…

Such encounters with improvisation are often followed by a retrospective analysis of why the actions taken worked (or didn’t). Schoen called this latter process reflection-on-action.  I think it isn’t a stretch to say that project managers hone their craft through reflection in and on ambiguous situations. This knowledge cannot be easily codified into techniques or practices but is worthy of study in its own right. To this end, Schon advocated an epistemology of (artistic) practice – a study of what such knowledge is and how it is acquired. In his words:

…the study of professional artistry is of critical importance. We should be turning the puzzle of professional knowledge on its head, not seeking only to build up a science applicable to practice but also to reflect on the reflection-in-action already embedded in competent practice. We should be exploring, for example, how the on-the-spot experimentation carried out by practicing architects, physicians, engineers and managers is like, and unlike, the controlled experimentation of laboratory scientists. We should be analyzing the ways in which skilled practitioners build up repertoires of exemplars, images and strategies of description in terms of which they learn to see novel, one-of-a-kind phenomena. We should be attentive to differences in the framing of problematic situations and to the rare episodes of frame-reflective discourse in which practitioners sometimes coordinate and transform their conflicting ways of making sense of confusing predicaments. We should investigate the conventions and notations through which practitioners create virtual worlds-as diverse as sketch-pads, simulations, role-plays and rehearsals-in which they are able to slow down the pace of action, go back and try again, and reduce the cost and risk of experimentation. In such explorations as these, grounded in collaborative reflection on everyday artistry, we will be pursuing the description of a new epistemology of practice.

It isn’t hard to see that similar considerations hold for project management and related disciplines.

In closing, project management as laid out in books and BOKs does not equip a project manager to deal with ambiguity.  As a start towards redressing this, formal frameworks need to acknowledge the limitations of the techniques and procedures they espouse.  Although there is no simple, one-size-fits-all way to deal with ambiguity in projects,  lumping it into a bucket called “risk” (or worse, pretending it does not exist)  is not the answer.

Written by K

January 30, 2014 at 9:07 pm

Organisational surprise and its relevance to project management

with 4 comments

Introduction

As humans, we tend to believe that events and processes will unfold in the way we expect them to.  Unfortunately things rarely go according to our expectations and we end up being, well… surprised! But it isn’t just individuals, entire organisations can be caught unawares by events. In this post I draw on a paper entitled, Clues, Cues and Complexity: Unpacking the Concept of Organisational Surprise, to elaborate on the different ways in which surprises can crop up in organisational settings and in particular, in projects.  My focus is on the latter because the temporary and one-off nature of projects seems to render them particularly prone to surprises.

Organizational surprise

The authors define organizational surprise as, “any event that happens unexpectedly or any expected event that takes an unexpected shape.”  One does not have to look far to see examples of organizational surprises. It is almost certain that any experienced project manager would have encountered a number of surprises in the course of his or her professional work. These could be unforeseen events (such as a project sponsor leaving for greener pastures) or unexpected twists and turns in what ought to have been a straightforward process (such as a software upgrade turning out to be more complicated than expected).

The ubiquity of organizational surprises begs the question as to why we are still “surprised by surprises.” The short answer is that this happens because we tend to overestimate our ability to control the future.  The authors suggest that we would be better served by regarding surprise as an inherent property of all open systems  (which includes entities such as organisations and projects). After living through the consequences of many over-optimistic managerial actions (both, my own and those of others), I would have to agree.

Classifying surprise – a typology of surprises

Nothing I have said so far would be surprising to readers: indeed, project management is largely about managing uncertainty…and all project managers know that. What might be new, however, is a classification of surprises proposed by the authors of the paper. I have hinted at the classification in the previous section where I gave one example each of a surprising event and a surprising process. It is now time to generalize this to a typology of surprises.

The authors classify surprises along two dimensions:

  • Issue – An issue can occur in one of two ways:
    • When something unusual happens.
    • When something that usually happens does not happen.

    It is important to note that although the term issue has negative connotations in project management parlance, it is used here in a neutral sense – i.e. issues can be either positive or negative.

  • Process – a process is a chain of related events that unfolds in an unusual manner. For example, when an ATM cash withdrawal fails because the machine does not have enough money left to process the withdrawal.

From the perspective of surprise, issues and processes can be either expected or unexpected. This gives us the four categories illustrated in Fig 1.

Figure 1: A typology of surprises

Figure 1: A typology of surprises

Let’s take a tour of the four categories

  1. Expected issue and process: This is the zone of predictability where one-off events tend to go as foreseen.  An example of an expected issue that was successfully dealt with through planning was the Y2K problem. Another example is provided by (successful) risk management activities that are triggered when a foreseen risk eventuates.
  2. Unexpected issue, expected process:  This is where a surprising issue occurs, but the consequences follow are expected. An example this would be a chance occurrence (say, a project team member on a troubled project stumbles on a novel technique that saves development time), and this leads to the project being completed within time and budget (expected process following the event).
  3. Expected issue, unexpected process:  This occurs when an expected event evolves in an unexpected way – i.e. leads to a surprising process. A common example of this in a project environment is when a  front-end project  decision unfolds in unexpected ways.   Another common example is an organizational change that has unintended consequences.
  4. Unexpected issue, unexpected process: This is a situation where both the event and the processes around it are counter to  conventional wisdom. In this case, those involved need to understand, or make sense of the situation and hence the term sensemaking crisis. An example of this is when project managers fail to anticipate factors that turn out to have a major influence on the way their projects evolve.  One could argue that many high profile project failures were the result of such crises.  The Denver Baggage Handling System and the Merck Vioxx affair are good examples. In both cases, the projects failed because those responsible failed to react to certain events that changed the trajectory of the projects irrevocably.

Let’s now take a brief look at the usefulness of this classification.

Coping with surprise

Managers expend a great deal of effort in attempting to predict surprises and hence corral them into the zone of predictability (Reminder: this is the bottom left quadrant in Figure 1).  As mentioned earlier, this is difficult because organisations are open systems, and novelty is an inherent property of such systems. The main implication of this is that surprises in quadrants other than the zone of predictability cannot be foreseen.  So, instead of worrying about predicting surprises, project and program managers would do better by focusing their efforts on creating an environment that enables team members to cope with nasty surprises and take advantage of good ones.

What might such an environment look like?

This question is best approached via a related question: what are the qualities displayed by project teams that are able to cope with surprises?

Here are some essential ones that are mentioned in the paper:

  1. Vigilance / problem sensing– a deep awareness of the project environment, with the ability to sense any changes in it.
  2. Resilience – the capacity to adjust to changes in the internal and external environment.
  3. Ability to improvise– the ability to respond to the unexpected by devising appropriate courses of action under pressure

The striking thing about these qualities is that they are impossible to create or engender by management fiat: teams will not improvise unless they feel empowered to, nor will they be resilient or vigilant unless they are intrinsically motivated to be so.These characteristics are emergent in the sense that they will be displayed spontaneously by teams that are in a frame of mind that comes out of being in  the right environment.

The primary task of a project manager, or any manager for that matter, is to create such a  holding environment that provides psychological safety to the team and encourages rational (or open) dialogue  between all project stakeholders (yes, including project sponsors). I won’t elaborate on these terms here  since they are dealt with at length in the articles that I have provided links to in the previous sentence.

Different types of surprise require different approaches

Having the right environment is the key to dealing with all four kinds of surprises. However, even within such an environment, it is important to note that different types of surprises have to be tackled in different ways. In particular:

  1. Predictable surprises are best tackled through traditional management approaches (as discussed in PMBOK, for example). In view of the prevalence of such approaches, I should perhaps emphasise again that they work only for a small subset of all possible surprises (only those that lie in the first quadrant)
  2. Surprising events and surprising processes are best dealt with by the people who are at the coalface of the problem since they are intimately familiar with the context and history of the problem.
  3. Sensemaking crises are best handled by collaborative problem solving approaches such as Dialogue Mapping.

The above yet again underscores the importance of the creating the right environment, for although predictable surprises can be tackled through traditional approaches to project management, those that lie in the other three quadrants cannot.

Conclusion

A fact of organizational life is that project managers are often caught unawares by unforeseen events and their dynamics. In this post, I have summarized a typology of organizational surprises and have elaborated on its relevance to project management.  I have also briefly discussed the ways in which different types of surprises can be tackled, emphasising that the key to tackling surprise lies in creating an environment that provides psychological safety and encourages open dialogue.

In closing, I reiterate that projects and organisations are open systems, and surprises are characteristic of such systems. The biggest surprise, therefore, is that we are continually surprised by some of the events and processes that occur within them

Written by K

November 27, 2013 at 9:38 pm

%d bloggers like this: