Archive for the ‘Consulting’ Category
A corporate outsourcer’s spiel in five stanzas
Note: Despite references to this sorry saga, the author affirms that this is a work of fiction.
Good morning, Mr. CEO Sir,
we offer services complete.
We’ll take care of your computers,
and fudge your balance sheet.
We’ll overstate your revenue,
and inflate profits.
Thus boosting your share value
in global stock markets.
We’ll find you well-known auditors
to sign off your accounts.
A thumbs-up from their managers
will put to rest all doubts.
Soon you’ll get rewards for sure,
despite such malfeasance.
Trophies and awards galore
for corporate governance.
I trust our varied expertise
gives you confidence.
We’ll take good care of your IT
…and your finances.
Project execution: efficiency versus learning
Most projects are subject to tight constraints. As a consequence, project teams are conditioned to focus on efficiency of project execution – i.e. to get things done within the least possible time, effort and expense. In this post I explore another approach; one that emphasises learning over efficiency. Now I know this sounds somewhat paradoxical: we all know learning takes time – and time’s the one commodity that’s universally in short supply on projects. However, please read on – I hope to convince you that an emphasis on learning may actually improve efficiency. My discussion is based on a recent Harvard Business Review article entitled, The Competitive Imperative of Learning, in which the author, Professor Amy Edmondson, presents two perspectives on organisational execution, which she defines as “the efficient, timely, consistent production and delivery of goods or services.” The two perspectives are: “execution as efficiency” and “execution as learning.” The former emphasises getting the job done, whereas the latter underscores the importance of finding better ways to get the job done. Projects are organisations too – albeit temporary ones – so the two views of execution discussed in the article may be relevant to project environments. This post discusses execution as efficiency vs. execution as learning in the context of project management.
Professor Edmondson compares and contrasts the two views of execution as follows:
| Execution as efficiency | Execution as learning |
| Leaders provide answers. | Leaders set direction and articulate mission. |
| Employees follow directions. | Employees discover the way. |
| Optimal work processes are designed and set up in advance. | Tentative work processes are set up as a starting point. |
| New work processes are developed infrequently. | Work processes are ever evolving and improving. |
| Feedback is one way (manager to team). | Two way feedback is common. |
| Employees rarely exercise judgement and make decisions. | Employees continually make important judgement-based decisions. |
The reader will notice that the efficiency approach is rigid and very “top-down” whereas the learning approach is flexible and if not quite “bottom-up”, at least open to change. The remainder of this note discusses the latter might work in a project environment.
In projects the focus is on getting the job done in time and on budget. This sometimes (often?) leads to micro-management of project execution to the extent that team members are given detailed directions on how they should do their tasks. This corresponds to the efficiency approach. In contrast, the execution as learning way recommends that project managers set the overall objectives and leave team members to find their own way to achieve them (within parameters of scope, time and budget).
On a similar note, as I have written in a post on motivation, the best way to ensure that people remain engaged in their work is to give them autonomy – i.e. empower them to make decisions pertaining to their work. This is true both in (permanent) organisations and projects. Many project managers are reluctant to delegate responsibility to team members – and here I mean proper delegation, where team members are given responsibility and decision rights over all issues that come up in their work. Granted, on some projects it may not be possible to delegate these rights entirely. Nevertheless, even in such cases it should still be possible to make decisions in a collaborative manner, with input from all affected parties.
In another post I pointed out that project management methodologies are sometime implemented wholesale, without any regard to their appropriateness for a particular project. This corresponds to an execution as efficiency approach where directions are followed without question. In contrast, an execution as learning approach is one in which processes are adopted and adapted as required. This is better because it uses only those processes that contribute to achieving a project’s objectives; anything more is recognised as bureaucratic overhead – good only for generating pointless documentation and wasting time. This applies to not only to project management processes, but also to processes used in the creation of deliverables. This bit of common sense can be codified into a “principle of minimal process” which may be stated as follows: one should not increase, beyond what is necessary, the number of processes to achieve a particular end. This principle is akin to the principle of parsimony or Occam’s Razor in the sciences. Furthermore, in an execution as efficiency approach, processes, once established, rarely change. However, a project’s environment is always subject to change. In response to this, execution as learning recommends that processes be continually reviewed and tweaked, or even overhauled, as needed. What works well today may not work so well tomorrow. Bottom line: process is good as long as it contributes to getting the project done, anything that doesn’t should be discarded or fixed (i.e. improved).
An execution as efficiency approach downplays the need for communication because it is assumed that all processes are already running as efficiently as they possibly can. Communication in these environments tends to be one-way: from top to bottom. In contrast, in learning-oriented environments communication is a two way process: those doing the work suggest process improvements to management and management, in turn, provides feedback. Two-way communication is therefore an important element of execution as learning in organisations. I’d argue this is especially the case for projects because – as all project managers know – change (in scope, timeline, budget or whatever) is inevitable.
To conclude: projects are organisations, albeit temporary ones. Therefore, principles and learnings from research on permanent organisations should be checked for potential applicability to project environments. With this in mind, it may be more productive to approach project execution with a learning mindset rather than a focus on efficiency. Of course, this is not new – proponents of agile techniques have long advocated such an approach; learning is at the heart of the the agile manifesto. That said, I’d love to hear what you think; I look forward to your comments.
A new perspective on risk analysis in projects
Introduction
Projects are, by definition, unique endeavours. Hence it is important that project risks be analysed and managed in a systematic manner. Traditionally, risk analysis in projects – or any other area – focuses on external events. In a recent paper entitled, The Pathogen Construct in Risk Analysis, published in the September 2008 issue of the Project Management Journal, Jerry Busby and Hongliang Zhang articulate a fresh perspective on risk analysis in projects. They argue that the analysis of external threats should be complemented by an understanding of how internal decisions and organisational structures affect risks. What’s really novel, though, is their use of metaphor: they characterise these internal sources of risk as pathogens. Below I explore their arguments via an annotated summary of their paper.
What’s a risk pathogen?
“Risk,” the authors state, “is a statistical concept of events that happen to someone or something.” Traditional risk analysis concerns itself with identifying risks, determining the probability of their occurrence, and finding ways of dealing with them. Risks are typically considered to be events that are external to an organisation. This approach has its limitations because it does not explicitly take into account the deficiencies and strengths of the organisation. For example, a project may be subject to risk due to the use of an unproven technology. When the risk becomes obvious, one has to ask why that particular technology was chosen. There could be several reasons for this, each obviously flawed only in hindsight. Some reasons may be: a faulty technology selection process, over optimism, decision makers’ fascination with new technology or some other internal predisposition. Whatever the case, the “onditions that lead to the choice of technology existed prior to the event that triggered the failure. The authors label such preexisting conditions pathogens. In the authors’ words, “At certain times, external circumstances combine with ‘resident pathogens’ to overcome a system’s defences and bring about its breakdown. The defining aspect of these metaphorical pathogens is that they predate the conditions that trigger the breakdown, and are generally more stable and observable.”
It should be noted that the pathogen tag is subjective – that is, one party might view a certain organisational predisposition as pathogenic whereas another might view it as protective. To illustrate using the above example – management might view a technology as unproven, whereas developers might view it as offering the company a head start in a new area. Perceptions determine how a “risk” is viewed: different groups will select particular risks for attention, depending on the cultural affiliations, background, experience and training. Seen in this light, the subjectivity of the pathogen label is reasonable, if not obvious. In the paper, the authors examine risk pathogens in projectised organisations, with particular focus on the subjectivity of the label (i.e. different perceptions of what is pathogenic). Why is this important? The authors note that in their studies, “the most insidious kind of risk to a project – the least well understood and potentially the most difficult to manage if materialised – was the kind that involved contradictory interpretations.” These contradictory interpretations must be recognised and addressed by risk analysis; else they will come in the way of dealing with risks that become reality.
The authors use a case study based approach, using a mix of projects drawn from UK and China. In order to accentuate the differences between pathogenic and protective perspectives of “pathogens”, the selected projects had both public and private sector involvement. In each of the projects, the following criteria were used to identify pathogens. A pathogen
- Is the cause of an identifiable adverse organisational effect.
- Is created by social actors – it should not be an intrinsic vulnerability such as a contract or practice.
- Exists prior to the problem – i.e. it predates the triggering event.
- Becomes a problem (or is identified as a problem) only after the triggering event.
The authors claim that in all cases studied, the pathogen was easily identifiable. Further it was also easy to identify contradictory interpretations (protective behaviour) made by other parties. As an example, in a government benefits card project, the formulation of requirements was done only at a high-level (pathogen). The project could not be planned properly as a consequence (triggering event). This lead to poor developer performance and time/cost overruns (effect). The ostensible reason for doing requirements only at a high-level was to save time and cost in the bidding process (protective interpretation). Another protective interpretation was that detailed requirements would strait-jacket the development team and preclude innovation. Note that the adaptive (or protective) interpretation refers to a risk other than the one that actually occurred. This is true of all the examples listed by the authors – in all cases the alternate interpretation refers to a risk other than the one that occurred, implying that the risk that actually occurred was somehow overlooked or ignored in the original risk analysis. It is interesting to explore why this happens, so I’ll jump straight to the analysis and discussion, referring the reader to the paper for further details on the case studies.
Analysis and Discussion
From an analysis of their data, the authors suggest three reasons why a practice that is seen as adaptive, might actually end up being pathogenic:
- Risks change with time, and managing risk at one time cannot be separated from managing it at another. For example, a limited-scale pilot project may be done on a shoestring budget (to save cost). A successful pilot may be seen as protective in the sense that it increases confidence that the project is feasible. However, because of the limited scope of the pilot, it may overlook certain risks that are triggered much later in the project.
- Risks are often interdependent – i.e. how one risk is addressed may affect another risk in an adverse manner (e.g. increase the probability of its occurrence)
- The stakeholders in a project do not have unrestricted choices on how they can address risks. There are always constraints (procedural or financial, for example) which restrict options on how risks can be handled. These constraints may lead to decisions that affect other risks negatively.
I would add another point to this list:
- Stakeholders do not always have all the information they need to make informed decisions on risks. As a consequence, they may not foresee the pathogenic effect of their decisions. The authors allude to this in the paper, but do not state it as an explicit point. In their words, “Being engaged in a particular stage of a project selects certain risks for a project manager’s attention, and the priority becomes dealing with these risks rather than worrying about how widely the way of dealing with them will ramify into other stages of the project.”
The authors then discuss the origins of subjectivity on whether something is pathogenic or adaptive. Their data suggests the following factors play an important role in how a stakeholder might view a particular construct:
- Identity: This refers to the roles people play on projects. For example, a sponsor might view a quick requirements gathering phase as protective, in that it saves time and money; whereas a project manager or developer may view it as pathogenic, as it could lead to problems later.
- Expectations of blame: It seems reasonable that stakeholders would view factors that cause outcomes that they may be blamed for as pathogenic. As the authors state, “Blameworthy events become highly specific risks to an individual and the origin of these events – whether practices, artefacts or decisions – become relevant pathogens.” The authors also point out that the expectation of blame plays a larger role in projectised organisations – where project managers are given considerable autonomy – compared to functional organisations where blame may be harder to apportion.
Traditional risk analysis, according to the authors, focus on face-value risks – i.e. on external threats – rather than the subjective interpretations of these risks by different stakeholders. To quote, “…problematic events become especially intractable because of actors’ interpretation of risk are contradictory.” These contradictory interpretations are easy to understand in the light of the discussion above. This then begs the question: how does one deal with this subjectivity of risk perception? The authors offer the following advice, combining elements of traditional risk analysis with some novel suggestions:
- Get the main actors (or stakeholders) to identify the risks (as they perceive them), analyse them and come up with mitigation strategies.
- Get the stakeholders to analyse each others analyses, looking for contradictory interpretations of factors.
- Get the stakeholders together, to explore the differences in interpretations particularly from the perspective of whether:
- These differences will interfere with management of risks as they arise.
- There are ways of managing risks that avoid creating problems for other risks.
They suggest that it is important to avoid seeking consensus, because consensus invariably results in compromises that are sub-optimal from the point of view of managing multiple risks
I end this section with a particularly apposite quote from the paper, “At some point the actors need to agree on how to get on with the concrete business of the project, but they should be clear not only about the risks this will create for them, but also the risks it creates for others – and the risks that will come from others trying to manage their risks.” That, in a nutshell, is the message of the paper.
Conclusion
The authors use the metaphor of a pathogen to describe inherent organisational characteristics or factors that become “harmful” or “pathogenic” when certain risks are triggered. The interpretations of these factors subjective in that one person’s “pathogen” may be another person’s “protection”. Further, a factor that offers protection at one stage of a project may in fact become pathogenic at a later stage. Such contradictory views must be discussed in an open manner in order to manage risks effectively.
Although the work is based on relatively few data points, it offers a novel perspective on the perception of risks in projects. In my opinion the paper is well written, interesting and well worth a read for academics, consultants and project managers.
References:
Busby, Jerry. & Zhang, Hongliang., The Pathogen Construct in Risk Analysis, Project Management Journal, 39 (3), 86-96. (2008).
Eight to Late 