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.

January 13, 2010 – An “OH [INSERT EXPLETIVE HERE]!” Moment

I bolted awake at 5:11 this morning…heart pounding, mind racing…to the sound of rain. Living in Southern California, it isn’t a sound I hear all that often, but it is one that strikes fear into my heart. Lest one think that I suffer from Ombrophobia, I actually enjoy a good rain storm. I miss the huge thunderstorms we had growing up south of Buffalo, NY. My true fear of rain rises from the list of my belongings sitting outside that are not intended to get wet.

Today it was the seat from our van, removed a month ago to make traveling easier for my daughter and her sprained ankle. Originally placed in the garage, it was sitting, exposed, on the patio where she had dragged it to sit in the sun.

It was indeed an “Oh [INSERT EXPLETIVE HERE]!” moment. Your mind, body and soul leave their peaceful ignorance and arrive, adrenaline pumping, heart stopping, in total awareness. I’ve had a few of those moments:
• Calculating the cost of sending my daughter to college next year
• Reading the scale the last time I weighed myself
• Opening the email telling me my team lied to me
• Checking the deadline on the project
• Realizing that my last blog was on April 6 of last year
• Getting called in to your manager’s office on the day they announce layoffs

I was reminded again that these moments are the result of choices we make every day. It usually isn’t the big decisions that trip us up. We tend to put a lot of thought into those. It is the little ones that nail us.

How many times did I walk by that seat and think, “That needs to be put back in the van” and did nothing about it? How many pieces of chocolate did I eat between Thanksgiving and New Years? Why didn’t I put either the dog or the garbage out before leaving the house?

Those haunting questions have driven me to take the Choice Challenge. By following these 5 steps, I predict you can drastically reduce your number of “those” moments.

1. Establish Priorities. Without priorities, nothing is important. You may think it is the opposite (i.e. everything becomes important), but life doesn’t work that way. Note to Tiger Woods: A moment (or moments) of excitement with a mistress is not at the same level as your family or your career.

2. Define Achievements. Set bench marks for yourself and head toward something. All great non-goal examples begin “perhaps this is the year I will…” or “wouldn’t it be amazing if….” Drop the “perhaps” and dreaming pieces and establish some real goals.

Having a happy, involved, and loving family would be a great achievement. Is it something you are going to leave to chance or are you willing to work at it?

3. Recognize Your Choices. When your phone rings, you have a choice: interrupt what I am doing or allow the caller to leave a message. Your reaction to a situation or individual is a choice: do I immediately yell and throw a fit or take time to plan my revenge… I mean response? Should I watch reruns on TV or work on my book?

Waiting until after you have eaten a candy bar to think about your diet doesn’t work. Believe me, I’ve been there.

4. Evaluate each Choice against your Priorities and Achievements. Many things are not bad, they just don’t get you where you need to go. Doing your timesheet is a good thing, unless you have a Director waiting for a report. Staying late at work to get ahead is great, unless it is your anniversary and your wife is waiting for you.

5. Make the right choice. Nine times out of ten you know what the right thing to do is. Have the courage and strength to pull the trigger on the right choice. You could avoid having another “Oh…” moment.

One of my achievements this year is to begin writing again… that and to get that chair dried off and back in the van.

January 1, 2009 – Going Covert, Part 1

Day 1 – It should have been an easy operation: go in, implement the update and get out. But it was anything but easy. It led to the Incident. Years from now I’m sure the Resource remaining with the Company may laugh about it, but this week the PMO was hit hard. The Head was chopped…gone. They pulled rank, brought her a box to go with the termination speech and brought in a Yes Man.

It may have been better if the whole unit had been pulled out. At least then we could land somewhere else and possibly do some good.

And this was supposed to be the year everything went right.

Day 2 – Made it to Friday without suffering the fate of the Head. I’ll regroup over the weekend and start fresh on Monday.

Day 5 – Overheard joking in the Development quadrant this morning. Someone said the Head had it coming. Overstepped her bounds and tried to call the Management to task for not following the Processes. IT’S A LIE! They were waiting for her to fail. Then they were all over her like flies on road kill. Stupid thing is we tried to warn her, but she didn’t see it coming.

Now the shuffle starts. I’ve been demoted from the PMO and reassigned to the Project Management squad. I knew too much to stay in the PMO but not enough to get rid of me completely. The patsies they are putting into the PMO certainly won’t push too hard or ask the wrong questions.

I’m ok for now. Gotta keep my head down, do the Job. It’s been a while since I had a full time PM roll, but I’m sure it will come back quickly.

Day 6 – Looks like I’m heading to the front lines: high profile, troubled project in the heat of battle. I suspect when he handed me the Binder, Management wanted me to think the smirk on his face was congratulatory. It wasn’t. This is a win-win for him. If by chance I survive and win the battle, the Company profits. If I fail, Management has a ready made reason to push me out. It would probably make him happy if I pulled the trigger on my own.

Day 8 – Been looking through the Binder. The previous PM didn’t do much. We’re supposed to be in Design, but there isn’t any evidence that the Requirements are complete. The Schedule looks like someone took the template and blew a big hole in it before throwing names against it like rotten vegetables at that house down on 3rd street. Not pretty.

Based on the Charter…which was never approved…we have a deadline. No real objective or clear direction. Just a deadline.

I’m assuming the previous Project Manager won the lottery…or got another job. Haven’t even heard what his name was.

Did meet the Team, though. Some of them seem pretty sharp.

Day 9 – It’s Friday again. With a long weekend of Planning ahead of me I suspect I won’t get much sleep. Entering the sleep-depravation phase. I wonder how long before the water-boarding starts.

I made the connection today. This is the project the PMO wasn’t allowed to review. It was stamped “Critical” and encouraged to “not let the Processes get in the way of progress.” Looks like it lived up to its calling because it did go critical…nearly nuclear.

And now it’s all mine.

Jump to Going Covert Part 2.

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This blog entry is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental.

November 26, 2008 – Watery Lessons

I'm in the middle of a "working vacation." Those are the ones you use to catch up on all the pieces that have been dropped over the last several weeks...or months. This blog was supposed to be one of those things. I had one topic started, but ran the concept by the Computerworld Project Management Editor. She likes it, so I will be developing an article on it...which means I needed another topic for the blog.

I was considering this while swimming with my daughters here in Palm Springs. We were having contests to see who could make it across the pool underwater without surfacing. That hit pretty close to some of the projects I have been on. What I observed was:

Disorientation. Once under water your senses diminish. Your eyesight becomes limited and your ears are muffled. You think you are heading in the right direction but end up arcing away from the target. In the middle of a project your focus can wander from your objectives, flooded by the Olympic sized pool full of meetings, tasks, resources, activities and all the other objects floating around you.

Go back and revisit your project charter. Look at what you promised the business. Are you still on track? Are you delivering what you said you would? Is your critical path backing up? Check your meetings to see if they are killing time or being productive. Swimming faster won’t help until you get your project pointed in the right direction.

Urge to Quit. While trying to cover the widest length of the pool, I found myself despairing over the distance and wanting to give up. I took two more strokes and realized I could finally see the end. I kicked through and made it all the way.

I’ve bumped into a couple of project managers lately that are wondering if it is time to find another job. Frankly, if the economy was better, they probably would have been gone by now.

If you haven’t already, create your own personal list of tasks and see how far you have to swim. Then, set closer goals. Fight the urge to quit and take it one stroke at a time.

Catch your Breath. At the end of the day, it is only a job. I spent over two hours in the pool horsing around with my daughters. In the greater scheme of life, that was by far more important than the two hours I spent answering work related emails. Go ahead. Take time to catch your breath before diving back in.

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.

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

August 18, 2008 - Stand up and act like a... PM?

For the past few weekends I have been pulling together training material to cover Project Initiation, Tracking and Reporting for HP’s Project and Program Management tool (PPM). Not the most inventive of names but it seems to be a fairly robust system that integrates Financial and Project Management at the corporate level with add-ins for QA and other project pieces.

For that reason all of my creativity has been sapped and I have been unable to blog. However, during last week’s PMI Orange County dinner meeting we had an interesting speaker. Listening to Lee R. Lambert, PMP (http://www.lambertconsultinggroup.com) was like getting a slap in the face to wake you up.

He began by asking how many people had the job title “Project Manager” and then gave us the stunning news that we weren’t. By PMI’s definition a project manager has the right and responsibility to make decisions. Very few of us actually make decisions. We supply timely information, analysis and recommendations for people that do. By PMI’s definition that makes us Project Coordinators or Project Expeditors.

Our responsibility then is to present clear truth, backed by evidence with solid analysis and delivered in a timely manner. Over the next couple of weeks I plan to revisit the basics of how to obtain that information. Far too often we fall under the hypnosis of management’s instructions to add scope, reduce costs and get it done sooner with fewer resources.

We say “oh, well” and back down with half hearted pleas for sanity to reign…but it doesn’t. Then we complain the entire life of the project, pushing the team beyond their limits and try to deliver something...anything…that resembles what was required impossibly soon.

As professional project managers we need the ability to say “Yes, we can do that and here is what it will take.” Then present a solid estimate, realistic timeline and honest cost for what they asked. State the case and let them make the decision.

So, tune in next time and we will get started.

August 4, 2008 - Failure to Manage

Our house recently went through some medium size renovations. It began with replacing the hot water heater with a tankless model. During the installation the plumber explained that our galvanized pipes were badly corroded. In some places the rusty build up was seeping through to the outside of the pipe and in other it was clogging the water flow.

Scope change #1: add $5500 to re-pipe the house using copper.

Since they were taking the shower wall apart we opted to rip it out and tile the entire bathroom.

Scope change #2: another $3500 + materials.

It finished with the “Since We’re Here” special: I was in the process of digging up my front lawn to install sprinklers and they offered to run the pipes.

Scope change #3: $800 + materials. Good thing we recently refinanced!

Instead of going with a company, I hired a couple of independent contractors. They did a great job with the work, but there was a lack of basic project management from the beginning. That failure to manage caused disappointment, minor frustration and more work for me:

• The hot water heater went in smoothly, but the promise to run the wire and mount the thermostat went unfulfilled.
• The bathroom and shower look terrific, but when they said they could raise the shower head above 6 feet, I thought they were actually going to do it.
• Refitting the house with copper was a success except for a minor design change. They originally planned to come up through the floor instead of the wall. Evidently they changed their minds and now I have big holes in my walls were the pipes come out. Evidently they don’t do drywall so now I have to.
• Removing the old shower and other trash evidently wasn’t in the plan, either.

Technically, I got more than I paid for. They charged quite a bit less than they could have, did a solid job and the bathroom alone increased our house value by more than the cost of the whole project. But if I had it to do over again I would have applied more project management myself by:

• Defining the Scope. There were several items I assumed were in scope that I ended up doing: wiring an outdoor electrical box; removing old pipes from under the house; disposing of garbage; and filling the holes in the walls to name a few. I’m sure it would have increased the cost of the project but at least communicating it up front would have prepared me for it.
• Identifying all requirements. As the “sponsor” this one was my fault. When they replaced the main water line to the house they dug under the sidewalk to connect it at the meter. Had I told them I was looking to add a sprinkler system we could have used that same hole and saved some digging.
• Documenting Changes. A potential problem was averted by writing down the prices quoted to me and verifying my understanding.
• Establishing Timelines. It seemed to take forever to complete all the projects. There were scheduling conflicts on our side and theirs that stretched the duration.
• Tracking Commitments. Every time I take a shower I will likely think, “I should have reminded him to raise that pipe.” As for the thermostat, I finally hung that to the wall today.
• Customer Satisfaction. The ultimate item a project manager would have brought to the mix was a better customer experience. Small details matter, like placing a runner on the floor to minimize tracking dirt across the floor; letting us know arrive and departure times; and setting expectations.

With the help of a project manager, I have no doubt these guys could double their work load and obtain great referrals every time. Then again, I’m probably biased.

July 7, 2008 – Making the Time Tracking Switch

Over the next several months, our company will be upgrading the project management system and adjusting our processes to take advantage of new features. One of the features getting a significant amount of interest is resource management. The ability to plan resource availability in advance will allow us to understand our project capacity and identify bottlenecks in time to adjust.

The key to making this work will be creating and maintaining realistic project schedules with resources assigned and hours tracked at the task level. The tricky part of making this time tracking switch is getting the team members to buy into the concept of entering actual hours into the system and re-estimating the time remaining. In order to make this happen you will need an EDGE.

Expect Resistance. Your team will push back when you inform them of the new expectation to record their project hours at the task level. The obvious reactions you will get include:

• It will take too long to break up my time.
• I work on too many projects for this.
• Why are you micromanaging me?

Anticipate these issues and have answers available. As an example, include additional time on the project schedule for status and timekeeping; up to an hour per week per project.

Direction from the Top. Communicating the change needs to come from as far up the organization as possible. When the CIO says this will help make us successful it carries a lot more weight than just you as a project manager advocating it. The directors and supervisors need to buy in, too. If management doesn’t take action when time isn’t recorded then nothing will happen.

Give Up Some Detail. In order to make this work you may need to cut down on the level of detail in the schedule. Trying to divide time up into 2-4 hour chunks for 3 different projects will drive them insane. The opposite temptation is to drop all the way back to the Phase level or, worse, the Project level. Either one of these is too high. Break tasks down to between 8 and 80 hours (approximately 2 weeks of effort). Additional details can be listed and tracked as started / completed in a spreadsheet to ensure specific tasks are assigned, worked and closed.

Explain the Purpose. It is important to clearly communicate why a more detailed accounting of the project time is required. Begin by explaining the need to understand resource usage and availability but make sure you follow up with these:

• Being over or under an estimate is expected. The theory is that they will balance each other over time.
• A realistic understanding of where we are off schedule allows us to discuss how to get back on track.
• Re-estimating at the task level allows us to re-plan when future resources are needed. This is especially useful if we are ahead of scheduled or if other projects require the same resources.
• This is not intended to single any individual out or micromanage the team.
  It will help identify areas where additional resources, training or other assistance can make a difference.
• By reviewing the workload across all projects, management can find workload issues and take actions to correct them.

As the team sees this information being used to make project decision they will realize its importance get on board.

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.

June 16, 2008 - Along for the Ride

For Father’s Day yesterday, we went to Knott’s Berry Farm, technically the oldest theme park in the United States. Father’s Day has to be the best day to go to an amusement park because there were no lines.

While we were waiting to board one of the roller coasters I snapped a picture of the warning sign: “Many rides at Knott’s Berry Farm are dynamic and thrilling. There are inherent risks in riding any amusement ride. For your protection, each ride is rated for its special features, such as high speed drops, sharp turns or other dynamic forces. If you choose to ride, you accept all of these risks.”

Perhaps projects should have their own warning signs:

“Many of the projects at are dynamic and thrilling but you probably won’t be assigned any of those. Regardless, there are inherent risks in managing any project. For our amusement, each project is rated for its special features, such as highly frustrating directors, unproductive team members, over ambitious time lines, unrealistic expectations and only a vague sense of scope. Unfortunately, we will keep this knowledge from you.”

So by now your seatbelt is fastened, the lap bar is in place and the ride operator has pushed the final button. Your project is picking up speed as it heads for the first turn. Now what?

Open Your Eyes. Rides are better if you can actually see what is coming. Take a realistic look at your project.

• Assess your team and determine what to expect from each individual. This includes knowledge, ability, availability, work ethic and attitude.
• If already written, re-read the charter or statement of work to understand what bumps you are expected to hit.
• If the charter or statement of work is not written, take the opportunity to write it, defining your scope and setting everyone’s expectations.

Secure Loose Articles. Straps on your glasses are a good idea. Get a good understanding of your budget, resource allocations, scope and any other aspect of your project that isn’t well defined. If you can’t explain it, you can’t manage it.

Focus on the Horizon. Some rides can make you sick to your stomach unless you focus at a fixed point and ignore the whirling objects all around you. Set you sites on the project scope and reign in the urge to go chasing extra items to add on.

Put Your Hands in the Air. Gripping tightly to the restraining bar does nothing to direct the ride or protect you. If you are strangling your team trying to force them to do things your way, loosen up a bit. Micromanaging the team isn’t going to keep it on track.

Scream. There are appropriate times for letting it out. Surprise, shock and horror occasionally pop up while managing projects. The tricky part is keeping it from becoming anger and dismay. Maybe screaming isn’t the most effective communication method. Lower your voice, but make sure people hear your concerns and address the issues.

Enjoy the Ride. Survival shouldn’t be the only goal. Having fun along the way is good for your team and for your blood pressure.

June 9, 2008 – Project Success…at What Cost?

Great things can be accomplished if Scope, Budget and Duration are no object. Here are some historical examples:

Hoover Dam
Scope: Stop a river and produce 2080 megawatts of power.
Budget: $49M US cost (under budget)
Duration: < 5 years (2 years ahead of schedule)
Added Expense: 112 Deaths

Egyptian Pyramid
Scope: Started as a grave. Scope creep resulted in one of the Seven Wonders of the Ancient World with quite a bit of gold plating, literally.
Budget: Spare not Cost
Duration: 27 years each
Added Expense: Slave Labor

Great Wall of China
Scope: Stop the Xiongnu attacks with a really big wall (6400km / 4000miles long)
Budget: Unknown
Duration: Several Centuries
Added Expense: 2 to 3 million Chinese lives

Each of these was an amazing project and each came with a high price tag in human lives.

Unfortunately there are a fair number of companies that force their teams to nearly kill themselves for unrealistic timelines. A friend of mine told me of the unhealthy environment they had recently left. The pressure there was tremendous. Deadlines were strictly enforced, resulting in projects that came in on time. How? People were required to work as much as 80 hours a week and be on call when they weren’t physically there. This resulted in people quitting, massive amounts of sick time request, spouses threatening divorce and people being hauled off in ambulances.

What made this story ironic was the fact that the company was in the health care industry.

How can you avoid killing your team?

Involve them in the estimating process. It seems obvious, but the people that do a deed generally know what it takes to get it done. Your job is to question the numbers. First, make sure there are enough hours. Are their estimates only for development? Did they include requirements, design and testing? Next, get a second opinion. One method for this is Planning Poker (see entry on Agile Estimating Methods). Finally, work to eliminate padding. Create a contingency pool to apply where needed but estimate the pieces realistically.

Limit overtime. Your initial pass at the schedule should not include overtime. Then, if overtime can’t be avoided, set boundaries on the timeframe. People can survive a lot if there is an end in sight. Strive to keep the overtime sprints to 6 weeks in duration. Show the team the time line and ask for their commitment.

Compensate them. Even “exempt” employees (salaried / non-time and materials) can’t be expected to work tirelessly without receiving something. The promise of several days off following a sprint can keep the team pushing forward. This isn’t expected to be an hour per hour trade for the time they put in. After all, salaried employees are expected to put a bit more into their jobs when necessary.

Set realistic expectations. As the project manager it is your responsibility to set the expectations of upper management.

Schedule team outings. Get your team out of the office once in a while. Lunch can be a simple solution. On the flip side, a friend of mine is attempting to set up a cricket match here in the states.

Give family friendly rewards. Stressful environments wreak havoc on families. Token rewards such as movie tickets or gift cards can help ease some of that pressure. Acknowledgement of that fact can go a long way. Consider presenting awards directly to spouses to show you understand the strain they are under.

Watch for warning signs. Keep on eye out for people that are putting in too many hours. Encourage them to throttle down a little, especially if they are wearing the same cloths they had on yesterday.

Very few projects are worth killing your team over. Besides, the paperwork involved in having an ambulance on site is a real pain.

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 24, 2008 – Estimating Lessons Learned – Estimate Creation

No matter which estimating type you use, there are common steps to creating one.

Lesson 6 - Include your Team. Don’t estimate in a vacuum. Using the team sets you up for success on two fronts. First, the estimate will be more accurate. They know the details of what needs to be done, without which you are just pulling a number out of your hat. Second, it builds buy in and commitment. If they are involved in the process they have ownership of the final result.

Lesson 7 - Break it down. The question always asked is “How do you eat an elephant?” Frankly, I don’t believe anyone eats elephants any more. It is probably a cholesterol thing. How do you get in shape is a different animal. Reduce it to chunks: Diet, Exercise, and Support. Then break those into pieces. Diet - What to eat and what to avoid. Exercise – Classes, weights, aerobics, swimming or walking. Support – find a group and meet regularly. Broken down you can wrap your mind around it.

Traditionally projects create a Work Breakdown Structure (WBS) to identify the work products. Another approach is using Use Cases to drill to specific stories. However you do it, chop the big chunks into smaller units that can be more accurately estimated.

Lesson 8 – Mix and match estimate types. There is no rule that says you must estimate all pieces the same way. If there is a piece that looks like something you have done before, use the Analogous technique to estimate it. For reports the Parametric type may be appropriate.

Lesson 9 – Ask the right questions. One of my previous employers estimated a project to complete a previously implemented system across an enterprise. The question they failed to ask? “Does it work in the area it was first implemented?” The answer would have been “no” and the estimate would have been considerably higher.

Lesson 10 - Document your reasoning. How you came up with the number is as important as what the number is. We’ll delve into this more next week.

Lesson 11 – Sketch a calendar. Create a sanity check for your estimate. Lay out the high level estimate on a timeline by month. Estimate the number resources you need, when you will need them and for how long. Include the number and type of resources broken down by week. Keep it simple as illustrated in the graph below.

I purposely used Excel and kept the image rough so that it does not convey any semblance to accuracy. Does the resource effort look accurate compared to the numeric estimate? Sometimes this rudimentary method allows you to see it from a different angle and find gaps in your estimation.

Lesson 12 - Add Project Management. Include time for status reporting, timekeeping, status meetings and other items. Be aware of other tasks that Project Managers may be pulled into like steering committees, metrics management and resource management. For larger projects a Project Coordinator or even sub-project leads will be necessary to help manage the effort.

In some respects establishing the actual estimate is learned and perfected as you do more estimates. What are some of the tricks you have picked up over the years?

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 19, 2008 – Welcome Aboard!

"Welcome aboard!" is, unfortunately, the only orientation some Newbies ever receive when starting a new job. If they are lucky someone shows them where the restrooms are...and how to find their way back. I can’t say how or why it happened, but I recently heard that a new project manager, on his first day, excused himself to use the facilities...and never came back. If you want to retain resources longer than a couple of cups of coffee, the PMO or department management should create a new hire initiation that covers the following areas.

People. Get them connected to others. An Org Chart helps. My biggest fear when starting in a new location is that the CEO will greet me in the hall and I’ll say something stupid. I can picture myself saying, "Must be great to be management and take all the prime parking spots!" Walk Newbies around with the Org Chart in hand and at least give them chance of not making fools of themselves. If possible, get a group to take him out to lunch and pay for it.

Access. A list of all required system, application and building accesses should be maintained. Prior to the Newbie showing up, make an effort to get the access set up. Add them to all of the distribution lists they need to be on. Extra Credit: Add to the list a paragraph or two describing what each system, application or building is and why it is important to them.

Tools. With great access must come great understanding. Too dramatic? Probably, but you need to know what tools are available and how to use them. Timesheets are a great example. Are employees required to complete one? How many different places is time recorded? When is it due? Oh, and how does it work? Make the documentation available and, when possible, step them through the first use.

Processes. For those of you who feel oppressed by process, be thankful you have one. Trying to run a project in a chaotic environment is worse. It is like hacking your way through a jungle with no paths. One client I was working had two IT departments: one had a well established process and the other took a more "whatever it takes" attitude. Several project managers moved from structure to chaos, thinking they were finally free. Within a couple of weeks they were calling back for templates and direction. They were drowning in their new found freedom.

Meetings. Every environment has a standard set of meetings that happen. In mature environments a Communication Plan exists that spells out each one along with its purpose, attendees, location, time and frequency. If the plan doesn’t exist, at least make sure they get sent the meeting invitation in time to attend the next one. Let them know what meetings they are expected to establish for their project. Is there an overall project status meeting? Does each area have their own? Are daily standing meetings the norm? Who handles the status with the Business? Is there a Steering Committee? Lacking direction some toes are likely to get stepped on.

Reports. From status to metrics, management doesn’t communicate without reports. This, too, is usually covered in a Communication Plan. Each company seems to have a different expectation for status reporting. Some obtain status information verbally at meetings with the team. Others expect everyone to produce a status report. I’ve seen several companies switch to a 4-Panel status approach (example: 1-page with 4 quadrants: Status, Financials, Schedule and Risks/Issues). Again, if the Newbie doesn’t know, someone isn’t going to get their expectations met.

Locations. The company I am currently working for has several buildings multiple miles apart on the same highway. When I first started out I would get meeting invitations for the "Large Conference Room" and end up in the wrong place. Let Newbies know where the different branches are, the best places to have lunch and how to decipher the meeting room locations. One place I worked used the names of different beaches for conference rooms. Cute idea, but where is Malibu in relationship to Laguna?

I would wait until last to mention the restrooms, though, just in case the Newbie gets the urge to check out and never return.

February 11, 2008 – Did You Get What You Wanted?

It was the perfect gift. Our daughter’s CD / Cassette player stopped functioning in time to add it to the Christmas list. We found just the right one on line for about $60. Unfortunately by mid-January it quit. It didn’t start skipping or playing songs backward, it simply refused to turn on. We contacted the company and sent it back: $19 shipping and $6 handling fee. Within two weeks a new one arrived on our doorstep. Unfortunately it was the $30 model. She was willing to live with it until it ate the first cassette tape she tried to play. Did I mention it was a book on tape from the library and it was completely destroyed, resulting in a $10 fine? So by now I have invested $105 and own a tape hungry paperweight.

Do end-users ever feel that way? They’ve gone over budget and ended up with a product that vaguely resembles what they asked for but isn’t anything they could possibly use. How can we avoid disappointing them?

Involvement. There are two sides to involvement: (1) Getting committed users to participate and (2) Using them effectively. Sell the concept that their participation is essential to building a successful product. Let them know the effort involved and timeframes they will be needed. Get buy in from their management to dedicate a percentage of their time to the project.

In order to maximize their availability, plan in advance when and how you will use them. Invite them to a kickoff meeting and lay out the plan. The tendency is to only use them a bit up front for requirements and then again for User Acceptance Testing. Send your designer and even your lead developers to sit with the users for a couple hours at a time to see what they do. The more your team understand what they are creating the better they can design and build it. Every week (two at most) touch base with the end user. Re-confirm the schedule. Bounce the latest design off them. Keep them involved.

Bite sized chunks. Agile methods use the concept of frequent releases, as often as every two weeks. The concept is not new, only the implementation. If you are not in an agile environment, instead of workable code, aim to have something tangible every 2 – 6 weeks. It may be the draft requirements or prototype, but it should be something that confirms the project direction and gains the confidence of and buy in from the sponsor and key stakeholders.

Picture it. Graphic illustrations and mock ups help people visualize the direction of the product. Use Case Models was one of my recent blog entry topics. This is a great way to drill out requirements with minimal effort.

Get Touchy. Nothing peaks the interest of end users like a demo. Moving to a screen version that mimics the final product sparks the memory, too. All too often you begin to hear, "oh, yeah, we forgot to tell you about ." Try to keep your patience and remember that the goal is a usable product that meets their needs.

As a side note, make sure they understand what they are seeing. I used to program handheld inventory machines. We made the mistake of giving the sales people a PC based tool that allowed the client to view a mocked up version of the application. It was great for developing the requirements, but their assumption was that once it was on the computer screen we just had to download it to the scanner and ship it. I’m convinced some of the sales guys thought so, too.

Keep Control. In addition to controlling your patience, it is important to control the direction and duration of the project. Too many directional changes and the product will be outdated before it ever goes live. The best way to deal with this is by starting with a core functionality release and building on to it. When an enhancement or change is raised, define it, estimate its impact to the project and have the sponsor prioritize it. Agree on which release it should be part of and what gets bumped for it. Then get back to the current release.

Remain Flexible. It may sound contrary to keeping control, but flexibility is your ally. In the end it will be the users of the system that define if the resulting product is a success. Regularly verify the critical success factors of the project and align with them. When presenting the impact of a change, explain it in terms of the success factors. If the go-live date is vital, show how the request will impact the delivery. If functionality is key, reference the priority list and ask how the change fits into the bigger picture. Communicate the trade off and get their informed direction...in writing.

If all else fails, charge them a $6 handling fee and tell them to expect a box in about 2 weeks.

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?

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.