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.

1. System development lifecycle.
2. 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:

1. Inception
2. Requirements gathering  / analysis
3. Specification
4. Design
5. Programming
6. Testing
7. Training
8. 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:

1. 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.
2. 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.
3. 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:

1. 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.
2. Position in organisation: in a corporate environment, business users generally outrank technical staff.
3. Affiliations: users and developers belong to different organisational units and therefore have differing loyalties.
4. 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…

The consultant’s dilemma – a business fable

It felt like a homecoming. That characteristic university smell  (books,  spearmint gum and a hint of cologne) permeated the hallway. It brought back memories of his student days: the cut and thrust of classroom debates, all-nighters before exams and near-all-nighters at Harry’s Bar on the weekends. He was amazed at how evocative that smell was.

Rich checked the directory near the noticeboard and found that the prof was still  in the same shoe-box office that he was ten years ago. He headed down the hallway wondering why the best teachers seemed to get the least desirable offices. Perhaps it was inevitable in a university system that rated grantsmanship over teaching.

It was good of the prof to see him at short notice. He had taken a chance really, calling on impulse because he had a few hours to kill before his flight home. There was too much travel in this job, but he couldn’t complain: he knew what he was getting into when he signed up.  No, his problem was deeper. He no longer believed in what he did. The advice he gave and the impressive, highly polished reports  he wrote for clients were useless…no, worse, they were dangerous.

He knew he was at a crossroad. Maybe, just maybe, the prof would be able to point him in the right direction.

Nevertheless, he was assailed by doubt as he approached the prof’s office. He didn’t have any right to burden the prof with his problems …he could still call and make an excuse for not showing up. Should he leave?

He shook his head. No, now that he was here he might as well at least say hello. He knocked on the door.

“Come in,” said the familiar voice.

He went in.

“Ah, Rich, it is good to see you after all these years. You’re looking well,” said the prof, getting up and shaking his hand warmly.

After a brief exchange of pleasantries, he asked Rich to take a seat.

“Just give me a minute, I’m down to the last paper in this pile,” said the prof, gesturing at a heap of term papers in front of him. “If I don’t do it now, I never will.”

“Take your time prof,” said Rich, as he sat down.

Rich cast his eye over the bookshelf behind the prof’s desk.  The titles on the shelf reflected the prof’s main interest: twentieth century philosophy. A title by  Habermas caught his eye.

Habermas!

Rich recalled a class in which the prof had talked about Habermas’ work on communicative rationality and its utility in making sense of ambiguous issues in management. It was in that lecture that the prof had introduced them to the evocative term that captured ambiguity in management (and other fields) so well, wicked problems.

There were many things the prof spoke of, but ambiguity and uncertainty were his overarching themes.  His lectures stood in stark contrast to those of his more illustrious peers: the prof dealt with reality in all its messiness, the other guys lived in a fantasy  world in which their neat models worked and  things went according to plan.

Rich had learnt  from the prof that philosophy was not an arcane subject, but one that held important lessons for everyone (including hotshot managers!). Much of what he learnt in that single term of philosophy had stayed with him. Indeed, it was what had brought him back to the prof’s door after all these years.

“All done,” said the prof, putting his pen down and flicking the marked paper into the pile in front of him.  He looked up at Rich: “Tell you what, let’s go to the café. The air-conditioning there is so much better,” he added, somewhat apologetically.

As they walked out of the prof’s office, Rich couldn’t help but wonder why the prof stuck around in a place where he remained unrecognized and unappreciated.

—

The café was busy. Though it was only mid-afternoon, the crowd was  already in Friday evening mode. Rich and the prof ordered their coffees and found a spot at the quieter end of the cafe.

After some small talk, the prof looked him and said, “Pardon my saying so, Rich, but you seem preoccupied. Is there something you want to talk about?”

“Yes, there is…well, there was, but I’m not so sure now.”

“You might as well ask,” said the prof. “My time is not billable….unlike yours.” His face crinkled into a smile that said, no offence intended.

“Well, as I mentioned when I called you this morning, I’m a management consultant with Big Consulting. By all measures, I’m doing quite well: excellent pay, good ratings from my managers and clients, promotions etc. The problem is, over the last month or so I’ve been feeling like a faker who plays on clients’ insecurities, selling them advice and solutions that are simplistic and cause more problems than they solve,” said Rich.

“Hmmm,” said the prof, “I’m curious. What triggered these thoughts after a decade in the game?”

“Well, I reckon it was an engagement that I completed a couple of months ago. I was the principal consultant for a big change management initiative at a multinational.  It was my first gig as a lead consultant for a change program this size. I was responsible for managing all aspects of the engagement – right from the initial discussions with the client,  to advising them on the change process and finally implementing it.” He folded his hands behind his head and leaned back in his chair as he continued,  “In theory I’m supposed to offer independent advice. In reality, though, there is considerable pressure to use our standard, trademarked solutions. Have you heard of our 5 X Model of Change Management?”

“Yes, I have,” nodded the prof.

“Well, I could see that the prescriptions of 5 X would not work for that organization. But, as I said, I had no choice in the matter.”

“Uh-huh, and then?”

“As I had foreseen,” said Rich, “the change was a painful, messy one for the organization. It even hit their bottom line significantly.  They are trying to cover it up, but everyone in the organization knows that the change is the real reason for the drop in earnings.  Despite this, Big Consulting has emerged unscathed. A bunch of middle managers on the client’s side have taken the rap.” He shook his head ruefully. “They were asked to leave,” he said.

“That’s terrible,” said the prof, “I can well understand how you feel.”

“Yes, I should not have prescribed 5 X. It is a lemon. The question is: what should I do now?” queried Rich.

“That’s for you to decide. You can’t change the past, but you might be able to influence the future,” said the prof with a smile.

“I was hoping you could advise me.”

“I have no doubt that you have reflected on the experience. What did you conclude?”

“That I should get out of this line of work,” said Rich vehemently.

“What would that achieve?” asked the prof gently.

“Well, at least I won’t be put into such situations again. I’m not worried about finding work, I’m sure I can find a job with the Big Consulting name on my resume,” said Rich.

“That’s true,” said the prof, “but is that all there is to it? There are other things to consider. For instance, Big Consulting will continue selling snake oil. How would you feel about that?”

“Yeah, that is a problem – damned if I do, damned if I don’t,” replied Rich. “You know, when I was sitting in your office, I recalled that you had spoken about such dilemmas in one of your classes. You said that the difficulty with such wicked issues is that they cannot be decided based on facts alone, because the facts themselves are either scarce or contested…or both!”

“That’s right,” said the prof, “and this is a wicked problem of a kind that is very common, not just in professional work but also in life.  Even relatively mundane issues such as  whether or not to switch jobs have wicked elements. What we forget sometimes, though, is that our decisions on such matters or rather, our consequent actions, might also affect others.”

“So you’re saying I’m not the only stakeholder (if I can use that term) in my problem. Is that right?”

“That’s right, there are other people to consider,” said the prof, “but the problem is you don’t know who they are .They are all the people who will be affected in the future by the decision you make now. If you quit, Big Consulting will go on selling this solution and many more people might be adversely affected. On the other hand, if you stay, you could try to influence the future direction of Big Consulting, but that might involve some discomfort for yourself. This makes your wicked problem an ethical one.  I suspect this is why you’re having a hard time going with the “quit” option.”

There was a brief silence. The prof could see that Rich was thinking things through.

“Prof, I’ve got to hand it to you,” said Rich shaking his head with a smile, “I was so absorbed by the quit/don’t quit dilemma from my personal perspective that I didn’t realize there are other angles to consider.  Thanks, you’ve helped immensely. I’m not sure what I will do, but I do know that what you have just said will help me make a more considered choice.  Thank you!”

“You’re welcome, Rich”

…And as he boarded his flight later that evening,  Rich finally understood why the prof continued to teach at a place where he remained unrecognized and unappreciated