Monday, September 29, 2008

September 29, 2008 – Back to the Basic: Communication - What

While waiting in line at Costco to buy my $1.50 hot dog and soda, I watched the manager collect money from the tills and seal it in plastic, oblong containers. He walked over to the wall and stuck them in a pneumatic tube. With a muted *phoomp* they shot up and out of sight.

Long before email, the quickest form of interoffice communication was the dial switch message tube. Plastic cylinders were sucked from one end of the building to a central switch board. From there they were placed in another tube and pushed to their destination. Instead of having a megabyte size limit for attachments there was a weight limit.

Given the length of time that people have been communicating, the topic of communication is obviously huge. Methods have evolved from papyrus to paper and are headed to paperless…which just seems to create more paper. Communication is concerned with the entire package: what to communicate, when to say it and how to deliver it.

What to Communicate. Simply put, as a project manager you need to communicate answers, accolades, applause, bad news, budgets, briefs, causes, critiques, costs, delays, dangers, decisions, earned value…and I’m only up to the Es!!! An estimated 80% of a manager’s job is communication.

So how do you know what to communicate? That depends on who needs to know.

Delivery Team. To the team you need to articulate the vision and direction of the project. Begin with the defining documents (Charter, Scoping Document, SOW, etc.) to lay out the vision of the project. Use the Work Breakdown Structure (WBS) to drive discussion of what needs to be accomplished and how to get there. Set delivery expectations by laying out a schedule with assigned resources, specified effort, and agreed upon dates.

Since communication is a bi-directional exchange, require feedback. Collect status, effort, re-estimates, criticism and suggestions. Don’t accept excuses, complaints and whining without moving them beyond to solutions.

Sponsor / Management. Contrary to popular belief, management does not always want a rosy picture painted for them. They need the truth told succinctly so they can make informed decisions. They also need bad news delivered as soon as possible so they can take action.

On the other hand, management, if left to their own devices, will make assumptions that may not be true. Understand their expectations and work to align them with reality. Based on the scope definition of one project I was on, we successfully upgraded a software package. The directive for Phase 1 was “out of the box” and we and held the modifications to a minimum. At the end, the sponsor was disappointed she didn’t get the new reports she wanted. I had failed to keep her expectations focused on the scope.

Governance / Auditors. The job of the Governance (Program or Project Management Office) and Auditor groups is to ensure that the safeguards are in place to make the project a success. They want to know that you understand the processes are following them. If your project doesn’t fit the mold, meet with them up front and carve out a new mold that everyone can live with. Communicate lessons learned and process improvements to make projects work more effectively.

End Users. Usually End Users are ignored until the product is virtually complete and then they are brought in to ooh and ah over what we created for them. Your job is to understand their expectations from the inception of the product, align those expectations with the development, confirm them in the User Acceptance Testing and deliver successfully. Communication is the key through each of these steps.

Others. There are always others. Some of them can kill even the most successful project. While speaking with my PMO counterpart on a mass transit project, I asked who was handling the communications to the ultimate end users: the people taking the trains and buses. The project was to implement smartcard technology into the public transportation system. If they were unprepared to use the system, it would be a failure. Who will be impacted by your project and how should you be communicating the changes to them?

The ultimate purpose of communication is to eliminate surprises. Do that and you will be communicating the “what.”

Sunday, September 14, 2008

September 15, 2008 – Back to the Basic: Competing Project Constraints

Following last week’s edition, one of my project management co-conspirators dropped me a note informing me that the triple constraint (see The Troubling Triangle) is officially dead. The upcoming release of the PMBOK Guide 4th edition has killed it.

In lieu of the binding, restricting, tri-legged barer of logic, PMI has opted for “Competing Project Constraints.” The new PMBOK includes Scope, Quality, Schedule, Budget, Resources and Risk as a representative list of the numerous constraints that a Project Manager faces.

Without reading the text directly I can not make a fully informed decision about the wisdom of creating a multisided polygon constraint. For one thing it doesn’t have quite the same ring as a triangle (I’m sure there’s a bad musical percussion joke in there somewhere). However, here are my initial thoughts.

  1. I whole heartedly agree that Project Managers have more to worry about than Scope, Schedule and Budget. I don’t think there was ever any real misunderstanding of that fact.
  2. By removing the Triple Constraint and accompanying triangular image, we loose the visual used to explain the impact of changing one of the legs.
  3. Of the examples given as other constraints, Quality is easily represented by the size of the area encompassed by the leg segments of the triangle. Although not originally part of the image, it fits.
  4. Another, Resources is generally a factor of the cost (or budget) of the project. If money is no object you can get better and more resources. The New York Yankees and Real Madrid sports franchises, with their ability to buy talent, come to mind. Generally speaking, projects run out of time or money before they experience a lack in available resources.
  5. For the other, Risks, I need more explanation for the use of the term “constraint.” If the term means “factors that may adversely impact your project” then I would agree.

Perhaps that is the basis of the change in the terms used. PMI may believe that it is doing us a favor by widening the term to show the myriad of chainsaws and knives we need to keep juggling. My fear is that it opens the door for management to defy the simple logic that if they increase scope, schedule or budget, one or both of the other legs have to adjust.

If we are expanding the number of constraints, maybe we just need a different image:
Picket Fence – Each of the slats represents a constraint holding the project level.
Suspension Bridge – All of the cables adjusted to keep the path safe for passage.
Multi-legged Table – Legs adjusting together to support the project.

Whatever the symbol, I will miss the triangle.

Monday, September 8, 2008

September 8, 2008 – Back to the Basic: The Troubling Triangle

In our quest to return to the basic of project management we have already tackled the stakeholders. Next we take on the triple constraint in the form of a triangle. The concept of a triangle to represent the Scope, Schedule and Cost of a project is actually quite ingenious. Adding more scope dictates an increase in the schedule, cost or both. Reducing the cost or timeline for the project requires less scope. Each part is dependent on the other two.

The trouble is that management thinks of these three items as completely independent of each other; like 3 line segments lying as distinctly separated as the bones in my daughter’s x-ray from last week’s edition.

Scope. The scope of your project includes the full extent of what is agreed to, both verbally and in writing. In reality scope is never fully defined until all of the requirements are vetted, but from the minute you take ownership it is our responsibility is to ferret out promises and commitments made. This is especially evident in the consulting world. Account Representatives (aka Salesmen) are notorious for making promises and not letting the project manager in on the secret. Take your list of Stakeholders and find out their expectations.

The resulting wish list is not your scope. Like pruning a Bonsai tree you need to cut that back to something you can realistically deliver in the timeframe and cost provided. Remember, you can’t set one line segment of your triangle without impacting the other two.

Cost. Auto salesmen get a bad rep, justifiably so in many cases. But you can take a page out of their play book. When asked how much it will cost to deliver the scope, ask how much they are looking to spend. If they only have enough for a used, beat up Yugo, don’t try to sell them a Lamborghini.

When giving an estimate, put it in terms of what will be delivered. Never give a quote without documenting your assumptions; the “here’s what I was thinking…” piece. Placing the cost into context forces the discussion of scope.

Schedule. Timing is always an issue. On one project our directive was to go live in August. Backing up from that date gave us July for Testing and Implementation, June for Development, May for Design and April for Requirements. It would be tight, but do-able. At the end of May “in production” was clarified to mean the day after 4 weeks of parallel testing in the production environment. Changing the move to production, even if we weren’t “live” would have been impossible without changing the scope and adding more resources (increasing the cost).

Find out what the date is and the significance of it. If it is a hard date you have already set one of the legs in the triangle.

As you establish the three legs of your triangle, it is management’s job to stretch the scope side while reducing the length of the cost and schedule sides. How can you effectively push back without a career shortening screaming match?

Go gourmet on them. Most CIOs, VPs and Senior Managers enjoy their share of fine food. The higher end restaurants produce amazing dinners that take longer to serve and cost quite a bit more than your local fast food joint. Even our cafeteria at work has a sign that says, “Good food takes time. Thank you for your patience.”

Build a reputation on speaking straight and not padding estimates. It is your responsibility to present the facts, back them up with evidence and state your case clearly. It is their job to make decisions.

Monday, September 1, 2008

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