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.

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.

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.