A well-executed and thoughtful analysis of the problem at hand, provided by a knowledgeable set of professionals can be extremely useful to your project. Time spent now analyzing the parts of problem and devising a methodology for solving them will be handsomely repaid later in reduced re-work, altered and slipped schedules, and feature creep. All of those bad things mean one thing: money. Avoid or mitigate them and you'll save money.

How do we do that analysis?

The first step in the this phase should be the decomposition of the problem into sub-problems. You might use a tool like an outliner or Visio to begin to sort the sub-problems or build a hierarchy of items. A visual representation of the sub-problems and how the problems relate to others up the chain can be useful. After a number of these exercises, your company may have a set of analysis procedures which standardize this process. If not, it should; don't reinvent the wheel each time.

How do you know when you've broken the problem down far enough? To decompose a problem into useful sub-problems, someone familiar with the domain of the problem should be engaged.

Suppose my website needs a shopping cart for on-line retail sales. Someone knowledgeable in the field of e-commerce would know that email delivery of order confirmations and shipment status is a de facto requirement in this space. Knowing that, we'd add "email delivery" or perhaps, more broadly "customer communication" as a sub-problem. We'd then engage someone who is knowledgeable in the delivery of mail at our expected volume.

This is a vastly simplified example, but the customer may not have the depth of knowledge to even articulate that portion of the problem beyond "yeah, we need to send receipts to our customers". At this point, if the subproblem lives in one domain and can be solved as a unit, we've probably reached the bottom of this sub-problem and need no further decomposition. This is a somewhat tough thing to teach and comes from the experience in the domain.

As we document sub-problems, it is important to keep focus and to relate every sub-problem back to the main problem at hand. In our shopping cart example, it might be interesting or even technically sexy to explore delivery of customer communications via alternative methods such as SMS, for example. However, someone knowledgeable in industry standards and best practices for the problem domain can tell you this is not a common practice or expectation and is really only peripherally related to the problem at hand: processing the sales of widgets on your website.

Here you may encounter the familiar tension between "engineering" and the business or marketing groups pushing for new gee-whiz features, when the design costs for them may be prohibitively expensive and any real-world utility suspect.

The last pass over the sub-problems should be used to arrive at a rough timetable and sequence for attacking each subproblem. The sum of the time to complete the sub-problems, acknowledging that some may be done in parallel, while others have a serial nature, may be weighed against the deadlines or time-to-market (ah, there's a buzzword) goal.

What are we trying to get out of the exercise?

Remember also, at this point, we're only documenting the problems, not solving them or writing project plans to implement possible solutions.

At the end of this work, you should have the following:

• A coherent statement of the problem
• Forecast of metrics, applicable dates, and financial bounds for solving the problem
• A set of sub-problems, categorized in a useful way
• A set of sub-problems in manageable, solvable chunks
• Techniques that may be applied to solving each sub-problem
• Identification of personnel (or gaps in knowledge) in your organization who can solve each sub-problem
• A timeline and level-of-effort for solving the problem
• A plan for reporting on the progress of solving each sub-problem

Next time, we'll review the sub-problems in the Transformation phase, to help us make use of past solutions and patterns from similar problems, so that we can arrive at cost-effective and standard solutions.

Hit me with some comments, if you've got techniques or suggestions for boiling problems down in their basic components.

Past articles in this series:

1. What Is It We're Doing Here? - Applying Engineering Principles To System Administration
2. Who Is It? - Defining Who Might Benefit

Technorati Tags: system administration

Tags: on technorati, delicious, netscape, google