Eight to Late

Sensemaking and Analytics for Organizations

Archive for the ‘Best Practice’ Category

A visit from the methodology police – a PMO satire

with 15 comments

They came for me at 11:00 am.

I  was just settling down to finishing that damned business case when I heard the rat-a-tat-tat on my office door. “Come in,” I said, with a touch of irritation in my voice.

The door opened and there they were. They looked at me as though I was something that had crawled out from under a rock. “Mr. Hersey, I presume,” said the taller, uglier one.

“Yes, that’s me.”

“Joe  Hersey?” He asked, wanting to make sure before unloading on me.

“Yes, the one and only,” I said, forcing a smile. I had a deep sense of foreboding now: they looked like trouble;  I knew they couldn’t be enquiring after my welfare.

“You need to come with us,” said the shorter one. I did imply he was handsomer of the two, but I should clarify that it was a rather close call.

“I have better things to do than follow impolite summons from people I don’t know. I think you should talk to my manager. In fact, I will take you to him,” I replied, rising from my chair. “He won’t be happy that you’ve interrupted my business case. He wants it done by lunchtime,” I added, a tad smugly.

“We’ve already seen him. He knows. I would advise you to come with us. It would make life easier for everyone concerned,”  I forget which one of the two said this.

“What is going on?” I asked, toning down my irritation. To be honest, I had no clue what they were on about.

“We’re the methodology police,” they said in unison. I guess they’d had a fair bit of practice scaring the crap out of hapless project managers. “We’re from the PMO,” they added unnecessarily – I mean, where else could they be from.

“Holy s**t,” I said to myself. I was in big trouble.

“Well, Hersey,” said the short one, “I think you owe the PMO an explanation.” Ah, I loved his use of the third person– not “us” but “the PMO.”

We were seated at a table in a meeting room deep in the bowels of the PMO: windowless, with low wattage lighting sponsored by one of those new-fangled, energy-saving, greenie bulbs . The three chairs were arranged in interrogation mode , with the two goons on one side and me – Joseph M. Hersey, Project Manager Extraordinaire – on the other.

I was in trouble alright, but I have this perverse streak in me, “I don’t know what you are talking about,” I said, feeling a bit like a hero from a Raymond Chandler novel. I knew what I had done, of course. But I also knew that I was one of the good guys. The clowns sitting opposite me were the forces of evil…such thoughts, though perverse, lifted my spirits.

I must have smiled because the tall one said, “You think this is funny, do you? We have a direct line to the board and we could make life really unpleasant for you if you continue this uncooperative attitude.”

That was bad. I did not want to be hauled up in front of the big cheese. If I was branded a troublemaker at that level, there would be no future for me in the company. And to be absolutely honest, I actually enjoyed working here – visits from the methodology police excepted, of course.

“OK, tell me what you want to know,” I said resignedly.

“No, you tell us, Hersey. We want to hear the whole story of your subversion of process in your own words. We’ll stop you if we need any clarification.” Again, I forget which one of the two said this. Understandable, I think – I was pretty stressed by then.

Anyway, there is no sense in boring you with all the PMO  and process stuff. Suffice to say, I told them how I partitioned my big project into five little ones, so that each mini project would fall below the threshold criteria for major projects and thus be exempt from following the excruciating methodology that our PMO had instituted.

Process thus subverted, I  ran each of the mini projects separately, with deliverables from one feeding into the next. I’d got away with it; with no onerous  procedures to follow I was free to devise my own methodology, involving nothing more complicated than a spreadsheet updated daily following informal conversations with team members and stakeholders. All this held together – and, sorry, this is going to sound corny – by trust.

The methodology cops’ ears perked up when they heard that word, “Trust!” they exclaimed, “What do you mean by trust?”

“That’s when you believe people will do as they say they will,” I said. Then added, “A concept that may be foreign to you.” I regretted that snide aside as soon as I said it.

“Look, “ said the uglier guy, “I suggest you save the wisecracks for an audience that may appreciate them. “You are beginning to annoy me and a report to the board is looking like a distinct possibility if you continue in this vein.”

I have to say, if this guy had a lot of patience if he was only just “beginning to get annoyed.” I was aware that I had been baiting him for a while. Yes, I do know when I do that. My wife keeps telling me it will get me into trouble one day. May be today’s the day.

“…I do know what trust is,” the man continued, “but I also know that you cannot run a project on warm and fuzzy notions such as trust, sincerity, commitment etc. The only thing I will trust are written signed off project documents.”

Ah, the folly, the folly. “Tell me this, what would you prefer – project documentation as per the requirements of your methodology or a successful project.”

“The two are not mutually exclusive. In fact, methodology improves the chance of success.”

“No it doesn’t,” I retorted.

“It does,” he lobbed back.

Jeez, this was beginning to sound like recess in the local kindergarten. “Prove it,” I said, staking my claim to the title of King of Kindergarten Debates.

“There are several studies that prove the methodologies efficacy,” said the short one, “but that is not the point.”

“All those studies are sponsored by the Institute,” I said, referring to the August Body that maintains the standard. “so there is a small matter of vested interest….anyway, you say that isn’t the point. So what is your point then?.”

“The methodology is an internal requirement, so you have to follow It regardless. We could have a lot of fun debating it, but that is neither here no there. Compliance is mandatory, you have no choice.”

“I did comply,” I said, “none of my projects were over the threshold, so I did not need to follow the methodology.”

“That was subterfuge – it was one project that you deliberately divided into five so that you could bypass our processes.”

I was getting tired and it was close to my lunchtime. “OK, fair point“ I said, “I should not have done that. I will not do it again. Can I go now?”

“Hmm,” they said in unison.  I don’t think either of them believed me. “That’s not good enough.”

I sighed. “What do you want  then?” I asked, weary of this pointless drama.

“You will read and sign this form,” said the short one, “declaring you have been trained in the PMO processes – which you were last year, as you well know – and that you will follow the processes henceforth. I particularly urge you to read and digest the bit about the consequences of non-compliance.” He flicked the form in my direction.

I was not surprised to see that the form  was a multi-page affair, written in 8pt bureaucratese, utterly incomprehensible to mere mortals such as I. I knew I would continue to bypass or subvert processes that made no sense to me, but I also knew that they needed me to sign that form – their boss would be very unhappy with them if I didn’t.  Besides, I didn’t want to stay in that room a second longer than necessary.

“OK, where do I sign,” I said, picking up a pen that lay on the table.

“Don’t you want to read it.”

“Nah,” I said, “I have a pretty fair idea of what it’s about.”

I signed.

“We’re done, Hersey. You can go back to your business case now. But you can be sure that you are on our radar now. We are watching you.”

“Well Gents, enjoy the show. I promise, to lead a faultless life henceforth. I will be a model project manager,” I said as I rose to leave.

“We’re counting on it Hersey.  One more violation and you are in deep trouble.”

I refrained from responding with a wisecrack as I exited, leaving them to the paperwork that is their raison d’etre.

On the evolution of corporate information infrastructures

leave a comment »


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 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.


Sections of this post are drawn from my article entitled, The ERP Paradox.

Written by K

April 3, 2013 at 7:07 pm

Sherlock Holmes and the case of the terminated PMO

with 12 comments

“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.



Thanks to Arati Apte and Paul Culmsee for encouragement and feedback on earlier drafts of this story.


  1. 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.
  2. If you enjoyed this piece, you might want to have a look  at the other business fables on this blog.

Written by K

March 19, 2013 at 8:01 pm

“Strategic alignment” – profundity or platitude?

with 6 comments


Some time ago I wrote a post entitled, Models and messes in management, wherein I discussed how a “scientific” approach to management has resulted in a one-size-fits-all  approach to problem solving in organizations.  This is reflected in the tendency of organisations to  implement similar information technology (IT) systems, often on the  “expert” advice of carbon-copy consultancies that offer commoditized solutions.

A particularly effective marketing tactic is to advertise such “solutions” as being able to help organisations achieve  strategic alignment between IT and the business.  In this post I discuss how the concept of “strategic alignment” though seemingly sensible, makes no sense in the messy, real world of organization-land. My discussion is based on a brilliant paper by Claudio Ciborra entitled, De Profundis? Deconstructing the concept of strategic alignment.  The paper analyses the notion of alignment as it is commonly understood in the context of  IT– namely as a process by which IT objectives are brought in line with those of the organization it serves.


The paper begins with a short chronology of the term strategic alignment, starting with this  highly cited paper  published by Henderson and Venkataraman  in 1993. The paper describes the need for alignment between business and IT strategies of companies.   More importantly, however, the authors detail a “Strategic Alignment Model” that purports to “guide management practice” towards achieving alignment between IT and the business. However, as Ciborra noted four years later, in 1997, it was still an open question as to what strategic alignment really meant and how it was to be achieved.

Fast forward 15 years to 2012, and it appears that the question of what strategic alignment is and how to achieve it still an open one. Here are some excerpts from recently published papers:

In the abstract to their paper entitled, Strategic Alignment of Business Processes, Morrison et. al. state:

Strategic alignment is a mechanism by which an organization can visualize the relationship between its business processes and strategies. It enables organizational decision makers to collect meaningful insights based on their current processes. Currently it is difficult to show the sustainability of an organization and to determine an optimal set of processes that are required for realizing strategies.” (italics mine)

Even worse, the question of what strategic alignment is is far from settled.  It appears that it means different things to different people. In the abstract to their paper entitled, Reconsidering the Dimensions of Business-IT Alignment, Schlosser et. al. state:

While the literature on business-IT alignment has become increasingly mature in the past 20 years, different definitions and conceptualizations have emerged. Several dimensions like strategic, intellectual, structural, social, and cultural alignment have been developed. However, no integrated and broadly accepted categorization exists and these dimensions are non-selective and do overlap…

This begs the question as to how meaningful it is for organizations to pursue “alignment” when people are still haggling over the fine print of what it means.

Ciborra dealt with this  very question 15 years ago. In the remainder of this post I summarize the central ideas of his paper,  which I think are as relevant today as the were at the time it was written.

Deconstructing  strategic alignment

The whole problem with the notion of strategic alignment is nicely summarized in a paragraph that appears in Ciborra’s introduction:

…while strategic alignment may be close to a truism conceptually, in the everyday business it is far from being implemented. Strategy ends up in “tinkering” and the IT infrastructure tends to “drift”. If alignment was supposed to be the ideal “bridge” connecting the two key variables [business and IT], it must be admitted that such a conceptual bridge faces the perils of the concrete bridge always re-designed and never built between continental Italy and Sicily, (actually, between Scylla and Charybdis) its main problem being the shores: shifting and torn by small and big earthquakes….

The question, then, is how and why do dubious concepts such as strategic alignment worm their way into mainstream management?

Ciborra places the blame for this squarely in the camp of academics who really ought to know better. As he states:

[Management Science] deploys careful empirical research, claiming to identify “naturally occurring phenomena” but in reality measures theoretical (and artificial) constructs so that the messiness of everyday reality gets virtually hidden. Or it builds models that should be basic but do not last a few years and quickly fall into oblivion.

And a few lines later:

…practitioners and academics increasingly worship simplified models that have a very short lifecycle….managers who have been exposed to such illusionary models, presented as the outcome of quasi-scientific studies, are left alone and disarmed in front of the intricacies of real business processes and behaviors, which in the meantime have become even more complicated than when these managers left for their courses. People’s existence, carefully left out of the models, waits for them at their workplaces.

Brilliantly put, I think!

Boxes, arrows and platitudes

Generally, strategic alignment is defined as a fit, or a bridge, between different domains of a business.  To be honest it seems the metaphor of a “bridge” seems to distract from reflecting on the chasm that is allegedly being crossed and the ever-shifting banks that lie on either side. Those who speak of alignment would do better to first focus on what they are trying to align. They may be surprised to find that the geometric models  that pervade their PowerPoint Presentations (e.g. organograms, boxes connected by arrows) are completely divorced from reality. Little surprise, then, that top-down, management efforts at achieving alignment invariably fail.

Why do such tragedies play out over and over again?

Once again, Ciborra offers some brilliant insights…

The messy world, he tells us, gives us the raw materials from which we build simplified representations of the organization we work in. These representations are often built in the image of models that we have learnt or read about (or have been spoon-fed to us by our expensive consultants). Unfortunately, these models are abstractions of reality – they cannot and must not be confused with the real thing.  So when we speak of alignment, we are talking of an abstraction that is not “out there in the world” but instead only resides in our heads; in textbooks and journal papers; and, of course, in business school curricula.

As he says,

…there is no pure alignment to be measured out there. It is, on the contrary, our pre-scientific understanding of and participating in the world of organizations that gives to the notion of alignment a shaky and ephemeral existence as an abstraction in our discourses and representations about the world.

This is equally true of management research programs on alignment: they are built on multiple abstractions and postulated causal connections that are simply not there.

If academics who spend their productive working lives elaborating these concepts make little headway, what hope is there for the manager who  to implement or measure strategic alignment?

Is there any hope?

Ciborra tells us that the answer to the question posed in the sub-heading is a qualified “yes”. One can pursue alignment, but one must first realize that the concept is an abstraction that exists only in an ideal world in which there are no surprises and in which things always go according to plan. Perhaps more importantly, they need to understand that implementations of technology invariably have significant unintended consequences that require improvised responses and adaptations. Moreover, these are essential aspects of the process of alignment, not things that can be wished away by better plans or improved monitoring.

So what can one do? As Ciborra states:

…we are confronted with a choice. Either we can do what management science suggests, that is “to realize these surprises in implementation as exceptions, build an ideal world of “how things should be” and to try to operate so that the messy world that in which managers operate moves towards this model….or we suspend  belief about what we think we know…and reflect on what we observe. Sticking to the latter we encounter phenomena that deeply enrich our notion of alignment… (italics mine)

Ciborra then goes on to elaborate on concepts of Care (dealing with the world as it is, but in a manner that is honest and free of preconceived notions), Cultivation (allowing systems to evolve in a way that is responsive to the needs of the organization rather than a predetermined plan) and Hospitality (the notion that the organization hosts the technology, much in the way that a host hosts a guest). It would take at least a thousand words more to elaborate on these concepts, so I’ll have to leave it here. However, if you are interested in finding out more, please see my summary and review of Ciborra’s book: The Labyrinths of Information.

…and finally, who aligns whom?

The above considerations lead us to the conclusion that, despite our best efforts, technology infrastructures tend to have lives of their own – they align us as much as we (attempt to) align them.  IT infrastructures are deeply entwined with the organizations that host them, so much so that they are invisible (until they breakdown, of course) and  even have human advocates who “protect” their (i.e. the infrastructure’s) interests! Although this point may seem surprising to business folks, it is probably familiar to those who work with information systems in corporate or other organizational environments.

A final word:  many other management buzz-phrases, though impressive sounding, are just as meaningless as the term strategic alignment.  However, I think I have rambled on enough, so I will leave you here to find and deconstruct some of these on your own.

Written by K

February 21, 2013 at 9:43 pm

Some perspectives on quality

with 7 comments


A couple of years ago, I wrote a post entitled, A project manager’s ruminations on quality, in which I discussed meaning of the term quality as it pertains to project work. In that article I focused on how the standard project management definition of quality differs from the usual (dictionary) meaning of the term. Below, I expand on that post by presenting some alternate perspectives on quality.

Quality in mainstream project management

Let’s begin with a couple of  dictionary definitions of quality to see how useful they are from a project management perspective:

  1. An essential or distinctive characteristic, property, or attribute.
  2. High grade; superiority; excellence

Clearly, these aren’t much help because they don’t tell us how to measure quality. Moreover, the second definition confuses quality and grade – two terms that the PMBOK assures us are as different as chalk and cheese.

So what is a good definition of quality from the perspective of a project manager? The PMBOK, quoting from the American Society for Quality (ASQ), defines quality as, “the degree to which a set of inherent characteristics fulfil requirements.”  This is clearly a much more practical definition for a project manager, as it links the notion of quality to what the end-user expects from deliverables. PRINCE2, similarly, keeps the end-user firmly in focus when it defines quality, rather informally, as, fitness for purpose.”

Project managers steeped in PRINCE and other methodologies would probably find the above unexceptional. The end-goal in project management is to deliver what’s agreed to, whilst working within the imposed constraints of resources and time.  It is therefore no surprise that the definition of quality focuses on the characteristics of the deliverables, as they are specified in the project requirements.

Quality as an essential characteristic

The foregoing project management definitions beg the question:

Is “fitness of purpose” or the “degree to which product characteristics fulfils requirements” really a measure of quality?

The problem with these definitions is that they conflate quality with fulfilling requirements. But surely there is more to it than that. An easy way to see this is that one can have a high quality product that does not satisfy user requirements or meet cost and schedule targets. For example, many  people would agree that WordPress blogging software is of a high quality, yet it does not meet the requirement of, say, “a tool to manage projects.”

Indeed, Robert Glass states this plainly in his book, Facts and Fallacies of Software Engineering. Fact 47 in the book goes as follows:

Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets or reliability.

So what is quality, then?

According to Glass quality is a set of (product) attributes, including things such as:

  1. Reliability – does the product work as it should?
  2. Useability – is it easy to use?
  3. Modifiability – can it be modified (maintained) easily?
  4. Understandability – is it easy to understand how it works?
  5. Efficiency – does it make efficient use of resources (including storage, computing power and time)?
  6. Testability – can it be tested easily?
  7. Portability – can it be ported to other platforms?  This isn’t an issue for all products – some programs need run only on one operating system.

Note that the above listing is not in order of importance. For some products useability maybe more important than efficiency, in others it could be the opposite – the order depends very much on the product and its applications.

Glass notes that these attributes are highly technical. Consequently, they are best dealt with by people who are directly involved in creating the product, not their managers, not even the customers. In this view, the responsibility for quality lies not with project managers, but with those who do the work. To quote from the book:

…quality is one of the most deeply technical issues in the software field. Management’s job, far from taking responsibility for achieving quality, is to facilitate and enable technical people and the get out of their way.

Another point to note is that the above characteristics are indeed measurable (if only in a qualitative sense), which addresses the objection I noted at in the previous section.

Quality as a means to an end

In our book, The Heretic’s Guide to Best Practices, Paul Culmsee and I discuss a couple of perspectives on quality which I summarise in this and the following section.

Our first contention is that quality cannot be an end in itself.  This is a subtle point so I’ll illustrate with an example. Consider the two  “ends-focused” definitions of quality mentioned earlier: quality as “fitness for purpose” and quality as a set of objective attributes. Chances are that different project  stakeholders will have differing views on which definition is “right”. The problem, as we have seen in the earlier sections, is that the two definitions are not the same.  Hence quality cannot be an end in itself.

Instead, we believe that a better definition comes from asking the question: “What difference would quality make to this project?” The answer determines an appropriate definition of quality for a particular project.  Implicit here is the notion of quality as an enabler to achieve the desired project objective. In other words, quality here is a means to an end, not an end in itself.

Quality and time

Typically, project deliverables – be they software or buildings or anything else – have lifetimes that are much longer than the duration of the project itself. There are a couple of important implications of this:

  1. Deliverables may be used in ways that were not considered when the project was implemented.
  2. They may have side effects that were not foreseen.

Rarely, if ever, do project teams worry about the long term consequences of their creations.  Their time horizons are limited to the duration of their projects. This myopic view is perpetuated by the so called iron triangle which tells us that quality is a function of cost, scope and time (i.e. duration) of a project.

The best way to see the short-sightedness of this view is through an example.  Consider the Sydney Opera House as an example of a project output. As we state in our book:

It is a global icon and there are people who come to Sydney just to see it. In term of economic significance to Sydney, it is priceless andi rreplaceable. The architect who designed it, Jørn Utzon, was awarded the Pritzker Prize (architecture’s highest honour) for it in 2003.

But the million dollar question is . . . “Was it a successful project?” If one was to ask one of the two million annual tourists who visit the place, we suspect that the answer would be an emphatic “Yes.” Yet, when we judge the project through the lens of the “iron triangle,” the view changes significantly. To understand why, consider these fun filled facts about the Sydney Opera House.

  • The Opera House was formally completed in 1973, having cost $102 million
  • The original cost estimate in 1957 was $7 million
  • The original completion date set by the government was 1963
  • Thus, the project was completed ten years late and over-budget by more than a factor of fourteen

If that wasn’t bad enough, Utzon, the designer of the opera house, never lived to set foot in it. He left Australia in disgust, swearing never to come back after his abilities had been called into question and payments suspended. When the Opera House was opened in 1973 by Queen Elizabeth II, Utzon was not invited to the ceremony, nor was his name mentioned…

Judged by the criteria of the iron triangle, the project was an abject failure. However, judged by through the lens of time, the project is an epic success! Quality must therefore also be viewed in terms of the legacy that the project leaves – how the deliverables will be viewed by future generations and what it will mean to them.

Wrapping up

As we have seen, the issue of quality is a vexed one because how one understands it  depends on which school of thought one subscribes to. We have seen that quality can refer to one of the following:

  1. The “fitness for purpose” of a product or its ability to “meet requirements.” (Source: PRINCE2 and PMBOK)
  2. An essential attribute of a product. This is based on the standard, dictionary definition of the term.
  3. A means of achieving a particular end.  Here quality is viewed as a  process rather than a project output.

Moreover, none of the above perspectives considers the  legacy bequeathed by a project;  how the deliverables will perceived by future  generations.

So where does that leave us?

Perhaps it is  best to leave definitions of quality to pedants, for as someone wise once said, “What is good and what is not good, need we have anyone tell us these things?”

Written by K

December 13, 2012 at 2:35 am

The cloud and the grass – a business fable

with 8 comments

Once upon a time there was an expansive lawn that was of the lushest shade of green you can possibly imagine. It was so because it was tended by gardeners who took pride in the health and appearance of their lawn: they mowed it when it needed mowing and watered it when it needed watering. Moreover, they did so because they loved their work and got immense satisfaction out of seeing the beautiful results of their handiwork.

So spectacular was the lawn that people would come from far and wide to admire the green expanse – children would frolic on it  while their parents watched indulgently as they munched their way through the huge hampers they brought to picnic on. The children would tire themselves out playing while their elders did the same eating. They would all then lay themselves out on the velvety verdant-ness and drift away into dreamland, aided by the perfect afternoon sunshine.

As they drifted away into sweet slumber, many of them would think, “If there is a paradise, this must be pretty darn close to it…”

One day the owners of the lawn, the folks who paid the gardeners a not insubstantial sum per month were looking at their monthly accounts. They realized that their financial standing was not as healthy as it was prior to the GFC (Yes alas, even owners of paradise have been affected by the mess caused by the erstwhile Masters of the Universe). Their financial advisers suggested that they outsource the tending of the lawn to professionals who were experts at that  sort of thing.

“Don’t worry about a thing,” said the Adviser in Chief, “We know some consultants who are experts at this sort of thing.”

The Adviser-in-Chief was as good as his word – the next day, the owners got a visit from a guy in a suit who, for reasons of privacy, we shall call The Consultant.

The Consultant told the owners  not to worry, he had just the solution to their problem. “Forget these expensive and slow gardeners,” he said, “what you need is The Cloud.”

Now anyone who is anyone at all has heard of The Cloud  – and so had the owners. “The Cloud!” they exclaimed, “Yes, we have heard of The Cloud, but pray, tell us: how will it solve our problem?”

“It’s simple,” said the The Consultant, “The Cloud will water the lawn and thus tend to its wellbeing. You don’t need gardeners, The Cloud will look after your investment. But what’s really interesting for you is that The Cloud will cost you a fraction of what the gardeners cost.” Then, pulling out a slickly produced dossier, he continued, “Here’s an analysis done by an Independent Analyst.”

(As a pointless aside we note that the Independent Consultant’s name happened to rhyme with word “Gardener”).

The owners read the analysis and were duly impressed. They decided that this Cloud business was a great idea. It  would help them cut costs and maintain (hey, even improve!) the quality of their lawn. It sounded like a winning proposition.

There was a downsize though (editor’s note: I think he means downside):

The owners soon realized they would have to let the gardeners go. This would not be easy as the gardeners had been in their employ for many years. However, the owners prided themselves on being pragmatists – they had, after all, overseen a successful venture for many years. Now, to maintain it, they would have to change with the times. This was, after all, The Age of The Cloud.

Many Difficult Conversations ensued and eventually the gardeners were shown the gate (paradise has no doors, I’m told, but it does have a gate…of a somewhat pearly appearance.)

The Cloud thus took over the tending of the lawn. And as they say, all was well in paradise: the lawns were regularly watered and the grass grew…

…and it grew, and it grew. It grew to such an extent that visitors no longer found the lush greenness as welcoming. From kids perspective, it hard to frolic in grass that’s to tall and from a grown-up’s view, it is impossible to picnic in.

The owners complained to The Consultant. The Consultant brought along a legal expert who knew all about the services the owners had bought and (more importantly) those they had not. The expert affirmed that the package the owners had bought did not include any mowing services…only watering was included. The owners had not read the fine print.

(One can’t blame them – tell me, is it easy to read last two words of the previous line.)

Understandably, many acrimonious arguments ensued – words were said that shouldn’t have been said, things were thrown that shouldn’t have been thrown (although, at people who ought to have a few things thrown at them).

The owners thought about the good old days when the lawn was being looked after by people who had a stake in it, and who cared about it. The Cloud was an entity that was everywhere and nowhere at the same time. Why would it care for a piddly patch of green?

The owners realized that the survival of the lawn was at stake. If they wanted the lawn to return to it original state of perfection, they would have to swallow their pride and admit they had made a mistake.

The question was: would they?

…and there I have to leave the story because I know not what they did.

There is a moral to this tale, however, and it is that clouds don’t give a damn about grass.

Written by K

November 5, 2012 at 9:30 pm

A consulting tragedy in five limericks

with 5 comments

The consultant said, “be assured,
my motives are totally pure.
I guarantee
my inflated fee
is well worth my ‘best practice’ cure.”

Although it was too much to pay,
this argument carried the day:
consultants hired
can always be fired
and assigned much of the blame.

After the contract was signed,
only then did the client find
the solution bought
would definitely not
help leave their troubles behind.

Cos’ the truth was plain to see,
the ‘best practice’ methodology
had only led
to the overhead
of a ponderous bureacracy.

The shock, the horror, the pain-
all that money and effort in vain,
but the tragedy
is the powers that be
would do it all over again.

Written by K

September 1, 2012 at 10:02 pm

%d bloggers like this: