April 6, 2009 – Going Covert, Part 6

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This series of entries is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental. To start at the beginning, jump to January 1, 2009 – Going Covert, Part 1.

Day 27, Tuesday – Management meetings have been switched to Tuesday. That actually works out well. On Monday’s I approve last week’s time, update the schedule and fill out the status report on line. In Tuesday morning’s standing meeting I confirm the status in time to make any last minute updates before the firing squad.

Speaking of firing squads, I think I’ve found a way to turn the tide on the management meetings: shoot yourself first. It sounds drastic but it seems to work.

Today I came in with my usual reports. This time, instead of waiting for the barrage of questions and going on the defense, I attacked…myself. I had already asked myself all of the questions I knew they wanted to so I walked through them all before they could start.

“We are currently 2 weeks behind schedule. In order to make the deadline I have asked the team to fast track some of the testing. We’ve completed the extract and started the data conversion and transfer pieces. While that is happening we’ve used Excel to generate a test file for the vendor, Counseling Phone Support (CPS), to use.

“There are 2 major risks to the project: 1) any additional changes to the format or content of the data. 2) The inability to make web services work as the interface.

“Because the probability of either of these remains high, I have an individual finalizing a manual means to produce the file and FTP it to CPS for processing. It may be labor intensive but we could extend the project indefinitely by supplying the data by hand.”

I answered most of their questions before they even asked them. I even threw in some they should have asked. For those I didn’t have answers to I brought the acknowledged the issue and told them when I thought there would be an answer.

Some of them looked bored. Quite a switch from the last meeting I had with them.

Day 28, Wednesday – Wednesdays always offer a little breathing space. The rush for the end of the week hasn’t started quite yet and all the reports are done. It gives me a chance to “walk around” and check with the team. It’s a bit easier when they are all co-located but I try to touch base with most of them somehow during the week. Still trying to work out the video thing with the offshore team.

Back to the PM problems. If I remember correctly we had just solved world hunger and started on world peace. No, that wasn’t it, but it sometimes helps to put this into perspective. There are a lot bigger problems in the world than the Business getting the requirements right the first time.

Estimated End Date: Deadline was set before anyone really estimated the effort.

We identified 3 types of estimates: Ballpark Estimate, Budget Estimate, and Detailed Estimate.

Ballpark Estimate is used the first time an idea is tossed out. It could be as much as 75% low because we only know the bare minimum.

Budget Estimate is given after a set of high level requirements is reviewed and an impact assessment team has reviewed it. This estimate can be up to 25% low and have a realistic duration. The end date should be announced until the project actually starts.

The Detailed Estimate is done while the design is finalized and should be within 10% of the final cost. End date should be set.

As a group we’ve decided to start using the terms. Without management support we can’t enforce it, but consistency may breed familiarity and that can lead to acceptance.

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.

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.

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.

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.

March 15, 2007 – Wowing Management

Register @ Cutting's Edge.

I heard an interesting quote the other day: “Desire without dedication is fantasy.” It was said in the context of maintaining a solid marriage, but it struck me that it was such a universal truth. If an athlete desires to be a professional but lacks the dedication to practice he is just dreaming. A farmer that wishes to have a good crop doesn’t lay around all spring thinking about it. It seems obvious in those contexts, yet it seems to fall apart in the world of management.

Many times management recognizes the need for establishing guidelines and following best practices but lacks the will to follow through with it. They get a glimpse of what consistent processes can do for them but can’t or won’t enforce them long enough to see the benefit. Granted, if it were easy everyone would do it.

I always enjoy starting in an environment where there is a lack of project management processes. It is fun to wow people with the simple things when they haven’t seen much real project management. Here are a few simple actions you can take as a professional project manager to impress your management.

Meeting Minutes. One of the simplest steps to project success is issuing minutes from meetings. It is also one of the things many project managers drop first. Minutes refresh attendee’s memories, inform those that weren’t there and give everyone a chance to confirm agreement with what happened. Good: Include a list of invitees and mark off those that show up. Better: Keep the minutes short. Give decisions, not discussions. Best: Publish them within 24 hours. Great: Use the minutes template as the agenda and send a draft version with the invitation.

Project Tracking. Use your project schedule don’t just look at it. Set it up with realistic estimates and time lines and keep it updated throughout the project. Good: Track the actual time expended (Actuals) and reforecast with the Estimates to Complete (ETCs). Better: Identify and manage the critical path. Best: Baseline to your budget and track and use Earned Value to manage the project.

Status Reporting. One of the basic communication elements, the status report is a clear, concise summary of what happened in the last week. Good: Add a section describing what to expect this week. Better: Include Risks and Issues. Best: Give the high-level project schedule indicating if you are on schedule/budget. Great: Use Earned Value statistics to show trending.

Status Meetings. Don’t just send the status report. Schedule a weekly meeting to review the status of the project with the Sponsor. It doesn’t have to be a long drawn out event. Good: Pick out the highlights from the report that will keep her informed of the project. Better: Discuss risks and issues and explain how management can help mitigate and resolve them. Best: If you don’t have an answer to a question, admit it, get the answer and get back to her.

If you can do these four things consistently you will not only wow everyone, you will deliver your project successfully and without any surprises.

November 3, 2006 - Garage Style Status Reporting

My garage is a mess. In addition to the boxes of clothes to be donated, old dressers with broken drawers and the large pile of stuffed animals there are a couple of projects in process. If I were to update you weekly on the activity in my garage you probably don’t care about most of it. This concept hold true for your status reports.

There are infinite variations of information given on status reports, but all of then convey what has been done for the recent period of time. Management doesn’t want details; they want to know what you started and what you completed. Here are some not-so-good phrases to avoid on your status report.

Met with team and discussed testing. Nobody really cares about meetings. They want decisions. You wouldn’t care that my wife and I discussed paint colors for an hour. You may be interested if we decided to paint the living room mauve. Replace “discussed” with decisions such as “Outlined Test Strategy and assigned Joe to begin creating the Test Plan.”

Continued developing Credit Collection application. One of my friends has an old mustang he is refinishing in his garage. It does me no good to have him generically tell me it is still a work in progress. It would be better for him to say, “I had the radiator re-cored and hooked it back in. Now I’m starting on replacing the hoses.” Better statements in your status might be “Completed Module X. Started design of Module Y.” Break it down and report real progress.
Development is about 90% complete. Random, unsupported percent complete is worse than giving no status. It gives the impression of accuracy without the reality. Sometimes the last 10% takes longer to complete than the first 90% did. Break the activity into pieces and reporting the number complete. The 90% complete would then become “Completed 18 of the 20 modules. The remaining 2 are scheduled for completion by the end of next week.”
Once you get your status reports cleaned up, maybe you can help me with my garage.