October 21, 2010 – Communicating what Matters

Several of the brain dump entries from February center around “Communicating what Matters.” This shouldn’t be a surprise. Some have estimated that 80% of project management is communication. Others claim that 63% of all statistics are made up on the spur of the moment.

The mark of an excellent project manager is communicating the right amount to the right people in the right format at the right time: making it matter.

The Right Amount

We’ve all sat through long winded, slide enhanced meetings that completely fill the4-hour morning time slot and spill over into lunch. If you are like me, you grasped the concept, impact and expectations of the topic within the first 20 minutes, but have to endure the remaining torture. In truth, I probably delivered some of those presentations.

The purpose of any communication is to allow the audience to make informed decisions (#2 on February’s list). This is true whether you are sending an email or presenting at an executive meeting. Give them all the information they need; leave nothing important out. Summarize the content and focus on the pertinent information. You will want to have any supporting evidence or content available, but wait until they ask before inundating them with it.

Additional suggestions:

• If asked to produce a report, verify the content and detail needed before starting.
• At the start of a meeting, lay out your direction and ask if where you are headed is where they expected to end up.
• Reread your emails from the perspective of the receiver. Is it organized logically? Is your main point summarized within the first two sentences? Are you being too wordy?

The Right People

Have you ever been to a meeting and thought, “Why in the world did they invite me to another one of these?”

Or what about speaking with someone for an hour only to have them say, “I’m not the person you need to talk with. You need to speak to Joe Smith in Accounting.” Why couldn’t they have informed me of that in the first 5 minutes?!?

One critical communication point is the “To:” list on your email. Check it twice before hitting send. Make sure you have only the intended audience copied. Avoid hitting “reply to all” unless you mean it or remove unnecessary names.

Make sure you have the right individual. In the Orange County chapter of PMI there is an individual named Tom Cumming. Because we are both active in the chapter, we are constantly receiving emails intended for the other individual. Making that mistake wouldn’t be too bad, but if one “Joe Smith” is the CEO and the other is the guy in accounting you wanted to contact, be careful.

Additional suggestions:

• Mailing lists are essential. Setting one up for each project will save time when sending out communications. Then make sure to maintain it as people join and leave the team.
• If you are not getting feedback on emails or people are not showing for your meetings, verify that they are receiving your communications.
• When in doubt, ask. A simple phone call saying, “I’m trying to reach the individual in charge of…” can save a lot of explaining later.

The Right Format

This became strikingly clear to me on one particular project. I failed to deliver the project’s schedule and status in a format consumable by my client. The direction of the project was on track to meet our schedule. We were well within budget. The scope was being honed appropriately.

However, because it wasn’t delivered in the format that was expected, I missed the mark. Once it was sorted out, things progressed much smoother.

If you are new to the department or company, ask others to point you in the right direction. If there is a PMO, there is usually a template. Don’t reinvent what already exists.

Additional suggestions:

• If there are several versions of a regular communication (ex. Status Report, Resource Request, Charter, etc.) in use, look to standardize it. Consistency will save time for you in creating it and for the recipient in reviewing it.
• Templates need to be reviewed and revised regularly to make sure they are meeting the needs of the intended audience.
• If there is a meeting, report, or template that is no longer needed get rid of it.

Presenting the right amount of information to the right people in the right format will at least you stand a chance of “Communicating What Matters.”

February 5, 2010 - PM Value Brain Dump

I am sitting here writing down all the words and phrases that come to my mind in relationship to real Project Management. Here is what I have so far.

Communicating what Matters
Informed Decisions
Change with Purpose
Monitoring Direction
Leading, not just Reporting
Analysis of Activity
Controlling the Outcome
Removing Random Factors
Risk Management
Involved Stakeholders
Enabling Management
Planning Success
Integrity in Action
Confronting Conflict
Lessons Learned
Tension Breaking
Instilling Confidence
Team Defender
Resource Motivator
Promoting Purpose
Follow Through
Critical Thinking
Ownership
Improving... Self, Situation, Team, Understanding...
Challenging... Self, Situation, Team, Understanding...
Results Driven
Business Focused
Influential
Self Controlled

Pieces of this brain dump will be examined more in the next several blogs. We'll ask "What is the result of a project manager being ____?" We will also touch on ways to instill more of these in your thoughts, actions and reactions.

Until then, if you have additional ideas, pitch in by leaving a comment.

January 24, 2010 – Driving me Crazy!

Having a GPS in the car drives me crazy. I do not operate well with directions that come one step at a time. It may be the Project Manager in me, but I want to see the big picture and know where I’m heading. Besides, at 65 miles an hour, I can’t judge “300 yards before taking the next left.” I’m not even sure if “Miss Voice” means her left or mine.

I realized this last week as I was traveling to a client site with our main sales person. She was driving and I was trying to navigate. We were attempting to go from Orange County, CA near Disney to the Pasadena area, home of the Rose Bowl Parade. The final destination was between the 60 and Interstate 10. I know how I would go and assumed the GPS would use the same route, straight up the 605.

Imagine my confusion when Miss Voice said, “In ½ mile, take exit to Interstate 5 North.” Before I could wrestle the screen to show the projected route, we had swerved onto the exit ramp to follow the directions. It was either that or face the dreaded “Recalculating…Recalculating” reprimand….or worse, the “Make a legal U-Turn” snide remark.

Through a comedy of errors, we managed to get back on track. We missed the 60, but found Interstate 10. Following Miss Voice’s advice, we passed the exit bearing the name of the street the client was on and took the next exit. I had a general sense of where we were heading by then and expected to head south and then east. Miss Voice, however, took us north and then west until we realized the ending address had changed.

I personally think Miss Voice was so disgusted with us that she was thinking, “Fine! If you don’t appreciate me, I’ll drive you to a back alley where you’ll get car jacked. They’ll strip this vehicle down and sell me to someone that can follow directions!”

Some project managers run their projects using a GPS. They punch a predefined address into their Charter and start driving. They fail to look far enough ahead to get into the right lane before missing the turn. Ultimately they allow the project direction to be altered without their knowledge, ending up somewhere else entirely. Even if they avoid a devastating collision, the sponsor usually ends up with car sickness.

Here are the top 10 ways to reach your destination without throwing your GPS out the window.

10. Lay out the full map. Understand where you are headed. You don’t need to know the turn by turn details, but you want to be able to sense when you are going in the wrong direction.

9. Verify your destination. Review the scope and requirements with your stakeholders and obtain their approval.

8. Keep an eye on the gas gauge. Budget, time and resources have to be planned and used appropriately.

7. Listen to Miss Voice. If you have laid out your plan and schedule accurately, follow them.

6. Track your progress. A GPS uses your current speed and position to calculate arrival time. Analyze your progress and spend rate to make sure you are on schedule and budget.

5. Look for landmarks. Set milestones in your schedule. Use them to validate your direction with stakeholders and gauge your timing.

4. Check the map frequently. Verify progress against the scope and requirements in order to stay on course.

3. Recalculate. As the project progresses, more information is available. It may be refined requirements, new technology, resource changes or other factors that impact the end product. Use formal change processes to re-evaluate and alter the direction and cost.

2. Check the traffic. Analyze the risks in your project. If it appears there is traffic ahead, take action to avoid it.

1. You have arrived at your destination. Recognize when you have completed the project’s scope. Don’t allow random course changes to be slammed in at the end of the project. These tend to be less structured, lack adequate testing and overrun the budget.

We arrived in one piece, but it is a good thing we left early.

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.

May 5, 2008 – Keeping Junk and Throwing Valuables

Value. It is a word that has come up several times over the last few weeks. My wife recently snagged me two Eisenhower dollar coins (1974 and 1978) she saw someone spending. We were also speaking to a realtor about possibly selling our house. Neither the coins nor my house were worth as much as I had hoped, but without knowing their value I might have given away something for nothing.

This can happen on your project. It starts with a promise made during a meeting or by one of your team members while gathering requirements. Then, as you start to estimate it and assign a cost, you realize that what seemed simple will break the budget. Here’s how to avoid the problem.

1. Scope Definition. Get it drawn up and agreed to. Whether you are using Use Cases Models or hand written napkins, spell out what you were asked to do and get it agreed to.



2. Scope Awareness. Publicize what is in and out of scope. Make sure your team understands the need to keep the design and development focused on what is agreed to and nothing else. Stress the same concept with the business, too.



3. Change Readiness. Create a way to change the scope: a change management process. Assure everyone that change is good and can result in a better finished product. Lay out the path an idea needs to follow to become a reality. Include what constitutes a change; estimating the effects on cost, time and resources; and who has to approve it.



4. Idea Promotion. Encourage your team and the business to identify changes, especially early in the requirements and design phases. Drawing out those ideas gives you an opportunity to deliver something of real value. Once they are identified run them through the change management process to determine if or when they will be included. Some ideas may be good enough to oust existing scope or extend the project. Others will hit the wish list and never see the light of day.



5. Effective Giving. Even if you are giving something away, determine and communicate the value of it. Adding another field to a display may not be significant, but one request can become twenty if the perception is that they are free.

Now you have the right people making the best decision while removing you from having to say "No!" all the time.

On the flip side, too often we hold on to things that have no real value. Garages quickly fill up with slightly broken electronics, old monitors, lamps missing shades and even partially bent golf clubs. When the garage is full people rent storage units at $150 or more per month to hide things they can’t part with. At those prices it doesn’t take too many years before the money spent could have purchased brand new replacements for the broken items.

Project secrets are not worth the price. I’ve had to pay before. On a project with clearly defined testing dates, one group continued to tell me they were on schedule. The Monday that testing was to begin we held a final go/no go meeting. They arrived to inform us that they had completed... their design. Construction was far from finished. If your dates are slipping, be the one to step up and identify it as a Risk. Do everything humanly possible to complete on time, but get the problem out in the open.

Unproductive resources cost too much. Sometimes we think that any resource is better than no resource. Compare your dead beat developer against that statement. Is he producing anything of value? Is she bringing the moral of the team down?

Check your value system. Are you throwing away valuables or holding on to junk?

April 7, 2008 – Scope Creep in Tent City

The city of Ontario, California had a problem: a large number of homeless people. To address this, the council decided to create “Tent City” using the land around the airport. They supplied tents, water and toilets. Government agencies supplied other goods and services. Everyone felt good about themselves and life was looking grand.

Unfortunately, this solution just created a bigger problem: more homeless people. The total number of residents quickly rose to over 400. People from out of state were showing up to take advantage of the generosity. With the situation officially out of control, the city gave notice to everyone and brought in bulldozers to level the area. The new plan is to place a fence around the area and issue 90 day registration tickets to set a limit of 170 residents.

I see three warnings for project managers from this well intentioned public image problem.

First, even the best intentioned additions to your project need to be planned, estimated and agreed to. We all want to exceed our client’s expectations. The temptation is strong to add things to the project and eat the cost. After all, it’s a simple change and we are a bit ahead of schedule anyway.

The problem is that little things add up. Even if you are giving it away, use a change management process to assess and communicate the impact to the project in time, cost, resources, etc. Once the value is understood you can give it away. If you hide the value it will be appear as if it was in scope already and not really an addition. It becomes just one more homeless person entering Tent City.

Second, consider the risks involved in the actions you take. Tent City seemed like a good idea at the time but it exploded into something ugly. The council thought far enough in advance to provide facilities and fresh water but failed to mitigate the influx of non-Ontario residents. Get your team to perform a Risk Assessment early and often. You should set aside time as a team to brainstorm potential risks minimally monthly and whenever something significant changes (see topic: Risky Business).

Finally, sometimes you have to admit your mistake and bring in the bulldozers. Had the city of Ontario continued to ignore the problem eventually someone would have died. In addition to the tragedy of loosing a human life, it would likely result in lawsuits and even more bad press. If additions to your project are bringing down the property value, it may be time to plow it under and put a fence up to control the scope.

March 31, 2008 – Estimating Lessons Learned – Communicating the Results

Back in December my 1997 Plymouth Neon was totaled when someone rear-ended me, forcing my car into the next one. It is an odd feeling to look into your rearview mirror and know that the car behind you isn’t stopping.

The insurance company sent me a check for a whopping $2,545. To quantify that massive amount, they compiled an 18 page document comparing my car to similar vehicles using mileage adjustment, feature assessments and other data. All that information was their justification of my car’s estimated value.

Lesson 13 – Tell them where you got the numbers.

An estimate is a guess based on the approach, assumptions and constraints that make up your understanding of the project. Theoretically your team’s estimate has some basis in reality. The key is to communicate that reality to your key stakeholders without them asking what color the sky is on your planet. In Lesson 10 we said to “Document your reasoning.” Let’s look closer at what that means.

Begin with the planned approach for the project. Are you cloning an existing application or starting on a new platform? Will there be a proof of concept performed? Is a pilot phase part of the process? Will it be a “big bang” conversion or phased in over time? Laying out the approach sets the foundation for the numbers. Keep track of any concepts that don’t make it and why they were dropped for future reference.

For constraints, any discussion or thought process that includes can’t, shouldn’t, must, or similar words needs to be recorded and confirmed. If you are saying “we can’t X if they don’t Y” or “we must have Z” then put it down on paper and bring it up.

Assumptions are more difficult to call out. In our minds we see them as obviously true. The hard part is pulling them out for examination and making sure everyone agrees. These can be negative assumptions (any discussion or thought process that ends “we’re not doing that”) or positive (“Marketing will surely have the brochures ready by then”). You may assume they are out of scope but unless it is stated there’s the chance others may think it is in.

Document these and you won’t end up looking at your estimate and saying “what were we thinking?”

Lesson 14 – Email doesn’t cut it.

Schedule a meeting and present your estimate. Sending out an email and expecting a meaningful response isn’t going to cut it. Either face to face or via an on-line conference, you need to walk it through. Explain the Type of Estimate (link) and your confidence level. Recap the estimating process used.

This is your chance to review and verify the approach, assumptions and constraints used to generate the estimate. Make sure everyone is heading in the same direction. Save time and energy by identifying the differences and adjust course earlier in the process.

Had my insurance company simply sent me a check for my Neon, I would have been disappointed and resentful, causing me to switch companies. Because the agent walked me through the numbers I understood that they probably gave me more than it was worth.

Lesson 15 – It is still just an estimate.

In the end, however precisely thought out, meticulously defined and well communicated, it is still an estimate. Things change and assumptions are proven untrue, but with a solid estimate as at its base, your project will be off to a good start.

February 26, 2008 – Estimating Lessons Learned - Intro

“How long to add text messages to the data transfer communication link?” the director asked.

The project manager was obviously hesitant to give an answer. “We haven’t really considered it yet. Why do you ask?”

“I’m heading to a meeting and the question may come up.”

“I would need more time to think it through completely but just for discussion purpose, I would ball park the figure at roughly $50,000 and a 6 month effort. Don’t hold me to it, though.”

Unfortunately for the PM that was the number that ended up on the IT budget for the next year. It started as little more than a wild guess and suddenly became a commitment. Lesson 1 – never give an estimate over the phone.

Types of Estimates. There are many different names for estimates: Rough, Ball Park, SWAG, Big Picture, Budgetary and Final to name a few. Each name attempts to convey the accuracy of the figure. All of them fall on the continuum between three points: Rough Order of Magnitude, Budgetary and Definitive.

The accuracy of the Rough Order of Magnitude (ROM) Estimate ranges from -25% to +75% off. That means a $100,000 estimate can be as low as $75,000 or as high as $175,000. It is the type of estimate usually given when very little is known about the project but management needs to decide whether to move forward or not.

A Budgetary Estimate is put together at the time the Project Charter or Statement of Work is defined. At this point enough is know about what is in and out of scope that boundaries can be established. The accuracy range is between -10% and +25% ($90K and $125K for our $100K project).

The Definitive Estimate range is between -5% and +10% ($95K and $110). This estimate is done based on detailed project information that, in IT, comes after the Requirements or Design phases.

Lesson 2 – not all estimates are created equal…on purpose. This is a fact that needs to be communicated to management and business a like. Set their expectations up front. When they request an estimate, ask what type they are expecting and how they are going to use it. Explain the range of accuracy and the level of effort as well as information required to make it more accurate.

Lesson 3 – don’t confuse people with artificially accurate estimates. By announcing your “rough estimate is $1,633,284.16” you are implying that every paper clip is already counted. Estimates should end in zeros. Past PMs I have worked with issue initial estimates like 1433 hours. This accuracy is impossible even if your scope is well defined and resources are already assigned in your detailed project schedule at the task level. At least round the number to 1450 if not 1500. Ending in a 3 implies precision that doesn’t exist.

Next week we will look at estimating methods and learn that technique is only half the issue.

February 4, 2008 – When the Plan Fails

In an on-shore / off-shore set up you need to expect the unexpected. Half you your team is in a foreign country, half way around the world. You’re never quite sure what time it is where you live, let alone where ever they are. Languages, especially English, can lead to confusion. Names are redundant (there are four Toms where I now work). I’m not sure how you could possibly have seen the following surprise coming, though.

Picture yourself sitting at your desk on Monday morning, pulling together reports from the weekend and getting ready for the week. Fred comes by with a new face and introduces you to Gupta . The name sounds familiar. "I have a team member by that name, where are you from?" you ask.

"That is me," is the reply.

"What are you doing here? Don’t you normally work from India?" you ask, bewildered.

"Yes, but I am going to be the project manager on a different project here on-shore now."

True story. Talk about putting a crimp in your plans.

Resources quit. Scope gets breached. Bugs happen. Systems go down. Priorities change. So what do you do when life throws you a curve ball? Hang on for the ride and follow these steps.

Take a deep breath. Before you react, take a moment to calm your blood pressure before you say or do something you might regret. It might save your health as well as your job.

Confirm it. I hate it when I start yelling about something only to find out I have the facts wrong. Take it to the source and, calmly, get some answers.

Assess the impact. If the issue is scope related, determine the gap factor. Resources can be difficult to replace. Is there a more junior member of the team that might be easier backfill? Can she step up to the role?

Check the schedule and budget to determine what the damage will be.

Identify Options. Don’t work in a vacuum to figure out what to do. Invite your team and other stakeholders to help develop strategies to stay on track.

Present Options. Take your findings and options to the Sponsor or Steering Committee. Explain the challenge facing the project and ask them how we, as a group, should resolve it. One of the things I stress is that the project manager does not own all of the problems. They are "our" problems and "we" have to take steps to resolve them.

Get approval. If a Change Request is necessary, file it and get it approved. Get the go ahead to make the resource changes. Confirm commitment by getting approval.

Learn. Figure out the root cause and take actions to keep it from happening again. You can’t keep a team member from taking a better job offer, but you can make the current position better. Scope is drawn to determine when it does change, not if it will. You can take steps to manage it better.

Move on. It is better to get beyond the issue than to dwell on how things should have been. Once you have taken steps to keep it from happening again get on with successfully completing your project.

Stuff happens. You can’t control the surprises but you can control your reaction. If it were simple, anyone could do it, right?

March 20 – Random Lessons Learned

Learning from your mistakes is a good but to learn from someone else’s mistakes saves a lot of time. The trick is to find someone willing to admit their mistakes. Fortunately I am secure enough in my stupidity to share a couple of mine.

Don’t be a bonehead. I remember trying to walk through an audit with a project manager that just didn’t seem to be getting the concept of project tracking. Rather than patiently working it through with him I blurted out, “Are you sure you want to be a project manager? We could probably work you back in to a technical field.” That effectively ended the conversation.

Avoid poking dragons. Within our consulting company everyone from newbie to upper management is expected to create a status report. As a member of the Project Office I was tracking and reporting on the number of individuals who where not producing them. During a meeting with upper management someone asked why I thought people weren’t doing it. In response I verbally picked up a stick and poked the management dragons by saying, “it could be because management isn’t producing theirs, either.” Needless to say, the dragons woke up.

Not all hopes come true. I have a good friend who worked as a process and quality auditor in a company that valued process less and less over the years. When her department was outsourced to a process oriented consulting firm her hopes soared. Finally the cavalry had arrived. Unfortunately the cavalry struggled with the same management issues she did. Management was slow to see the benefits of process and always tried to drop it. Rather than despair, the group aimed high, worked hard and lowered their expectations.

If you don’t want to milk cows for the rest of your life, don’t learn how. This was a bit of wisdom my grandmother used to tell my mother. Granted, there are aspects of your job that aren’t enjoyable but still need to be done. However, there are other things that probably don’t make sense for you to take on. SAS programming is a good example. Yes, it is still around. There may be a need for some simple SAS reports, but unless you want to be the one everyone goes to for SAS you might want to find someone else to do it and claim ignorance.

Hopefully you can take these lessons to heart and not have to stub your toe on them yourself.

If you have experience from the school of hard knocks, weigh in with a comment and help us all get a little wiser.

January 16, 2007 – Lessons from a Shotgun

I grew up in rural western New York State. By rural I mean there were more cows than people in most of the towns. The street my parents live on to this day intersects with Pondunque Road. The college I graduated from, Houghton College, boasts that it has at least two trees for every student. Because of this forest filled environment it seems that everyone owns guns. My brothers were out back one afternoon practicing their shooting skills. They hung a can from a tree by a string. One of them would swing the can, get out of the way and the other would try to hit it.

My dad was a chef at the college and would cook breakfast and lunch, come home to take a nap and then return to cook dinner. Needless to say, gunfire doesn’t allow for much napping, so out he comes. When he arrives he takes the gun and says, “Let me try.” The can swings, my dad fires, the rope snaps and the can flies to the ground. “That, boys, is how you do it.” He handed the gun back, turned and went back to work.

I learned three things from that unspoken lesson.

1. It is better to be lucky than good. A good shot would have hit the can, making it jump and bob. Hitting the string would require a marksman or a lot of luck.

2. Never admit it wasn’t planned. Planning well and working hard will set you up for success, but sometimes you accidentally hit a home run. Don’t stand around looking dumbfounded; act like you meant to do it. Let others try to determine if you are a marksman or just lucky.

3. Know when to walk away. My dad could have shot for the rest of the day and never hit that string again. He knew it and quite while he was ahead, leaving us standing around with our mouths open.