Sean yawned as he powered down his computer and stretched out in his chair. It was nearly 3 am and he had just finished proofreading his presentation for later that day. He didn’t remember ever being this tired; a great deal of effort had been expended over the last three months but it had been worth it. Now, finally, he was done.
He gazed down at the beautifully bound document on his desk with a fondness that lesser mortals might bestow on their progeny.
“That’s a fine looking document you have there,” said an oddly familiar voice from right behind his chair.
“Wha..,” squeaked Sean, shooting out of his chair, upending his coffee mug in the process.
He grabbed a couple of tissues and dabbed ineffectually at the coffee stain that was spreading rapidly across the front of his brand new chinos. “Damn,” he cursed as he looked up to find himself face-to-face with someone who looked just like him – right down to the Ralph Lauren shirt and Chinos (minus the unseemly stain).
“Pardon me,” sputtered the apparition, giving in to a fit of laughter. “That’s funniest thing I’ve seen in a long time, a scene worthy of million YouTube hits. You should’ve seen yourself jump out the chair and…”
“Pardon my rudeness, but who the f**k are you?” interrupted Sean, a tad testily. Who did this guy think he was anyway? (Lest you get the wrong idea, Sean didn’t normally use expletives, but he reckoned the situation merited it.)
“Don’t swear at me,” said the double, “because I am you…well, your conscience actually. But, in the end I’m still you.”
“Bah,” replied Sean. He figured this had to be a prank hatched by one of his workmates. “Tell me which one of my smartarse colleagues put you up to this?” he demanded, “Let me guess; it is either Mal or Liz.”
“You don’t believe me, do you? No one put me up to this. Well actually, if anyone did, it was you!”
“That’s nonsense,” spat Sean, his blood pressure rising a notch, “I have no idea who you are.”
“Ah, now we get to the nub of the matter,” said the apparition, “You have no idea who I am, and that is precisely why I’m here: to remind you that I exist and that you should listen to me from time to time. I usually start to bother you when you’re are about to do something stupid or unethical.”
“Me? Stupid? Unethical? I have no idea what you’re on about,” contested Sean.
“It appears I need to spell out for you. Well here’s the executive summary: I think you need to revise that document you’ve been working on. I’m your conscience, and I think I can help.”
“I… don’t… need… your… help,” said Sean enunciating each word exaggeratedly for emphasis, “you probably do not know this, but I have completed the biggest and most ambitious design I’ve ever done: a comprehensive systems architecture for Big Enterprise. I’m confident of what I have proposed because it is backed by solid research and industry best practice.”
“I know what you have done,” said the doppelganger, “I’m your conscience, after all.” He paused to clear his throat. “And I’m sure you believe what you have written, “he continued, “but that doesn’t make it right.”
“It is impeccably researched! You know, I’ve cited over 800 references, yeah eight hundred,” said Sean with pride. “That’s over two references per page, and most of these are to works written by acknowledged experts in the field.”
“I do not doubt your knowledge or diligence, my friend,” said the doppelganger with a smile, “what I worry about is your judgement.”
Sean was ready to blow a fuse, but was also confused (intrigued?) by the double’s choice of words. “Judgement?” he blurted, “WTF do you mean by ‘judgement?” He picked up the tome and waved it in front of the doppelganger imperiously…but then spoilt the effect by almost spraining his wrist in the process. He put the book down hurriedly saying, “this is an objective evaluation; the facts speak for themselves.”
“Do they?” queried the apparition. Sure, you’ve collected all this information and have fashioned into a coherent report. However, your recommendations, which appear to be based on facts, are in truth based on unverifiable assumptions, even opinions.”
“That’s nonsense,” dismissed Sean. “You haven’t even read the report, so you’re in no position to judge.”
“I have. I’m your conscience, remember?”
“OK, so tell me what you did and how you did it,” said the apparition evenly.
Sean held forth for a few minutes, describing how he researched various frameworks, read case studies about them and then performed an evaluation based on criteria recommended by experts.
“I concede you that you truly believe you are right, but the sad fact is that you probably aren’t,” said the double, “and worse, you refuse to entertain that possibility.”
“That’s hogwash! If you’re so sure then prove it,” countered Sean.
“Hmmm, you are thicker than I thought, let me see if I can get my point across in a different way,” said the double. “You’re doing something that will influence the future of technology in your organisation for a long time to come. That is an immense responsibility…”
“I’m aware of that, thank you,” interrupted Sean, raising his voice. He’d had enough of this presumptuous, insulting clown.
“If you say so,” said the doppelganger, “but, to be honest, I sense no doubts and see no caveats in your report.”
“That’s because I have none! I believe in and stand by what I have done,” shouted Sean.
“I have no doubt that you believe in what you have done. The question is, do others, will others?”
“I’m not stupid,” said Sean, “I’ve kept my managers and other key stakeholders in the loop throughout. They know what my recommendations are, and they are good with them.”
“How many stakeholders, and where are they located?”
“Over ten important stakeholders, senior managers, all of them, and all seated right here in the corporate head office,” said Sean. He made to pick up the tome again, but a twinge in his wrist reminded him that it might not be wise to do so. “Let me tell you that the feedback I have from them is that this is a fantastic piece of work,” he continued, emphasizing his point by rapping on the wrist-spraining tome with his knuckles. “So please go away and leave me to finish up my work.”
“Yeah, I’ll go, it seems you have no need of me,” said the double, “but allow me a couple of questions before I go. I am your conscience after all!”
“Ok, what is it?” said Sean impatiently. He couldn’t wait to see the back of the guy.
“You’re working in a multinational right? But you’ve spoken to a few stakeholders all of whom are sitting right here, in this very building. Have you travelled around and spoken with staff in other countries – say in Asia and Europe – and gotten to know their problems before proposing your all-embracing architecture?”
“Look,” said Sean, “it is impossible to talk to everyone, so, I have done the best I can: I have proposed a design that adheres to best practices, and that means my design is fundamentally sound,” asserted Sean. “Moreover, the steering committee has reviewed it, and has indicated that it will be approved.”
“I have no doubt that it will be approved,” said the apparition patiently, “the question is: what then? Think about it, you have proposed an architecture for your enterprise without consulting the most important stakeholders – the people who will actually live it and work with it. Would you have an architect build your house that way? And how would you react to one who insisted on doing things his or her way because it is “best practice” to do so?”
“That’s a completely inappropriate comparison,” said Sean.
“No it isn’t, and you know it too” said the doppelganger. “But look, I’ve nothing more to add. I’ve said what I wanted to say. Besides, I’m sure you’re keen to see the back of me…most people are.”
…and pfft…just like that, the apparition vanished, leaving a bemused architect and a rapidly drying coffee stain in its wake.
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 .
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.
- System development lifecycle.
- Techniques for user involvement
I’ll look at each of these in turn in the next two sections, emphasising their rational features.
The basic steps of a system development lifecycle, common to all methodologies, are:
- Requirements gathering / analysis
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:
- 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.
- 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.
- 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:
- 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.
- Position in organisation: in a corporate environment, business users generally outrank technical staff.
- Affiliations: users and developers belong to different organisational units and therefore have differing loyalties.
- 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.
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…
It felt like a homecoming. That characteristic university smell (books, spearmint gum and a hint of cologne) permeated the hallway. It brought back memories of his student days: the cut and thrust of classroom debates, all-nighters before exams and near-all-nighters at Harry’s Bar on the weekends. He was amazed at how evocative that smell was.
Rich checked the directory near the noticeboard and found that the prof was still in the same shoe-box office that he was ten years ago. He headed down the hallway wondering why the best teachers seemed to get the least desirable offices. Perhaps it was inevitable in a university system that rated grantsmanship over teaching.
It was good of the prof to see him at short notice. He had taken a chance really, calling on impulse because he had a few hours to kill before his flight home. There was too much travel in this job, but he couldn’t complain: he knew what he was getting into when he signed up. No, his problem was deeper. He no longer believed in what he did. The advice he gave and the impressive, highly polished reports he wrote for clients were useless…no, worse, they were dangerous.
He knew he was at a crossroad. Maybe, just maybe, the prof would be able to point him in the right direction.
Nevertheless, he was assailed by doubt as he approached the prof’s office. He didn’t have any right to burden the prof with his problems …he could still call and make an excuse for not showing up. Should he leave?
He shook his head. No, now that he was here he might as well at least say hello. He knocked on the door.
“Come in,” said the familiar voice.
He went in.
“Ah, Rich, it is good to see you after all these years. You’re looking well,” said the prof, getting up and shaking his hand warmly.
After a brief exchange of pleasantries, he asked Rich to take a seat.
“Just give me a minute, I’m down to the last paper in this pile,” said the prof, gesturing at a heap of term papers in front of him. “If I don’t do it now, I never will.”
“Take your time prof,” said Rich, as he sat down.
Rich cast his eye over the bookshelf behind the prof’s desk. The titles on the shelf reflected the prof’s main interest: twentieth century philosophy. A title by Habermas caught his eye.
Rich recalled a class in which the prof had talked about Habermas’ work on communicative rationality and its utility in making sense of ambiguous issues in management. It was in that lecture that the prof had introduced them to the evocative term that captured ambiguity in management (and other fields) so well, wicked problems.
There were many things the prof spoke of, but ambiguity and uncertainty were his overarching themes. His lectures stood in stark contrast to those of his more illustrious peers: the prof dealt with reality in all its messiness, the other guys lived in a fantasy world in which their neat models worked and things went according to plan.
Rich had learnt from the prof that philosophy was not an arcane subject, but one that held important lessons for everyone (including hotshot managers!). Much of what he learnt in that single term of philosophy had stayed with him. Indeed, it was what had brought him back to the prof’s door after all these years.
“All done,” said the prof, putting his pen down and flicking the marked paper into the pile in front of him. He looked up at Rich: “Tell you what, let’s go to the café. The air-conditioning there is so much better,” he added, somewhat apologetically.
As they walked out of the prof’s office, Rich couldn’t help but wonder why the prof stuck around in a place where he remained unrecognized and unappreciated.
The café was busy. Though it was only mid-afternoon, the crowd was already in Friday evening mode. Rich and the prof ordered their coffees and found a spot at the quieter end of the cafe.
After some small talk, the prof looked him and said, “Pardon my saying so, Rich, but you seem preoccupied. Is there something you want to talk about?”
“Yes, there is…well, there was, but I’m not so sure now.”
“You might as well ask,” said the prof. “My time is not billable….unlike yours.” His face crinkled into a smile that said, no offence intended.
“Well, as I mentioned when I called you this morning, I’m a management consultant with Big Consulting. By all measures, I’m doing quite well: excellent pay, good ratings from my managers and clients, promotions etc. The problem is, over the last month or so I’ve been feeling like a faker who plays on clients’ insecurities, selling them advice and solutions that are simplistic and cause more problems than they solve,” said Rich.
“Hmmm,” said the prof, “I’m curious. What triggered these thoughts after a decade in the game?”
“Well, I reckon it was an engagement that I completed a couple of months ago. I was the principal consultant for a big change management initiative at a multinational. It was my first gig as a lead consultant for a change program this size. I was responsible for managing all aspects of the engagement – right from the initial discussions with the client, to advising them on the change process and finally implementing it.” He folded his hands behind his head and leaned back in his chair as he continued, ”In theory I’m supposed to offer independent advice. In reality, though, there is considerable pressure to use our standard, trademarked solutions. Have you heard of our 5 X Model of Change Management?”
“Yes, I have,” nodded the prof.
“Well, I could see that the prescriptions of 5 X would not work for that organization. But, as I said, I had no choice in the matter.”
“Uh-huh, and then?”
“As I had foreseen,” said Rich, “the change was a painful, messy one for the organization. It even hit their bottom line significantly. They are trying to cover it up, but everyone in the organization knows that the change is the real reason for the drop in earnings. Despite this, Big Consulting has emerged unscathed. A bunch of middle managers on the client’s side have taken the rap.” He shook his head ruefully. “They were asked to leave,” he said.
“That’s terrible,” said the prof, “I can well understand how you feel.”
“Yes, I should not have prescribed 5 X. It is a lemon. The question is: what should I do now?” queried Rich.
“That’s for you to decide. You can’t change the past, but you might be able to influence the future,” said the prof with a smile.
“I was hoping you could advise me.”
“I have no doubt that you have reflected on the experience. What did you conclude?”
“That I should get out of this line of work,” said Rich vehemently.
“What would that achieve?” asked the prof gently.
“Well, at least I won’t be put into such situations again. I’m not worried about finding work, I’m sure I can find a job with the Big Consulting name on my resume,” said Rich.
“That’s true,” said the prof, “but is that all there is to it? There are other things to consider. For instance, Big Consulting will continue selling snake oil. How would you feel about that?”
“Yeah, that is a problem – damned if I do, damned if I don’t,” replied Rich. “You know, when I was sitting in your office, I recalled that you had spoken about such dilemmas in one of your classes. You said that the difficulty with such wicked issues is that they cannot be decided based on facts alone, because the facts themselves are either scarce or contested…or both!”
“That’s right,” said the prof, “and this is a wicked problem of a kind that is very common, not just in professional work but also in life. Even relatively mundane issues such as whether or not to switch jobs have wicked elements. What we forget sometimes, though, is that our decisions on such matters or rather, our consequent actions, might also affect others.”
“So you’re saying I’m not the only stakeholder (if I can use that term) in my problem. Is that right?”
“That’s right, there are other people to consider,” said the prof, “but the problem is you don’t know who they are .They are all the people who will be affected in the future by the decision you make now. If you quit, Big Consulting will go on selling this solution and many more people might be adversely affected. On the other hand, if you stay, you could try to influence the future direction of Big Consulting, but that might involve some discomfort for yourself. This makes your wicked problem an ethical one. I suspect this is why you’re having a hard time going with the “quit” option.”
There was a brief silence. The prof could see that Rich was thinking things through.
“Prof, I’ve got to hand it to you,” said Rich shaking his head with a smile, “I was so absorbed by the quit/don’t quit dilemma from my personal perspective that I didn’t realize there are other angles to consider. Thanks, you’ve helped immensely. I’m not sure what I will do, but I do know that what you have just said will help me make a more considered choice. Thank you!”
“You’re welcome, Rich”
…And as he boarded his flight later that evening, Rich finally understood why the prof continued to teach at a place where he remained unrecognized and unappreciated
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:
- You have to make an important project-related decision, but don’t have enough information to make it.
- Your team is overworked and your manager has already turned down a request for more people.
- 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.
When making decisions, some people follow a structured process that involves gathering data, identifying options and analysing them to arrive at a decision. Others prefer an approach in which they seek to understand the diversity of perspectives on the issue and then attempt to synthesise a decision based on their understanding. To be sure these are stereotypes and, like all stereotypes, are somewhat exaggerated. Nevertheless, most decision-makers in organisations fall into one of these categories, at least as far as their preferred decision-making mode is concerned. Of course, people may change from one mode to another, depending on the situation. For example, a person who is predominantly an objective decision maker in his or her professional life might not be so objective when it comes to making personal decisions.
The differences between the two approaches roughly mirrors the divide between those who believe in an objective reality and those who believe that reality, or at least our perception of it, is a subjective matter. This is akin to the difference between CP Snow’s Two Cultures: the scientists and the artists. At the risk of making a gross generalisation, those who have a scientific or technical background tend to fall into the first category whereas those who lean towards the arts or humanities tend to fall into the other. Like all generalisations this one is, again, not strictly correct, but I think it is fair to say that a person’s training does have an influence on what they deem as the right way to make decisions.
The physicist and polymath Heinz von Foerster summed this up nicely when he noted that the difference between the two types of decision-makers is akin to the differences between discoverers and inventors. The objective decision-maker (the discoverer) attempts to discover the objectively correct decision based on what he or she believes to be true. On the other hand, the subjective decision-maker (the inventor) constructs or creates the decision based on facts and opinion (or even emotion) rather than facts alone.
The conventional view of decision making in organisations – that decisions should be made on the basis of facts – does not recognize this difference. To be sure, matters that can be decided based on facts should be made on the basis of facts. For example, a decision regarding the purchase of equipment can (often) be made based on predetermined criteria.The problem, however, is that most important decisions in organisations do not fall into this category – they have wicked elements that cannot be resolved by facts because the “facts” themselves are ambiguous. Unfortunately, decision-makers often do not understand the difference between the two types of decision problems. A common symptom of this lack of understanding is that when confronted with a wicked decision problem, many decision-makers feel compelled to clothe their reasoning and choices in a garb of (false) objectivity.
The above is not news to observers and scholars of organisational life – see this post, for example. However, a not-so-well-appreciated dimension to the objective/subjective debate on decision-making is that wicked decision problems invariably have an ethical dimension. I elaborate on this briefly below.
In a paper on ethics and cybernetics, von Foerster noted that the objective approach to decision making is but a means of avoiding responsibility. In his words:
…objectivity requires that the properties of an observer be left out of any descriptions of his (sic) observations. With the essence of observing (namely the processes of cognition) having been removed, the observer is reduced to a copying machine with the notion of responsibility successfully juggled away.
Objectivity…and other devices [such as rules and processes] are all derivations of a choice between a pair of in-principle undecidable questions [See Note 1] which are:
“Am I apart from the universe?”
“Am I a part of the universe?”
Although von Foerster may be accused overblown rhetoric in the quote, he raises a critical question that we all ought to ask ourselves when confronted with an undecidable issue:
When making this decision, am I going to avoid involvement (and responsibility) by hiding behind rules or processes, or am I going to take full responsibility for it regardless of the outcome?
An honest answer will reveal that such decisions are invariably made on ethical grounds rather than objective ones. Indeed, the decisions we make in our professional lives tell us more about ourselves than we might be willing to admit.
An undecidable question is one that cannot be decided on logical grounds alone – a wicked problem by another name. See my post on wickedness, undecidability and the metaphysics of organizational decision making for more on this point.
Flexibility is one of those buzzwords that keeps coming up in organizational communiques and discussions. People are continually asked to display flexibility, without ever being told what the term means: flexible workplaces, flexible attitudes, flexible jobs – the word itself has a flexible meaning that depends on the context in which it is used and by whom.
When words are used in this way they become platitudes – empty words that make a lot of noise. In this post, I analyse the platitude, flexibility, as it is used in organisations. My discussion is based on a paper by Thomas Eriksen entitled, Mind the Gap: Flexibility, Epistemology and the Rhetoric of New Work.
Background – a bit about organizational platitudes
One of the things that struck me when I moved from academia to industry is the difference in the way words or phrases are used in the two domains. In academics one has to carefully define the terms one uses (particularly if one is coining a new term) whereas in business it doesn’t seem to matter, words can mean whatever one wants them to mean (OK, this is an exaggeration, but not by too much). Indeed, as Paul Culmsee and I discuss in the first chapter of The Heretic’s Guide to Best Practices, many terms that are commonly bandied about in organizations are platitudes because they are understood differently by different people.
A good example of a platitude is the word governance. One manager may see governance as being largely about oversight and control whereas another might interpret it as being about providing guidance. Such varying interpretations can result in major differences in the way the two managers implement governance: the first one might enforce it as a compliance-oriented set of processes that leave little room for individual judgement while the other might implement it as a broad set of guidelines that leave many of the decisions in the hands of those who are actually doing the work. Needless to say, the results in the two cases are likely to be different too.
Flexibility – the conventional view
A good place to start our discussion of flexibility is with the dictionary. The online Oxford Dictionary defines at as:
- the ability to be easily modified
- willingness to change or compromise
The term is widely used in both these senses in organizational settings. For example, people speak of flexible designs (i.e. designs that can be easily modified) or flexible people (referring to those who are willing to change or compromise). However, and this is the problem: the term is open to interpretation – what Jack might term a flexible approach may be seen by Jill as a complete lack of method. These differences in interpretation become particularly obvious when the word is used in a broad context – such as in a statement justifying an organizational change. An executive might see a corporate restructure and the resulting changes in jobs/roles as a means to achieve organizational flexibility, but those affected by it may see it as constraining theirs. As Eriksen states:
Jobs are flexible in the sense that they are unstable and uncertain, few employees hold the same jobs for many years, the content of jobs can be changed almost overnight, and the boundaries between work and leisure are negotiable and chronically fuzzy.
Indeed, such “flexibility” which requires one to change at short notice results in a fragmentation of individual experience and a resulting loss of a coherent narrative of one’s life. It appears that increased flexibility in one aspect results in a loss of flexibility in another. Any sensible definition of flexibility ought to reflect this.
Consider the following definition of flexibility proposed by Gregory Bateson:
“Flexibility is uncommitted potential for change”
This deceptively simple statement is a good place to start understanding what flexibility really means for projects, organisations …and even software systems.
As Eriksen tells us, Bateson proposed this definition in the context of ecology. In particular, Bateson had in mind the now obvious notion that the increased flexibility we gain through our increasingly energy-hungry lifestyles results in a decrease in the environment’s capacity to cope with the consequences. This is true of flexibility in any context: a gain in flexibility in one dimension will necessarily be accompanied by a loss of flexibility in another.
Another implication of the above definition is that a system that is running at or near the limits of its operating variables cannot be flexible. The following examples should make this clear:
- A project team that is putting in 18 hour workdays in order to finish a project on time.
- A car that’s being driven at top speed.
- A family living beyond their means.
All these systems are operating at or near their limits, they have little or no spare capacity to accommodate change.
A third implication of the definition follows from the preceding one: the key variables of a flexible system should lie in the mid-range of their upper and lower limits. In terms of above examples:
- The project team should be putting in normal hours.
- The car should be driven at or below the posted road speed limits
- The family should be living within its income, with a reasonable amount to spare.
Of course, the whole point of ensuring that systems operate in their comfort zone is that they can be revved up if the need arises. Such revving up, however, should be an exceptional circumstance rather than the norm – a point that those who run projects, organisations (and, yes, even vehicles) often tend to forget. If one operates a system at the limits of its tolerance for too long, not only will it not be flexible, it will break.
Flexibility in the workplace
As mentioned in the introduction, the term flexibility keeps cropping up in organizational settings: corporate communiques exhort employees to be flexible in the face of change. This is typically a coded signal that employees should expect uncertainty and be prepared to adjust to it. A related manifestation of flexibility is the blurring of the distinction between work and personal life. As Eriksen puts it:
The term flexibility is often used to describe this new situation: Jobs are flexible in the sense that they are unstable and uncertain, few employees hold the same jobs for many years, the content of jobs can be changed, and the boundaries between work and leisure are poorly defined.
This trend is aided by recent developments in technology that enable employees to be perpetually on call. This is often sold as a work from home initiative but usually ends up being much more. Eriksen has this to say about home offices:
One recent innovation typically associated with flexibility is the home office. In Scandinavia (and some other prosperous, technologically optimistic regions), many companies equipped some of their employees with home computers with online access to the company network in the early 1990s, in order to enhance their flexibility. This was intended to enable employees to work from home part of the time, thereby making the era when office workers were chained to the office desk all day obsolete.
In the early days, there were widespread worries among employers to the effect that a main outcome of this new flexibility would consist in a reduction of productivity. Since there was no legitimate way of checking how the staff actually spent their time out of the office, it was often suspected that they worked less from home than they were supposed to. If this were in fact the case, working from home would have led to a real increase in the flexibility of time budgeting. However, work researchers eventually came up with a different picture. By the late 1990s, hardly anybody spoke of the home office as a convenient way of escaping from work; rather, the concern among unionists as well as researchers was now that increasing numbers of employees were at pains to distinguish between working hours and leisure time, and were suffering symptoms of burnout and depression. The home office made it difficult to distinguish between contexts that were formerly mutually exclusive because of different physical locations.
It is interesting to see this development in the light of Bateson’s definition of flexibility: the employee gains flexibility in space (he or she can work from home or from the office) at the expense of flexibility in time (organization time encroaches on personal time). As Eriksen states:
There seems to be a classic Batesonian flexibility trade-off associated with the new information technologies: increased spatial flexibility entails decreased temporal flexibility. If inaccessibility and ‘empty time’ are understood as scarce resources, the context of ‘new work’ thus seems to be an appropriate context for a new economics as well. In fact, a main environmental challenge of our near future will consist in protecting slow time and gaps from environmental degradation.
In short, it appears that flexibility for the organization necessarily implies a loss of flexibility for the individual.
Flexibility is in the eye of the beholder: an action to increase organisational flexibility by, say, redeploying employees would likely be seen by those affected as a move that constrains their (individual) flexibility. Such a dual meaning is characteristic of many organizational platitudes such as Excellence, Synergy and Governance. It is an interesting exercise to analyse such platitudes and expose the difference between their espoused and actual meanings. So I sign off for 2013, wishing you many hours of platitude-deconstructing fun
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.
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.
Let’s take a tour of the four categories
- 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.
- 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).
- 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.
- 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:
- Vigilance / problem sensing– a deep awareness of the project environment, with the ability to sense any changes in it.
- Resilience – the capacity to adjust to changes in the internal and external environment.
- 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:
- 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)
- 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.
- 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.
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