HALF-BAKED PROJECT MANAGEMENT

A constant refrain I hear when with clients or in my PM classes at UW-Milwaukee is "...that project management methodology sounds great, but can we only do this and this and this instead of the whole thing?"

Of course they can, and often do. But the Laws of Unintended Consequences come into play as well. Well-defined and honed methodologies work best if they are completely implemented and executed without stinting on portions that seem irrelevent, expensive, take too much time, ad nauseum. When "pick-and-choose" comes into play on PM methodologies, oftentimes the outcome is worse than had no methodology been followed in the first place. This applies to agile methods as well as process-oriented methods. In fact, agile methods are more tightly coupled with each other than process-oriented ones, so skipping processes has potentially a greater negative impact on project outcomes.

OK, I'm aware that some of the skeptics out there eschew methodologies as mostly cooked up by consultants hungry to make a lot of bucks hawking their wares. However, the fact remains that mainstream PM methodologies are tested and viable means to deliver projects within cost and time parameters. That has been proven over many years on millions of successful projects.

Another valid consideration is that PM done "by the book" has up-front costs, which gives managers and small organizations heartburn when cash and time go out the door up-front and the return on that investment is sometime later when the project is delivered. The point here is that the project will cost more (or become a sunk cost if it fails to deliver) if a project plan isn't developed and isn't executed properly.

Finally, these processes are resource-driven. That is, a PM who may be contributing in some other way to projects (as an engineer, programmer, scientist, etc.) now must pay attention to project management and let go of specific tasks within projects. Some kind of balance must be struck as the transition from the operational/tactical roles the PM played on projects to straight project management - with the eventual goal being that the PM is 100% dedicated to project management at some point.

So, let's say you are facing these constraints and need to make some choices about what can and cannot be accomplished using a PM methodology. Here's a list of "must-have's" in the traditional, process-oriented methodology and why you need it:

1. Project Charter or Statement of Work (SOW) signed off by project sponsor and major stakeholdlers - this is mandatory because if you have no initial scope or boundaries drawn about what the project outcome should be, you have no basis going forward to plan anything formally.

2. Work Breakdown Structure - Following from the charter, if you have no list of tasks needed to accomplish the work, how do you measure progress during the project and/or know that you are delivering what is required? You cannot generate a realistic schedule or budget without a WBS, although many PMs try (and fail miserably).

3. Schedule and Budget - Follows from the charter and WBS. The amount of detail and iterations required to generate a detailed schedule or budget can be compressed to save time or money, as long as each fairly represents the project situation.

4. Risk Management Plan - A basic risk plan with corrective actions if risk events are triggered is mandatory and can save your project. As an organizations perfects its PM processes and techniques, the risk plan can (and should) get more sophisticated.

The above documents are the basic, fundemental work products of a project plan. For other project plan deliverables in a PM methodology, you may find it useful to apply the following rules of thumb:

• Does the document or work product deliver value to your sponsor/stakeholders and you as a PM? For the former, it must convey useful and timely project information; for you, it must help you track progress and execute the project. If it can't or won't, don't do it.
• Can you generate this project plan element easily or with modest effort? Some portions of plans and reports, particularly detailed progress reporting using earned-value analysis, require a lot of data to be accurate. Collecting and processing this data requires time and money. If you have niether, then basic tracking from status reports and updates to the project plan should suffice.
• Is this project plan element a one-time only exercise or something you will do on all projects? Obviously, greater PM value is obtained the more time a plan element is used within projects. Certain projects require one-time-only plan elements (see point 2 above) but you will obtain better value for your efforts the more times you generate and use specific project plan elements.

Finally, a few suggestions to help ease the transition and hone your PM methodology if you're starting from zero:

• Use commercially available project management software. Sounds obvious, but $500 for a copy of Microsoft Project is cheap compared to the alternatives. And yes, I've seen more than a few people balk at this so that's why I'm mentioning it.
  
• Copy, develop, and use templates for standard PM documentation. The good news here is that there are templates available free for just about any PM document you can think of. If you put "project management templates" into Google you will not have enough years of your life left to look at everything that comes back from that search. Hone the search in to what specific element you are looking for to narrow the choices. Once you have downloaded what you need, don't be shy about modifying templates to suit your needs - just be consistent going forward about using them on your projects.