The Principles of Project Management

Stakeholder Tools and Best Practices

Let's examine some of the tools and best practices that will help you identify stakeholders and manage their involvement in your project.

The Project Organization Chart

A project organization chart is a simple graphical illustration of who's involved in the project and where they fit in the overall organizational, or project, plan. First you'd include yourself, the project manager, with the project team linked in beneath. You report to the project board, which is led by the project sponsor. Depending on the specifics of your project, you will likely then group the remaining stakeholders into their respective areas (for instance, end users and IT staff). These groups are shown on either side of the project team, since they'll be giving input as the project progresses, as Figure 2.1 reflects.

To create a project organization chart, follow these steps:

• Write down the names of everyone who's involved in the project.
• Group them according to their roles -- project board members, stakeholders, and project team members. In most cases, you'll need to split the stakeholders' group further into the various stakeholder categories.
• Chart the results graphically, with project board at the top, the project team in the middle, and stakeholders radiating out from them. If some of the stakeholders report to the project board members, it may be worth indicating this on the chart.

The project organization chart is useful because it illustrates to everyone within the organization who's directly involved in the project (that is, the project team and board), and who has a more advisory role to play. You may need to consider establishing a team of key stakeholders who will be directly involved in the project, whether they're providing realistic testing for the product, or helping with the requirements gathering task.

Is There Anybody Out There?
If people in your project haven't worked together in the past, or if they're spread across offices or even time zones, it may be worth adding their photos and contact information to the organizational chart. Making it easy for team members and stakeholders to get in touch with each other can only aid communication and collaboration.

As your project progresses, keeping the project organization chart up to date becomes more and more important. Projects tend to get more complex as they continue, and more people get involved, and understanding where any given person fits into the bigger picture is important if you are to have a context for his or her input. A particular stakeholder who complains about everything, wants to be involved in every decision, and generally makes a nuisance of himself or herself can be difficult to deal with. But, by looking at the project organization chart, you might realize that that particular individual is really a minor stakeholder, but reports to the project sponsor. In the process, you may also recognize that the person is trying to get noticed in the run-up to the annual review period, which can help you work out how best to deal with this individual.

Perhaps you'll choose to have a word with that person in private, and ask for his or her help in making the project a success; you may also involve this person more obviously in the project so he or she obtains the desired visibility. On the other hand, if the person is being positively destructive, you might choose to have a word with the sponsor to see if that individual's efforts couldn't be redirected somewhere more constructive.

Organizational Chart Evolution
Quite often, your organizational chart will evolve. Before your project has really started, you might not have a full picture of what the team will look like, and which stakeholders will be involved. It's a useful tool from the very start, though, so always start by drawing a rough chart on a piece of paper, even if you only progress to a shareable electronic version later on during the project's Initiating or Planning phases.

The Communication Plan

A communication plan is a simple document that outlines how you will communicate the project process, how frequently you'll do so, who will be invited or involved, and who will be in charge of making sure the communication occurs.

The communication plan should cover everything from monthly email updates (which might be sent to all the interested parties) to daily meetings (for the project team) and fortnightly board meetings (organized by you with the project board). It might also define what specific information you'll be reporting to a much wider public -- for instance, for particularly important projects, it might be worth posting summary updates on the homepage of the company's intranet.

Therefore, anyone who's interested in the project, or feels that their own work might somehow overlap with what your team is doing, can see what's going on. You should always include your contact details alongside this type of communication -- after all, you never know who might warn you of the next big project hiccup!

Letting Them Know
Believe it or not, some of the value of your communication plan lies just in letting people know they'll be kept informed! Uncertainty is the cause of a lot of noise in projects. The communication plan can not only reassure stakeholders that they'll be kept in the loop, but can also inform them of how and when this will happen. It can also help you to ensure their input is directed to the appropriate people and points in the project, and avoid having them crash your team meetings!

Initiating Your Project

Now we're ready to really get going with the project! So let's look at why initiating your project well is so important, and how you should go about it. We'll also investigate some of the tools and best practices for doing so.

The Purpose of Initiating

The purpose of the Initiating phase is to set the project up for success. I often argue that it is the most important phase of the project life cycle, since, if it's neglected, the results can be catastrophic. After all, the beginning of the project is the point at which you form with the customer the contract (both formal and informal) that explains what will be delivered, roughly how it will be done, and when it will be ready.

The formal contract will be the piece of paper you sign, but the informal contract is the unspoken understanding between yourself and the other interested parties. Often the informal contract is the more important of the two -- people are more interested in what they believe you're going to deliver than the specifics written in the contract. This is especially true if the contracts are drawn up by a lawyer or separate part of the organization. If you're working internally and there's no formal contract, the informal contract is all that matters!

Keeping the Project in Perspective
Unless this is agreed on, you and the customers can walk away with completely different understandings of what you're trying to accomplish. These differences of perspective will only creep out of the woodwork to cause you trouble later on, unless you consciously shine a light on them during the project's initiation.

Initiating is also the best chance you'll get to define success. At the very outset you can agree on the project's success criteria -- key elements that need to be delivered for the project to be successful. These criteria will then help guide you throughout the project. Of course, if it's obvious from your initial discussions that the success criteria aren't clearly linked to the business purpose of the project, again, you've uncovered a potential stumbling block very early, before too much energy has been invested in the project.