A performance review tragedy in five limericks
The yearly performance review
is something we all must go through.
So you may well know
the story below
…it may’ve even happened to you.
The boss, a hawk not a dove,
dictated the goals from above.
He said, “You will do
as I tell you to,
and that should be more than enough.”
The year whizzed by like a race.
(Isn’t that always the case?)
Soon it was time
for that moment sublime,
when performance would be appraised.
And as the review progressed,
the minion suffered much stress,
because it was clear
he’d be marked a failure
even though he’d given his best.
In the end he said, “OK, that’s fine,
but we were never aligned.
I know you don’t care
but it just ain’t fair
that these were your goals, not mine.
On the evolution of corporate information infrastructures
Introduction
In the last few decades two technology trends have changed much of the thinking about corporate IT infrastructures: commoditisation and the cloud. As far as the first trend is concerned, the availability of relatively cheap hardware and packaged “enterprise” software has enabled organisations to create their own IT infrastructures. Yet, despite best efforts of IT executives and planners, most of these infrastructures take on lives of their own, often increasing in complexity to the point where they become unmanageable.
The maturing of cloud technologies in the last few years appears to offer IT decision makers an attractive solution to this problem: that of outsourcing their infrastructure headaches. Notwithstanding the wide variety of mix-and-match options of commodity and cloud offerings, the basic problem still remains: one can create as much of a mess in the cloud as one can in an in-house data center. Moreover, the advertised advantages of cloud-based enterprise solutions can be illusory: customers often find that solutions are inflexible and major changes can cost substantial sums of money.
Conventional wisdom tells us that these problems can be tackled by proper planning and control. In this post I draw on Claudio Ciborra’s book, From Control to Drift: The Dynamics of Corporate Information Infrastructures, to show why such a view is simplistic and essentially untenable.
The effects of globalisation and modernity
The basic point made by Ciborra and Co. is that initiatives to plan and control IT infrastructures via centrally-driven, standards-based governance structures are essentially misguided reactions to the unsettling effects of globalisation and modernity, terms that I elaborate on below.
Globalisation
Globalisation refers to the processes of interaction and integration between people of different cultures across geographical boundaries. The increasing number of corporations with a global presence is one of the manifestations of globalisation. For such organisations, IT infrastructures systems are seen as a means to facilitate globalisation and also control it.
There are four strategies that an organisation can choose from when establishing a global presence. These are:
- Multinational: Where individual subsidiaries are operated autonomously.
- International: Where work practices from the parent company diffuse through the subsidiaries (in a non-formal way).
- Global: Where local business activities are closely controlled by the parent corporation.
- Transnational: This (ideal) model balances central control and local autonomy in a way that meets the needs of the corporation while taking into account the uniqueness of local conditions.
These four business strategies map to two corporate IT strategies:
- Autonomous: where individual subsidiaries have their own IT strategies, loosely governed by corporate.
- Headquarters-driven: where IT operations are tightly controlled by the parent corporation.
Neither is perfect; both have downsides that start to become evident only after a particular strategy is implemented. Given this, it is no surprise that organisations tend to cycle between the two strategies, with cycle times varying from five to ten years; a trend that corporate IT minions are all too familiar with. Typically, though, executive management tends to favour the centrally-driven approach since it holds the promise of higher control and reduced costs.
Another consequence of globalisation is the trend towards outsourcing IT infrastructure and services. This is particularly popular for operational IT – things like infrastructure and support. In view of this, it is no surprise that organisations often choose to outsource IT development and support to external vendors. Equally unsurprising, perhaps, is that the quality of service often does not match expectations and there’s little that can be done about it. The reason is simple: complex contracts are hard to manage and perhaps more importantly, not everything can be contractualised. See my post on the transaction cost economics of outsourcing for more on this point.
The effect of modernity
The phenomenon of modernity forms an essential part of the backdrop against which IT systems are implemented. According to a sociological definition due to Anthony Giddens, modernity is “associated with (1) a certain set of attitudes towards the world, the idea of the world as open to transformation, by human intervention; (2) a complex of economic institutions, especially industrial production and a market economy; (3) a certain range of political institutions, including the nation-state and mass democracy”
Modernity is characterised by the following three “forces” that have a direct impact on information infrastructures:
- The separation of space and time: This refers to the ways in which technology enables us reconfigure our notions of geographical space and time. For instance, coordinating activities in distant locations is now possible – global supply chains and distributed project teams being good examples. The important consequence of this ability, relevant to IT infrastructures such as ERP and CRM systems, is that it makes it possible (at least in principle) for organisations to increase their level of surveillance and control of key business processes across the globe.
- The development of disembedding mechanisms: As I have discussed at length in this post, organisations often “import” procedures that have worked well in organisations. The assumption underlying this practice is that the procedures can be lifted out of their original context and implemented in another one without change. This, in turn, tacitly assumes that those responsible for implementing the procedure in the new context understand the underlying cause-effect relationships completely. This world-view, where organisational processes and procedures are elevated to the status of universal “best practices” is an example of a disembedding mechanism at work. Disembedding mechanisms are essentially processes via which certain facts are abstracted from their context and ascribed a universal meaning. Indeed, most “enterprise” class systems claim to implement such “best practices.”
- The reflexivity of knowledge and practice: Reflexive phenomena are those for which cause-effect relationships are bi-directional – i.e. causes determine effects which in turn modify the causes. Such phenomena are unstable in the sense that they are continually evolving – in potentially unpredictable ways. Organisational practices (which are based on organisational knowledge) are reflexive in the sense that they are continually modified in the light of their results or effects. This conflicts with the main rationale for IT infrastructures such as ERP systems, which is to rationalise and automate organisational processes and procedures in a relatively inflexible manner.
Implications for organisations
One of the main implications of globalisation and modernity is that the world is now more interconnected than ever before. This is illustrated by the global repercussions of the financial crises that have occurred in recent times. For globalised organisations this manifests itself in not-so-obvious dependencies of the organisation’s well-being on events within the organisation and outside it. These events are usually not within the organisation’s control So they have to be managed as risks.
A standard response to risk is to increase control. Arguably, this may well be the most common executive-level rationale behind decisions to impose stringent controls and governance structures around IT infrastructures. Yet, paradoxically, the imposition of controls often lead to undesirable outcomes because of unforeseen side effects and the inability to respond to changing business needs in a timely manner.
A bit about standards
Planners of IT infrastructures spend a great deal of time worrying about which standards they should follow. This makes sense if for no other reason than the fact that corporate IT infrastructures are embedded in a larger (external) ecosystem that is made up of diverse organisations, each with their own infrastructures. Standards ease the problem of communication between interconnected organisations. For example, organisations often have to exchange information electronically in various formats. Without (imposed or de-facto) standards, this would be very difficult as IT staff would have to write custom programs to convert files from one format to another.
The example of file formats illustrates why those who plan and implement IT infrastructures prefer to go with well established technologies and standards rather than with promising (but unproven) new ones. The latter often cause headaches because of compatibility problems with preexisting technologies. There are other reasons, of course, for staying with older technologies and established standards – acceptance, maturity and reliability being a few important ones.
Although the rationale for adopting standards seems like a sound one, there are a few downsides too. Consider the following:
- Lock in: This refers to the fact that once a technology is widely adopted, it is very difficult for competing technologies to develop. The main reason for this is that dominant technology will attract a large number of complementary products. These make it more attractive to stick with the dominant standard. Additionally, contractual commitments, availability of expertise, switching costs make it unviable for customers to move to competitor products.
- Inefficiency: This refers to the fact that a dominant standard is not necessarily the best. There are many examples of cases where a dominant standard is demonstrably inferior to a less popular competitor. My favourite example is the Waterfall project management methodology which became a standard for reasons other than its efficacy. See this paper for details of this fascinating story.
- Incompatibility: In recent years, consumer devices such as smartphones and tablets have made their way into corporate computing environments, primarily because of pressures and demands from technology savvy end-users. These devices pose problems for infrastructure planners and administrators because they are typically incompatible with existing corporate technology standards and procedures. As an example, organisations that have standardised on a particular platform such as Microsoft Windows may face major challenges when introducing devices such as iPads in their environments.
Finally, and most importantly, the evolution of standards causes major headaches for corporate IT infrastructure planners. Anyone who has been through a major upgrade of an operating system at an organisation-wide level will have lived this pain. Indeed, it is such experiences that have driven IT decision-makers to cloud offerings. The cloud brings with it a different set of problems, but that’s another story. Suffice to say that the above highlights, once again, the main theme of the book: that infrastructure planning is well and good, but planners have to be aware that the choices they make constrain them in ways that they will not have foreseen.
Summing up
The main argument that Ciborra and his associates make is that corporate information infrastructures drift because they are subject to unpredictable forces within and outside the hosting organisation. Standards and processes may slow the drift (if at all) but they cannot arrest it entirely. Infrastructures are therefore best seen as ever-evolving constructs made up systems, people and processes that interact with each other in (often) unforeseen ways. As Ciborra so elegantly puts it:
Corporate information infrastructures are puzzles, or better collages, and so are the design and implementation processes that lead to their construction and operation. They are embedded in larger, contextual puzzles and collages. Interdependence, intricacy, and interweaving of people, systems, and processes are the culture bed of infrastructure. Patching, alignment of heterogeneous actors and making do are the most frequent approaches…irrespective of whether management [is] planning or strategy oriented, or inclined to react to contingencies.
And therein lies an important message for those who plan and oversee information infrastructures.
Notes:
Sections of this post are drawn from my article entitled, The ERP Paradox.
Sherlock Holmes and the case of the terminated PMO
“Tch, tch,” clucked Holmes, shaking his head. “What a tragedy, Watson,” he continued, “yet another project management office cut down in its prime.”
Watson said nothing; he knew his friend did not like interruptions when he was surveying a crime scene.
Holmes walked around as he always did, in apparently random fashion, his sharp eyes darting from here to there taking in the details – the process flowcharts on a wall, project schedules displayed over on the other side, the printed portfolio reports that lay on the table and the many other artefacts that are part and parcel of a PMO.
After watching his friend for what seemed like an eternity, Watson could hold his curiosity no longer: “What’s your guess, Holmes?” he asked.
“I never guess. It is a shocking habit—destructive to the logical faculty.” He looked up sharply, “You should know better than to ask Watson….”
“I know, Holmes, but my curiosity gets the better of me. What do you think happened?”
“Ah yes, what I think. What I think is not important, Watson,” he said, wagging his index finger in his friend’s direction. “We must focus on what we know – the facts.”
“So, what are the facts?” asked Watson wearily. His friend could be an insufferable pedant.
“You know my methods, Watson. Look around you. What do you see?”
Oh, they were going to play that game again. Shaking his head in exasperation, Watson said, “Why don’t you save time and tell me, Holmes. You are the genius, not I.”
“Ah Watson, sarcasm does not become you. Anyway, I take no offence and will offer you some hints so that you may begin to discern the real reason for the failure of this PMO.”
He walked over to the flowcharts on the wall and asked,” Tell me Watson, What are these and what do they tell you?”
Watson walked over to the charts, looked at them intently and said, “I think we can safely say these describe project management processes.” Then, jabbing his finger at a chart, he continued, “This one describes the process of authorisation. It seems sensible enough – a need is identified, a business case drawn up and submitted to the project governance board, it is evaluated against certain criteria and then a decision is made on whether the project should be authorised or not. And look at this one, ‘tis a work of art….”
“Do you know, Watson,” interrupted Holmes, “that it is one of the curses of a mind with a turn like mine that I must look at everything with reference to my own special subject. You look at these attractive flowcharts, and you are impressed by their beauty. I look at them, and the only thought which comes to me is a feeling of their isolation and of the impunity with which they may be subverted.”
“Huh?” blurted Watson, not knowing quite what to make of this.
“I see you are perplexed, Watson. Let me put it another way, a PMO may require that project managers comply with certain process, but it cannot enforce compliance.”
“So you think the PMO failed because it could not get project managers to follow processes?”
“Yes, Watson. But experience tells me that although that may be a visible symptom, it is not the cause. You’re a doctor so I don’t need to tell you that identifying symptoms is necessary but, to cure the disease, one must find the cause. It is all too easy to label the symptom as the cause – many consultants have done so, and have thus made recommendations that are worse than useless.”
“Worse than useless? I don’t understand, Holmes.”
“Yes, worse than useless. If organisations focus on curing symptoms rather than causes, they will end up exacerbating the underlying dysfunctions. For example, if a consultant mistakenly labels the fact that project managers did not follow processes as the cause, the organisation may put in place procedures that forces managers to comply with processes. That, as you will no doubt appreciate, is doing exactly the wrong thing – it will only make things worse.”
“Why is it the wrong thing? Surely if they are forced to comply, they will and the processes will then be followed as they should be.”
“Ah, Watson,” said Holmes, shaking his head in exasperation, “that’s the army man in you talking.” He continuted sharply, “This is not the military, Sir! This is the messy world of organisation-land where people are autonomous agents even though management orthodoxy would have us believe otherwise.”
“’Tis a matter of discipline, Holmes. Surely you do not advocate letting project managers behave as they would want – as, how do you say it…autonomous agents.”
“ You know Watson, may be you are right,” said Holmes. “Perhaps when a man has special knowledge and special powers like my own, it rather encourages him to seek a complex explanation when a simpler one is at hand.”
“Indeed, I think you are over-complicating matters my dear Holmes. This is an open and shut case – a failure of enforcement and compliance.” said Watson.
“Possibly, Watson. However, the truth is not to be found here in the PMO. It lies elsewhere, in the hallowed heights of the executive floor… Anyway there is a more immediate matter that needs our attention: it is late and the sun sinks rapidly. We must make our way to that fine establishment I noticed at the end of the street – I could do with a pint or three.”
“Well said, Holmes!”
The two made their way towards the exit.
———
“Come, friend Watson, the curtain rings up for the last act,” murmured Holmes, as the two of them entered the elevator. They had come to the head office to meet the executive director.
The two found their way to the meeting room on the executive floor and entered.
“Hello Holmes, it is good to see you again,” boomed the executive director, “and I see you have brought Dr. Watson with you. Good to see you too, sir. Do come in and meet my management team.”.
After the mandatory round of introductions and business card exchanges, the director continued,”I take it you have something for us, Holmes.”
“Yes sir, I have a number of questions.“
“Questions? I don’t understand, Holmes. We hired you to find us some answers about the failure of our PMO, and you tell me have a few questions. I take it you have some answers too. The CIO expects answers not questions,” he said with a nervous chuckle.
“No,I have no answers…but a hypothesis that I hope to validate soon.”
“I do not understand the need for this drama,” said the director.
“Watson here will tell you that I can never resist a touch of the dramatic.”
“OK, Holmes, you had better get to it then,” said the director shortly.
“I’ll get right to it sir,” he said, and turned to face the seated managers. “Ladies and gentlemen, pray what was the objective of your PMO?”
There was a stunned silence. Finally, one of the managers spoke up, “Surely that is obvious Mr, Holmes.”
“Thank you. I do realise my question may seem a little simple minded to you, but I beg that you answer it in a way that you would to someone who knows nothing about PMOs.” He turned to the executive director for confirmation.
“Yes, yes, answer his question,” said the executive director impatiently.
“OK, if you insist. The basic objective of the PMO can be summarised in a line. It was to ensure that all our strategic projects are delivered on time, within the agreed budget and to the required standards of quality. Needless to say, the PMO failed to deliver: as I recall, out of the 12 strategic projects we have, 8 or 9 are in serious trouble – over budget and/or time by more than 50%,” said the manager. “That is all the relevant detail… I trust it is not too much for you, Mr Holmes,” he added.
“”I am glad of all details, whether they seem to you to be relevant or not,” retorted Holmes. Then, in a gentler tone, he asked, “How exactly was the PMO expected to achieve these objectives?”
The managers looked at each other, nonplussed at the question.
Finally, one of them asked, “Mr. Holmes, what do you mean by “how”? I do not understand your question…and I think I speak for my colleagues too. We followed the advice of Lord Gartner and Baron McKinsey in setting up our PMO. Among many other things, we are fully aware of the importance of giving a PMO complete authority to oversee and control IT projects across the organisation. I am sure you are aware that our PMO had implemented a set of proven best practice project and portfolio management standards to ensure control and oversight.”
“Yes, we have seen the process charts…they are impressive indeed,” piped up Watson. Holmes gave him The Look.
“That is so, and the fact that some projects have succeeded shows that the processes do work,” said another manager.
“My dear sir, results without causes are impressive but assuming a causal link between them, sans proof, is not,” said Holmes. “Let me ask you a simple question, sir. Would you say your organisation is unique – one of a kind?”
“Of course it is,” said the manager. “We have just been voted a ‘best employer’ and we won several industry awards in previous years. Indeed we are unique.”
“…and yet you implement standardised processes?”
“What is your point, Mr. Holmes?”
“Let me spell it out: your organisation is unique, as are your people. Right?”
“Yes,” said the manager. Others around the room were nodding their assent.
“In view of your uniqueness, don’t you think you ought to develop – rather evolve – your own unique processes in collaboration with your project managers rather than impose one-size-fits-all “best practice” standards on them?”
“But…why should we do that…and how ?” Asked the executive director.
“Sir, I’ve already answered the “why.” I will leave the “how” for you and your team to figure out. Whatever else you do, I cannot overemphasise the importance of including your frontline managers and employees in the discussions about how your PMO should function, and also in selecting and designing appropriate processes.”
“I see…,” said the director thoughtfully.
“Sir, your PMO failed because it attempted to transplant practices that allegedly worked elsewhere into your unique –dare I say, special – organisation. As was inevitable, the transplant was roundly rejected: your people found the processes strange, even arbitrary, and resented them. Consequently, they found ways to work around them instead of with them. Failure of your PMO was preordained because of your focus on processes rather than intentions.
The executive director nodded thoughtfully, as the penny dropped. “Thank you Holmes,” he said, “I see your point….finally.”
“Thank you sir…and thank you all,” said Holmes nodding at each of the seated managers in turn. “There is much work for you all to do now, so Dr. Watson and I will show ourselves out.”
The two gathered their papers and left, shutting the door behind them gently.
“Never underestimate the power of a question to illuminate the truth,” said Holmes sententiously as he and Watson entered the elevator.
Watson rolled his eyes; his friend was brilliant, but he could also be a pompous ass.
——–
Acknowledgements:
Thanks to Arati Apte and Paul Culmsee for encouragement and feedback on earlier drafts of this story.
Notes:
- Spot the quote (for Sherlock Holmes trainspotters): there are eight quotes from various Sherlock Holmes adventures in this post; most are verbatim, but a couple of the longer ones have been adapted to fit the narrative.
- If you enjoyed this piece, you might want to have a look at the other business fables on this blog.

