Archive for the ‘IT Management’ Category
Politics and counter-politics in project evaluation
Introduction
Ideally, project evaluation decisions should be made on the basis of objective criteria (cost/benefit, strategic value etc.). In reality, however, there is often a political dimension to the process: personal agendas, power games etc. play a significant role in determining how key stakeholders perceive particular projects. In a paper entitled Seven Ways to get Your Favoured IT Project Accepted – Politics in IT Evaluation, Egon Berghout, Menno Nijland and Kevin Grant discuss seven political ploys that managers use to influence IT project selection. This post presents a discussion of these tactics and some strategies that can be used to counter them.
The seven tactics
Before outlining the tactics it is worth mentioning some of the differences between political and rational justifications for a project. In general, the former are characterised by a lot of rhetoric and platitudes whereas the latter dwell on seemingly objective measures (ROI, cost vs. benefit etc.). Further, political justifications tend to take a “big picture” view as opposed to the detail-oriented focus of the rational ones. Finally, it is worth mentioning that despite their negative connotation, political ploys aren’t always bad – there are situations in which they can lead to greater buy-in and commitment than would be possible with purely rational decision-making methods.
With that for background, let’s look at seven commonly used political tactics used to influence IT project decisions. Although the moves described are somewhat stereotypical and rather obvious, I do believe they are used quite often on real-world projects.
Here they are:
1. Designate the project as being strategic: In this classic ploy, the person advocating the project designates a project as being necessary in order to achieve the organisation’s strategic goals. To do this one may only need to show a tenuous connection between the project objectives and the organisation’s strategy. Once a project is deemed as being strategic, it will attract support from the upper echelons of management – no questions asked.
2. The “lights on” ploy: This strategy is to dub the project as an operational necessity. Here the idea is to indulge in scare-mongering by saying things like – “if we don’t do this, we run an 80% chance of system failure within the next year.” Such arguments are often used to justify expensive upgrades to legacy systems.
3. The “phase” tactic: Here the idea is to slice up a project into several smaller sub-projects and pursue them one at a time. This strategy keeps things under the organisation’s financial radar until the project is already well under way, a technique often used by budget-challenged IT managers.
4. Creative analysis: Most organisations have a standard process by which IT projects are evaluated. Typically such processes involve producing metrics to support the position that the project is worth pursuing. The ideas here is to manipulate the analysis to support the preferred decision. Some classic ways of doing this include ignoring negative aspects (certain risks, say) and/or overstating the benefits of desired option.
5. Find a problem for your solution: This strategy is often used to justify introducing a cool new technology into an organisation. The idea here is to create the perception that the organisation has a problem (where there isn’t necessarily one) and that the favoured technology is the only way out of it. See my post on solutions in search problems for a light-hearted look at warning signs that this strategy is in use.
6. No time for a proposal: Here the idea is to claim that it would take too much time to do a proper evaluation (the implication being that the person charged with doing the evaluation is too busy with other important matters). If successful, one can get away with doing a bare-bones evaluation which leaves out all inconvenient facts and details.
7. Old wine in a new bottle: This strategy is employed with unsuccessful project proposals. The idea here is to resubmit the proposal with cosmetic changes in the hope that it gets past the evaluation committee. Sometimes a change in the title and focus of the project is all that’s needed to sneak it past an unwary bunch of evaluators.
Of course, as mentioned earlier, there’s a degree of exaggeration in the above: those who sanction projects are not so naïve as to be taken in by the rather obvious strategies mentioned above. Nevertheless, I would agree with Berghout et. al. that more subtle variants of these strategies are sometimes used to push projects that would otherwise be given the chop.
Countering politics
The first step in countering political ploys such as the ones listed above is to understand when they are being used. The differences between political and rational behaviour were outlined by Richard Daft in his book on organisational theory and design. These are summarised in the table below (adapted from the paper):
| Organisational Feature relating to decision making | Rational response or behaviour | Political response or behaviour |
| Goals | Similar for all participants – aligned with organisational goals | Diversity of goals, depending on preferences and personal agendas |
| Processes | Rational, orderly. | Haphazard – determined by dominant group |
| Rules/Norms | Optimisation – to make the “best” decision (based on objective criteria) | Free for all – characterised by conflict |
| Information | Unambiguous and freely available to everyone | Ambiguous, can be withheld for strategic reasons |
| Beliefs about cause-effect | Known, even if only incompletely | Disagreement about cause-effect relationships |
| Basis of decisions | Maximisation of utility | Bargaining, interplay of interests |
| Ideology | Organisational efficiency and effectiveness | Individual/ group interest |
Although Daft’s criteria can help identify politically influenced decision-making processes, it is usually pretty obvious when politics takes over. The question then is: what can one do to counter such tactics?
The authors suggest the following:
1. Go on the offensive: This tactic hinges on finding holes in the opponents’ arguments and proposals. Another popular way is to attack the credibility of the individuals involved.
2. Develop a support base-: Here the tactic is to get a significant number of people to buy into your idea. Here it is important to focus efforts on getting support from people who are influential in the organisation.
3. Hire a consultant: This is a frequently used tactic, where one hires an “independent” consultant to research and support one’s favoured viewpoint.
4. Quid pro quo: This is the horse-trading scenario where you support the opposing group’s proposal with the understanding that they’ll back you on other matters in return.
Clearly these tactics are not those one would admit to using, and indeed, the authors’ language is somewhat tongue-in-cheek when they describe these. That said, it is true that such tactics – or subtle variants thereof – are often used when countering politically motivated decisions regarding the fate of projects.
Finally, it is important to realise that those involved in decision making may not even be aware that they are engaging in political behaviour. They may think they are being perfectly rational, but may in reality be subverting the process to suit their own ends.
Conclusion
The paper presents a practical view on how politics can manifest itself in project evaluation. The authors’ focus on specific tactics and counter tactics makes the paper particularly relevant for project professionals. Awareness of these tactics will help project managers recognise the ways in which politics can be used to influence decisions as to whether or not projects should be given the go-ahead .
In closing it is worth noting the role of politics in collective decision-making of any kind. A group of people charged with making a decision will basically argue it out. Individuals (or sub-groups) will favour certain positions regarding the issue at hand and the group must collectively debate the pros and cons of each position. In such a process there is no restriction on the positions taken and the arguments presented for and against them. The ideas and arguments needn’t be logical or rational – it is enough that someone in the group supports them. In view of this it seems irrational to believe that collective decision making – in IT project evaluation or any other domain – can ever be an entirely rational process.
The four destructive enthusiasms of IT
Introduction
Several surveys have indicated that IT projects – especially large ones – fail at an alarming rate. In a paper entitled, Pessimism, Computer Failure, and Information Systems Development in the Public Sector, Shaun Goldfinch mentions that 20-30% of projects costing more than $ 10 million are abandoned altogether. Further, over half are over time and/or budget, and do not deliver to expectations. Although Goldfinch’s paper focuses on IT investments in the public sector, the situation in the private sector isn’t much better.
Goldfinch makes the observation that,
Enthusiasm for large and complex investments in IS continues unabated despite decades of failure. Indeed, the largest-ever public sector project was initiated in 2002 by the United Kingdom’s National Health Service at an estimated cost of US$11 billion…
He proposes a model of four pathological enthusiasms which cause key stakeholders to talk-up benefits and downplay difficulties when advocating such projects. In this post, I take a brief look at the model and its utility evaluating project proposals.
The four enthusiasms model
Many projects begin as ideas which originate from a small number of enthusiastic advocates. Often a single enthusiast with sufficient influence can push an ill-conceived project through the approval stages to the point where it is given the go-ahead. According to Goldfinch, such misplaced enthusiasm generally falls into one of the following categories:
- Idolisation (Technological Infatuation): This is a situation where a key business stakeholder believes that business problems can always be solved by technology. Projects driven by such people place technology at the heart of the solution. Such efforts often fail because not enough attention is paid to other factors (people, processes etc.).
- Technophilia: This refers to the IT profession’s belief that all problems have technical solutions. As Goldfinch puts it, “it is the myth of the technological fix, in which “the entire IS profession perpetuates the myth that better technology, and more of it, are the remedies for practical problems.” Efforts driven by technophilia fail because those who are involved get too caught up in learning and mastering the technology rather than solving the problem.
- Lomanism: This term, derived from the protagonist in the play Death of a Salesman, refers to the (real or feigned) over-enthusiasm that IT sales and marketing professionals have for their companies’ products. Unfortunately such folks often have the ear of IT decision-makers who are susceptible to sales pitches that promise untold (but unrealistic) benefits. On the other hand it should also be mentioned that Lomanism is often a response to unrealistic customer expectations coupled with the pressure to meet sales targets. The only clear beneficiaries from Lomanism-driven efforts are technology vendors.
- Managerial faddism: This refers to the tendency of managers and senior executives to fall under the spell of the latest management fads. Many of these fads recommend a wholesale overhaul of organizational structures and processes, and are often accompanied by technical tools. IT service management methodologies are good examples of such fads.
Goldfinch states that:
Together, these four enthusiasms feed on and mutually reinforce one another in a vicious cycle, creating a strongly held belief that newer and larger IS projects are a good idea. Doubters and skeptics may be portrayed as “negative,” “not team players,” “not helpful”… Together, these pathologies make up the four enthusiasms of IT failure. When a project does encounter difficulties, these four enthusiasms can undermine attempts to curtail or abandon the project — a project can always be fixed with better management, a redesigned monitoring system or contract, more technology or hardware, better programming, or just a reassuring “it’ll be right on the night.”
Conclusion
Goldfinch suggests that large IT projects are often driven by one of four types of enthusiasm. These can lead to projects being driven by nothing more than wishful thinking and undue optimism. To counter this, he recommends that decision-makers take a pessimistic view when evaluating proposals for IT projects. Among other things this means questioning assumptions, particularly those relating to the technology that will be employed. Independent opinions are a good way to do this, but truly unbiased ones can be hard to come by (vested interests aren’t always obvious). In the end the solution may be as simple as relying on one’s own common sense and judgement. That’s where the model can help: viewing a business case or project proposal through the lens of the model can show up over-optimistic claims and projections.
Doing the right project is as important as doing the project right
Introduction
Many high profile projects fail because they succeed. This paradoxical statement is true because many projects are ill-conceived efforts directed at achieving goals that have little value or relevance to their host organisations. Project management focuses on ensuring that the project goals are achieved in an efficient manner. The goals themselves are often “handed down from above”, so the relevance or appropriateness of these is “out of scope” for the discipline of project management. Yet, the prevalence of projects of dubious value suggests that more attention needs to be paid to “front-end” decision making in projects – that is, decision making in the early stages, in which the initiative is just an idea. A paper by Terry Williams and Knut Samset entitled, Issues in front-end decision making on Projects looks at the problems associated with formulating the “right” project. This post is a summary and review of the paper.
What is the front-end phase of the project? According to Williams and Samset, “The front-end phase commences when the initial idea is conceived and proceeds to generate information, consolidate stakeholders’ views and positions, and arrive at the final decision as to whether or not to finance the project.”
Decisions made in the early stages of a project are usually more consequential than those made later on. Most major parameters – scope, funding, timelines etc. are more or less set in stone by the time a project is initiated. The problem is that these decisions are made at a time when the availability of relevant information is at its lowest. This highlights the role of sound judgement and estimation in decision making. Furthermore, these decisions may have long-term consequences for the organisation, so due care needs to be given to alignment of the project concept with the organisation’s strategic goals. Finally, as the cliché goes, the only constant is change: organisations exist in ever-changing environments, so projects need to have the right governance structures in place to help navigate through this turbulence. The paper is an exploration of some of these issues as they relate to front-end decision making in projects.
Defining the project concept
Williams and Samset define the terms concept as a mental construction that outlines how a problem will be solved or a need satisfied. Note that although the definition seems to imply that the term concept equates to technical approach, it is more than that. The project concept also includes considerations of the outcomes and their impact on the organisation and its environment.
The authors emphasise that organisations should to conceive several distinct concepts prior to initiating the project. To this end, they recommend having a clearly defined “concept definition phase” where the relevant stakeholders create and debate different concepts. Choosing the right concept is critical because it determines how the project will be carried out, what the end result is and how it affects the organisation. The authors emphasise that the concept should be determined on the basis of the required outcome rather than the current (undesirable) situation.
When success leads to failure
This is the point alluded to in the introduction: a project may produce the required outcomes, but still be considered a failure because the outcomes are not aligned with the organisation’s strategy. Such situations almost always arise because the project concept was not right. The authors describe an interesting example of such a project, which I’ll quote directly from the paper:
One such example is an onshore torpedo battery built inside the rocks on the northern coast of Norway in 2004 (Samset, 2008a). The facility was huge and complex, designed to accommodate as many as 150 military personnel for up to three months at a time. It was officially opened as planned and without cost overrun. It was closed down one week later by Parliamentary decision. Clearly, a potential enemy would not expose its ships to such an obvious risk: the concept had long since been overtaken by political, technological, and military development. What was quite remarkable was that this project, which can only be characterized as strategic failure, got little attention in the media, possibly because it was a success in tactical terms.
A brilliant example of a successful project that failed! The point, of course, is that although the strategic aspects of projects are considered to be outside the purview of project management, they must be given due consideration when the project is conceptualized. The result of a project must be effective for the organisation, the efficiency of project execution actually matters less.
Shooting straight – aligning the project to strategic goals
Aligning projects with strategic goals is a difficult because the organizational and social ramifications of a project are seldom clear at the start. This is because the problem may be inherently complex – for example, no one can foresee the implications of an organizational restructure (no, not even those expensive consultants who claim to be able to). Further, and perhaps more important, is the issue of social complexity: stakeholders have diverse, often irreconcilable, views on what needs to be done, let alone how it should be done. These two factors combine to make most organizational issues wicked problems.
Wicked problems have no straightforward solutions, so it is difficult if not impossible to ensure alignment to organizational strategy. There are several techniques that can be used to make sense of wicked problem. I’ve discussed one of these – dialogue mapping – in several prior posts. Paul Culmsee and I have elaborated on this and other techniques to manage wicked problems in our book, The Heretic’s Guide to Best Practices.
One has to also recognize that the process of alignment is messier still because politics and self interest play a role, particularly when the stakes are high. Further, at the individual level, decisions are never completely objective and are also subject to cognitive bias – which brings me to the next point…
Judgement and the formulation of organizational strategy
Formulating organizational strategy depends on making informed and accurate judgements about the future. Further, since strategies typically cover the mid to long term, one has to also allow some flexibility for adjustments along the way as one’s knowledge improves.
That’s all well and good, but it doesn’t take into account the fact that decision making isn’t a wholly rational process – humans who make the decisions are, at best, boundedly rational (sometimes rational, sometimes not). Bounded rationality manifests itself through cognitive biases – errors of perception that can lead us to making incorrect judgements. See my post on the role of cognitive bias in project failure for more on how these biases have affected high profile projects.
The scope for faulty decision making (via cognitive bias or any other mechanism) is magnified when one deals with wicked problems. There are a number of reasons for this including:
- Cause-effect relationships are often unclear.
- No one has complete understanding of the problem (the problem itself is often unclear).
- Social factors come into play (Is it possible make an “unbiased” decision about a proposed project that is going to affect one’s livelihood?)
- Consequent from points 1 through 3, stakeholders perceive the problem (and its solution) differently.
It is worth pointing out that project planning is generally “less wicked” than strategy formulation because the former involves more clear cut goals (even though they may be wrong-headed). There is more scope for wickedness in the latter because there are many more unknowns and “unknowables.”
Why estimates are incorrect
Cost is a major factor in deciding whether or not a project should go-ahead. Unfortunately, this is another front-end decision; one which needs to be made when there isn’t enough information available. In his book, Facts and Fallacies of Software Engineering, Robert Glass names poor estimation as one of the top causes of project failure. This is not to say that things haven’t improved. For example, Agile methods which advocate incremental/iterative development continually refine initial estimates based on actual, measurable progress.
Techniques such as reference class forecasting have been proposed to improve estimation for projects where incremental approaches are not possible (infrastructural projects, for example). However, this technique is subject to the reference class problem.
Finally, all the aforementioned techniques assume that reliable information on which estimates can be based is a) available and b) used correctly. But this is just where the problem lies: the two key factors that lead to poor estimation are a) the lack of knowledge about what exactly the work entails and b) the fact that people may misunderstand or even misrepresent the information if it is available.
Governance in an ever-changing environment
A negative consequence of the quest for organizational agility and flexibility is that organizational environments are turbulent. The main point of the paper is that traditional project management (as laid out in frameworks such as PMBOK) Is ill-suited to such environments. As they state:
The key point in this article, however, is that the environment in which most projects operate is complex and turbulent, and conventional project management is not well suited to such conditions, despite the attraction of project organization to companies in fast-moving environments seeking agility and responsiveness…
Yet, ironically, this uncertainty is the reason for the spectacular growth in adoption of project management methodologies (see this post for a discussion of a relevant case study).
For project management to be truly useful, it must be able to cope with and adapt to turbulent environments. To this end, it may be best to view project management as a set of activities that emerge from a real need rather than an arbitrary imposition dictated by methodologies that are divorced from reality. This is nothing new: iterative/incremental methods, which advocate adaptation of methods to suit the environment, are a step in this direction.
Adaptive methods are obviously easier to apply on smaller projects than larger ones. However, one could argue that the need for flexibility and adaptability is even greater on massive megaprojects than smaller ones. A major consequence of a changing environment is that people’s views on what needs to be done diverge. Recent work in applying dialogue mapping to large project environments shows that it is possible to reduce this divergence. Getting people on the “same page” is, I believe, the first step to successful governance, particular in unstable environments.
Lack of information
The most important decisions on projects have to be made upfront, when little or no reliable information is available. The authors argue that the lack of information can actually be a benefit in front-end decision for the following reasons:
- Too much information can lead to confusion and analysis paralysis.
- Information can get out of date quickly – forecasts based on outdated information can be worse than useless because they can mislead.
- It is often hard to tell between important and irrelevant information. The distinction may only become clear as the project proceeds.
Be that as it may, one cannot deny that front-end decision making is hampered by the lack of relevant information. The real problem, though, is that decisions are often made by those who cannot tell the difference between what’s important and what’s not.
Conclusion
The article is an excellent summary of the major impediments in front-end decision making on projects. Such decisions have a major impact on how the project unfolds, yet they are often made with little or no consideration of what exactly the project will do for the organisation, or what its impact will be.
In my experience, front-end decisions are invariably made in an ad-hoc manner, rooted more in hope and fantasy than reality. A first step to ensuring that organizations do the right project is to ensure that all stakeholders have a common understanding of the goals of the project – that is, what needs to be done. The next is to ensure a common understanding of how those goals will be achieved. Such stakeholder alignment is best achieved using communication-centric, collaborative techniques such as dialogue mapping. Only then, after ensuring that one is doing the right project, does it make sense to focus on doing the project right.
Eight to Late 