Political Risks

Few projects fail strictly for technical reasons. When I speak to colleagues about problems on a project, political problems always seem high on the list. This is a difficult subject to discuss, in part because every project and every customer is different. As a project manager, you must become politically savvy and aware, or you risk being broadsided by situations you did not anticipate. As with many risks, you may not be able to avoid being adversely affected by political risks, but you can at least identify the ones that may affect your project. This information may influence your decision-making such that you can avoid making a fatal political mistake. As the saying goes, forewarned is forearmed.

I believe that many political situations result in projects being set up for difficulties from the very beginning. Some of these situations were discussed in Chapter 3, "Getting Started: Request for Proposals (RFPs), Proposals, and Contracts." Many project managers find themselves joining a project too late to be able to influence some of the factors discussed in Chapter 3. Yet, there are other political risks that you can do something about. I will discuss these here.

An Example of Discovering a Political Risk

At a kickoff meeting for one project, I was discussing the history of how the project was identified and bid with my customer. On this particular project, a different contractor had already performed the requirements elicitation. My team's task was to take these requirements as input and implement the system. (This was more of a Waterfall-style project.) During the course of this discussion, my customer contact stated that an individual on his organization's upper management team had mistakenly thought the requirements elicitation effort performed by the first contractor involved delivering the completed system, not just performing the requirements elicitation. This individual had promised another member of the upper management team that the system would be completed, delivered, and in production at the conclusion of what was actually only the requirements elicitation! This caused severe embarrassment within this organization's upper management ranks. For this reason, there was great pressure to deliver the system as soon as possible. Every project has deadline pressure, but in this case, careers were clearly on the line. On this project, we therefore based our decisions on getting the project done on time, and we always chose the simplest and quickest solutions when multiple alternatives were identified.

Identifying Political Risks

To identify political risks, you need to think like a detective and ask a lot of questions of the stakeholders. Quite frankly, you can learn much by simply asking each stakeholder separately, "What do you see as the riskiest part of this project?" The stakeholders, particularly nontechnical people, will often launch into a discussion that frequently touches on political risks. This is good information, especially for an outsourced project. It is important to ask each stakeholder privately. In some organizations, political issues may not be discussed openly. Stakeholders may be more forthcoming with information if you speak to them privately. Since by definition an outsourced project involves separate organizations, you will be unaware of political situations that are common knowledge but that are seldom discussed in the open. Here are some other examples of questions to ask in these discussions:

• Were other potential solutions identified as alternatives to conducting this project? If so, what were the alternative solutions, and who was in favor of them?

• What experiences has the organization had in the past couple of years with other software projects? What projects have gone well, and which ones have gone poorly, and why?

• Was this project attempted previously? If so, what happened?

• Is anyone in the organization not in favor of the solution currently proposed? If so, why not?