What is a Model?

In the most general definition, a model is anything that is used to represent something else.

A fashion model lets you imagine how clothes might look on you. A plastic model may be a child’s first experience with how things are assembled from parts into the whole. In product development, models are widely used to help communicate options and inform decision making.

There are many different types of models: physical, symbolic, mathematical, logical and even mental. Each brings strengths and weaknesses, requires a different set of skills to create and apply, and carries different execution overhead. None are perfect, but all are useful in some way.

Models are intended as a substitute for reality. That’s where the power comes from – you can make things simpler, focus just on key aspects, or try things using models that would be impractical or inadvisable in the “real world.”

All Plans are Models

Any plan represents reality, and to the extent that representation is consistent with the nature of the real world, provides you with a correspondingly useful “test bed” on which to try out different strategies and predict outcomes.

We build the project plan prior to the project for exactly the same reason that a civil engineer will run a static and dynamic loads analysis on a bridge before it is built. It’s a lot smarter to predict and test scenarios to avoid basic mistakes than to correct them later.

Models Vary by Need

Project plans earn their value by streamlining effort and helping you avoid problems, but they also let you adjust your approach to fit a wide variety of situations and objectives.

Detailed product process planning and execution is the means by which extraordinarily high manufacturing efficiency is obtained. In that case, new ideas must follow a very formal channel or process to meet the production baseline.

On the other hand, in “one-off” manufacturing, such as product development, the plan may only be asked to define the boundaries of success or failure. You want fresh thinking, so details beyond those boundaries only work against you.

The entire spectrum from control to chaos will be useful in some context.  The secret to success is tailoring the plan to match the true needs at a point in time and then following those needs as they evolve.

A plan cannot be declared “right” or “wrong” without comparison to both the nature of the work itself and the desired decision-making outcome.

Mental Models

You don’t need a million-node FEA analysis to understand why a paper clip breaks if you keep bending it. Basic metal fatigue insight would be entirely sufficient. Likewise, predicting the outcome of dropping a bowling ball on an egg doesn’t require much math.

Randomized double-blind studies probably were not required to compare the outcome of jumping out of a plane with or without a parachute. Required or not, money was spent to do just such an analysis! 

Development planning is like that in some ways. It generally doesn’t make sense to spend time and money creating a detailed model of a choice that is already obvious.

Depending on your experience, you may not need anything but your mind to understand the situation and reach a sound decision. That doesn’t mean others will understand, or necessarily believe you, which is why so many formal plans are created out of self-defense rather than genuine need. Avoid this trap when you can.

The most efficient models are typically the ones we carry around in our minds, but there are two challenges with mental models:

• First, they are severely limited in scale. Unless you have rare intellect and even rarer freedom from interruptions they will leave many aspects uncovered.
• Second, mental models are very hard to validate and share consistently. Unless converted to culture, you’ll find mental models very difficult to scale.

When a problem comfortably fits your mental model though, no advantage is gained by further formalizing its nature.

What we really need is a way to take big problems and break them down into pieces that individual minds can effectively process. This is the secret of every successful development project.

The ability to take on practically unlimited challenges was perhaps most vividly demonstrated during the Apollo program. The Apollo moon landings would have been impossible without project plans, but the actual intellectual work took place in thousands of individual minds operating at a level below those plans (not in them).

The role of the project plan is not to replace our mental models, but to enable them. To do this, the project plan must logically break the overall effort down into coordinated packages of work that comfortably fit within individual minds. Before that point, assumptions introduce risk and inefficiency. Beyond that point, additional planning offers no further value, and can quickly slow progress.

Modeling Project Plans

In part one of this post we’ve built a case that models are general tools used to help us make decisions, that our mental models are very effective at helping us manage a portion of the effort but break down when we want to tackle large problems.

We’ve been very clear to point out that plans are only good or bad in comparison to the work you want to manage, and that fixed process cannot serve a range of needs efficiently.

In part two of this post we’ll introduce how to apply existing engineering insight as the basis to confidently “design” whatever plan you need.