Archive for the ‘Paper Review’ Category
The danger within: internally-generated risks in projects
Introduction
In their book, Waltzing with Bears, Tom DeMarco and Timothy Lister coined the phrase, “risk management is project management for adults”. Twenty years on, it appears that their words have been taken seriously: risk management now occupies a prominent place in BOKs, and has also become a key element of project management practice.
On the other hand, if the evidence is to be believed (as per the oft quoted Chaos Report, for example), IT projects continue to fail at an alarming rate. This is curious because one would have expected that a greater focus on risk management ought to have resulted in better outcomes. So, is it possible at all that risk management (as it is currently preached and practiced in IT project management) cannot address certain risks…or, worse, that there are certain risks are simply not recognized as risks?
Some time ago, I came across a paper by Richard Barber that sheds some light on this very issue. This post elaborates on the nature and importance of such “hidden” risks by drawing on Barber’s work as well as my experiences and those of my colleagues with whom I have discussed the paper.
What are internally generated risks?
The standard approach to risk is based on the occurrence of events. Specifically, risk management is concerned with identifying potential adverse events and taking steps to reduce either their probability of occurrence or their impact. However, as Barber points out, this is a limited view of risk because it overlooks adverse conditions that are built into the project environment. A good example of this is an organizational norm that centralizes decision making at the corporate or managerial level. Such a norm would discourage a project manager from taking appropriate action when confronted with an event that demands an on-the-spot decision. Clearly, it is wrong-headed to attribute the risk to the event because the risk actually has its origins in the norm. In other words, it is an internally generated risk.
(Note: the notion of an internally generated risk is akin to the risk as a pathogen concept that I discussed in this post many years ago.)
Barber defines an internally generated risk as one that has its origin within the project organisation or its host, and arises from [preexisting] rules, policies, processes, structures, actions, decisions, behaviours or cultures. Some other examples of such risks include:
- An overly bureaucratic PMO.
- An organizational culture that discourages collaboration between teams.
- An organizational structure that has multiple reporting lines – this is what I like to call a pseudo-matrix organization 🙂
These factors are similar to those that I described in my post on the systemic causes of project failure. Indeed, I am tempted to call these systemic risks because they are related to the entire system (project + organization). However, that term has already been appropriated by the financial risk community.
Since the term is relatively new, it is important to draw distinctions between internally generated and other types of risks. It is easy to do so because the latter (by definition) have their origins outside the hosting organization. A good example of the latter is the risk of a vendor not delivering a module on time or worse, going into receivership prior to delivering the code.
Finally, there are certain risks that are neither internally generated nor external. For example, using a new technology is inherently risky simply because it is new. Such a risk is inherent rather than internally generated or external.
Understanding the danger within
The author of the paper surveyed nine large projects with the intent of getting some insight into the nature of internally generated risks. The questions he attempted to address are the following:
- How common are these risks?
- How significant are they?
- How well are they managed?
- What is the relationship between the ability of an organization to manage such risks and the organisation’s project management maturity level (i.e. the maturity of its project management processes)
Data was gathered through group workshops and one-on-one interviews in which the author asked a number of questions that were aimed at gaining insight into:
- The key difficulties that project managers encountered on the projects.
- What they perceived to be the main barriers to project success.
The aim of the one-on-one interviews was to allow for a more private setting in which sensitive issues (politics, dysfunctional PMOs and brain-dead rules / norms) could be freely discussed.
The data gathered was studied in detail, with the intent of identifying internally generated risks. The author describes the techniques he used to minimize subjectivity and to ensure that only significant risks were considered. I will omit these details here, and instead focus on his findings as they relate to the questions listed above.
Commonality of internally generated risks
Since organizational rules and norms are often flawed, one might expect that internally generated risks would be fairly common in projects. The author found that this was indeed the case with the projects he surveyed: in his words, the smallest number of non-trivial internally generated risks identified in any of the nine projects was 15, and the highest was 30! Note: the identification of non-trivial risks was done by eliminating those risks that a wide range of stakeholders agreed as being unimportant.
Unfortunately, he does not explicitly list the most common internally-generated risks that he found. However, there are a few that he names later in the article. These are:
- Resource allocation (see my article on the resource allocation syndrome for much more on this)
- Inadequate sponsorship (see my post on the systemic roots of project failure for more on this)
I suspect that experienced project managers would be able to name many more.
Significance of internally generated risks
Determining the significance of these risks is tricky because one has to figure out their probability of occurrence. The impact is much easier to get a handle on, as one has a pretty good idea of the consequences of such risks should they eventuate. (Question: What happens if there is inadequate sponsorship? Answer: the project is highly likely to fail!). The author attempted to get a qualitative handle on the probability of occurrence by asking relevant stakeholders to estimate the likelihood of occurrence. Based on the responses received, he found that a large fraction of the internally-generated risks are significant (high probability of occurrence and high impact).
Management of internally generated risks
To identify whether internally generated risks are well managed, the author asked relevant project teams to look at all the significant internal risks on their project and classify them as to whether or not they had been identified by the project team prior to the research. He found that in over half the cases, less than 50% of the risks had been identified. However, most of the risks that were identified were not managed!
The relationship between project management maturity and susceptibility to internally generated risk
Project management maturity refers to the level of adoption of standard good practices within an organization. Conventional wisdom tells us that there should be an inverse correlation between maturity levels and susceptibility to internally generated risk – the higher the maturity level, the lower the susceptibility.
The author assessed maturity levels by interviewing various stakeholders within the organization and also by comparing the processes used within the organization to well-known standards. The results indicated a weak negative correlation – that is, organisations with a higher level of maturity tended to have a smaller number of internally generated risks. However, as the author admits, one cannot read much into this finding as the correlation was weak.
Discussion
The study suggests that internally generated risks are common and significant on projects. However, the small sample size also suggests that more comprehensive surveys are needed. Nevertheless, anecdotal evidence from colleagues who I spoke with suggests that the findings are reasonably robust. Moreover, it is also clear (both, from the study and my conversations) that these risks are not very well managed. There is a good reason for this: internally generated risks originate in human behavior and / or dysfunctional structures. These tend to be a difficult topic to address in an organizational setting because people are unlikely to tell those above them in the hierarchy that they (the higher ups) are the cause of a problem. A classic example of such a risk is estimation by decree – where a project team is told to just get it done by a certain date. Although most project managers are aware of such risks, they are reluctant to name them for obvious reasons.
Conclusion
I suspect most project managers who work in corporate environments will have had to grapple with internally generated risks in one form or another. Although traditional risk management does not recognize these risks as risks, seasoned project managers know from experience that people, politics or even processes can pose major problems to smooth working of projects. However, even when recognised for what they are, these risks can be hard to tackle because they lie outside a project manager’s sphere of influence. They therefore tend to become those proverbial pachyderms in the room – known to all but never discussed, let alone documented….and therein lies the danger within.
Professionals or politicians? A client’s guide to management consultants
Introduction
The general image of management consultants in contemporary society is somewhat ambiguous. To take two rather extreme views: high achievers in universities may see management consulting as a challenging (and well paying!) profession that offers opportunities to make a positive difference to organisations, whereas those on the receiving end of a consultant-inspired restructure may see the profession as an embodiment of much that is wrong with the present-day corporate world.
The truth, as always, is not quite so black and white. In this post I explore this question by taking a look at the different types of consultants one may encounter in the wilds of the corporate jungle. My discussion is based on a typology of management consultants proposed by Mats Alvesson and Anders Johansson in a paper published in this book (see citation at the end of this post for the full reference).
Background
There is a considerable body of research on management consulting, most of which is tucked away in the pages of management journals and academic texts that are rarely read by professionals. It would take me too far afield to do even a cursory review of this literature so I’ll not go there, except to point out that much of the work can be classified as either strongly pro- or anti-consultant. This in itself is revealing: academics are just as divided in their opinions about consultants as professionals are. Indeed, to see just how strong the opinions are, here’s a small list of paper / book titles from the pro and anti-consultant camps
Pro
“Management Consulting as a Developer of SMEs”
“Process Consultation, Vol 1: Its Role in Organization Development”
Anti
“The Management Guru as an Organizational Witch Doctor”
“The Violent Rhetoric of Re-engineering: Management Consultancy on the Offensive”
These titles have been taken from the reference list in Alvesson and Johansson’s paper. A quick search on Amazon will reveal many more.
The pro camp depicts consultants as rational, selfless experts who solve complex problems for their clients, sometimes at considerable personal cost. The anti camp portrays them as politically-motivated, self-interested individuals whose main aim is to build relationships that ensure future work. The classification proposed by Alvesson and Johansson puts these extreme views in perspective.
A classification of management consultants
Alvesson and Johansson classify consultants into the following categories based on consultants’ claims to professionalism and their preferred approaches to dealing with political issues:
Esoteric experts
These consultants typically offer high expertise in some specialized area. Some examples of these include IT consultants specializing in complex products (such as ERP systems) and tax experts who have specialized knowledge typically not possessed by those who work within business organisations. As one might expect, esoteric experts have strong claims to professionalism.
One might think that such consultants have little need to play political games as their skill/knowledge does not threaten anyone within organizations. However, this is not always so because esoteric experts may portray themselves as being experts when they actually aren’t. In such cases they would have to use their social and political skills to cover up for their shortcomings. Perhaps more important, esoteric experts may also play politics to secure future gigs.
Typical clients of esoteric experts are purchasers of large IT systems, small organisations in occasional need of specialized skills (lawyers, accountants etc.) and so on.
Brokers of meaning
Brokers of meaning are sense makers: they help clients make sense of difficult or ambiguous situations. Typically brokers of meaning act as facilitators, teachers or idea-generators, who work together with clients to produce meaning. They often do not have deep technical knowledge like esoteric experts, but instead have a good understanding of human nature and the socio-political forces within organizations.
Brokers of meaning typically do not indulge in overt politics as the success of their engagements depends largely on their ability to gain the trust of a wide spectrum of stakeholders within the organization. That said, such consultants, once they have gained trust of a large number of people within an organization, are often able to influence key stakeholders in particular directions. Another way in which brokers of meaning influence decisions is through the skillful use of language – for example, depending on how one wants to portray it, an employee taking the initiative can be called gung-ho (negative) or proactive (positive).
Typical clients of brokers of meaning are managers who are faced with complex decisions.
Traders in trouble
The archetypal trader in trouble is the hatchet-man who is employed by a senior executive who wants to reduce costs. Since the work of these consultants typically involves a great deal of organizational suffering, they are careful to cast their aims in neutral or objective language. Indeed, much of the corporate doublespeak around layoffs (e.g. rightsizing) and cost reduction initiatives (e.g. productivity improvements) originated from traders in trouble. Typical outcomes of such consulting engagements involve massive restructuring on an organization-wide scale, often resulting in a lot of pain for minimal gain.
The work of such consultants is necessarily political – they must support senior management at all costs. Indeed this is another reason that they go to great lengths to portray their proposed solutions as being rational. On the other hand, their claim to professional knowledge is ambiguous as they often have to (knowingly) forgo actions that may be more logical and (more important!) ethical.
Alvesson and Johansson summarise this by quoting from Robert Jackall’s brilliant ethnographical study of managers, Moral Mazes:
The further the consultant moves away from strictly technical issues – that is from being an expert in the ideal sense, a virtuoso of some institutionalized and valued skill – the more anomalous his status becomes. He becomes an expert who trades in others’ troubles. In managerial hierarchies, of course, troubles, like everything else, are socially defined. Consultants have to depend on some authority ‘s definition of what is troublesome in an organization and, in most cases, have to work on the problem as defined. As it happens, it is extremely rare that an executive declares himself or his own circle to be the problem; rather, other groups in the corporation are targeted to be ‘worked on.
A terrific summary of the typical trader in trouble!
Clients of such consultants tend to be senior managers who have been tasked with increasing “efficiency” or “productivity.”
Agents of anxiety (suppliers of security)
The agent of anxiety is a messiah who sells a “best practice” solution to his clients’ problems. This type of consultant can therefore also be described as a supplier of security who assures his clients that their troubles will vanish if they just follow his prescribed process. Common examples of agents of anxiety are purveyors of project management methodologies and frameworks (such as PRINCE2 or IPMA) or process improvement techniques (such as Six Sigma).
Although such consultants may seem to have a high claim to professional expertise, they actually aren’t experts. A good number of them are blind followers of the methods they sell; rarely, if ever, do they develop a critical perspective on those practices. Also, agents of anxiety do not have to be overtly political: once they are hired by senior managers in an organization, employees have no choice but to follow the “best practice” techniques that are promoted.
Clients of such consultants tend to be senior managers in organisations that are having trouble with specific aspects of their work – projects, for example. What such managers do not realize is that they would be better served by creating and fostering the right work environment rather than attempting to impose silver bullet solutions sold by suppliers of security.
A comment
Now that we are done with the classification, I should mention that most of the consultants I have come across cannot be boxed into a single category. This is no surprise: consultants, like the rest of humanity, display behaviours that vary from situation to situation. Many consultants will display characteristics from all four categories within a single engagement or, at the very least, exhibit both professional and political behaviours. As Alvesson and Johansson state:
Management consultancy work probably typically means some blending of these four types. Sometimes one or two of the types dominates in the same assignment. But few management consultants presumably operate without appealing to the management fashions signalling the needs for consultancy services; few altogether avoid trouble-shooting tasks; few can solely rely on a technocratic approach, and few can simply work with cooperative meaning making processes. The complexity and diversity of consultancy assignments requires that the consultant move back and forth between a professional area and a non-professional area, i.e. areas viewed as coherent with claims of professionalism, recognizing the highly floating boundaries between these areas and the constructed character also of technical and professional work. Professional work is mingled with, but can’t be reduced to, political or symbolic work.
Finally, I should also add that consultants sometimes hide their real objectives because they are required to: their duplicity simply reflects the duplicity of those who hire them. Whether consultants should choose to do such work is another matter altogether. As I have argued elsewhere, the hardest questions we have to deal with in our professional lives are ethical ones.
Closing remarks
In this post I have described a typology of consultants. For sure, the four categories of consultants described are stereotypes. That said, although consultants may slip on different personas within a single engagement, most would fit into a single category based on the nature of their work and their overall approach. A knowledge of this classification is therefore helpful, not just for clients, but also for front-line employees who have to deal with consultants and those who hire them.
References
Alvesson, M. & Johansson, A.W. (2002). Professionalism and politics in management consultancy work. In R. Fincham & T. Clark (Eds), Critical consulting: New perspectives on the management advice industry. Oxford: Blackwell, pp. 228–246.
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…
Eight to Late 