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.

Systems Engineering–Coping with Complexity

A readable introduction to Systems Engineering. 

 

Listed below are some of the books referenced by the above work.  This list is not necessarily complete (Sometimes, I list only those that interest me).  When there is a newer edition of a book than the one originally referenced, the link is to the newer version.  Items marked with a , are works I can recommend.

Title	Author	Remarks
Winning at New Products	Robert G Cooper	Amazon
Metrics and Case Studies for Evaluating Engineering Designs	William L. Chapman, F. David Van Voorhees, A. Terry Bahill, Jay Alan Moody	Amazon
The Anatomy of Major Projects	Peter Morris	Amazon
Systems Thinking, Systems Practice	Peter Checkland	Amazon
Turn Signals are the Facial Expressions of Automobiles	Donald Norman	Amazon
21sr Century Jet – The Making of the Boeing 777	Karl Sabbagh	Amazon
The Sources of Innovation	Eric Von Hippel	Amazon
Object-Oriented Software Engineering: A Use Case Driven Approach	Ivar Jacobson	Amazon
Principles of Software Engineering Management	Tom Gilb	Amazon
UML Distilled: Applying the Standard Object Modeling Language	Martin Fowler, Kendall Scott	Amazon
Real Time Structured Methods	Keith Edwards	Amazon
Object-Oriented Modeling and Design	James Rumbaugh	Amazon
Notes on the Synthesis of Form	Christopher Alexander	Amazon
The Rise and Fall of Strategic Planning	Henry Mintzberg	Amazon
Normal Accidents: Living with High Risk Technologies	Charles Perrow	Amazon
MANPRINT – An Approach to System Integration	Booher	Amazon
Value Analysis and Value Engineering	Frederick Oughton	Amazon
Invention by Design: How Engineers Get From Thought to Thing	Henry Petroski	Amazon
The House of Quality	J. Hauser, D. Clausing	Amazon
To Engineer is Human	Henry Petroski	Amazon
Product Development Performance	Clark	Amazon
Design Methods	Christopher-Jones	Amazon
Software Inspection	Tom Gilb, Dorothy Graham	Amazon
The New Rational Manager	Kepner	Amazon
Against the Gods: The Remarkable Story of Risk	Peter Bernstein	Amazon
The Sciences of the Artificial	Herbert Simon	Amazon
Managerial Economics	Evan Douglas	Amazon
Mastering the Dynamics of Innovation	James Utterback	Amazon
The Product Manager’s Handbook	Linda Gorchels	Amazon
Intellectual Capital	Thomas Stewart	Amazon
New Products: The Key Factors in Success	Elko Kleinschmidt	Amazon
Systems Engineering Guidebook: A Process for Developing Systems and Products	James N. Martin	Amazon
A Quantitative Approach to Software Management	Kevin Pulford	Amazon
Skunk Works	Ben Rich	Amazon
The New Organizational Wealth	Svieby	Amazon
Peopleware: Productive Projects and Teams	Tom DeMarco, Tim Lister	Amazon
A Methodology for Systems Engineering	A. D. Hall	Amazon This is a classic.
The Fifth Discipline: The Art and Practice of the Learning Organization	Peter Senge	Amazon
Guns, Gems and Steel: The Fate of Human Society	Jared Diamond	Amazon
The Blind Watchmaker	Richard Dawkins	Amazon