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

June 30, 2008 – Muskrats in Your Levee

Last week the Mississippi River broke through the levees holding it back despite the efforts of hundreds of people fortifying it with sandbags. What caused the problem? Muskrats. Their burrows in the grounds along the river weakened it to the point that a breach was formed, flooding miles of farm land.

As managers we strive to make sure the project stays within the course set by the river banks established in the Charter and Scope Statement. Usually we are successful in keeping things flowing smoothly but occasionally problems poke enough holes in to create havoc. Here are five muskrats to watch out for on your project.

1. Slipping timelines. At first they seem harmless: a task runs long but it’s finished the next week. Unfortunately that pushes the next task back 3 days to when Bill is on vacation, costing you another week. Tracking the project at the task level allows you to see potential slips and make adjustments quickly. Most projects can survive by tracking weekly but more agile methods require checkpoints daily to make sure people are working on and completing the right things, right now.
2. Competing projects. As resources are stretched further, many people are required to work on multiple projects simultaneously. When things heat up on one project, the other projects suffer. Keep tabs on how many projects your team members are working and coordinate with the other managers to make it work.
3. Negative Rumors. Perceived pending bad news can demoralize a team, kill productivity and, if unattended, cause people to seek employment elsewhere. Rumors can actually cause more damage than the reality they represent. Work quickly to kill false rumors. If there is truth to the rumor, get it out in the open and show how your are dealing with the problem.
4. Miscommunications. Sometimes the simplest statements can be taken extremely wrong. The pastor of our church was interrupted once by someone coughing in the audience. He said, “Can one of the ushers please help that man out?” Immediately a couple of ushers descended on him and started dragging him away. “No! No!” the pastor corrected quickly, “I meant give him a cup of water or something!” In this situation everyone spoke English and still messed up a simple thing. Given the global world we live in and the complexity of the solutions we develop, it is no wonder our projects have communication problems. When you think you have over communicated what you need, you probably need to repeat yourself.
5. Unresponsive Stakeholders. Silence from your sponsor, end users and other key stakeholders is not good. If you are inviting them to meetings and asking for input but getting nothing back, find out why. It could be simply that people are on vacation or otherwise occupied, but you need to understand why and get it fixed. The problem with assuming that silence means consent is that when they finally do speak up it may be to say everything is wrong. Keep the time between feedback opportunities frequent and follow up when you don’t hear from them.

Each of these things may seem harmless at the time, but when the project is flooding the banks any one of them can cause the levee to break.

December 17, 2007 - Use Case Diagrams: A PM's View

Last week I attended a class on managing requirements with Use Cases. It was aimed at training business analysts and programmers to use Unified Modeling Language (UML) to understand and communicate business requirements . As a project manager I found it both enlightening and encouraging.

Enlightenment. Bottom line, modeling requirements is the quickest way to work with the end users and agree upon of what the system should be designed and developed to do. Because our focus was requirements, the class used Use Case diagrams as the basis for the training.

The three main components of a Use Case diagrams are the Actors, Use Cases and Scenarios. Actors are represented by stick figures, Use Cases by ovals and Scenarios by text boxes. An Actor is a role played by either humans or other systems that interact with the system being built. A Use Cases is a complete series of events handled by the system to help the actor achieve a goal. Scenarios detail how the Use Case will achieve those goals.

In one of my training sessions I use the eXtreme Insurance company as the basis for the exercises. The company is creating a new system to support the sale of life insurance policies to extreme sports nuts. These policies will be sold by cashiers of D&L Sporting Goods stores. The diagram above details the Purchase Policy use case. Other use cases that would be added to this diagram include Process Claim and Reconcile Transactions.

These quick, graphical representations are developed from information gathered through interviewing the users, observing system usage, researching similar systems and other means. The diagrams are then reviewed with the business to verify understanding, accuracy and completeness of the system. Gaining this clarity early in the process is cheap. Waiting for feedback until a prototype or, even worse, User Acceptance Testing may result in costly rework.
Encouraging. The encouraging part of this class was the way the instructor used Use Cases as a means to establish a requirements baseline and discuss change management. Remember, this was a class designed for analysts and programmers. By moving the discussion to their level, the Project Manager wins powerful allies for managing scope. Analysts can better identify the required functionality and processes, lower future surprises and rework. Programmers start to recognize gold plating as anything that isn’t specified in the use cases. When the business begins to ask for additions or changes, clarification begins with revisiting the diagrams and understanding what is different. Those differences become change requests to be processed by the Project Manager.

August 13, 2007 – Fortune Cookie Management

Not far from work is a Chinese buffet that we frequent to celebrate birthdays and any other excuse we can fine. It is called the World Buffet and in order to maintain truth in advertising they throw in French fries, pizza and Hawaiian chicken to give it a more global menu. You can still tell it is a Chinese restaurant, though, because they hand out fortune cookies with the bill.

While listening to everyone read their fortune recently it struck me that these pearls of wisdom applied amazingly well to project management. Here are some from our last visit.

They’ll definitely remember all your efforts. This is more than hopeful wishing. A month or more after turning over a project to another manager they encountered a problem. Evidently the infrastructure partner was claiming that we hadn’t informed them of certain responsibilities. I was able to retrieve emails and minutes showing the discussions and decisions. Keeping records paid off.

On another occasion it took nearly three months before I got the call. Phase 2 of a project was getting ready to go through a Sarbanes-Oxley (SOX) audit. The effort had changed hands twice since I left and the new project manager couldn’t find the evidence for the review. I had to think my way back through the SharePoint site layout to talk her to the location. Organizing the approvals and forms before handing over the reins saved her sanity.

Care and attention to the key relationships in your life will pay off. Stakeholder management immediately came to mind when I heard this gem. Understanding their influence levels, expectations, pressures and needs is priceless. You can’t solve needs or reset bad expectations you don’t know about. You will fail to interpret warning signs without comprehending the stakeholders’ points of view.

This fortune also made me think of resource relationships. I’ve seen key resources threaten to leave because they aren’t getting properly care. It really doesn’t take much. One individual is having trouble with immigration paperwork. His frustration is compounded because he can’t get an update on the status. A simple email or phone call to him would clear the air and keep him satisfied.

Step away from the power position for one day. This is a tough one for me. When I attend a meeting I am impressed if there is an agenda and the facilitator effectively directs discussion so we finish on time or even early. If a meeting is spiraling out of control I have to fight the urge to assume ownership.

In the same vein, for your team to grow and mature you can’t assume ownership of their work. When the coding is not getting done, it isn’t your job to step in and write code for them. You may need to negotiate more of their time, find help, apply forceful encouragement, remove barriers or a number of other things, but they are supposed to be the programmers, not you. Stealing that power from them leaves them without a purpose and it leaves you doing everything.

You’ll meet your big cheese today. Okay, this one didn’t make any sense to me.

If it seems the fates are against you today, they probably are. Sometimes it may just be better to go home and try again the next day.

On the back of many fortune cookies are words to help you learn Chinese. I’ve often wondered how many cookies you had to eat to become fluent. The Chinese on this particular paper slip says, “yao xe waon” which translates to “Hopeful.” That seemed appropriate for a project manager that all the fates are against.

By the way, your lucky numbers are 4, 18, 37, 14, 28 and 7.

May 21, 2007 – How to Meet Expectations

Some things are predictable. Love stories always end with the couple getting together. Tragedies end with someone dying. If you are watching a horror movie you know the phone won’t work and the lights will go out. You also know that instead of staying together where it is safe the characters will venture off on their own and become victims. Predictability is so ingrained in us that when things don’t turn out like you think they should you get upset.

Case in point: I once watched over an hour of a documentary about rebuilding a World War 2 plane. Evidently on the way back from Europe after the war, the plane ran out of fuel in far northern Canada and landed. The people were rescued but the plan remained there for over 40 years. A team of mechanics and a film crew spent several years refitting the plane. Because of the harsh winters and short summers there was only a short window to work on it each year. Upon completion they added fuel to it and were able to get it started.

The plane taxied down the frozen ground and wonder of wonders lifted off the ground. It flew in a wide circle and life was as it should be…until smoke started pouring out the back. By the time they landed the plane was engulfed in flames and everyone stood around watching it burn to the ground. I was mad. They had suckered me in to investing over an hour of my life to see all that effort go to ruin.

Then I started to imagine how my business team would feel if they invested their money and time helping my team refit their systems only to have the results miss their expectations. I’m pretty sure they wouldn’t be happy. How can you avoid this problem? Here are 5 ways to keep your project from going up in flames because of unmet expectations.

1. Understand the Business. Before you start gathering requirements, understand the group for whom you are doing the work. What is the problem they are trying to solve and how does it fit in with the rest of their business? You don’t need to be the expert but you need to comprehend the need.

2. Confirm expectations. Requirements are a good place to start but may not be the whole picture. Use modeling or prototyping to work through more of the details when possible. Walk through the requirements documentation and models with them to be sure everyone understands and is in agreement. If you don’t have a formal approval process, adopt one. It doesn’t have to be elaborate; it just needs to show that at a specific point in time everyone agreed on the direction to head.

3. Verify along the way. Your goal is to produce a useful product, not blindly follow the specifications. I was reminded of this on one of my projects. The test results showed that we successfully processed and loaded the data we received. They also showed the data was messed up. We had to add a mini project to correct the data at the source. If we had ignored it the system would have met the specs but would have been useless. The great part about working in an agile environment with graphical components is the ability to put pieces of the end product in front of the users on a regular basis. Seeing and touching along the way will bring corrections and improvements for consideration.

4. Horses…rein them in. A change management process is your lifeline. While #3 above may sounds like an open invitation to chaos, the project is still constrained by time, scope and budget. Use the process to confirm the necessity of a change and to allocate sufficient time and money to complete it. Where the approval process points you in the right direction, change management keeps you on the right path.

5. Abuse case testing. Much of our testing tends to focus on meeting the specifications. If I enter an amount and press button A then screen X appears and shows W. But can I bypass the security and grant myself access to view screen Y? Can I guess by the URL other areas I shouldn’t be able to get to and hack in? Trying to say you delivered a product that works to spec while the company burns to the ground isn’t going to cut it. Designate a resource for several days to try and break the system. Take off the gloves and just start abusing it.

In the end it is about delivering something of quality. Ensure it is something that doesn’t leave your business disappointed.