Problem solving processes

Koberg & Bagnall, the authors of “The Universal Traveler”, propose a methodical problem solving process.  Their process closely resembles the systems approach to problem-solving, an example of which I’ll include below for comparison.

K&B’s process has seven stages:

1. Accept – accept the challenge of solving the problem (this is unique to K&B I think)
2. Analyse – familiarise yourself with the problem; understand its ins and outs
3. Define – determine the main issues; conceptualise and clarify the aims and goals
4. Ideate – generate possible solutions to the problem
5. Select – compare the alternative solutions and select the best one
6. Implement – take action to implement the solution
7. Evaluate – measure success; check how well the problem has been solved.  In addition, reflect on the experience and learn what you can from it for future applications.

To compare, here’s a typical approach for a ‘hard’ systems engineering approach, taken from Zust and Troxler’s “No More Muddling Through”:

1. Situation analysis – similar to the ‘Analyse’ section of K&B
2. Goal definition – define the parameters of what we want to achieve
3. Concept synthesis – development of alternative solutions.  Same as K&B’s ‘Ideate’
4. Concept analysis – analysis and evaluation of the generated alternative solutions.  Same as the first part of ‘Select’ in K&B
5. Evaluation – comparison of the alternatives (when none appear to be the obvious best choice)
6. Decision – selection of the solution

The most obvious difference is that K&B’s covers more ground: it treats acceptance of the problem as part of the process.  At the other end, it adds two stages: Implement, and Evaluate.

Come to think of it, if you only select a solution and not yet implemented it, you have not yet begun to resolve the problem.  It’s therefore hard to think of Zust and Troxler’s ‘Problem-Solving Cycle’ as a complete problem solving process (it’s still an excellent book and one of my favourites for systems engineering).

 

del.icio.us Tags: Problem Solving Process,The Universal Traveler,Systems Engineering

Creativity is not normal

I am currently absorbing a book called “The Universal Traveler”, a book on creativity and problem solving using a (soft) systems approach.

The authors suggest that by definition, creativity is innovation, which is about coming up with something new.  Something new is something not normal but different.

“If you accept the fact that the goal of creativity is innovation, you should realize that creating something “new” is NOT NORMAL but DIFFERENT from normal, perhaps even ‘abnormal.”

Think about it. If people are immediately accepting of your ideas or your behaviour, then perhaps your ideas are not really that unique.

“If you believe you are behaving creatively and your behavior is readily accepted in normal society, one of two conditions is probable: either you have conditioned society to accept your abnormal actions or your input is really not as unique as it seems.”

You may come up with innovative ways of attacking a problem.  But is it really innovative, or is it just an idea already applied elsewhere (perhaps even by yourself).

Underwater weddings, wedding on rollercoasters, getting married while parachuting are all variations on a unique idea.  Whoever first thought of getting married differently from the norm gets the credit for creativity.  The rest are just extensions of the same basic idea; they are not innovations.

What is the point of creativity though?  Creativity for its own sake may be important for art, but where else?  For businesses certainly, it becomes important as a differentiator: new products and services. 

The iPhone is innovative. All the other look-alike smartphones are variations.  As we can see, innovation by itself does not guarantee commercial success.  While the iPhone may be the leading smartphone, the Samsungs and others are enjoying tremendous profits as well.

But to me the most important application of creativity is for meeting the challenges of new problems.

New problems, by definition, do not have a history of solutions that have been successfully applied against them (that would mean they are old problems, not new).   New problems require new solutions, something that have not been tried before.

And that is where creativity comes in: in the generation of new ideas.

Using PERT in MS Project 2010, Part 1

I want to investigate and write about how to use PERT effectively in MS Project.  But first I’ll do a review of the basics of PERT.

PERT was first developed within the United States Navy’s Polaris submarine program as a tool to help manage that very large, very complex, and unprecedented undertaking. 

The term stands for Program Evaluation Review Technique.  The focus of this management tool is on evaluating and forecasting the likely duration of a project.

Its distinguishing characteristic is recognising that project tasks are not deterministic: you cannot say with absolute confidence that task A will finish in 3 days, task B will finish in 5 days and so on. 

The reality is that task A might finish in 2 days if everything goes well, might finish in 3-4 days in most circumstances, but can potentially take 8 days if some problems arise.  So any project schedule crafted on the basis that A will take 3 days and B will take 5 days is simplistic, and is not based on reality.

To properly use PERT, you need to provide 3 duration estimates for each task in your network of activities:

1. The optimistic duration (T_Optimistic)
2. The most likely duration (T_{Most Likely})
3. The pessimistic duration (T_Pessimistic)

The optimistic duration is our estimate of how long a task will take if everything goes well.  If we have previous experience of finishing a similar task where everything went according to plan, we can use that historical basis for our estimate.

The most likely duration is our estimate of how long the task normally takes, given the normal disruptions of normal execution.

The pessimistic duration is our estimate of how long the task will take to complete if things just are not working out.  We can also use historical data if available. We’ll need to put an upper bound on this estimate because clearly there is no limit to the kinds of things that can go wrong, and we cannot include all of them in the estimate.  If the task was painting the exterior of a house, we might consider such things as the impact of rain suspending the work, or of one worker calling in sick, or even running out of paint and the accompanying delays of buying more paint. 

Once we have gathered the 3 durations, we use the following formula to come up with the most likely duration of the task:

T_Likely = (T_Optimistic + (4 * T_{Most Likely}) + T_Pessimistic) / 6

Example:

TOptimistic	20 days
TMost Likely	25 days
TPessimistic	35 days

Then

T_Likely = (20 + (4 * 25) + 35) / 6 = 25.83 days

And we will use 25.83 days as our estimate for this task. 

We perform the above procedure for each task in the project network,  computing the T_Likely duration for each.