Politics and counter-politics in project evaluation
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.
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.
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.