I'm surprised at how complicated the subject of project planning has become. I have served on the board of directors of a couple of non-profit organizations, and as the CIO of a small publicly traded company.
It’s surprising to me, though, how many organizations either can’t or don’t think in those terms. Project management is seen as either too complex, or out of reach for some organizations.
From my experience, simplicity is a key factor in planning and communicating projects.
I believe anyone would agree that in terms of process maturity just beginning the act of planning, and thinking in terms of some things must be done before others, takes a project from being ad-hoc to almost achievable.So, for me, I boil project management down to few very simple things:
- Before you do ANYTHING else, decide where you want to go, and clarify the goal with all of the project stakeholders. As the cliché states, “when you don’t know where you’re going, any road will get you there” is true in both life and managing projects.
- Once you’ve identified the goal in terms of where you want to go, start listing out the what’s about what the goal looks like when you’re finished. I break requirements gathering in to very simple to understand pieces of information, I also don’t use the term “requirements” I use something more approachable like a “Needs List.” Each need (requirement) have 5 attributes:
a. For each requirement use some type of unique identifier, I use numbered lists, but they could be anything simple and unique.
b. Describe the need (requirement) in 4th grade English. It’s easy to have an academic understand the requirement. But when you can describe the need so that your 4th grade daughter or son can understand it, then chances are YOU understand the requirement. Don’t be overly legalistic here, if the need appears to be too ambiguous then you should strive for further decomposition of the need in to more chunks until you have a good simple explanation of a single requirement in a sentence or two.
c. Describe what the need looks like if it’s successfully filled, oddly enough, it’s the success criteria for the need being completed. Again, I don’t make it more complicated than it needs to be. The law of parsimony definitely applies here.
d. Then describe in as simple of terms as possible how to check to see if the success criteria has been met. This then becomes the basic test of completing the requirement.
e. Finally, any additional comments.
So, a good requirement (IMHO) might look something like:
- Need #1
- Description: All information must usable on multiple computers.
- Success Criteria: Information can be transported to different computer and used by the same application.
- How to check the success criteria: With the same application on two different computers; use the information from a portable drive on a different computer than the computer that first saved the information.
- Comments: The removable drive does not need to be a USB thumb drive, it can be any number of removable storage devices, as long as it is reasonably portable.
- Once I’ve created a needs list, then I create a list of risks that might derail the project; again, simple is better. Risk management and mitigation can get complicated quickly, but just getting people to think about risk to a project is a big step to a successful project. A simple risk list relates to back to the project’s goals and needs. So a simple risk list has 5 attributes:
a. The risk list starts with, again, a unique identification of the risk itself. Like the needs list I use a numbered lists.
b. No risk is arbitrary, and every risk should relate either to a clarifying component of the project goal, or one of its needs. So, identify the relationship here as a reference to the number of the need item, or if I have a numbered list for a clarifying component of the goal, I list it here.
c. I then describe the risk in a simple sentence or two, in simple English.
d. Then I rate the impact on the project as either high, medium, or low.
e. Finally, describe in a single sentence or two in simple English the current plan to mitigate the risk.
A good risk item (IMHO) might look something like:
- Risk #1
- Relating to: Need #1
- Description: Drives used for in the application may fail during transportation between workstations.
- Impact to project: High
- Current Mitigation: Insure that storage devices used for the application are hardened to withstand severe environments with a failure time of no less than 50,000 hours of use.
- Finally, using the information from one two and three above, put together a simple schedule of high level milestones for the project, simpler, here, is always better. I typically start out with no more than between 6 and 10 milestones, depending on the project, and refine the schedule from there.
From these four basic elements, in very simple terms, look what has been accomplished:
- A project goal statement has been created
- Objectives in the form of clarifying statements to the goal have been defined
- A list of requirements has been created
- A remedial test plan has been created through the use of success criterion and criterion checks
- A simple risk management plan has been created through identifying and quantifying the risks
- A risk mitigation plan has been created through mitigation identification.
The project management purists would criticize the simplistic approach to project planning I’ve listed here, but keep in mind that not all projects need a PMP, and complicated earned value analysis.
“It's not the plan that is important, it's the planning.” -Dr Graeme Edwards