Eight to Late

Introduction

Those involved in information systems projects will be well aware of the gap between user expectations and the actual capabilities newly rolled-out systems.  Despite change management and training initiatives, users often complain that they can’t do this or that (which the old system did so well…) or that the new system has a terrible interface and is just too hard to use.  Although such projects may not be dubbed total failures, both sides of the IS/User divide are left feeling a bit cheated.  As Jim Underwood noted in a paper entitled, Negotiating the chasm in system development: some advice from Actor Network Theory:

While academics, managers and accountants believe that many IS projects, if not total failures, are at least very expensive mistakes, the developers themselves seem to believe that they are doing as well as could be expected and are producing many highly valuable systems. For managers the gap between idea and reality is caused by inappropriate culture or lack of commitment on the part of the developers; for theoreticians the cause is a failure to use or properly adhere to an appropriate methodology.

The gap between expectations and reality is often attributed to a misunderstanding of requirements that are articulated at the start of a project. One of the key selling points of iterative/incremental approaches to development, wherein the “system reality checks” are carried out at regular intervals (at the end of each iteration), is that they allegedly reduce or eliminate this gap altogether.   However, in reality, the gaps often remain, and none of the parties involved get their own way entirely.   Unfortunately these differences are often “swept under the carpet”, only to emerge later on.  In this post, I summarise Underwood’s paper, highlighting the insights he provides that can help project professionals  negotiate this gap.

The world according to ANT

Underwood’s work is based on Actor-Network Theory (ANT) which, for the purposes of the present discussion, can be viewed as an approach to studying systems that consist of interacting social and technical elements. According to Underwood, ANT can be considered as a type of stakeholder analysis. A distinguishing feature of ANT is that it considers non-human “stakeholders”  (or actors, as they are referred to in ANT) to be on on  an equal footing to human ones.  For example, a system is an actor with its own “viewpoint” and “agenda.”  I know this sounds a bit “out there” but hopefully it will make more sense as we go on. A key point in ANT is that all stakeholders are internal to the network. Moreover they exert influence on each other, and this influence can change in time (exactly like in real life). Influence is exerted through scripts– descriptions of actions that the actors are expected to carry out.   Actors inscribe each other with scripts through communication – written, verbal or otherwise.  Others interpret (or de-scribe) scripts in order to understand the motives actions of actors.   A plan to inscribe actors with scripts with the aim of achieving a particular goal (project objectives, for example) is called a program. Programs can be countered with anti-programs, which as their name suggests, are plans that work against the program. It is important to note that the process of interpreting scripts is done within a particular set of norms and rules that are specific to a discipline.  For example, depending on the specific development methodology followed the script “gather user requirements” may be interpreted in different ways.  However, the interpretation is rarely unambiguous – different stakeholders will interpret scripts in different ways. A manager may, for instance, assume that the end product of a requirements gathering process is a comprehensive requirements document whereas a developer might be content with informal notes and mockups.

Espoused and interpreted scripts

In real life scripts change their form as they are passed on and interpreted by actors: directives, however explicit they may be, are always open to being interpreted in different ways, depending on the backgrounds of actors. So, we have two levels of scripts: the original one as intended by the author and the interpreted ones that are put into action by other actors.  Following Argyris and Schoen’s distinction between espoused and in-use theories, Underwood calls these espoused scripts and scripts- in-use.  As I see it, the collection of espoused scripts form the “official” project while the scripts-in-use make up the “actual” one.

Betrayal and ambiguity

The fact that there are two levels of scripts points to the fact that the planned project rarely coincides with the actual one. There are always deviations. The point is, a plan (an espoused script) is never unambiguous, it can be translated into many different scripts-in-use. At times these translations may be viewed as betrayals – i.e. unacceptable deviations from the original script. At others, the content of a script may be translated covertly. This often happens when the content of a script is potentially contentious or vague. A good example of the latter is the script “the system must be  scalable”, which may be translated to a specific interpretation of scalability that the system developer can achieve.

Implications for project managers

One of the key functions of a project manager is to ensure that the project is on track. In other words, it is to monitor and control the project. Indeed this is one of the process areas described in the PMBOK guide.  Underwood contends that there are essentially two ways in which project managers exert control: overt and covert. In his words:

They either take a Machiavellian view or promote superficial agreement and high sounding concepts while secretly working to their own goals, or they insist on all players subscribing to detailed design specifications expressed in the language of some dominant discourse.

Of course, they may do both, depending on what specific situations call for.  However, according to Underwood, the actor-network view suggests that project management is more about facilitation than control. With this in mind, he offers the following advice (or scripts!) to project managers.

1. Don’t be afraid of politics: In the actor-network view, political stakeholders are actors who have their own scripts. These scripts must be incorporated into the project, interpreted in ways that keep all actors on side.  This may be a difficult process that requires skilful negotiation. Ignoring politically motivated scripts may end up jeopardizing the project.
2. Keep project boundaries broad and less technical: system planners and developers tend to focus on the technical aspects of projects.  Despite rhetoric to the contrary, the technical aspects of systems are given the place of pride in project plans and schedules.   ANT focuses our attention on the fact that the non-technical aspects of systems – humans, environment and (organizational) culture  etc.  – are just as important (if not more).
3. Track scripts: Underwood suggests keeping of track of scripts through regular audits. Scripts that have been dropped (i.e.  inadvertently forgotten) are likely to turn up again later when someone asks, “What have we done about X’.  The function of the audit is to remind everyone about actions that are required and reaffirm actors’ intention to action scripts that they have committed to.
4. Don’t cover up disagreements: Disagreements (differing interpretations of scripts) are often ignored because no one wants unpleasantness.  Underwood suggests airing differences with the aim of reaching shared understanding. This does not mean that all differences will be resolved, only that they are debated openly with the aim of achieving a consensual way forward.

Of course, this advice is somewhat idealistic and difficult to implement in practice: good intentions and the need for shared understanding are often forgotten in the heat of managing messy, real-life projects.

Conclusion

The main point made in the paper is that project managers should attempt to facilitate actions rather than direct or control them. The best way to do this is by enabling stakeholders to reach a shared understanding of what the project is all about and a shared commitment to actions that will make it happen.  Dialogue mapping, which I have described in many earlier posts is an excellent way to achieve this. But in the end it isn’t about specific techniques or methodologies – it  is about taking responsibility and genuinely caring about the outcome.   As Underwood states in his conclusion,

The simplest, most important and most difficult script recommended for all actors, but particularly project managers is “let go”. Managing a project can be compared to teaching students or bringing up children. We have some ideas about what we hope to achieve, some knowledge and experience, plenty of advice to give and a few techniques (of doubtful efficacy) for influencing behaviour. We feel responsible, we care deeply about the outcome, but we should be neither surprised nor disappointed when the reality turns out quite differently from anything we might have expected…

I don’t think I can put it any better.