Archive for the ‘Paper Review’ Category
On the inherent ambiguities of managing projects
Much of mainstream project management is technique-based – i.e. it is based on processes that are aimed at achieving well-defined ends. Indeed, the best-known guide in the PM world, the PMBOK, is structured as a collection of processes and associated “tools and techniques” that are categorised into various “knowledge areas.”
Yet, as experienced project managers know, there is more to project management than processes and techniques: success often depends on a project manager’s ability to figure out what to do in unique situations. Dealing with such situations is more an art rather than science. This process (if one can call it that) is difficult to formalize and even harder to teach. As Donald Schon wrote in a paper on the crisis of professional knowledge :
…the artistic processes by which practitioners sometimes make sense of unique cases, and the art they sometimes bring to everyday practice, do not meet the prevailing criteria of rigorous practice. Often, when a competent practitioner recognizes in a maze of symptoms the pattern of a disease, constructs a basis for coherent design in the peculiarities of a building site, or discerns an understandable structure in a jumble of materials, he does something for which he cannot give a complete or even a reasonably accurate description. Practitioners make judgments of quality for which they cannot state adequate criteria, display skills for which they cannot describe procedures or rules.
Unfortunately this kind of ambiguity is given virtually no consideration in standard courses on project management. Instead, like most technically-oriented professions such as engineering, project management treats problems as being well-defined and amenable to standard techniques and solutions. Yet, as Schon tells us:
…the most urgent and intractable issues of professional practice are those of problem-finding. “Our interest”, as one participant put it, “is not only how to pour concrete for the highway, but what highway to build? When it comes to designing a ship, the question we have to ask is, which ship makes sense in terms of the problems of transportation?
Indeed, the difficulty in messy project management scenarios often lies in figuring out what to do rather than how to do it. Consider the following situations:
- You have to make an important project-related decision, but don’t have enough information to make it.
- Your team is overworked and your manager has already turned down a request for more people.
- A key consultant on your project has resigned.
Each of the above is a not-uncommon scenario in the world of projects. The problem in each of these cases lies in figuring out what to do given the unique context of the project. Mainstream project management offers little advice on how to deal with such situations, but their ubiquity suggests that they are worthy of attention.
In reality, most project managers deal with such situations using a mix of common sense, experience and instinct, together with a deep appreciation of the specifics of the environment (i.e. the context). Often times their actions may be in complete contradiction to textbook techniques. For example, in the first case described above, the rational thing to do is to gather more data before making a decision. However, when faced with such a situation, a project manager might make a snap decision based on his or her knowledge of the politics of the situation. Often times the project manager will not be able to adequately explain the rationale for the decision beyond knowing that “it felt like the right thing to do.” It is more an improvisation than a plan.
Schon used the term reflection-in-action to describe how practitioners deal with such situations, and used the following example to illustrate how it works in practice:
Recently, for example, I built a wooden gate. The gate was made of wooden pickets and strapping. I had made a drawing of it, and figured out the dimensions I wanted, but I had not reckoned with the problem of keeping the structure square. I noticed, as I began to nail the strapping to the pickets that the whole thing wobbled. I knew that when I nailed in a diagonal piece, the structure would become rigid. But how would I be sure that, at that moment, the structure would be square? I stopped to think. There came to mind a vague memory about diagonals-that in a square, the diagonals are equal. I took a yard stick, intending to measure the diagonals, but I found it difficult to make these measurements without disturbing the structure. It occurred to me to use a piece of string. Then it became apparent that I needed precise locations from which to measure the diagonal from corner to corner. After several frustrating trials, I decided to locate the center point at each of the corners (by crossing diagonals at each corner), hammered in a nail at each of the four center points, and used the nails as anchors for the measurement string. It took several moments to figure out how to adjust the structure so as to correct the errors I found by measuring, and when I had the diagonal equal, I nailed in the piece of strapping that made the structure rigid…
Such encounters with improvisation are often followed by a retrospective analysis of why the actions taken worked (or didn’t). Schoen called this latter process reflection-on-action. I think it isn’t a stretch to say that project managers hone their craft through reflection in and on ambiguous situations. This knowledge cannot be easily codified into techniques or practices but is worthy of study in its own right. To this end, Schon advocated an epistemology of (artistic) practice – a study of what such knowledge is and how it is acquired. In his words:
…the study of professional artistry is of critical importance. We should be turning the puzzle of professional knowledge on its head, not seeking only to build up a science applicable to practice but also to reflect on the reflection-in-action already embedded in competent practice. We should be exploring, for example, how the on-the-spot experimentation carried out by practicing architects, physicians, engineers and managers is like, and unlike, the controlled experimentation of laboratory scientists. We should be analyzing the ways in which skilled practitioners build up repertoires of exemplars, images and strategies of description in terms of which they learn to see novel, one-of-a-kind phenomena. We should be attentive to differences in the framing of problematic situations and to the rare episodes of frame-reflective discourse in which practitioners sometimes coordinate and transform their conflicting ways of making sense of confusing predicaments. We should investigate the conventions and notations through which practitioners create virtual worlds-as diverse as sketch-pads, simulations, role-plays and rehearsals-in which they are able to slow down the pace of action, go back and try again, and reduce the cost and risk of experimentation. In such explorations as these, grounded in collaborative reflection on everyday artistry, we will be pursuing the description of a new epistemology of practice.
It isn’t hard to see that similar considerations hold for project management and related disciplines.
In closing, project management as laid out in books and BOKs does not equip a project manager to deal with ambiguity. As a start towards redressing this, formal frameworks need to acknowledge the limitations of the techniques and procedures they espouse. Although there is no simple, one-size-fits-all way to deal with ambiguity in projects, lumping it into a bucket called “risk” (or worse, pretending it does not exist) is not the answer.
Understanding “flexibility” – a close-up view of an organizational platitude
Introduction
Flexibility is one of those buzzwords that keeps coming up in organizational communiques and discussions. People are continually asked to display flexibility, without ever being told what the term means: flexible workplaces, flexible attitudes, flexible jobs – the word itself has a flexible meaning that depends on the context in which it is used and by whom.
When words are used in this way they become platitudes – empty words that make a lot of noise. In this post, I analyse the platitude, flexibility, as it is used in organisations. My discussion is based on a paper by Thomas Eriksen entitled, Mind the Gap: Flexibility, Epistemology and the Rhetoric of New Work.
Background – a bit about organizational platitudes
One of the things that struck me when I moved from academia to industry is the difference in the way words or phrases are used in the two domains. In academics one has to carefully define the terms one uses (particularly if one is coining a new term) whereas in business it doesn’t seem to matter, words can mean whatever one wants them to mean (OK, this is an exaggeration, but not by too much). Indeed, as Paul Culmsee and I discuss in the first chapter of The Heretic’s Guide to Best Practices, many terms that are commonly bandied about in organizations are platitudes because they are understood differently by different people.
A good example of a platitude is the word governance. One manager may see governance as being largely about oversight and control whereas another might interpret it as being about providing guidance. Such varying interpretations can result in major differences in the way the two managers implement governance: the first one might enforce it as a compliance-oriented set of processes that leave little room for individual judgement while the other might implement it as a broad set of guidelines that leave many of the decisions in the hands of those who are actually doing the work. Needless to say, the results in the two cases are likely to be different too.
Flexibility – the conventional view
A good place to start our discussion of flexibility is with the dictionary. The online Oxford Dictionary defines at as:
Flexibility (noun):
- the ability to be easily modified
- willingness to change or compromise
The term is widely used in both these senses in organizational settings. For example, people speak of flexible designs (i.e. designs that can be easily modified) or flexible people (referring to those who are willing to change or compromise). However, and this is the problem: the term is open to interpretation – what Jack might term a flexible approach may be seen by Jill as a complete lack of method. These differences in interpretation become particularly obvious when the word is used in a broad context – such as in a statement justifying an organizational change. An executive might see a corporate restructure and the resulting changes in jobs/roles as a means to achieve organizational flexibility, but those affected by it may see it as constraining theirs. As Eriksen states:
Jobs are flexible in the sense that they are unstable and uncertain, few employees hold the same jobs for many years, the content of jobs can be changed almost overnight, and the boundaries between work and leisure are negotiable and chronically fuzzy.
Indeed, such “flexibility” which requires one to change at short notice results in a fragmentation of individual experience and a resulting loss of a coherent narrative of one’s life. It appears that increased flexibility in one aspect results in a loss of flexibility in another. Any sensible definition of flexibility ought to reflect this.
Understanding flexibility
Consider the following definition of flexibility proposed by Gregory Bateson:
“Flexibility is uncommitted potential for change”
This deceptively simple statement is a good place to start understanding what flexibility really means for projects, organisations …and even software systems.
As Eriksen tells us, Bateson proposed this definition in the context of ecology. In particular, Bateson had in mind the now obvious notion that the increased flexibility we gain through our increasingly energy-hungry lifestyles results in a decrease in the environment’s capacity to cope with the consequences. This is true of flexibility in any context: a gain in flexibility in one dimension will necessarily be accompanied by a loss of flexibility in another.
Another implication of the above definition is that a system that is running at or near the limits of its operating variables cannot be flexible. The following examples should make this clear:
- A project team that is putting in 18 hour workdays in order to finish a project on time.
- A car that’s being driven at top speed.
- A family living beyond their means.
All these systems are operating at or near their limits, they have little or no spare capacity to accommodate change.
A third implication of the definition follows from the preceding one: the key variables of a flexible system should lie in the mid-range of their upper and lower limits. In terms of above examples:
- The project team should be putting in normal hours.
- The car should be driven at or below the posted road speed limits
- The family should be living within its income, with a reasonable amount to spare.
Of course, the whole point of ensuring that systems operate in their comfort zone is that they can be revved up if the need arises. Such revving up, however, should be an exceptional circumstance rather than the norm – a point that those who run projects, organisations (and, yes, even vehicles) often tend to forget. If one operates a system at the limits of its tolerance for too long, not only will it not be flexible, it will break.
Flexibility in the workplace
As mentioned in the introduction, the term flexibility keeps cropping up in organizational settings: corporate communiques exhort employees to be flexible in the face of change. This is typically a coded signal that employees should expect uncertainty and be prepared to adjust to it. A related manifestation of flexibility is the blurring of the distinction between work and personal life. As Eriksen puts it:
The term flexibility is often used to describe this new situation: Jobs are flexible in the sense that they are unstable and uncertain, few employees hold the same jobs for many years, the content of jobs can be changed, and the boundaries between work and leisure are poorly defined.
This trend is aided by recent developments in technology that enable employees to be perpetually on call. This is often sold as a work from home initiative but usually ends up being much more. Eriksen has this to say about home offices:
One recent innovation typically associated with flexibility is the home office. In Scandinavia (and some other prosperous, technologically optimistic regions), many companies equipped some of their employees with home computers with online access to the company network in the early 1990s, in order to enhance their flexibility. This was intended to enable employees to work from home part of the time, thereby making the era when office workers were chained to the office desk all day obsolete.
In the early days, there were widespread worries among employers to the effect that a main outcome of this new flexibility would consist in a reduction of productivity. Since there was no legitimate way of checking how the staff actually spent their time out of the office, it was often suspected that they worked less from home than they were supposed to. If this were in fact the case, working from home would have led to a real increase in the flexibility of time budgeting. However, work researchers eventually came up with a different picture. By the late 1990s, hardly anybody spoke of the home office as a convenient way of escaping from work; rather, the concern among unionists as well as researchers was now that increasing numbers of employees were at pains to distinguish between working hours and leisure time, and were suffering symptoms of burnout and depression. The home office made it difficult to distinguish between contexts that were formerly mutually exclusive because of different physical locations.
It is interesting to see this development in the light of Bateson’s definition of flexibility: the employee gains flexibility in space (he or she can work from home or from the office) at the expense of flexibility in time (organization time encroaches on personal time). As Eriksen states:
There seems to be a classic Batesonian flexibility trade-off associated with the new information technologies: increased spatial flexibility entails decreased temporal flexibility. If inaccessibility and ‘empty time’ are understood as scarce resources, the context of ‘new work’ thus seems to be an appropriate context for a new economics as well. In fact, a main environmental challenge of our near future will consist in protecting slow time and gaps from environmental degradation.
In short, it appears that flexibility for the organization necessarily implies a loss of flexibility for the individual.
Conclusion
Flexibility is in the eye of the beholder: an action to increase organisational flexibility by, say, redeploying employees would likely be seen by those affected as a move that constrains their (individual) flexibility. Such a dual meaning is characteristic of many organizational platitudes such as Excellence, Synergy and Governance. It is an interesting exercise to analyse such platitudes and expose the difference between their espoused and actual meanings. So I sign off for 2013, wishing you many hours of platitude-deconstructing fun 🙂
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 