December 15, 2008 - Killing False Confidence

You leave for your flight well ahead of schedule. Traffic is light and you arrive, unhurried, at the airport. Strolling up to the counter you secretly laugh at the frantic people running toward the crowded ticket line or scanning the flickering departure screens in panic. Being the saint that you are, you even let a mother with a screaming child ahead of you in line, silently praying they are not on your flight.

The kiosk attendant signals you forward and you confidently hand him your ticket. Reading his tag you smile and say, “Good morning, William.” He glances at the ticket and looks quizzically at you then rechecks the document before calling over a manager. As she scans the paper you catch William staring at you with a smirk on his face but he quickly turns away.

“Sir,” the manager says, “were you aware that this ticket was for yesterday?” Your sense of confidence is proven false…and your day was going so well. Fortunately, William is to busy helping the next customer to notice the dumb look on your face.

Call it paranoia, but every time I get a strong surge of confidence I get nervous. It seems that no matter how many times I verify project progress something ugly always rears its head to ruin my day, like when:

• The vendor promised a strong replacement project manager for a very client intensive project. During the turnover meeting the clueless look on his face caused a bit of doubt. Upon questioning, he admitted to never having managed a project before; never receiving project management training; and wasn’t told that his new role would include project management.
• The team developing the backend interface has been “on schedule” for testing for weeks. At every status meeting they re-state that they will be ready by 6/28. On 6/28 they proudly announce that they have completed the interface…design.
• The support team has confirmed that backups are being performed nightly. They have even told the project manager to stop repeatedly asking such a stupid question. After all, they are professionals and know what they are doing. A month after going live the system fails. No problem. The tapes are recalled to perform a restore only to discover that the backups never completed successfully.

How do you keep from being lulled into a false sense of confidence? I suggest you K.I.L.L. it.

Keep changing the questions. The project manager dealing with the “professional” support team asked to the point of irritation if the backups were being performed. She needed other questions that may have produced a different answer. “Who is performing the backups?” “When do they complete?” “How many tapes are involved?” “How long is it taking?”

For the interface problem, a simple “What will be ready by 6/28?” may have uncovered a serious problem.

Even though it was a fixed bid project, asking for the replacement project manager’s resume would have saved time and effort.

Insist on evidence. To ensure the project stays on schedule you need facts, not promises. One of those facts is actual time spent and estimates to complete from the people performing the work. Minimally this can be collected at the activity level but preferably by task. This exposes trends before they become trouble.

Have the support team show run times and completion codes of successful executions. Check with end users to ensure successful processing. Go check the online system yourself to verify that the changes were implemented.

Listen to what is not said. As you begin changing your questions and insisting on evidence there may be long pauses or blurted out excuses. Usually what is left out is as important as what is said. Begin by saying “So, what I am hearing is…” and restate what they said. Then follow up with “Can you confirm then that you…” to clarify what you didn’t hear them say.

“We will replace the current PM with another one” should have solicited “Can you confirm that the PM will have equal or more experience?”

For the errant development manager, reiterate that he said, “The code will be unit tested and turned over to the development environment by 6/28.”

Learn from previous mistakes. The saying “once bitten, twice shy” applies to both your mistakes and other project managers’ lessons learned. Review the results from similar projects and ask other project managers about the team members you inherit.

Informed optimism is far more reliable than false confidence. Keep checking the details and you won’t miss your flight.

NOTE: This article was originally offered to all PMI chapters for their newsletters. If you would like original content for your publication, please contact me.

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.

October 27, 2008 – Back to the Basic: Communication – How

Once, in the midst of a long distance relationship I had the grand idea of sending a Western Union Telegram to my girlfriend. From my vast knowledge of telegrams, based solely on movies and TV, I knew that every time you put a period they say "STOP" to indicate the end of the sentence. I envisioned a hand delivered envelop with the words “Don’t STOP loving me and I won’t STOP loving you” on Western Union paper. I think they took my $20 and placed a phone call instead that incoherently said "Don't loving me and I won't loving you."

Telegrams were a great way to express you feelings in the 1800’s but by the 1980’s it was out dated. Sometimes you know what to say and when to say it but fail to be heard because of how you choose to say it.

How to be Heard. When deciding how to get your message out, you need to consider both the method and content.

The method does matter. There are the normal methods:

• Phone. Great for quick answers and to give initial direction. Not so good for detailed instructions or approvals.
• Voice Mail. Excellent for letting people know you called and for playing phone tag. Don’t rely on it to guarantee the message was conveyed or that action will be taken.
• Instant Messaging. Good tool to exchange ideas and verify progress.
• Email. Reliable for giving more detailed instructions and receiving approval. Not very personal and can lead to chaos when everyone replies to everyone else.
• Teleconference. When your team is half way around the world, email doesn’t cut it. It can take 2 days to convey a message. Scheduling a teleconference can clarify the conversation quickly.
• Webex / GoToMeeting. Web meeting tools that allow you to share your desktop information make it possible for you to run your business from practically anywhere.
• Get out of your seat. The personal touch allows you to observe the non-verbal aspects of communication like body language, eye contact, gestures and facial expressions. When other methods fail, it may be worth the trip down the hall or across the world.
• Video Conference. The next best thing to being there. Setting up a web cam on both ends of the world can be relatively cheap and net big benefits.

Sometimes you have to think beyond the normal to get your message across.

• Go Big. The company I work for owns a plotter for printing poster size images. Some statements need to be loud. Skywriting might be a little much.
• Websites / SharePoint. A central location for communicating project updates is a great means to keep the team, management, end users and other key stakeholder informed.
• Hand Written. In an age of electronic everything, sometimes the best communication is a hand written note. It can be a card of encouragement, a sticky note of thanks or a message on the whiteboard.

Content clarifies. Here are some simple things that will help get you heard clearer.

• Check the Spelling. I recently received a high glossy postcard from my insurance company. They spelled the word “their” wrong…twice. It doesn’t instill a large amount of confidence in the company.
• Reread it for clarity. Some sentences make their own nonsense…like this one. Often I review what I think is brilliant writing and find it muddled.
• Shorten it. As you reread, look for simpler, more concise ways to communicate your thoughts.

In the end, you need to merge the What, When and How to get your message across.

By the way, that long distance relationship? We just passed our 19th wedding anniversary.

October 13, 2008 – Back to the Basic: Communication – When

Rarely do you hear a project sponsor say, “There is way too much communication going on here.” Unfortunately a common complaint is the lack of communication. True, the loudest complainers are often those that opted out of the weekly status meetings and never responded to your emails. You are left wondering when it is appropriate to connect with them.

When to Speak Up. This weekend I was listening to The Tech Guy on a local radio show. Google is piloting a new gmail feature that checks your sobriety before letting you hit the send button. You have a minute to answer math questions correctly to proceed. Evidently too many drunks were waking up in the morning with a hangover AND some explaining to do. For the record, late night may not be the best time to send an email. Sleep impaired judgment can make the worst email look like Shakespeare.

Status. Many factors go into how often you need to get the word out on your project’s progress. The list includes:

• Project length – Quick hit projects may be over within a week so weekly meetings are useless. For projects in excess of a year, weekly status meetings are too frequent during slower development phases.
• Development type – Agile project development requires daily, fifteen minute, standing meetings. More traditional projects don’t.
• Location of resources – Co-located teams communicate hourly. World-wide teams require more structure behind their interaction.
  

End Users. It has been my experience that the biggest potential failure in communication is with end users. We engage them to get requirements, flash some screens by them for User Acceptance Testing, and finish by dumping the product on them unannounced. Instead of being the central focus they are nearly an afterthought.

Use touch points throughout the project to build to the product release finale. Electronic Arts and other entertainment related industries go all out. When EA Sports released “Tiger Woods PGA Tour” the world knew months in advance and they gave it a media show kicked off. Major motion pictures splash billboards, previews and internet sites long before opening night.

Instead of the implementation date being just the point you are pushing your team toward, start a count down for the intended recipients. “NEWS BULLETIN: Only 47 Days until Dallas goes Digital!” Tease them with the features they will get.

Road construction has the main route to our house torn up. A typical construction sign reads, “Reduced lanes from September 15 to November 10. Use alternate routes.” That says “Your life will be painful for then next 2 months.” Instead they should say, “On November 10 your pothole problems will be gone.” Or “Coming soon: An extra turning lane to get you home faster.”

No Surprises. Ever the optimists, project managers tend to hold out on reporting bad news in the hopes they can right the boat before it sinks. If you foresee problems, raise them as risks as soon as possible. Be proactive in avoiding and mitigating them before they become issues.

Rarely does an issue spring out of nowhere to crush a project. By not warning management ahead of time you eliminate any leadership they may be able to give (additional funds, better people or different priorities) and make them look bad at the same time. Not a good combination. Managers tend to remember such things. With advanced warning the Titanic might be retired to the docks in Long Beach, CA instead of the Queen Mary.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 8, 2008 – Back to the Basic: The Troubling Triangle

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

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

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

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

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

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

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

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

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

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

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

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 20, 2008 - Random Thoughts

While on vacation I am pulling together a chunk of my blog entries to publish in book format entitled Project Management RX: 101 Daily Doses. This hasn’t left me much time to sit down and write anything new, but I did have a couple of random thoughts to pass on to you.

Red, Yellow, Green. The often used RYG symbols indicating project status risk levels have proven very useful. But what if you were sitting at a stop light and the color never changed? It can be very frustrating. Sometimes I am tempted to jump out of my car and press the crosswalk button to make it change. For your project, anything other than Green should be temporary, too. Items causing your project to be Yellow should be resolved within 2 weeks. For Red issues, fast action should be taken to back it down to Yellow within 2-4 days.

Intolerable. While mentoring projects managers I occasionally hear the statement, “I guess we just have to live with it.” We cave in on many issues and inconveniences, including poor performers, additional scope, old resources, impossible time lines, or slow responses from other department. We feel like there is nothing we can do to stop it. Instead of whining about it, here’s a suggestion. Document the items as change requests and present them to the sponsor and PMO. Explain the impact to the project and receive their buy in stating that they are okay with it. When they see it in black and white it will be harder to ignore, forcing some action to be taken. If you put up with it, nothing will ever change.

July 14, 2008 - Postponed...

Too busy this weekend with house renevations, family stuff and prep for vacation. Should be able to add an update later this week.

Until then....

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 23, 2008 - 10 Ways to Avoid Falkirk

The Falkirk battle scene in the movie Braveheart has William Wallace engaging the English army. At a crucial point in the fight, the Scottish nobles that were supposed to be his allies betrayed him and withdrew from the field, leaving him to be defeated. Knowing who your allies are is important. Knowing you can trust them is vital.

This goes both ways. You need to know your team is behind you but they need to know you have them covered, too. Failing to protect them, you can imagine how quickly they would hunt you down and dispose of you, much like William Wallace did to his enemies.

Keep yourself and your team from being destroyed with these 10 points.

Be aware of conflicts and issues within the team. Not all disagreements are unhealthy, but when it becomes a conflict it needs to be aired and dealt with quickly.

Recognize a challenge from outside. Some people are able to couch their attacks in a manner that hides their intent. It starts out supportively with “Your team does have an aggressive timeline and seems to be over allocated.” Then it turns to “Obviously they can’t estimate properly and are incompetent in other areas as well.”

Address the attack. If a member of your team comes under fire during a meeting it is your job to set the record straight. You don’t have to defend the guilty, but you can keep them from being executed on the spot. Let the attacker and anyone he has told know that the issue is being handled and, if appropriate, how.

Verify the facts before laying blame. Nothing kills credibility with your team faster than assuming they are guilty. A manager I once knew failed to find the truth before assuming his new team was in the wrong. It took him nearly three months to realize his mistake. He never regained the confidence of his team.

Eliminate flashpoints. If you have team members that can’t stand each other, don’t make them work together. One individual I worked with lacked any verbal filter and could be a little abrasive at times. Unfortunately he was heading up a task force that dealt directly with upper management. He said some things to the CIO that should have been left unsaid. Luckily the CIO was extremely patient and handled it well. That person didn’t stay the head of the group long afterward.

Have an open door policy. Give your team the opportunity to talk through problems and address things directly with you before they get explosive. My principal in high school had an open door policy and it probably saved me from being expelled. An idiot named Bubba moved in during my junior year. For no apparent reason he started spreading lies about my girlfriend. He deserved a thrashing, and I told the principal I was going to do it if he didn’t stop. Mr. Stockin was able to talk me down and save my academic career.

Escalate major issues to upper management. If there are problems that have further reaching impacts, senior management needs to know and be involved in resolving them.

Allow time for the situation to cool down. Like a cut, some things take time to heal. If you keep picking the scab the situation is going to scar.

Revisit the situation to ensure the coals aren’t smoldering. After the cooling down phase, loop back around and check with the involved parties to address any lingering problems.

Treat everyone with respect, even the difficult ones. I’ve been asked to be a reference for people I did not enjoy working with. Evidently they were clueless that I couldn’t stand working with them.

Notes:

• There several historical inaccuracies in the Braveheart movie. Falkirk may never have truly happened.
• I generally hide the identity of my examples, but it felt good to finally take a swing at Bubba.

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.

June 2, 2008 - Under Construction

I am in the middle of multiple construction projects. Last week it was the guest bathroom. A trip to IKEA netted a new vanity, sink, faucet, medicine cabinet and wall shelves. For good measure I purchased a new light. Because nothing is ever simple, I had to drywall part of the hole where the old medicine cabinet was and add a layer of paint to that wall. All things considered it turned out pretty well and cost me less than $350 US.

The next project is to repaint the dining room. One wall was bare wood so a coat of primer went on today. We'll probably go with a chair railing and a two tone wall above / below that.

One last thing I am playing at is reworking my home page (http://www.cuttingsedge.com/). I spent quite a bit of time on it this afternoon and failed to acheive what I had hoped to. In the process I upgraded to Microsoft Word 2007 and thought I would see what the publisher would allow me to do out of the box. From what I have seen it is impressive so far, but it didn't allow me to publish effectively.

I have been putting off creating a realistic home page and allowing my blog site to cover for me. Time to step it up a notch, as they say. Look for an upgrade within the week.

For those of you in the Orange County, California (US) area: On June 10 I will be speaking at the PMI-OC dinner meeting in Costa Mesa. The topic is Grabbing Authority. For more information or to register, visit http://www.pmi-oc.org/.

May26, 2008 - Memorial Day

Take the time you would have spent reading this blog to honor those who have protected the innocent, preserved freedom and provided peace.

May 19, 2008 – Purpose Driven Projects

Last Friday I had the privilege of speaking at PMI-San Diego’s annual Project Management conference. There was a great turnout and several excellent key note speakers.

Friday’s lunch time speaker was Karen McBride, NASA Mars Program Executive, speaking about the upcoming Mars landing of the Phoenix project (5/25/08). She recapped how they managed the risks of attempting to land an expensive and extremely heavy piece of machinery 48 Million miles from Earth. The landing experience takes 7 minutes. At the speed of light, communications to and from the Mars Lander takes 15 minutes. Their mission is to put down at the pole and take samples of the ice and soil for 2 purposes:

1. To study the history of water in the Martian arctic and
2. Search for evidence of a habitable zone and assess the biological potential of the ice-soil boundary.

She was quick to remind us that they are not looking for life on Mars, just the potential for life.

The last speaker of the conference was Red Hat founder, Bob Young, whose latest endeavor is LuLu, the online self-publishing company. The purpose of the company is to eliminate traditional entry barriers to publishing and enable content creators and owners to be heard.

What is your project’s purpose? You can’t motivate your team to quality and getting to market solely on making the company more money. Understand the business purpose of the project and then translate that to how it will impact your customers.

Several years ago I heard a Project Management in an insurance company say their project could save lives. At first I thought it was a stretch, but after thinking it through I altered my perception a bit. If an error caused the company to deny necessary treatment coverage it could result in death.

Here are examples from some of my previous employers. For each there is a Reason and a Purpose. The reason simply states the scope of what we were doing. The purpose gives the effort a value.

American Greetings: Handheld Inventory Applications.
Reason – Accurately record returns and stock on shelves.
Purpose – Enabling the timely restock of cards to supply just the right thoughts, words and emotions to cheer a patient, brighten a day, thank a mom and encourage a child.

KeyBank: Customer Marketing Database.
Reason – Store customer information to identify additional sales opportunities.
Purpose – Proactively offering cost savings and financial opportunities for customers to enhance their lives by funding their dreams of education, home ownership and a better life.

Marymount Hospital: Y2K Application Testiong.
Reason – Ensure the applications would work successfully at the turn of the calendar.
Purpose – Ensure the functionality and security of patient treatment and information systems, without which the health and life of individuals may be at risk.

These are just three examples, but you can see the difference it makes to think through why the project was initiated. I can’t get too excited about a telemarketing database but a database of people with dreams to be funded I can promote.

May 12, 2008 – Stop Wasting My Time

My brother-in-law, Paul, tells a story about a boy, Theo, who wass afraid of clowns. The tale follows Theo’s life from childhood to teenager to young man through to his old age. At different stages in his life he attempts to survive a circus performance but always ends up fleeing, screaming hysterically, at the sight of the clown. He tries therapy, hypnosis and other extreme means to cure himself. Finally he joins a religious order of monks known for their fearlessness and sharp comebacks in the face of danger. In the final confrontation with the clown, Theo is being chased, stumbles and falls down. With the clown standing menacingly over him, Theo finally faces his fear and yells, “I don’t like you very much!”

Quite pointless, eh? Paul can drag this story out for at least 15 minutes, adding more details and deeper insights. When he finishes you feel cheated out of a large portion of your time.

As project managers, we need to make sure that what we are asked to do has purpose. The Systems Development Life Cycle is a great example of this. As part of the Project Management Office, I expect pushback from the people using the SDLC. The majority of the templates and processes come directly from the teams, but if they don’t make sense we need to get them changed. In order to be successful, everyone needs to get involved in the following ways.

Know What. Keep an eye out for PMO announcements telling you what has been added or changed. When you start a new project or phase, browse through the processes, templates, best practices and lessons learned to make sure you have the latest and greatest. The temptation is to modify what worked for the last project, but great improvements may have been made since then.

Understand Why. I’ve been guilty of playing the PMO blame card. Early in my PM career I would ask the team or client to complete something “because the PMO requires it.” A great example is the Risk Assessment. If you are just filling in risks because you have to, you are missing out on a project saving devise. Telling the client / business that you have to have one to pass an audit may get you off the hook immediately, but it shoots an arrow into your support team. Eventually the client / business will think all PMs blindly do whatever is dictated. They then loose faith in the whole organization.

Use Them. Put the process to the test. Processes and templates generally aren’t built to gaze longingly at. They make really lousy wall hangings and lawn ornaments. They are intended to be used. Besides, the best and most constructive complaints come from those that have tried to use them, not those that ignore them.

Provide Improvements. The goal is to use the group’s collective knowledge and learning to continuously refine and replace what exists today. The PMO will be among the first to admit that the best answers come from the line. Toyota’s manufacturing success has at its core the right and responsibility of assembly workers to suggest ways to make it work better.

The users of the processes are the real owners, not the PMO. If a piece is broken, get it fixed. If it doesn’t make sense, find out why it even exists. If no one knows why, get the PMO to drop it until someone screams for it back.

In the end, no one wants to waist your time with pointlessness. Well, except maybe my brother-in-law.

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 28, 2008 – Them’s Fightin’ Words!

Choosing the wrong words can start a fight. I vividly remember conducting a PMO status meeting with upper management in which I nearly started a brawl without meaning to. While reporting the results of a recent project audit, I made the observation that very few resources were completing their weekly status reports. I surmised that management was setting a poor example by not producing their status reports. Unfortunately I said it out loud, immediately creating a hostile environment for myself.

Here are five lessons to learn from this:

1. Watch what you say. Obviously the filter between my brain and mouth was not functioning during that meeting. Check your filter before you let something slip. Report the information concisely and clearly. You can present analysis and reasoning, but leave out the commentary.
2. Consider how you say it. Only 7% of face to face communication is the words you say. Tone and visual cues (body language, gestures, eye contact, etc.) make up the other 93%.
3. Recognize a challenge. Sometimes people deliberately try to draw you into a fight. They know the buttons to push and they start poking them. It may seem like an innocent question or a simple statement but it is intent is to challenge your authority and put you on the defensive: "Our projects have not been completing on time. Is it the role of the PMO to audit them and ensure they are successful?" It may even come across as a show of support or sympathy: "The PMO is obviously too understaffed to be effective in this environment." Be aware of who is saying what and think through why they may be saying it.
4. Don’t take the bait. There are some things that are worth fighting over, but not everything. Just because someone is looking for a battle doesn’t mean you have to take it. This doesn’t mean to run from a direct challenge but don’t jump at every offense. Choose the time and place for your battles.
5. Respond appropriately. The greatest life management book ever written says, "A gentle answer turns away wrath, but a harsh word stirs up anger." Think it through and determine what is being challenged and then choose a response like one of the following:

• Call them on it. A direct challenge in a group setting requires a response. One tactic is to look them straight in the eye and ask, "Are you challenging my authority on this?" Generally people back down at this point. If not, you may have to pick another response.
• Ignore it. You can ignore a question or comment that is intended as an attack. Don’t ever try to answer question like, "Are you still beating your wife?" It may be prudent to ignore a slight at the time and address it in private later. Sometimes the offense is unintentional and it won’t happen again, but if it continues you will need to deal with it.
• Apologize. This is especially effective if they are reacting to a perceived threat by you. Believe me, during that status meeting I apologized quickly. True as it was, I needed them on my side to be effective.
• Just the Facts. People can get defensive but they can’t really argue with facts. Make sure you have them right and then present them as evidence to support your case.
• Humor. Making light of a comment acknowledges it and defuses it. Don’t mistake ridicule for humor, however. Making fun of the person will just tick them off and escalate the fight.
• Delay. Retreat is not giving in, it is allowing both of you time to cool off and try again later.
• Defend yourself. When push comes to shove, sometimes you have to push back.

It is easy to throw out fighting words. Dealing with them takes maturity and forethought.

Volunteering: Good for Credibility, Bad for Blogging

Volunteering has been on my mind lately. This is partly because I am now a member of the Board of Directors for the Orange County Chapter of the Project Management Institute (www.PMI-OC.com). Volunteering is a great way to:

• Get involved
• Meet people who share similar interests
• Establish credibility
• Network
• Have fun while doing it.

It is also the reason I didn't get around to writing a entry this week.

Until next time...

April 14, 2008 – Surviving the Project Review Firing Squad

Companies have this crazy idea that they want their projects to be successful. To ensure this they modernized the firing squad and changed the name to “Project Review Meeting.” A recurring meeting is scheduled where the project managers stand up and give an account of their progress. Guns loaded, management fires questions at them, trying to find holes in their stories.

Here are 5 ways to help you dodge the bullets and come through the firing squad in one piece.

1. Update your data. Old data results in upper management making poor decisions. Giving an accurate picture of your project includes maintaining the schedule, updating risks and issues and revising the change requests.

One of the biggest side benefits of having a regularly scheduled Project Review Meeting is that it forces the project manager to refresh their data. There were several times when my Risk Assessment sat neglected until days before the meeting. It forced me to revisit the risks and take action.

Always being the one apologizing for having outdated information does little for your reputation as a strong project manager.

2. Produce the documents. Whether you are physically printing them or displaying them electronically, having the documents ready on time is important. If the meeting owner prints or displays documents from a central repository, get it in on time.

3. Say something worth hearing. When I was about ten I had reconstructive surgery on my eardrum. For weeks afterward my mother would drive me 30 miles to the doctor where we would sit for 20 minutes. Once in his office he would say, “Looking good. Come back in another week.” It didn’t take long for my mother to tire of that trip and start demanding more information.

At a minimum tell them what was accomplished for the previous period, what is coming up and how it is tracking. For tracking include a light version of Earned Value: are you ahead/behind schedule; over/under budget and by how much? Include issues or risks with which management can assist.

4. Show facts to substantiate statements. Percentages are great…if they mean anything. One PM always included the statement that her project was 64% complete. She never really explained what that percent meant or what she was measuring. They may have spent 64% of the funds or they could have had 18 weeks left of their year long project. The percentage alone was useless. Put it in context and have the figures available to back it up. You don’t have to walk through the numbers, just make them available.

5. Practice your presentation. Listening to someone fumble through a status report is painful. Watching them flip from slide to slide trying to piece together a full sentence only serves to communicate a lack of respect for the audience. The only thing worse is being the one giving the presentation. I know. I have attempted it.

In the end, the real reason for the Project Review Meeting is for management to gain a comfort level that you are in control of your project. You can keep their confidence in you high if your data is up to date, your documents are in order and you present your status coherently. Then they can save their bullets for someone else.

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.

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?

March 18, 2008 - Estimating Lessons Learned - Agile Methods

One of the most pathetic looking sights on the highway is a man walking, head down, with a gas can. He represents the ultimate in poor estimating practices. It is bad enough that he ran out of fuel, but he was probably already late or he would have stopped to get gas. Having the embarrassment of trekking back to the car only adds to his dilemmas.

One of the misperceptions of Agile development is that the team continues to code until they “run out of gas” by hitting the target date.

Lesson 5 – Agile development requires estimation.

Although non-traditional methods differ in their techniques, they still rely on estimates to plan for and meet projected dead lines. We’ll look at three different types: Predictive Modeling, Time Boxing and Planning Poker.

In order to be effective, each of these estimating types requires a prioritized list of functionality and features that define the scope of the project. SCRUM estimates items on a Product Backlog. In the Rational Unified Process (RUP) Use Cases are identified and estimated at a high level (ex. 2 days for A and 5 days for B). XP uses Stories. The difference lies in the way the estimates are determined.

Predictive Modeling involves breaking the product into pieces and assigning relative work units to each one. For example, you may assign feature X 5 units and feature Y 10 units because Y is 2 times bigger or more complex than X. Initially you predict the duration for the first set of features and extrapolate the full project effort based on those numbers. Upon completion of the first set you have a better idea of how long it will take to complete the next, allowing you can refine your prediction. As each piece is completed you can more accurately estimate the remainder of the project.

Time Boxing is based on the concept of set periods of duration, anywhere from 1 to 6 weeks, for each release. Based on their size, complexity and dependencies, Use Cases (or features) are scheduled for specific releases throughout the project. At the end of each release the next set of Use Cases is re-evaluated to verify that they are the right ones and that they can still be completed in the timeframe. If a trend begins to appear showing that the team is consistently falling behind, the overall project schedule will require re-evaluated.

Planning Poker is a variation on the Wideband Delphi technique. In the 1970s Barry Boehm and John A. Farquhar expanded the US Armed Forces’ Delphi method to use multiple experts giving anonymous estimates for pieces of a project. Those estimates would be reviewed and the pieces with big discrepancies would be discussed in meeting and re-estimated.

As with every other aspect of development, Agile decided to speed up the process. In a Planning Poker session, team members are given cards with numbers on them, representing work effort (i.e. 3, 5, 10, 20 hours). Individual stories are reviewed and discussed by the team. Each member then selects a number from their deck that corresponds with their estimate. Only after everyone has picked a number do they show their estimates. If the numbers are close together, the value stands. When there is a large difference, additional discussion is held and another secret estimate is held.

Each of these estimating types has their strengths and weaknesses. Sometimes it is best to use a different technique for different parts of the project. The key will be how you explain and communicate the numbers to the project stakeholders. We’ll cover that next time.

March 10, 2008 – Estimating Lessons Learned - Traditional

Estimating is probably the hardest part of any project. My wife will attest that my ability to estimate when I will leave work is inversely proportional to the importance of me getting home at a specific time. The plan will be for me to only work until noon the day we leave for vacation. At 2:00 I will still need to finish my status report, change my voice message and set my out-of-office email. Maybe I just need a better estimating technique.

Lesson 4 - There are many different ways to come up with an estimate. This week we will take a look at the more traditional methods: Analogous / Top Down, Parametric, Bottom Up and Work Distribution. Next time we will discuss a some of the newer methods like Time Boxing and Wideband Delphi.

Analogous (Top Down). When a project is first considered, the quickest ways to develop an estimate is to compare it with one from your past. The question then becomes: Is it half as big or 5 times bigger? The focus is on what is different from the previous project. This technique requires the least amount of detail and gives the widest margin of uncertainty. This typically regulates it to Rough Order of Magnitude estimates.

Parametric. Normally associated with construction, Parametric estimates are based on historical data. For building a house a contractor may price it at $103 dollars per square foot. The calculation is built from years of completing similar jobs and calibrated with the current cost of materials. This is similar to the use of Function Point analysis in software development. A Function Point is a single unit of business functionality. The cost (in dollars or hours) of a single unit is calculated from past projects. New projects are defined by the number of function points and the math is done to create an overall estimate. This can be effective for features of similar sizes like reports or system interfaces. If historically it takes 40 hours to design, create, build and implement a report, 10 reports is going to take 400 hours.

Bottom Up. This form of estimate requires a more detailed analysis of the project. The Work Breakdown Structure (WBS) is defined further to identify the tasks associated with the work products. Each task is estimated and the cost for all of the individual pieces is combined to create the overall total. Using scheduling software like Primavera and Microsoft Project helps to define, record and plan the estimate. This is the most accurate type of estimate, but it requires a level of detail usually only known after the requirements are fully defined.

Work Distribution. Somewhere between Bottom Up and Parametric is the Work Distribution method. Usually the development phase of the project is estimated at some level of detail and the time for the other phases is based on a percentage of the project. The percentages are specific to the organization and project team performing the work based on their past performance. Generic numbers could be:
Phase %
Initiation 5
Requirements 15
Design 10
Construction 30
Testing 20
Implementation 5
Project Mgmt 15

The development team estimates the construction effort and the other hours are calculated based on that amount.

March 3, 2008 – Estimating Lessons Learned – Side Track

After last week’s blog entitled “Estimating Lessons Learned” I received the following comment:

“On the contrary-publishing an estimate of 1,433 hours may be entirely appropriate, unless there's a general disclaimer and/or policy noting that all estimated in a named range are rounded up to the "developer day" (five or six hours) or to a calendar week.

Generally I avoid spontaneous schedule adjustments-over time, they'll distort the schedule and play havoc with historical analysis of estimating accuracy. Any moderately quantitative sponsor or executive stakeholder should question estimates that always end in "0", because it signals subjectivity in the estimating process, and that's something we don't want.” – posted by "badge number ?"

I don’t have time to write a full blog this week (finalizing a presentation for PSQT’s Las Vegas conference), but I do want to respond to this line of thinking.

Let me begin with the last statement: “...because it signals subjectivity in the estimating process.” If you work in an industry that is able to do quantitative analysis and produce a spot on estimate, go for it. The construction industry has a well established, quantitative estimating practice based on years of historical data. However, by definition (http://www.dictionary.com/) an estimate is “to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately.” The use of the words “approximate” and “opinion” denotes subjectivity.

Having said that let me agree with the reader’s comment on two counts. First, “publishing an estimate of 1,433 may be entirely appropriate.” It certainly is when you are putting together a Definitive Estimate. It is not true for a rough estimate when you lack the necessary information to be that accurate. If you can support the detailed estimate, give it to them. Otherwise, don’t give them a number that they will assume is more accurate than it is.

Second, “avoid spontaneous schedule adjustments.” They are bad. I have never advocated them and didn’t in my entry. There are key points throughout your project that you will have significantly more information. At these junctures it is important to re-evaluate the reality of your estimates and communicate any changes to management.

As we will see over the next couple of weeks, that communication begins by clearly stating the logic behind the original estimate with the estimating assumptions made to get there. When re-working the estimate later in the project, those assumptions are may not be true any longer. If the basis for your estimate changed you have a responsibility to communicate the resulting change in your estimate to management.

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.