Archive for the ‘IT Management’ Category
Sherlock Holmes and the case of the failed projects
….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
- 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.
- 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.
- For insight into the vexed question of governance, check out this post by Paul Culmsee and the book I co-authored with him.
The architect and the apparition – a business fable
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?”
“Pah!”
“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.
Rituals in information system design and development
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.
- 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.
Development lifecycle
The basic steps of a system development lifecycle, common to all methodologies, are:
- Inception
- Requirements gathering / analysis
- Specification
- Design
- Programming
- Testing
- Training
- 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:
- 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.
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…
Eight to Late 