Project Management Part 2 - Stakeholders

Introduction

In my previous article, I touched on the basic concepts and principles of Project Management. This article focuses more on the Stakeholder Analysis aspect and serves as the essential elements that will build the project foundation.

Where do you start?

So you're all hyped up about your latest project and you want to know where to start. Well, before you run off and fire up your IDE, I suggest you take the time to lay the foundation for what it is you will be working on. This foundation starts with identifying the project stakeholders. Without concrete, there is no foundation, likewise, without stakeholders, there is no project. (You didn't think Project Management was all about setting up a CVS repository did you? ;P )

What is a stakeholder?

In general, a stakeholder is anyone who will use, create, or have an impact on any aspect of your project. I like to classify stakeholders in two primary groups:

• Direct Stakeholders - These are the people (developers, managers, customers) that are directly involved in your project's lifecycle (more on lifecycle later).
• Indirect Stakeholders - These are the people who are not directly involved in your project, but have the political power to influence the project.

Once you have identified who these people are, it may be necessary to classify them into sub-groups (i.e. developers, managers, etc.). Then you must choose a representative (point of contact, or POC as they are commonly referred) for each group that has both the responsibility and authority (R&A) to make decisions on behalf of those whom they represent. I stress the R&A because without both, the POC is destined for failure. That is, if I have the responsibility to make a decision but don't have the authority to do so, I can never bring a concept to fruition. Likewise, if I have authority over the project, but I am not responsible for the outcome, I am likely to make, shall we say, stupid decisions. Either way, both are a hindrance to the project. So remember, the POC needs to have R&A.

Stakeholder analysis - also known as project politics

As you become increasingly successful in your career, the decisions you make will have an effect on an ever-increasing number of people. The more people you affect then leads to a direct impact on those above you who have power and influence over your projects. These people could be strong proponents of your work, or they could block it altogether. Stakeholder analysis is the technique used to identify those people who need to be won over.

Identifying the direct stakeholders is usually quite obvious, it's the indirect stakeholders that always seem to come back and haunt you. The political exercise I am about to present is the type of exercise that's done behind closed doors and in strict confidentiality. As the nature of the exercise unfolds, you will see why.

Here's the scenario

Company Bob-CP is currently in the process of developing an OCR project for reading license plates on automobiles at the busy Metropolis airport. The CEO, Dr. Baa, has just been briefed on the project and isn't sure if he wants to commit to it or not. John, a long trusted friend and confidant of Dr. Baa is on the board of directors and has not yet heard of the project. Sally, the SW Engineering director, has worked with John on several high-profile projects before his retirement from the company last year. Julie, the SW Engineering VP, is slightly skeptical of the project after getting all the details from Sally. Sally and Julie have worked successfully together for the past four years. Julie and Dr. Baa also share several project successes and have a trusting relationship. Jerry, the director of market research, is strongly opposed to the project and has bumped heads with Sally several times in the past. Jerry thinks he has a good relationship with Julie, but several years earlier he went behind Julie's back on making a decision that caused a major contract to be cancelled. John was the SW Engineering VP at the time and never realized the extent of Jerry's manipulation until after the customer cancelled the contract.

Your job as the Project Manager (PM) is to ensure that Dr. Baa is convinced that the project is a sound business decision and decides to give it his endorsement.

OK, our first step here is to map out these stakeholders and illustrate their power to influence the project and their position on the issue. We also want to identify how easy they will be to convince and illustrate their working relationships. We do this by constructing a "political map" as illustrated in the following figure.

As you can see, I used shapes to identify how hard a given individual will be to convince, and two types of lines to show relationships. Note the relationship between Jerry and Julie. The solid line shows that Jerry thinks he has a good relationship with Julie, however the dashed line coming back shows that the relationship is not mutual. As you can imagine, these diagrams could become quite complex and sensitive, which is why this exercise is done in strict confidence. It is important to be thoroughly open and honest while conducting this exercise, as these relationships are a real risk item that may potentially cancel your project.

So now that everything is on the proverbial table, it becomes clear what nodes in the network need to be reached. If Sally could convince John to endorse the project and continue to work on Julie, then, through Julie and John, Dr. Baa can be brought on-board with the idea. You can see that Sally must obviously spend more effort in reaching out to Julie than will be necessary for John. And although Jerry is loud and obnoxious, he has no power to cancel the project and since his relationship with Julie is weak, he becomes a minimal threat.

Obviously, real-life is never so simple, but this is still a necessary item to consider when doing your stakeholder analysis.

Keeping them informed

Now that you have won support for your project, it is necessary to gauge the level of effort you need to adopt in order to keep your stakeholders informed about the project. This is done by using another stakeholder map similar to the one illustrated below. ^[1]

Map out your stakeholders using the Power/Interest Grid shown above, and classify them by their power over your work and by their interest in your work. For instance, your boss is likely to have high power and influence over your projects and high interest. Your fellow CPians may have high interest, but are unlikely to have power over it.

Someone's position on the grid shows you the actions you have to take with them:

• High power, interested people: these are the people you must fully engage and make the greatest efforts to satisfy. (Read: They pay the bills.)
• High power, less interested people: put enough work in with these people to keep them satisfied, but not so much that they become bored with your message. (Read: They approve your budget.)
• Low power, interested people: keep these people adequately informed, and talk to them to ensure that no major issues are arising. These people can often be very helpful with the details of your project.
• Low power, less interested people: again, monitor these people, but do not bore them with excessive communication. (Read: They have more important technical discussions to carry on in the Soapbox.)

Conclusion

I hope this has opened your eyes to the world of stakeholder management, or, more than likely, given a formal name to something you already do informally. This is a topic of increasing importance within the scope of software development, and I hope this proves to be a useful tool for your next project.

References

[1] - Stakeholder Analysis and Stakeholder Management. (Mind Tools)