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.