Archive for the ‘Best Practice’ Category
Processes and intentions: a note on cause and effect in project management
Introduction
In recent years the project work-form has become an increasingly popular mode of organizing activities in many industries. As the projectization bandwagon has gained momentum there have been few questions asked about the efficacy of project management methodologies. Most practitioners take this as a given and move on to seek advice on how best to implement project management processes. Industry analysts and consultants are, of course, glad to oblige with reams of white papers, strategy papers or whatever else they choose to call them (see this paper by Gartner Research, for example).
Although purveyors of methodologies do not claim their methods guarantee project success, they imply that there is a positive relationship between the two. For example, the PMBOK Guide tells us that, “…the application of appropriate knowledge, processes, skills, tools and techniques can have a significant impact on project success” (see page 4 of the 4th Edition). This post is a brief exploration of the cause-effect relationship between the two.
Necessary but not sufficient
In a post on cause and effect in management, I discussed how the link between high-level management actions and their claimed outcomes is tenuous. The basic reason for this is that there are several factors that can affect organizational outcomes and it is impossible to know beforehand which of these factors are significant. The large number of factors, coupled with the fact that controlled experimentation is impossible in organizations, makes it impossible to establish with certainty that a particular managerial action will lead to a desired outcome.
Most project managers are implicitly aware of this – they know that factors extrinsic to their projects can often spell the difference between success and failure. A mid-project change in organizational priorities is a classic example of such a factor. The effect of such factors can be accounted for using a concept of causality proposed by the philosopher Edgar Singer, and popularised by the management philosopher Russell Ackoff. In a paper entitled Systems, Messes and Interactive Planning, Ackoff had this to say about cause and effect in systems – i.e. entities that interact with each other and their environment, much like organizations and projects do:
It will be recalled that in the Machine Age cause-effect was the central relationship in terms of which all actions and interactions were explained. At the turn of this century the distinguished American philosopher of science E.A. Singer, Jr.noted that cause-effect was used in two different senses. First… a cause is a necessary and sufficient condition for its effect. Second, it was also used when one thing was taken to be necessary but not sufficient for the other. To use Singer’s example, an acorn is necessary but not sufficient for an oak; various soil and weather conditions are also necessary. Similarly, a parent is necessary but not sufficient for his or her child. Singer referred to this second type of cause-effect as producer-product. It has also been referred to since as probabilistic or nondeterministic cause effect.
The role of intentions
A key point is that one cannot ignore the role of human intentions in management. As Sumantra Ghoshal wrote in a classic paper:
The basic building block in the social sciences, the elementary unit of explanation is individual action guided by some intention. In the presence of such intentionality functional [and causal] theories are suspect, except under some special and relatively rare circumstances, because there is no general law in the social sciences comparable to [say] the law of natural selection in biology
A producer-product view has room for human intentions and choices. As Ackoff stated in the his paper on systems and messes,
Singer went on to show why studies that use the producer-product relationship were compatible with, but richer than, studies that used only deterministic cause-effect. Furthermore, he showed that a theory of explanation based on producer-product permitted objective study of functional, goal-seeking and purposeful behavior. The concepts free will and choice were no longer incompatible with mechanism; hence they need no longer be exiled from science.
A producer-product view of cause and effect in project management recognizes that there will be a host of factors that affect project outcomes, many of which are beyond a manager’s ken and control. Further, and possibly more important, it acknowledges the role played by intentions of individuals who work on projects. Let’s take a closer look at these two points.
Processes and intentions
To begin, it is worth noting that that project management lore is rife with projects that failed despite the use of formal project management processes. Worse, in many cases it appears that failure is a consequence of over-zealous adherence to methodology (see my post entitled The myth of the lonely project for a detailed example). In such cases the failure is often attributed to causes other than the processes being used – common reasons include lack of organizational readiness and/or improper implementation of methodology from which the processes are derived. However, these causes can usually be traced back to lack of employee buy-in, i.e. of getting front-line project teams and managers to believe in the utility of the proposed processes and to make them want to use them. It stands to reason that people will use processes only if they believe they will help. So the first action should be to elicit buy-in from people who will be required to use the proposed processes. The most obvious way to do this is by seeking their input in formulating the processes.
Most often though, processes are “sold” to employees in a very superficial way (see this post for a case in point). Worse still, many times organizations do not even bother getting buy-in: the powers that be simply mandate the process with employees having little or no say in how processes are to be used or implemented. This approach is doomed to fail because – as I have discussed in this post – standards, methodologies and best practices capture only superficial aspects of processes. The details required to make processes work can be provided only by project managers and others who work at the coal-face of projects. Consequently employee buy-in shouldn’t be an afterthought, it should be the centerpiece of any strategy to implement a methodology. Buy-in and input are essential to gaining employee commitment, and employee commitment is absolutely essential for the processes to take root.
..and so to sum up
Project management processes are necessary for project success, but they are far from sufficient. Employee intentions and buy-in are critical factors that are often overlooked when implementing these. As a first step to addressing this, project management processes should be considered and implemented in a way that makes sense to those who work on projects. Those who miss this point are setting themselves up for failure.
The ERP paradox
“…strategic alignment flounders in never-ending tactics and compromises…” Ole Hanseth et. al. in The Control Devolution: ERP and the Side-effects of Globalization (The Database for advances in information systems, Vol. 32, pp. 34-36)
Introduction
Organisations implement Enterprise Resource Planning (ERP) systems for a number of reasons. Some of the more common ones are:
- To gain control over processes within the organisation.
- To make these processes more efficient.
- To reduce the portfolio of applications that the IS department has to manage.
Yet, the end result of ERP implementations is often the opposite: less control, and efficiency; and even though the number of applications may be reduced, this advantage is often offset by the cost and effort of maintaining ERP systems. In this post I explore this paradox, drawing from the paper from which the quote at the start of this post was taken. In essence, the paper discusses- via a case study – how the implementation of an ERP system can actually increase organisational drift and reduce efficiency.
Globalisation and its effect on IT strategy
Those who have lived through an ERP implementation would be well aware of the some of the difficulties associated with these. This is no longer news: there is a fair bit of research done on the problems and pitfalls of ERP system implementations (see this paper, for example). The question, however, is why ERP implementations run into problems. To answer this, the authors of the paper turn to the notion of globalisation and how ERP systems can be seen as a reaction to it.
Globalisation is essentially the interaction and integration between people of different cultures across geographical boundaries, facilitated by communication, trade and technology. The increasing number of corporations with a global presence is one of the manifestations of globalisation. For such organisations, ERP systems are seen as a means to facilitate globalisation and control it.
There are four strategies that an organisation can choose from when establishing a global presence. These are:
- Multinational: Where individual subsidiaries are operated autonomously.
- International: Where work practices from the parent company diffuse through the subsidiaries (in a non-formal way).
- Global: Where local business activities are closely controlled by the parent corporation.
- Transnational: This (ideal) model balances central control and local autonomy in a way that meets the needs of the corporation while taking into account the uniqueness of local conditions.
These four business strategies map to two corporate IT strategies:
- Autonomous: where individual subsidiaries have their own IT strategies, loosely governed by corporate.
- Headquarters-driven: where IT operations are tightly controlled by the parent corporation.
Neither is perfect – both have downsides that start to become evident only after a particular strategy is implemented. Given this, it is no surprise that organisations tend to cycle between the two strategies, with cycle times varying from five to ten years; a trend that corporate IT minions are all too familiar with. Typically, though, executive management tends to favour the centrally-driven approach since it holds the promise of higher control and reduced costs.
Another consequence of globalisation is the trend towards outsourcing IT infrastructure and services. This is particularly popular for operational IT – things like infrastructure and support. In view of this, it is no surprise that the organisation discussed in the paper chose to outsource their ERP operations to an external vendor. Equally unsurprising, perhaps, is that the quality of service did not match expectations.
The effect of modernity
The phenomenon of modernity forms an essential part of the backdrop against which ERP systems are implemented. According to a sociological definition due to Anthony Giddens, modernity is “associated with (1) a certain set of attitudes towards the world, the idea of the world as open to transformation, by human intervention; (2) a complex of economic institutions, especially industrial production and a market economy; (3) a certain range of political institutions, including the nation-state and mass democracy”
Modernity is characterised by the following three “forces” that have a direct impact on our lives:
- The separation of space and time: This refers to the ability to coordinate activities across the world – be they global supply chains or virtual project teams. The ability to coordinate work across space and time is made possible by technology. The important consequence of this ability, relevant to ERP systems, is that it makes it possible for organisations to increase their level of surveillance and control of key business processes.
- The development of disembedding mechanisms: As I have discussed at length in this post, organisations often “import” procedures that have worked well in organisations. The assumption underlying this practice is that the procedures can be lifted out of their original context and implemented in another one without change. This, in turn, tacitly assumes that those responsible for implementing the procedure in the new context understand the underlying cause-effect relationships completely. This world-view, where organisational processes and procedures are elevated to the status of universal “best practices” is an example of a disembedding mechanism at work. Disembedding mechanisms are essentially processes via which certain facts are abstracted from their context and ascribed a universal meaning.
- The reflexivity of knowledge and practice: Reflexive phenomena are those for which cause-effect relationships are bi-directional – i.e. causes determine effects which in turn modify the causes. Such phenomena are unstable in the sense that they are continually evolving – in potentially unpredictable ways. Organisational practices (which are based on organisational knowledge) are reflexive in the sense that they are continually modified in the light of their results or effects. This conflicts with the main rationale for ERP systems, which is to rationalise and automate organisational processes and procedures (most often in a completely inflexible manner) .
Implications for organisations
One of the main implications of globalisation and modernity is that the world is now more interconnected than ever before. This is illustrated by the global repercussions of the financial crises that have occurred in recent times. For globalised organisations this manifests itself in not-so-obvious dependencies – both on events internal to the organisation and those that take place in its business, political and social environment. The important thing to note is that these events are outside of the organisation’s control. At best they can be managed as risks –i.e. events that cannot be foreseen with certainty.
A standard response to risk is to increase control. Arguably, this may well be the single most common executive-level rationale behind many ERP implementations. Yet, paradoxically, the imposition of stringent controls can lead to less control. One of the main reasons for this is that strict controls can give rise to unanticipated side effects. A good example of this is when employees learn how to game performance metrics and service level agreements.
The gap between plan and reality
The authors use a case study to illustrate how ERP implementations can be subverted by the side effects of globalisation and modernity. The organisation they studied was Norsk Hydro a Norwegian multinational which, at that time, was undergoing an organisation-wide consolidation of its IT infrastructure and services. Up until then, the IT landscape within the organisation was heterogeneous, with individual business units and subsidiaries free to implement whatever systems they saw fit. The decision to implement a global ERP system (SAP R/3) was a direct consequence the drive to consolidate the IT portfolio.
To reduce risk, it was decided to develop and validate a pilot project in one site and manufacturing plant. Problems started to emerge during the pilot validation. As the authors state:
When the pilot was installed, it took three months of extensive support to make it work properly. …The validation effort identified more than 1000 “issues,” each of them requiring changes in the system.
Understandably, business managers were not impressed:
Some managers also argued that the “final” version should be based on a complete redesign of the pilot, as the latter was not structured as well as the more complex “final” version would require.
Yet, this redesign never happened. One can only speculate why – but it is a pretty good guess that cost had something to do with it.
The SAP implementation unfolded against a backdrop of a large-scale business restructuring. One of the other sub-projects in this restructuring was a business re-engineering initiative. Quite logically, this was subsumed within the SAP project. One of the main outcomes of this was the establishment of “common” organisation-wide processes to replace myriad local processes. These common processes were to be modelled on “best practices.” Although this made sense from a management perspective, implementation was difficult because just about every local procedure had quirks that could not be shoe-horned into standardised global processes.
Side effects
The authors list a number of unintended “side effects” of the implementation. I will describe just a couple of these, referring the reader to the original paper for others.
Homogeneity to heterogeneity
Ideally, an SAP implementation is intended to provide a single “harmonised” solution across an organisation. In practice, however, local differences and the existence of legacy systems guarantees that this ideal will be compromised. This is exactly what happened at Norsk Hydro. In the authors’ words:
…differences in business cultures and market structures in nations and regions [had to be accounted for]. In this process locals played a key role. They, in fact, took over the design process and turned SAP into an ally helping them get control over the overall change process…the SAP solution was customised for each individual site. Slowly, but irreversibly, the SAP solution had changed from one coherent common system to a complex, heterogeneous infrastructure.
Those who have lived through an ERP implementation may recognise echoes of this in their own experiences.
Side effects of integration
Although the above example illustrates the integration was perhaps not as complete as was intended, the implementation was largely successful in rationalising the organisation’s IT landscape. For one, it replaced several legacy systems, thus (in theory) reducing costs. However, as the authors’ point out, integration means interdependence, which can create significant maintenance problems. ERP systems are notoriously hard and expensive to maintain. Norsk Hydro’s experience was no different: SAP upgrades were horrendously expensive and time consuming. As the authors state:
Typically, SAP is subject to rapid change because the huge customer base generates lots of new requirements all the time. Moreover, as its integrated nature implies, when any module is changed, the whole system has to be modified. Thus, in spite of the fact that the number of interfaces to be maintained decreases when an organization installs SAP, their complexity and change rate increase so much that the overall maintenance costs reach very high levels.
In spite of the standard solutions applied, the upgrades of the SAP code itself are also very complex and time consuming. The last upgrade (at the time of writing) enforced the SAP application to be down for 9 days! Also here there are many explanations.
For example, when all the work processes are integrated it creates a complex production lattices. Because of many errors in the software all work processes have to be tested extensively, etc.
This side effect is, in fact, an unavoidable consequence of the complexity and interconnectedness of ERP systems
Conclusion
In closing, it is appropriate to return to the themes mentioned at the start of this post. The case study discussed by the authors highlights the fact that ERP systems can have effects that are exactly opposite to the ones intended. Specifically, they can lead to less rather than more control, less efficiency and addition of complexity to the IT portfolio. Moreover, seen in a broader context, ERP systems are a microcosm of modernity: they attempt to coordinate activities at a global scale, implement disembedding mechanisms in the form of best practices, and are reflexive in the sense that they change organisational practices but are also changed by them. The interconnectedness and uncertain cause-effect relationships lead to unanticipated side effects that can completely subvert the original intent of these systems.
The authors summarise this well in the last few lines of the paper:
ERP installations in global organizations conform pretty well to the image of the modern world as a juggernaut, i.e. a runaway engine of enormous power that, collectively as human beings, we can drive to some extent but that also threatens to rush out of our control in directions we cannot foresee, crushing those who resist it
In my opinion, those thinking of committing their organisations to implementing ERP systems would do well to read this paper in addition to vendor propaganda literature.
Planned failure – a project management paradox
The other day a friend and I were talking about a failed process improvement initiative in his organisation. The project had blown its budget and exceeded the allocated time by over 50%, which in itself was a problem. However, what I found more interesting was that the failure was in a sense planned – that is, given the way the initiative was structured, failure was almost inevitable. Consider the following:
- Process owners had little or no input into the project plan. The “plan” was created by management and handed down to those at the coalface of processes. This made sense from management’s point of view – they had an audit deadline to meet. However, it alienated those involved from the outset.
- The focus was on time, cost and scope; history was ignored. Legacy matters – as Paul Culmsee mentions in a recent post, “To me, considering time, cost and scope without legacy is delusional and plain dumb. Legacy informs time, cost and scope and challenges us to look beyond the visible symptoms of what we perceive as the problem to what’s really going on.” This is an insightful observation – indeed, ignoring legacy is guaranteed to cause problems down the line.
The conversation with my friend got me thinking about planned failures in general. A feature that is common to many failed projects is that planning decisions are based on dubious assumptions. Consider, for example, the following (rather common) assumptions made in project work:
- Stakeholders have a shared understanding of project goals. That is, all those who matter are on the same page regarding the expected outcome of the project.
- Key personnel will be available when needed and – more importantly – will be able to dedicate 100% of their committed time to the project.
The first assumption may be moot because stakeholders view a project in terms of their priorities and these may not coincide with those of other stakeholder groups. Hence the mismatch of expectations between, say, development and marketing groups in product development companies. The second assumption is problematic because key project personnel are often assigned more work than they can actually do. Interestingly, this happens because of flawed organisational procedures rather than poor project planning or scheduling – see my post on the resource allocation syndrome for a detailed discussion of this issue.
Another factor that contributes to failure is that these and other such assumptions often come in to play during the early stages of a project. Decisions that are based on these assumptions thus affect all subsequent stages of the project. To make matters worse, their effects can be amplified as the project progresses. I have discussed these and other problems in my post on front-end decision making in projects.
What is relevant from the point of view of failure is that assumptions such as the ones above are rarely queried, which begs the question as to why they remain unchallenged. There are many reasons for this, some of the more common ones are:
- Groupthink: This is the tendency of members of a group to think alike because of peer pressure and insulation from external opinions. Project groups are prone to falling into this trap, particularly when they are under pressure. See this post for more on groupthink in project environments and ways to address it.
- Cognitive bias: This term refers to a wide variety of errors in perception or judgement that humans often make (see this Wikipedia article for a comprehensive list of cognitive biases). In contrast to groupthink, cognitive bias operates at the level of an individual. A common example of cognitive bias at work in projects is when people underestimate the effort involved in a project task through a combination of anchoring and/or over-optimism (see this post for a detailed discussion of these biases at work in a project situation). Further examples can be found in in my post on the role of cognitive biases in project failure, which discusses how many high profile project failures can be attributed to systematic errors in perception and judgement.
- Fear of challenging authority: Those who manage and work on projects are often reluctant to challenge assumptions made by those in positions of authority. As a result, they play along until the inevitable train wreck occurs.
So there is no paradox: planned failures occur for reasons that we know and understand. However, knowledge is one thing, acting on it quite another. The paradox will live on because in real life it is not so easy to bell the cat.
Eight to Late 