Preventing Project Failure

Today I’m beginning an on-going series called Real Life.

I Started A Baby PMO Yesterday I manage the development of various intranet and extranet applications for the Army. As Deputy Program Manager I have a staff of 10 analysts, testers and trainers that are applied to various projects. There is a co-lead for a team of 8 developers.

Say Happy Birthday to our new Baby PMO! Such a Cutie!

I have three fantastic brilliant project managers in training who are growing into excellent PMs. But I realized this week that I wasn’t pushing them hard enough to do the technical aspects of project management. They are all great communicators, so their stakeholders are well informed, but when it comes to immediate dissemination of meeting notes, or keeping a schedule up to date, or updating a risk register or documenting stakeholder analysis, I wanted to see more technical proficiency.

So I struggled a bit because I’ve had some pretty directive, technical bosses in the past, who laid a heap of documentation on very busy PMs and didn’t have a lot of understanding when, for example, the project report came in one hour late because you were on the phone with a client. I didn’t want to be that person.

But , as we get busier, I’ve got to have a way to know what’s happening in the projects without breathing down their necks. Further, if I’m not pushing them to be disciplined, then I’m not doing them, or the profession, any favors. So I had my aha moment and I wanted to share with you, and get your feedback on, what I’ve put in place.

Creating Project Management Standard Operating Procedures First, I increased clarity around what the expectation was for each PM. Since we are on a path to CMMI, we make sure that everything we do becomes a documented procedure. So I updated old SOPs and created new ones. My main goals with the SOPs are to:

 Clarify what’s expected of a PM – I want a new PM to come in and know exactly what to do and I incorporated my lessons learned about what is truly the most important pieces to gather on each project.

 Keep it simple so that its quickly and easily actionable – That means that I was very light on metrics, for example. There’s a simple gauge for determining if a project deserves the light or heavy treatment with documentation as well.

 Reference back to Standards – These SOPs are built around PMBOK ideas, so if the PM needs more information, they are instructed to reference the PMBOK.

So here they are; my Project Management Standard Operating Procedures.

Note: All documents have been scrubbed of proprietary data.

 Project Initiation. The Project Initiation SOP specifies the initial tasks a PM has to do to get the project up and running.

 Project Documentation. The Project Documentation SOP details documents that must be delivered for each project. PMs can go with less documentation if it’s a “Small” project; ie less than 6 months from initiation to close.

 Managing Project Risks. The Managing Project Risks SOP provides the guidance on the mechanics of keeping up a risk register, though it doesn’t provide information on how to identify a risk.

 Scheduling and Metrics. The Scheduling and Metrics SOP specifies that a GANTT chart should be created, required fields and the a requirement to baseline. It also specifies the two metrics we’ll be using; duration variance (quantitative) and project status indicator (qualitative).

 Assessment and Reporting. The Assessment and Reporting SOP provides detail about how a project will be assessed by the PMO and when weekly and monthly reports are due.

The Weekly Report to the PMO Second, I set up a easy to update list on sharepoint as our weekly PMO reporting. I’m asking the PMs to rate themselves with an indicator called ‘project management indicator.’ This allows the PM to evaluate how well they are performing against the above 5 SOPs. I thought about setting the indicator myself, after a weekly review of their work, but then figured that it would be much more powerful and instructive for them to reference the SOPs and understand where they may not be aligned, on their own. Again, with this list, I want to keep it simple, so that it’s not a time suck.

Implementation I’m implementing these processes gradually. This week is all about reading and understanding. Next week will be about getting familiar with weekly reporting and deciding collaboratively which day to make the report. Then we’ll kick it off formally the week after that. Again, the most important thing is that this stuff allow the PMs to think and communicate, so I don’t want to burden with a sudden process that has to be implemented immediately.

Things I’m Worried About

· Duration Variance – I need to be able to pull a metric out of project that doesn’t use cost, because we don’t have visibility into cost on this program. I’m looking for opinions on this one.

· Project Size Indicator – Is the less than or greater than six months indicator really useful? Will it prove to be too simplistic?

W.A.I.T! I heard a fantastic acronym at the PMI Washington, DC Chapter August Dinner meeting last week. This is circa Dave Gerber and its Why Am I Talking or W.A.I.T. So I’m going to shut up now and wait for your feedback!