21 December 2009

Factors Assessment: Analysis and problem-solving

Factor: an event, fact, prediction or uncertainty that can help or hinder realizing the objective.

Analysis: a process to evaluate and organise incomplete data to support decision making with a clear understanding of the implications of the data.

Once we've established a crystal-clear objective, we still aren't ready to start making lists of things to do. First, we need a clear understanding of what we're up against and what we're going to do about it.

Factors assessment is a methodical approach to identifying and dealing with all the factors that might affect the success of the plan. This is the analysis, synthesis, and problem-solving part of planning—the fun part. It's also the part that keeps our project from being blind-sided.

In general, we need to collect the relevant factors and, for each factor, answer three questions:
  1. What is it?
  2. Why is it relevant?
  3. What are we going to do about it?
Some factors will come from the scope and target environment, others from information gathering. Depending on the circumstances, we'll be collecting information from a variety of sources, which could include:
  • industry data, 
  • market data,
  • customer input,
  • internal databases,
  • stakeholder interviews, and
  • workshops.
Yet other factors may come from the assessment process itself, when the response to one factor creates a new factor to deal with.

Some factors will be identified as opportunities to be exploited, others as obstacles to be neutralized, still others as uncertainties creating risks to be mitigated.

Factors Identification

The first step is to find the factors. There are lots of ways to do this. Depending on what we are trying to accomplish and the culture of the organization, this could be a lone analyst on a due-diligence trek or all the stakeholders in a free-for-all brainstorming session, or both, or something in between—whatever works.

The important thing is to identify all of the relevant factors. At this stage it's usually good not to be too picky; including irrelevant factors is preferrable to missing relevant ones.


The next step is where things get interesting. This is where we consider each factor, decide whether it's relevant and, if so, decide what to do about it.

There are lots of ways to approach this but I found one that works well in isolation or in a workshop. One factor at a time, we write the factor down and ask, "So what?". We write the answer down and ask again, "So what?" We keep this up until it's a meaningless question and we have the factor covered. One or more of the so-whats will become action items in the plan. If a "so-what" uncovers what are effectively new factors, we add them to the list of factors and continue on.

For example, in an IT application platform migration:

Factor #14: According to our SLA, we have to provide 24x7 service.

So What? There can be no downtime during the switch between the current system and the new. History tells us that this is rarely acomplished.

So What? (a)Identify this as a risk factor in the plan. (b)This calls for "make before break"; We'll need to keep the old platform running while we're testing the new one and there must be a transition period when both platforms are viable.

So What? There are two options:
  1. Split the system to free resources for the new platform while keeping the current running at a reduced service level, or
  2. Lease additional resources for the migration, move the current platform to the leased system and develop the new platform on the permanent system.
So What? We need to evaluate the costs and risks of the two options. This is promoted to Factor #54 and added to the Inception task list.

If the situation calls for a somewhat more formal approach, we can build a four-column table where the columns are "Factor#", "Description", "Relevance", and "Response". This makes for a more structured presentation, but the work is the same. A spreadsheet table of this sort could be useful by extending it with columns for things like cost and risk and references to project tasks and tests for traceability. 

There are a number of frameworks devised to help identify all the relevant factors. It doesn't hurt to be familiar with them. The first that comes to mind is the Zachman Framework. There is also a less formal (and more entertaining) framework described in Dan Roam's "The Back of the Napkin." 

Some factors will pose difficult problems that aren't easily disposed of. Combinations of factors may need to be considered. In such a case we'll need to apply more potent analytic and problem solving techniques (e.g. Morphological Analysis, Probability Management). This is particularly likely if there is any uncertainty in the factors that translates into uncertainty in the outcome, and the answer to "so what?" is "we need a model." This will almost certainly crop up in a non-trivial project.

This is an important milestone in the planning effort. At this point, we'll organize the results for readability and send them out to our stakeholders for some feedback. When our stakeholders are satisfied that we have the right factors enumerated and managed, we can move on to develop a Strategy.

No comments:

Post a Comment