Wednesday, April 20, 2011

Plan Based On What You Do Know, and On What You Don't!

When you sit down to start planning your next project or program, you lay out the tasks that will need to be undertaken and completed, the time expected to be required for each task, the resources that will be required for each of these tasks (and the availability of those resources), the sequences in which these tasks must be done, and the dependencies these tasks have on other tasks. From this, and other considerations, a timeline can be developed, milestones can be identified, deliverable dates can be estimated, and the anticipated outcome of the project or program as a whole can be projected.  The natural approach is to base the project/program planning effort on what you know will be required. However, if you base your project/program plan solely on what you know, you may well be headed for trouble at the outset. There are other considerations that you don’t fully know that you need to take into account, and it’s best to consider them from the outset. What you don’t know can hurt you!

So how can you plan based on what you don’t know? I suggest you break your planning effort down into four categories – known knowns, unknown knowns, known unknowns, and unknown unknowns. By thinking in these terms, you can more fully account for likely situations that will arise, and build such situations into your project/program plan. I will discuss each of these categories, and how to utilize them in your planning efforts.

Known Knowns: These are the things you know you need, and you know what they are. These are what you normally base your project plans on. You know these tasks must be done, you know about how much time is needed to complete each task, you know who needs to perform these tasks, you know the sequences in which they must be performed, and you know what tasks depend upon other tasks to be completed. Your last project/program required all of this information, and you are comfortable assuming that your next project/program will be carried out with similar knowledge and forethought. You feel comfortable saying to yourself (and others) that since I did this before and it worked, I feel comfortable assuming that similar planning considerations will lead to a successful project/program effort this time. Of course, we all know what happens when we “ass/u/me”; we make an “ass” of “u” and “me”. That’s why we want to move beyond the known knowns.

Unknown Knowns: These are things you don’t know you need, but when you learn that you need them, you know what they are. An example in a software project may be that you don’t know you will need a specific software module, but you know how to account for that module, including how long it will take to add it, who needs to be involved, when it needs to be done in the sequence of tasks, what other tasks will depend on it, and what other tasks it depends upon. You may kick yourself for forgetting to include this task, but when you realize that it is required, it is not a big thing to incorporate it into the overall plan, and to quickly recognize the impact to the deliverables, and to let everyone know what it means to the overall impact (benefits and costs). The key during the planning effort is to very carefully review the requirements (requirements are so important!  See Quality By Design!, Product Definition: Define What It Is and What It Isn’t!Does Everyone Really Understand?, and What Do Your Customers Really Want?), and identify, to as thorough a degree as possible, what is required and account for it in your project/program plan. It is often better to include too much in your initial plan and then drop tasks that won’t really be needed than it is to add tasks once the plan is in place, being followed, and being depended upon by others outside your organization (like sales for example to plan for revenues coming in from this project/program!).

Known Unknowns: These are the things you know you need, but don’t know specifically what they are. An example from the hardware world is that you know that your product must go out for agency certification (e.g. UL and FCC), and you know how long that typically takes and account for it in your plan, but you plan for success and don’t really know or account for the impact if your product fails. Another example is that you know that a certain feature is essential to your product/project, but in an area that is completely new to the company, so you have no experience to base an estimate of time, resources, or dependencies on. You plan based on your best estimate, but you know that estimate is really a crapshoot. The key during the planning effort is to have as much information as possible about the risks associated with each task, and to take these risks into account. One way may be to add some contingency into these tasks assuming that something but not everything will go wrong; this can give you dates with some, but not all risk accounted for. Another way may be to incorporate early finish and late finish intervals for tasks that are “known unknowns”; this may provide more accuracy, but can get very messy from a scheduling perspective. Risk assessment is a large topic area that deserves special treatment on its own.

Unknown Unknowns: These are the things you don’t know you need, and when you learn that you need them, don’t know what they are or their impact. It is very difficult, if not impossible, to account for “unknown unknowns” in your project planning efforts. Often the best you can do is to hold some brainstorming sessions with others to identify areas where things could go wrong, reasonable and unreasonable. Ask people to get creative in what could happen; this can actually be a lot of fun. At this point, don’t talk about solutions – only problems. Then, after defining all of the possible Armageddon scenarios, discuss what would be the likely impact for each of these catastrophes, and what could be done to address them and how. Next, try to order the list, in terms of the probability of such a catastrophe occurring, in terms of impact to the company should such a catastrophe arise, and other orders that make sense.  Finally, think about whether any of these potential catastrophes should be accounted for in the project planning efforts, and if so, how. Even if none of these are accounted for, you have at least done some thinking about what could happen and what the plan of attack would be in such an event. This could be worth its weight in gold later on, when time and market pressures may prevent clear thinking on how to address such problems.

Putting it all together: OK, what does all of this really mean to your planning efforts. Primarily it means to think beyond what you know. Don’t become complacent because this is the third time you’ve done such a project/program. Think outside the box to include things you don’t know – likely, possible, or absurd. By thinking about what you don’t know, you can do a much better job in putting together a project/program plan that has a much higher probability of being achieved. And this means better products, projects or programs delivered on time! So, to the best of your ability, plan based on what you do know, and on what you don't!

No comments:

Post a Comment

Comments are welcome and encouraged!