Archive for the ‘Corporate IT’ Category
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…
Routines and reality – on the gap between the design and use of enterprise systems
Introduction
Enterprise IT systems that are built or customised according to specifications sometimes fail because of lack of adoption by end-users. Typically this is treated as a problem of managing change, and is dealt with in the standard way: by involving key stakeholders in system design, keeping them informed of progress, generating and maintaining enthusiasm for the new system and, most important, spending enough time and effort in comprehensive training programmes.
Yet these efforts are sometimes in vain and the question, quite naturally, is: “Why?” In this post I offer an answer, drawing on a paper by Brian Pentland and Martha Feldman entitled, Designing Routines: On the Folly of Designing Artifacts While Hoping for Patterns of Action.
Setting the context
From a functional point of view, enterprise software embodies organisational routines – i.e. sequences of actions that have well-defined objectives, and are typically performed by business users in specific contexts. Pentland and Feldman argue that although enterprise IT systems tend to treat organisational routines as well defined processes (i.e. as objects), it is far from obvious that they are so. Indeed, the failure of business process “design” or “redesign” initiatives can often be traced back to a fundamental misunderstanding of what organisational routines are. This is a point that many system architects, designers and even managers / executives would do well to understand.
As Pentland and Feldman state:
… the frequent disconnect between [system or design] goals and results arises, at least in part, because people design artifacts when they want patterns of action…we believe that designing things while hoping for patterns of action is a mistake. The problem begins with a failure to understand the nature of organizational routines, which are the foundation of any work process that involves coordination among multiple actors… even today, organizational routines are widely misunderstood as rigid, mundane, mindless, and explicitly stored somewhere. With these mistaken assumptions as a starting point, designing new work routines would seem to be a simple matter of creating new checklists, rules, procedures, and software. Once in place, these material artifacts will determine patterns of action: software will be used, checklists will get checked, and rules will be followed.
The fundamental misunderstanding is that design artifacts, checklists, and rules and procedures encoded in software are mistaken for the routine instead of being seen for what they are: idealised representations of the routine. Many software projects fail because designers do not understand this. The authors describe a case study that highlights this point and then draw some general inferences from it. I describe the case study in the next section and then look into what can be learnt from it.
The situation
The case study deals with a packaged software implementation at a university. The university had two outreach programs that were quite similar, but were administered independently by two different departments using separate IT systems. Changes in the university IT infrastructure meant that one of the departments would lose the mainframe that hosted their system.
An evaluation was performed, and the general consensus was that it would be best for the department losing the mainframe to start using the system that the other department was using. However, this was not feasible because the system used by the other department was licensed only for a single user. It was therefore decided to upgrade to a groupware version of the product. Since the proposed system was intended to integrate the outreach-related work of the two departments, this also presented an opportunity to integrate some of the work processes of the two departments.
A project team was set-up, drawing on expertise from both departments. Requirements were gathered and a design was prepared based on the requirements. The system was customised and tested as per the design, and data from the two departments was imported from the old systems into the new one. Further, the project team knew the importance of support and training: additional support was organised as were training sessions for all users.
But just as everything seemed set to go, things started to unravel. In the author’s words:
As the launch date grew nearer, obstacles emerged. The implementation met resistance and stalled. After dragging their feet for weeks, [the department losing the mainframe] eventually moved their data from the mainframe to a stand-alone PC and avoided [the new system] entirely. The [other department] eventually moved over [to the new system], but used only a subset of the features. Neither group utilized any of the functionality for accounting or reporting, relying instead on their familiar routines (using standalone spreadsheets) for these parts of the work. The carefully designed vision of unified accounting and reporting did not materialize.
People in the department that was losing the mainframe worked around the new system by migrating their data to a standalone PC and using that to run their own system. People in the other department did migrate to the new system, but used only a small subset of its features.
All things considered, the project was a failure.
So what went wrong?
The authors emphasise that the software was more than capable of meeting the needs of both departments, so technical or even functional failure can be ruled out as a reason for non-adoption. On speaking with users, they found that the main objections to the system had to with the work patterns that were imposed by it. Specifically, people objected to having to give up control over their work practices and their identities (as members of specific) departments. There was a yawning gap between the technical design of the system and the work processes as they were understood and carried out by people in the two departments.
The important thing to note here is that people found ways to work around the system despite the fact that the system actually worked as per the requirements. The system failed despite being a technical success. This is a point that those who subscribe to the mainstream school of enterprise system design and architecture would do well to take note of.
Dead and live routines
The authors go further: to understand resistance to change, they invoke the notion of dead and live routines. Dead routines are those that have been represented in technical artifacts such as documentation, flowcharts, software etc. whereas live routines are those that are actually executed by people. The point is, live routines are literally living objects – they evolve in idiosyncratic ways because people inevitably tweak them, sometimes even without being conscious that they are making changes. As a consequence live routines often generate new patterns of action.
The crux of the problem is that software is capable of representing dead routines, not live ones.
Complementary aspects of routines
Routines are composed of people’s understandings of the routines (the authors call this the ostensive aspect) and the way in which they are actually performed or carried out (the authors call this the performative aspect). The two aspects, the routine as understood and the routine as performed, complement each other: new actions will modify one’s understanding of a routine, and the new understanding in turn modifies future actions.
Now, the interesting thing is that no artifact can represent all aspects of a routine – something is always left out. Even though certain artifacts such as written procedures may be intended to change both the ostensive and performative aspects of a routine (as they usually are), there is no guarantee that they will actually influence behaviour. Managers who encounter resistance to change will have had first-hand experience of this: it is near impossible to force change upon a group that does not want it.
This leads us to another set of complementary aspects of routines. On the one hand, technology puts in place structures that enable certain actions while constraining others – this is the standard technological or material view of processes as represented in systems. In contrast, according to the social or agency view, people are free to use technology in whatever way they like and sometimes even not use it at all. In the case study, the former view was the one that designers took whereas users focused on the latter one.
The main point to take away from the foregoing discussion is that designers/ engineers and users often have very different perspectives on processes. Software that is based on a designer/engineer perspective alone will invariably end up causing problems for end users.
Routines and reality
Traditional systems design proceeds according to the following steps:
- Gather requirements
- Analyse and encode them in rules
- Implement rules in a software system
- Provide people with incentives and training to follow the rules
- Rollout the system
Those responsible for the implementation of the system described in the case study followed the steps faithfully, yet the system failed because one department didn’t use it at all and the other used it selectively. The foregoing discussion tells us that the problem arises from confusing artifacts with actions, or as I like to put it, routines with reality.
As the authors write:
This failure to understand the difference between artifacts and actions is not new…the failure to distinguish the social (or human) from the technical is a “category mistake.” Mistakenly treating people like machines (rule-following automata) results in a wide range of undesirable, but not entirely surprising, outcomes. This category difference has been amply demonstrated for individuals, but it applies equally (if not more so) to organizational routines. This is because members’ embodied and cognitive understandings are often diverse, multiple, and conflicting.
The failure to understand the difference between routines and reality is not new, but it appears that the message is yet to get through: organisations continue to implement (new routines via) enterprise systems without putting in the effort to understand ground-level reality.
Some tips for designers
The problem of reconciling user and designer perspectives is not an easy one. Nevertheless, the authors describe an approach that may prove useful to some. The first concept is that of a narrative network – a collection of functional events that are related by the sequence in which they occur. A functional event is one in which two actants (or objects that participate in a routine) are linked by an action. The actants here could be human or non-human and the action represents a step in the process. Examples of functional events would be:
- The sales rep calls on the customer.
- The customer orders a product.
- The product is shipped to the customer.
The important thing to note is that the functional event does not specify how the process is carried out – that can be done in a myriad different ways. For example, the sales rep may meet the customer face-to-face or she may just make a phone call. The event only specifies the basic intent of the action, not the detail of how it is to be carried out. This leaves open the possibility for improvisation if the situation calls for it. More importantly it places the responsibility for making that decision on the person responsible for the carrying out the action (in the case of a human actant).
Then it is useful to classify a functional event based on the type of actants participating in the event – human or (non-human) artifact. There are four possibilities as shown in Figure 1.
Figure 1: Human-artifact grid
The interesting thing to note is that from the perspective of system design, an artifact-artifact event is one over which the designer has the strongest control (actions involving only artifacts can be automated) whereas a designer’s influence is the weakest in human-human events (humans rarely, if ever, do exactly as they are told!). Decomposing a routine in this way can thus serve to focus designer efforts in areas where they are likely to pay off and, more importantly, help them understand where they are likely to get some push back.
Finally, there are some general points to consider when designing a system. These include:
- Reinforce the patterns of the routine: Much as practise makes an orchestra perform better, organisations have to invest in practicing the routines. Practice connects the abstract routine to the performed one.
- Consider every stakeholder group’s point of view: This is a point I have elaborated at length in my posts on dialogue mapping so I’ll say no more about it here.
- Understand the relationship between abstract patterns and actual performances: This involves understanding whether there are different ways to achieve the same goal. Also consider whether it is important to enforce a specific set of actions leading up to the goal, or whether the actions matter less than the goal.
- Encourage people to follow patterns of action that are important: This involves creating incentives to encourage people to carry out certain important actions in specified ways. It is not enough to design and implement a particular pattern within a routine. One has to make it worthwhile for people to follow it.
- Make it possible for users to become designers: Most routines involve decisions points where actors have to choose between alternate, but fixed, courses of action. At such points human actors have little room to improvise. Instead, it may be more fruitful to replace decision points with design points, where actors improvise their actions.
- Lock in actions that matter: Notwithstanding the previous point, there are certain actions that absolutely must be executed as designed. It is as important to ensure that these are executed as they should be as it is to allow people to improvise in other situations.
- Keepan open mind and invite engagement: Perhaps the most important point is to continually engage with people who work the routine and to be open to their input as to what’s working and what isn’t.
Most of the above points are not new; I’d even go so far as to say they are obvious. Nevertheless they are worth restating because they are often unheeded.
Conclusion
A paradox of enterprise systems is that they can fail even if built according to specification. When this happens it is usually because designers fail to appreciate the flexibility of the business process(es) in question. As the authors state, “…even today, organizational routines are widely misunderstood as rigid, mundane, mindless, and explicitly stored somewhere.” This is particularly true for processes that involve humans. As the authors put it, when automating processes that involve humans it is a mistake to design software artefacts while hoping for (fixed) patterns of action. The tragedy is that this is exactly how enterprise systems are often designed.
Eight to Late 