The material presented here is one of three postings on the fundamentals of Project Management. I know, reviewing fundamentals is about as much fun as watching paint dry but if you don’t have a good foundation you won’t have anything to build on. My advice is to use this material as a guide. Check in occasionally to be sure you have covered all the bases then move on to more interesting material.
As stated in the No Special Glasses Required post: Process is a systematic series of actions performed to achieve a goal, the key word being systematic. Taking a formal approach to project management requires process. Let’s take a look at some of the elements involved in the process.
Project Plan,
Let’s be clear, that list of tasks, dates, resources etc. is, at best, a schedule. Schedules lack key ingredients necessary for planning a project, two of them being the objectives, and a list of stakeholders. If you don’t have clear objectives then you don’t know where you are going. If you don’t know where you are going how will you know when you get there? Objectives should be stated in quantifiable terms, vague terms lead to disappointment. Good objective should be easily converted to a checklist. When everything has been checked off the project is done. A list of stakeholders is necessary to know who is driving the project and who will be making project related decisions. Know your audience.
Project Scope,
What’s in, what’s out, how big is the project? An initial scope is necessary even if the full extent of the project has not yet been defined. Often the scope will continue to be refined as the project progresses. Usually the project’s success will rest on the ability of the PM to manage the scope of the project. Without a clear understanding of what that scope is there is nothing to manage to and ultimately time and costs spiral out of control.
Communication Plan,
Who gets to know what, when, and under what circumstances? This is often not an issue for small projects but even if the project is small if it is a critical project, or a project of high visibility a formal communication plan may be necessary. A good communication plan ensures everyone is kept informed. It also ensures a consistent message to all parties and alleviates the interruptions for “a quick status” while respecting the chain of command.
Assumptions and Constraints,
Seldom does a project come without assumptions. If they are not evident at the start of the project they will crop up when the estimating process begins. It is often necessary to reexamine the assumptions as a project progresses to ensure they are still valid. This can be difficult if there is no record of the assumptions. Know and understand the assumptions then document them and periodically review them.
Risk Management process,
“Risk is like fire: If controlled it will help you; if uncontrolled it will rise up and destroy you” – Theodore Roosevelt. A risk is an issue that has not yet happened. It is not enough to identify the risks, the risks must be managed. Managing risks means making a determination on the likelihood of the risk becoming an issue, being able to identify the issue at the earliest possible moment, and having an escalation plan. Risk Management will be covered in the Risky Business post coming in a few weeks so, stay tuned.
Issues process,
Project Managers are paid to manage. That means you need to manage issues not just report them. When a risk becomes an issue someone must take ownership, the issue must be tracked, and there should be an action plan along with regular review dates. Managing Issues also means tracking the progress toward resolution, or lack thereof and taking action. Many projects fail due to the inability to resolve the issues. When the issue has been resolved the resolution should be documented and the issue closed. I don’t have a crystal ball either so there are often issues that were never identified as risks. The PM owns the issue until a rightful owner has been identified. It is therefore up to the PM to manage that issue in the interim. Remember, it is not up the PM to resolve the issues, the PM’s responsibility is to find an owner and track the issues.
Decision Log,
Marcel Proust said: “All our final decisions are made in a state of mind that is not going to last.” Hence, the need to document the decision and the basis for that decision. Not all decisions are made immediately, often a decision is needed by someone other than the person who requires the answer. For this reason it is important to track the question while an owner is being determined and to periodically review the status of all open decisions. A Decision Log will help the PM to organize both open and closed decisions and may even save his/her reputation should a decision be questioned later on.
Change Control process,
I once attended a User Acceptance meeting where several of the stakeholders balked at accepting the software. They did not like the layout of the screens and they felt they did not receive everything they were promised. The PM reminded everyone of specific meetings in which trade-offs were made and then explained why the system was not as they expected. Fortunately, some of the stakeholders backed up the PM and in the end everyone accepted the system. Thanks to a good memory and some Stakeholders help the PM pulled this out of the fire . . . this time. The PM may not be so lucky next time. A Change Log alone will not save the day but a formal Change Control process will go a long way toward a successful acceptance in the future.
Larger projects will require additional process and smaller projects will require fewer processes or a “lite” version of these processes but all well managed projects require some formal processes. In future weeks I will explore these topics is greater detail. For now these cover the basics. Stay tuned and let me know your thoughts.
To your success
Steve
Copyright 2009, all rights reserved, S. Randall Westcott
