Archive for the ‘Wicked Problems’ Category
Unforeseen consequences – an unexpected sequel to my previous post
Introduction – a dilemma resolved?
Last week I published a post about how a friend and I used the Issue-based Information System (IBIS) notation to map out a dilemma he was facing – whether to accept or decline a job offer. The final map of that discussion is reproduced in Figure 1 below.
Figure 1: Final map from previous post
The map illustrates how we analysed the pros and cons of the options before him.
As I’d mentioned in the post, a couple of days after we did the map, he called to tell me that he had accepted the offer. I was pleased that it had worked out for him and was pretty sure that the dilemma was essentially resolved: he’d accepted the job, so that was that.
..or so I thought.
An unforeseen consequence
Last Saturday I happened to meet him again. Naturally, I asked him how things were going – how his current employer had reacted to his resignation etc.
“You’re not going to believe this,” he said. “After he heard that I had resigned, the CEO (who is many levels above me in the org chart) asked to see me immediately.”
“Wow!” I couldn’t help interjecting.
“…Yeah. So, I met him and we had a chat. He told me that management had me marked for a role at a sister organization, at a much higher level than I am at now. So he asked me to hold off for a day or two, until I’d heard what was on offer. When I told him I’d signed the contract already, he said that I should hear what they had to say anyway.”
Wow, indeed – we couldn’t have anticipated this scenario… or could we?
An expert’s observations
In a comment on that post Tim van Gelder makes two important points:
- The options explored in the map (accept/decline) are in fact the same point – one is simply the negation of the other. So this should be represented as a single option (either accept or decline), with the pros arguing for the represented option and the cons arguing for the unrepresented one.
- Options other than the obvious one (accept or decline) should have been explored.
In my response I pointed out that although representing the two options as separate points causes redundancies, it can help participants “see” arguments that may not be obvious immediately. One is drawn to consider each of the actions separately because they are both represented as distinct options, each with their own consequences (I’ll say more about this later in this post). The downside, as Tim mentions, is more clutter and superfluity. This is not necessarily a problem for small maps but can be an issue in larger ones.
However, it is the second point that is more relevant here. In my response to Tim’s comment I stated:
For completeness we ought to have explored options other than the two (one?) that we did, and had we more time we may have done so. That said, my mate viewed this very much as an accept/decline dilemma (precluding other options) because he had only a day to make a decision.
Clearly, in view of what happened, my argument about not having enough time is a complete cop out: we should have made the time to explore the options because it is precisely what had come back to bite us.
Choice and consequence
In hindsight it’s all very well to say that we could have done this or should have done that. The question is: how could we have given ourselves the best possible chance to have foreseen the eventuality that occurred (and others ones that didn’t)?
One way to do this is to explore other ideas in response to the root question: what should I do? (see Figure1). However, it can be difficult for the person(s) facing the dilemma to come up with new ideas when one option looms so much larger than all others. It is the facilitator’s job to help the group come up with options when this happens, and I had clearly failed on this count.
Sure, it can be difficult to come up with options out of the blue – especially when one is not familiar with the context and background of the problem. This highlights the importance of getting a feel for things before the discussion starts. In this case, I should have probed my friends current work situation, how he was regarded at his workplace and his motivations for moving before starting with the map. However, even had I done so, it is moot whether we would have foreseen the particular consequence that occurred.
So, is there any way to get participants thinking about consequences of their choices? Remember, in IBIS one “evaluates” an idea in terms of its pros and cons. Such an analysis may not include consequences .
In my opinion, the best way to get folks thinking about consequences is to ask the question explicitly: “What are the consequences of this idea/option?”
Figure 2 illustrates how this might have worked in the case of my friend’s dilemma. Had we brainstormed the consequences of accepting, he may well have come up with the possibility that actually eventuated.
Figure 2: Exploring consequences (branch highlighted in yellow
The branch highlighted in yellow shows how we might have explored the consequences of accepting the job. For each consequence one could then consider how one might respond to it. The exploration of responses could be done on the same map or hived off into its own map as I’ve shown in the figure. Note that clicking on a map node in Compendium (the free software tool used to create IBIS maps) simply opens up a new map. Such sub-maps offer a convenient way to organise complex discussions into relatively self-contained subtopics.
I emphasise that the above is largely a reframing of pros and cons: all the listed consequences can be viewed as pros or cons (depending on whether the consequence is perceived as a negative or a positive one). However asking for consequences explicitly prompts participants to think in terms of what could happen, not just known pros and cons.
Of course, there is no guarantee that this process would have enabled us to foresee the situation that actually occurred. This deceptively simple dilemma is indeed wicked.
Epilogue
On Sunday I happened to re-read Rittel and Webber’s classic paper on wicked problems. In view of what had occurred, it isn’t surprising that the following lines in the paper had a particular resonance:
With wicked problems…. any solution, after being implemented, will generate waves of consequences over an extended–virtually an unbounded– period of time. Moreover, the next day’s consequences of the solution may yield utterly undesirable repercussions which outweigh the intended advantages or the advantages accomplished hitherto. In such cases, one would have been better off if the plan had never been carried out.
The full consequences cannot be appraised until the waves of repercussions have completely run out, and we have no way of tracing all the waves through all the affected lives ahead of time or within a limited time span.
I can’t hope to put it any better than that.
To accept or to decline: mapping life’s little dilemmas using IBIS
Introduction
Last weekend I met up with a friend I hadn’t seen for a while. He looked a bit preoccupied so I asked him what the matter was. It turned out he had been offered a job and was mulling over whether he should accept it or not. This dilemma is fairly representative of some of the tricky personal decisions that we are required to make at various junctures in our lives: there’s never enough information to be absolutely certain about the right course of action, and turning to others for advice isn’t particularly helpful because their priorities and motivations are likely differ from ours.
The question of whether or not to accept a job offer is a wicked problem because it has the following characteristics:
- It is a one-shot operation.
- It is unique.
- One is liable to face the consequences of whatever choice one makes (one has no right to be wrong)
- Since one can make only one choice, one has no opportunity to test the correctness of ones choice.
- The choice one makes (the solution) depends on which aspects of the two choices one focuses on (i.e. the solution depends on ones explanation of the issue).
Admittedly, there are some characteristics of wickedness that the job dilemma does not satisfy. For example, the problem has a definitive formulation (specified by the choices) and there are an enumerable number of choices (accept or decline). Nevertheless, since it satisfies five criteria, one can deem the problem as being wicked. No doubt, those who have grappled with this question in real life will probably agree.
Horst Rittel, the man who coined the term wicked problem also invented the Issue-based Information System (IBIS) notation to document and manage such problems (note that I don’t use the word “solve” because such problems can’t be solved in the conventional sense). The notation is very easy to learn because it has just three elements and a simple grammar – see this post for a quick introduction. Having used IBIS to resolve work related issues before (see this post, for example), I thought it might help my friend if we could used it to visualize his problem and options. So, as we discussed the problem, I did a pencil and paper IBIS map of the issue (I didn’t have my computer handy at the time). In the remainder of this post, I reconstruct the map based on my recollection of the conversation.
Developing the map
All IBIS maps begin with a root question that summarises the issue to be resolved. The dilemma faced by my friend can be summarized by the question:
What should I do (regarding the job offer)?
Questions are represented by blue-green question marks in IBIS (see Figure 1).
There are two possible responses to the question– accept or decline. Responses are referred to as ideas in IBIS, and are denoted by yellow lightbulbs. The root question and the two ideas responding to it are shown in Figure 1.
Figure 1
An IBIS map starts with the root questions and develops towards the right as the discussion progresses.
The next step is to formulate arguments for and against each idea. These are referred to as pros and cons in IBIS, and are denoted by a green + and red – sign respectively (See Figures 2 and 3 for examples of these).
We focused on the “accept” option first. The pros were quite easy to see as the offer was generous and the new role a step up from where he was now. I asked him to describe list all the pros he could think of. He mentioned the following:
- Better pay (30% more than current)
- Greater responsibility compared to current job.
- Good learning opportunity (new domain)
- Better career prospects
These points have been depicted in Figure 2.
I felt the second point needed clarification, so I asked him to elaborate on what he meant by “Greater responsibility.” Now, any node in IBIS can be elaborated by asking appropriate questions and responding to them. He mentioned that he would be managing a bigger team which was responsible for a wider range of functions. I broke these up into two points elaborating on the “greater responsibility” point. The elaborations are on the extreme right in Figure 2.
Figure 2
“Do you see any downside to taking the job?” I asked.
“A big one,” he said, “there are all the unknowns that go with a new working environment: the need to build relationships from scratch, greater pressure and possibly longer working hours until I establish my credibility.”
I mapped these points with “New working environment” as the main point and the others as elaborations of it.
I then asked him if there were any other cons he could think of.
“Just one,” he said, “From what I hear, the company may not be as stable as my current employer.”
I added this in and asked him to check if the map was an accurate representation of what he meant. “Yes,” he said, “that’s a good summary of my concerns.”
The map at this stage is shown in Figure 3.
Figure 3
He seemed to be done with the “accept” option, so I suggested moving on to outlining arguments for and against staying with his present employer.
Tellingly, he outlined the pros first:
- He was in his comfort zone – he knew what was expected of him and was able to deliver it with ease.
- The working environment in his company was excellent.
- The company was doing very well and the outlook for the foreseeable future was good.
I mapped these as he spoke. After he was done, I asked him to outline the cons of staying. Almost right away he mentioned the following:
- No prospects for career advancement; the job was a dead end.
- After five odd years, he was getting a bit bored.
The map at this stage is shown in Figure 4.
Figure 4
Through the conversation, he was watching me sketch out the map on paper, but he hadn’t been looking too closely (perhaps because my handwriting is pure chicken scrawl). Nevertheless, at this point he turned the paper around to have a closer look, and said, “Hey, this isn’t bad – my options and reasons for and against them in one glance.”
I asked him if the analysis thus far suggested a choice.
“No,” he said shaking his head.
To make progress, I suggested looking at the cons for both options, to see if these could be mitigated in some way.
We looked at the “stay with the current employer option” – there was really nothing that could be done about the issue of career stagnation or the fact that the work was routine. The company couldn’t create a new position just for him, and the work was all routine because he had done it for so long.
Finally, we turned our attention to the cons of the “move to the new employer” option.
After a while, he said “The uncertainty regarding a new work environment isn’t specific to this employer. It applies to any job – including the ones I may consider in future.”
“That’s an excellent point,” I said, “So we should disregard it, right?”
“Yes. So we’re left with only the stability issue.”
“Perhaps you can search the Web for some information on the company and may be even ask around.”
“I think things are a lot clearer now,” he said as I added the points we’d just discussed to the map.
Figure 5
Figure 5 shows the final result of our deliberations.
Afterword
A few days later he called to tell me that he had accepted the job, but only after satisfying himself that the company was sound. He had to rely on information that he found on the web because no one in his network of accquaintances knew anything about the company. But that’s OK, he said – absolute certainty is impossible when dealing with life’s little dilemmas.
Doing the right project is as important as doing the project right
Introduction
Many high profile projects fail because they succeed. This paradoxical statement is true because many projects are ill-conceived efforts directed at achieving goals that have little value or relevance to their host organisations. Project management focuses on ensuring that the project goals are achieved in an efficient manner. The goals themselves are often “handed down from above”, so the relevance or appropriateness of these is “out of scope” for the discipline of project management. Yet, the prevalence of projects of dubious value suggests that more attention needs to be paid to “front-end” decision making in projects – that is, decision making in the early stages, in which the initiative is just an idea. A paper by Terry Williams and Knut Samset entitled, Issues in front-end decision making on Projects looks at the problems associated with formulating the “right” project. This post is a summary and review of the paper.
What is the front-end phase of the project? According to Williams and Samset, “The front-end phase commences when the initial idea is conceived and proceeds to generate information, consolidate stakeholders’ views and positions, and arrive at the final decision as to whether or not to finance the project.”
Decisions made in the early stages of a project are usually more consequential than those made later on. Most major parameters – scope, funding, timelines etc. are more or less set in stone by the time a project is initiated. The problem is that these decisions are made at a time when the availability of relevant information is at its lowest. This highlights the role of sound judgement and estimation in decision making. Furthermore, these decisions may have long-term consequences for the organisation, so due care needs to be given to alignment of the project concept with the organisation’s strategic goals. Finally, as the cliché goes, the only constant is change: organisations exist in ever-changing environments, so projects need to have the right governance structures in place to help navigate through this turbulence. The paper is an exploration of some of these issues as they relate to front-end decision making in projects.
Defining the project concept
Williams and Samset define the terms concept as a mental construction that outlines how a problem will be solved or a need satisfied. Note that although the definition seems to imply that the term concept equates to technical approach, it is more than that. The project concept also includes considerations of the outcomes and their impact on the organisation and its environment.
The authors emphasise that organisations should to conceive several distinct concepts prior to initiating the project. To this end, they recommend having a clearly defined “concept definition phase” where the relevant stakeholders create and debate different concepts. Choosing the right concept is critical because it determines how the project will be carried out, what the end result is and how it affects the organisation. The authors emphasise that the concept should be determined on the basis of the required outcome rather than the current (undesirable) situation.
When success leads to failure
This is the point alluded to in the introduction: a project may produce the required outcomes, but still be considered a failure because the outcomes are not aligned with the organisation’s strategy. Such situations almost always arise because the project concept was not right. The authors describe an interesting example of such a project, which I’ll quote directly from the paper:
One such example is an onshore torpedo battery built inside the rocks on the northern coast of Norway in 2004 (Samset, 2008a). The facility was huge and complex, designed to accommodate as many as 150 military personnel for up to three months at a time. It was officially opened as planned and without cost overrun. It was closed down one week later by Parliamentary decision. Clearly, a potential enemy would not expose its ships to such an obvious risk: the concept had long since been overtaken by political, technological, and military development. What was quite remarkable was that this project, which can only be characterized as strategic failure, got little attention in the media, possibly because it was a success in tactical terms.
A brilliant example of a successful project that failed! The point, of course, is that although the strategic aspects of projects are considered to be outside the purview of project management, they must be given due consideration when the project is conceptualized. The result of a project must be effective for the organisation, the efficiency of project execution actually matters less.
Shooting straight – aligning the project to strategic goals
Aligning projects with strategic goals is a difficult because the organizational and social ramifications of a project are seldom clear at the start. This is because the problem may be inherently complex – for example, no one can foresee the implications of an organizational restructure (no, not even those expensive consultants who claim to be able to). Further, and perhaps more important, is the issue of social complexity: stakeholders have diverse, often irreconcilable, views on what needs to be done, let alone how it should be done. These two factors combine to make most organizational issues wicked problems.
Wicked problems have no straightforward solutions, so it is difficult if not impossible to ensure alignment to organizational strategy. There are several techniques that can be used to make sense of wicked problem. I’ve discussed one of these – dialogue mapping – in several prior posts. Paul Culmsee and I have elaborated on this and other techniques to manage wicked problems in our book, The Heretic’s Guide to Best Practices.
One has to also recognize that the process of alignment is messier still because politics and self interest play a role, particularly when the stakes are high. Further, at the individual level, decisions are never completely objective and are also subject to cognitive bias – which brings me to the next point…
Judgement and the formulation of organizational strategy
Formulating organizational strategy depends on making informed and accurate judgements about the future. Further, since strategies typically cover the mid to long term, one has to also allow some flexibility for adjustments along the way as one’s knowledge improves.
That’s all well and good, but it doesn’t take into account the fact that decision making isn’t a wholly rational process – humans who make the decisions are, at best, boundedly rational (sometimes rational, sometimes not). Bounded rationality manifests itself through cognitive biases – errors of perception that can lead us to making incorrect judgements. See my post on the role of cognitive bias in project failure for more on how these biases have affected high profile projects.
The scope for faulty decision making (via cognitive bias or any other mechanism) is magnified when one deals with wicked problems. There are a number of reasons for this including:
- Cause-effect relationships are often unclear.
- No one has complete understanding of the problem (the problem itself is often unclear).
- Social factors come into play (Is it possible make an “unbiased” decision about a proposed project that is going to affect one’s livelihood?)
- Consequent from points 1 through 3, stakeholders perceive the problem (and its solution) differently.
It is worth pointing out that project planning is generally “less wicked” than strategy formulation because the former involves more clear cut goals (even though they may be wrong-headed). There is more scope for wickedness in the latter because there are many more unknowns and “unknowables.”
Why estimates are incorrect
Cost is a major factor in deciding whether or not a project should go-ahead. Unfortunately, this is another front-end decision; one which needs to be made when there isn’t enough information available. In his book, Facts and Fallacies of Software Engineering, Robert Glass names poor estimation as one of the top causes of project failure. This is not to say that things haven’t improved. For example, Agile methods which advocate incremental/iterative development continually refine initial estimates based on actual, measurable progress.
Techniques such as reference class forecasting have been proposed to improve estimation for projects where incremental approaches are not possible (infrastructural projects, for example). However, this technique is subject to the reference class problem.
Finally, all the aforementioned techniques assume that reliable information on which estimates can be based is a) available and b) used correctly. But this is just where the problem lies: the two key factors that lead to poor estimation are a) the lack of knowledge about what exactly the work entails and b) the fact that people may misunderstand or even misrepresent the information if it is available.
Governance in an ever-changing environment
A negative consequence of the quest for organizational agility and flexibility is that organizational environments are turbulent. The main point of the paper is that traditional project management (as laid out in frameworks such as PMBOK) Is ill-suited to such environments. As they state:
The key point in this article, however, is that the environment in which most projects operate is complex and turbulent, and conventional project management is not well suited to such conditions, despite the attraction of project organization to companies in fast-moving environments seeking agility and responsiveness…
Yet, ironically, this uncertainty is the reason for the spectacular growth in adoption of project management methodologies (see this post for a discussion of a relevant case study).
For project management to be truly useful, it must be able to cope with and adapt to turbulent environments. To this end, it may be best to view project management as a set of activities that emerge from a real need rather than an arbitrary imposition dictated by methodologies that are divorced from reality. This is nothing new: iterative/incremental methods, which advocate adaptation of methods to suit the environment, are a step in this direction.
Adaptive methods are obviously easier to apply on smaller projects than larger ones. However, one could argue that the need for flexibility and adaptability is even greater on massive megaprojects than smaller ones. A major consequence of a changing environment is that people’s views on what needs to be done diverge. Recent work in applying dialogue mapping to large project environments shows that it is possible to reduce this divergence. Getting people on the “same page” is, I believe, the first step to successful governance, particular in unstable environments.
Lack of information
The most important decisions on projects have to be made upfront, when little or no reliable information is available. The authors argue that the lack of information can actually be a benefit in front-end decision for the following reasons:
- Too much information can lead to confusion and analysis paralysis.
- Information can get out of date quickly – forecasts based on outdated information can be worse than useless because they can mislead.
- It is often hard to tell between important and irrelevant information. The distinction may only become clear as the project proceeds.
Be that as it may, one cannot deny that front-end decision making is hampered by the lack of relevant information. The real problem, though, is that decisions are often made by those who cannot tell the difference between what’s important and what’s not.
Conclusion
The article is an excellent summary of the major impediments in front-end decision making on projects. Such decisions have a major impact on how the project unfolds, yet they are often made with little or no consideration of what exactly the project will do for the organisation, or what its impact will be.
In my experience, front-end decisions are invariably made in an ad-hoc manner, rooted more in hope and fantasy than reality. A first step to ensuring that organizations do the right project is to ensure that all stakeholders have a common understanding of the goals of the project – that is, what needs to be done. The next is to ensure a common understanding of how those goals will be achieved. Such stakeholder alignment is best achieved using communication-centric, collaborative techniques such as dialogue mapping. Only then, after ensuring that one is doing the right project, does it make sense to focus on doing the project right.
Eight to Late 