September 1, 2008 – Back to the Basic: Stakeholders

On July 17, 1999 I was sitting in an emergency room waiting for x-rays to confirm something obvious. My six year old daughter had broken her left arm just above the elbow.

On the television a worse parental nightmare was unfolding for the Kennedy family. The night before, John F. Kennedy Jr.’s plane had crashed off Martha’s Vineyard, MA (USA) and the news was covering the ongoing search. It was determined that the likely cause of the accident was spatial disorientation, a confusion of the brain that completely destroys your perceptions. The sky that night was dark, and a haze hid the horizon. Without visual references the brain can misinterpret signals from your inner ear.

Pilots with this condition have been known to fly upside down while believing they are right side up. Instead of climbing steeply they may in fact be heading straight for the ground. Only by relying on their instrument panel can they pull through it.

In the midst of a project, when changes are dogging you and deadlines are due, it is easy to loose sight of reference points, forget the basics and start running on adrenaline and pure luck. If your instincts are solid you may be able to fly by the seat of your pants for some distance. However, even the best project mangers can succumb to project disorientation. Fortunately it is neither fatal nor as tragic as JFK Jr’s death.

This series is entitled “Back to the Basics” and is intended to remind us that projects fail day by day, usually when we loose sight of simple things.

Stakeholders.
Project success begins by identifying and understanding who your key stakeholders are. If you can’t identify the players and which side they are on, you stand little chance of satisfying their needs and landing the project without incident.

Identification. Several stakeholders jump out immediately: the sponsor, end users and your team. But a stakeholder is an individual or group that is either impacted by the development process or the end product of your project

In 1988, New York State attempted to put a low level radioactive waste dump in Allegany County. Although not involved in the construction or ultimate use of the facility, the people of the county were key stakeholders. Their “Bump The Dump” campaign successfully blocked the project and in 1992 the US Supreme Court amended the federal law that required states to store radioactive waste within their own borders.

Create a list of the people and groups impacted by your project. Include hidden ones like:
Current users of what you are getting rid of or replacing (system, building, facility, software, highway, forest)
External suppliers, users or supports. Whole communities are impacted by factory shutdowns, megastore constructions or radioactive dumps. On a much smaller scale, the company supplying data or using your information will have impacts, too.
Support Teams. Call center reps, operational support and disaster recovery are impacted by system changes.

Motivation. Once you have identified them, you need to understand their position. Some will be strong supporters of the project. Others my loose their jobs or need to be retrained as a result of it. For each stakeholder determine and document how the project will impact them.

What pressures are they under? Your director’s bonus may be based on you spending the entire budget. Regulatory or legal requirements may impose strict timeframes. CEO commitments to shareholders may have been made.

Recognition. Return to your list throughout the project. In addition to documenting new stakeholders, begin to put specific names beside each one. This will help you think through whom you are dealing with and begin to plan your approach to dealing with them.

Communication. From the beginning of the project you need to keep the stakeholders informed. You don’t need to have all the answers and in some cases you won’t be able to divulge all of the information, but an open line of communication will alleviate fear and uncertainty.

Unspoken and unaddressed concerns will exist for something as big as potential layoffs or as seemingly small as a new time entry logon screen. Create a forum and an atmosphere conducive to asking question and providing feedback.

The ultimate success of you project depends on you identifying the right stakeholders and satisfying their requirements while sustaining minimal damage from the opposing viewpoints. It is easy to become disoriented by the loudest stakeholder or the one holding the cash, but by identifying them and their agendas you can pull out of a dive before you crash.

NOTE: For an interesting twist on Stakeholder Management, visit the article “The End of Fairy Tale Beginnings” at www.computerworld.com

May 29, 2007 – How to Ruin a Perfectly Good Team

One rotten apple can spoil the whole bushel. Imagine the speed with which it can happen if that apple is the project manager? It doesn’t take long before the rot starts to spread and any chance of success dwindles. So how do you keep from ruining your perfectly good team? Here are 5 sure fire ways to accomplish it.

Demotivate Them. I remember a specific meeting in which I got shot down and how small it made me feel. It was already a rough time for the team I was leading and I was having a passionate (read “heated”) discussion with our new manager. He said something to the effect of “How can I make changes to this group if I have to argue everything with you?” I remember apologizing and not saying anything else. Clearly what I had to offer wasn’t what he wanted to consider.

If you have blown it with one of your resources you will need to set things right. Unfortunately it is much easier to demotivate than to re-motivate. A nice poster with an inspiring saying probably isn’t going to cut it. Try these suggestions:

• Meet with them individually to start recreating a foundation. If you said something stupid, apologize and leave the “but you…” out.
• Catch them doing something right and praise them for it. It doesn’t have to be public, just let them know you appreciate what they do.
• Reset the vision of the project and their role in it.

Say Stupid Technical Things. It has been a while, but I used to program in C. One of the great aspects of the language is the ability to separate the common shared variables from the code and use them in multiple programs. My manager challenged me on why I didn’t use a single file for easier version control and storage. That statement failed to inspire confidence in her abilities to manage me.

Recently I have had to oversee the connectivity set up for our offshore team. When I started I suspected a NAT wasn’t the same as a URL but couldn’t have proven it. When I find myself short on technical knowledge I start a lot of questions with “help me understand something….” It frees me from pretending to know it all and allows them to show their expertise. If they can’t explain it either I start to get nervous.

Drop Your Support. Hanging your team out to die isn’t likely to win you manager of the year. I recall one instance in particular where I had to fall on my sword for the team. Action wasn’t being taken to finish off a couple of key tasks and the client wasn’t very happy. A large part of me wanted to blame the team and their ability to take ownership. In reality I was responsible for not driving it harder and the email I sent stated it that way.

Ignore Them. Sometimes it is easy to neglect you team, especially if they appear to be working together well. Things are moving smoothly when suddenly you start hearing complaints. Soon a couple of team members resign for positions elsewhere and the rest of the team is left floundering, trying to absorb the extra work. Even productive teams need cultivating. Remember to:

• Recognize their effort both individually and as a team. It doesn’t have to be big, but it should be real. Generic praise will fail. You won’t be able to get away with saying, “great job doing whatever it is you do.”
• Keep them informed. Connect them to the bigger project picture including business goals, discussions and decisions. Let them know how their piece fits in and how the overall project is progressing.
• Keep things positive. Address issues, but don’t resort to yelling. And certainly don’t make the business out as the bad guys.

Assume. Always assume your team members know what you are thinking. If no one is bothering you, assume everything is fine. No need to check up on anything. Your team would tell you if you needed to worry, right? This is one area I have to watch out for. As project managers we worked our way up because we work independently. We either figure out what we need or we ask questions until we get it right. Trouble starts when I assume that my team is making progress and I choose not to confirm it.

Even a great running machine needs to be oiled to keep the friction down and things working properly. You’re the one with the oil can so get busy.