Guerilla Project Management: Part One

Guerilla Project Management: This is the first post in an occasional series looking at low-effort, high-impact project management practices that contribute to project success.

Know Thy Stakeholders

Stakeholder identification, in the context of a project, is really just taking stock of all of the people who are involved in a project and capturing a little bit of information about them in order to help you manage the project well. It doesn't necessarily need to take a lot of time and effort, but it can pay off in big ways later on down the line. I'll be discussing this practice in terms of web projects, but the concepts here are broadly applicable to projects in all fields.

Any person who may impact or be impacted by a project should be considered a stakeholder. Identifying stakeholders will help you meet their needs better, will help uncover hidden requirements as early as possible, and will help you manage project risk.

Try It Yourself

1. Grab a piece of paper or a dry-erase board, take fifteen minutes with your project teammates and preferably one of your client contacts, and do the following:
2. Make a list of everyone who is involved in the project, including their names and job titles. Who might use the system that is being built? Who is affected by the project? Include people who won't directly interact with the system (such as those who receive reports produced by the system), or members of the public who will be using the system to make a purchase or request a service. Who are the decision-makers who might be called upon to provide input?
3. Next to each person's name, write one or two lines about the nature of their involvement within the project. Answer the questions, Why does the project matter to this person? and what is the most important thing to keep in mind about this person's involvement in the project?

Look at the list of names and ask, Are we missing anyone?  Don't just include the people with whom you will be interacting directly with to try to get the full cast of characters.

Why it Matters

Some issues which can be revealed through stakeholder identification include:

• Someone on the client side who has had a bad experience in the past with a similar project and is now particularly sensitive to certain situations. You might be surprised at how often this has happened in our experience. For example, we have had clients whose previous vendors overwhelmed them with techno-jargon and made it difficult for them to discuss their needs using plain language, leaving them with a bad taste in their mouth when it came to dealing with websites and tech firms. To counteract this, we communicate using the lowest amount of technological detail necessary and make a point of using their language whenever possible.
• Someone on the client side whose input is crucial but who is very busy (possibly overworked) and difficult to pin down. It becomes important to develop strategies for obtaining this person's feedback, such as tracking their travel dates on a calendar and adjusting the project schedule accordingly; knowing when to call as opposed to email, and using short, descriptive subject lines with short emails that contain the most important information at the beginning of the message.
• A person in a possible position of influence who thinks that the project is not necessary, or may have some fundamental disagreement with the way the project has been conceptualized or designed. (This really does happen and it can jeopardize a project's success, so you need to be aware of it.)

Having this information written down also smooths the transition when new staff are brought on to a project team or when another project manager needs to take over on a temporary or permanent basis. The project manager and teammates who are involved from the start most likely have acquired a deep understanding of all the people involved; they know how to anticipate stakeholder needs and concerns and how to manage project risk. Getting stakeholder information captured and accessible to the whole team shortens the learning curve whenever there are changes in the team's structure.

Hindsight is 20/20

Sometimes, this information does not become readily available until the project has been ongoing. That is perfectly alright - just get in the habit of revisiting the list and updating it on a regular basis, and you'll be fine.

Lets Get Fancy

A more advanced activity in stakeholder management involves mapping stakeholders in a matrix and indicating their level of influence and level of impact in order to determine how best to manage their involvement. There are a variety of techniques and methods for doing this, but the basic idea is as follows.

1. For each stakeholder, write down the level of impact the project will have on him/her, using a numbered scale (such as 1 to 5). Someone who will need to use the system every day in order to perform his/her job functions could be said to be high impact (or alternatively, high interest) and may be given a rating of 5 out of 5, whereas someone who occasionally looks at reports generated by the system but might not actually use them, could be said to be low impact and scored as a 1 or 2.
2. For each stakeholder, indicate the level of influence he or she has over project decisions. A C-level executive who will be signing contracts and approving requirements and system changes would be considered high influence (or high power) and scored as a 5, while a staffer who may use the system but isn't available to be consulted on the systems design might be considered low influence. Note that people can be low influence / high impact because they aren't in a position to make lot of decisions about the project but the decisions that are being made will have a big effect on them.

What are your thoughts on stakeholder identification? Did you have a time when you worked on a project and found out about somebody too late in the game? Or where you ever put in a situation where you were able to uncover and handle a potential issue early because you were keeping track of all the players right from the start?