My fellow ArgonDigital bloggers have written about the many virtues of Org Charts and their relationship to requirements elicitation and management. In case you missed it, here is a good summary of an org chart and how to use one in requirements gathering. To help catch you up to speed, an org chart is one of the first requirements activities you should engage in at the beginning of the project (or even when you join a project in the middle or end). Briefly, the org chart should be used to:
- Identify Key Project Stakeholders
- Identify Actors in Use Cases
- Delineate project roles and responsibilities.
In other words, the org chart drives many of the other requirements-related project activities. I’d like to talk about another, little-known use for an org chart–navigating project politics. Like it or not, politics are a part of any project, and successfully navigating project politics can mean the difference between project success and failure (Note that I did not say “playing project politics”. This is an entirely different matter altogether and a skill that I don’t recommend fostering). Unfortunately, there are few formal tools at the Product Manager’s disposal for recognizing political risks and avoiding political disasters before they happen. Typically, when projects are overly political, “navigating project politics” is an exercise in damage control rather than avoiding politically dicey situations to begin with.
The nice thing about using an org chart to help identify and manage the political realities of your project is that they are fairly simple to create and maintain, and it is easy to hand off to other team members. Additionally, an org chart should already exist on your project, so to create a Political Org Chart is just a matter of adding supplemental formatting to your project org chart.
It’s best to use an example to illustrate how to convert a standard org chart into one which bounds political realities. Consider the following org chart which displays a typical top-down hierarchical organizational structure. Such an org chart is useful for identifying key stakeholders, reporting structure, and areas of expertise (click on the image for a larger view):
This is a great org chart for determining which meetings to schedule with stakeholders and which actors should be included in Use Cases. However, there have been times on projects where I’ve needed answers to the following questions:
- Which other stakeholders does this SME have influence over?
- Which stakeholders does this SME not work well with?
- What are some other important non-organizational relationships between the members of the groups identified here?
Being able to answer such questions quickly and decisively is key to project success and to prevent wasting time in meetings. In order to help communicate such information, I designed an org chart like the following (click on the image for a larger view):
Green and Orange Colors denote spheres of influence: two or more team members who often rely on each other for guidance when making a decision. Like colors represent similar spheres of influence.
Red represents stakeholders who do not work well together. Avoid setting meetings where these two stakeholders are in the same room at the same time. Meet with them separately if at all possible.
Dotted lines represent “hidden” or extra-organizational groupings that are important to know. It could be something as simple as a familial relationship, but could also include relationships like “play on the same softball team” or “go to the same church”. These relationships aren’t always pertinent to requirements gathering, but might be helpful if you are having difficulty gaining the attention of one of the members of the group.
Note that the above, “political” version of the diagram highlights relationships that could not be interpreted from the standard org chart. It adds information that goes beyond reporting structures and areas of expertise. Such an org chart was especially useful on a large project where the Product Managers and Business Analysts would rotate out in “shifts” in a highly political environment. This format made it easier to hand off information about the project’s political realities as others ramped on the project. This made meetings more efficient and less stressful, and facilitated much easier sign off as the ‘spheres of influence’ could easily be navigated to identify stakeholders which could convince others of a particular solution.
An important warning: The political version of your org chart is likely a very sensitive document, and is probably best not shared with everyone on the project. I wish that such documents could be shared in the interests of open and honest communication, but not everyone appreciates exposing the political realities of their project to others. Keep it private, lest you commit political suicide, and use with caution.
