Two categories of models

In this post I find it useful to make a distinction between two categories of models: scientific models and design models.

Scientific models

Scientists create models to describe their understanding of phenomena that they are studying. They test their model by using it to make predictions and then seeing how accurately the model predicts observed behavior. For example, a group of scientists studying glaciers in Greenland might make a model that uses precipitation, sunlight and average temperatures to calculate a predicted melt-off. They will then compare the observed melt-off with what the model predicted.

If the model does not predict the observed data very well, they analyze the discrepancy to determine what assumptions made by the model are incorrect. They update the model and hope that it will predict next year’s data more accurately. The first iteration of the model may not be very accurate, but over the years, they improve the model to make better predictions. For example, weather predictions are based on scientific models that weren’t very accurate half a century ago, but, after many iterations of refinement (and increasingly powerful computers) are generally quite accurate now.

Once a scientific model starts making accurate predictions it becomes useful to other people. Policy makers can use the glacial melt-off model to suggest climate change mitigation measures. People can and do rely on weather forecasts now that the models that generate them have become increasingly accurate.

Design models

People who are designing new things often make models of a proposed design. They can then analyze the model to determine how well the design will perform. If the model shows that the design doesn’t perform well, they revise the model and analyze it again. They save a lot of time and effort by not building anything until the model shows that the design is good.

Design models abound:

• Structural engineers make a model to analyze the strength of a design for a new bridge. If the model shows that the bridge won’t be strong enough, they modify the design before building the bridge.
• Architects create a virtual reality model of a building to show to a client. If the client doesn’t like the look of the building, they revise the design to satisfy the client before constructing the building.
• Electrical engineers use CAD systems to model the design and performance of a new computer chip. These things are so complex they could not be designed without using models.
• Program managers can use schedules to design the best way to run a proposed development project.

Schedules are Models of Projects

To reiterate: project managers can use schedules to model the best way to develop a product. The schedule lists all of the tasks to be done, what skills are needed to perform each task, the order in which tasks must be done, which tasks can’t be started until other tasks are completed, which tasks can be done in parallel and an estimate of how long each task will take. It specifies the resources needed for development: purchased components, test equipment, people with specific skills.

Project managers can then take all of this information and come up with a development plan optimized to meet the objectives of the company – typically some compromise between the fastest time to market, the lowest development cost and the most reliable product.

A well thought out schedule…

A well thought out schedule is a very useful model for planning a project. Managers can use it to guide decisions, including:

• How many people with what skills do we need to assign to this project?
• Can we shorten the delivery time by assigning more people to work on concurrent tasks?
• Are there less important tasks that could be postponed to a future project?
• What tasks create scheduling bottlenecks?
• What tasks need to be completed before we can test a component?
• What tasks need to be completed before we can integrate components?
• What is the best way to break down the design into tasks and components?
• Is it better to purchase off-the-shelf components or develop them ourselves?
• What people and resources can we add to complete the project sooner?
• What tasks do we need to include to reduce the risk that the project will fail?
• If we remove people and resources from the project, how much longer will it take?

A well thought out schedule, like other models, can save a lot of time and effort. Like other models it is a tool that allows us to analyze and improve a design (in this case the design of the development project) BEFORE it is executed.

The benefits of putting together a carefully thought-out schedule are enormous, but in my entire career, I have only worked on ONE project where this was done adequately!

A poorly thought out schedule…

A poorly thought-out schedule will create many problems during execution of the project. See Why is my Project Late – Schedule Issues for a discussion.

Schedules evolve

A model, to be useful, needs to be updated as new conditions arise. Given the long development times being modeled, it is certain that a schedule will need to be updated several times. Schedules may need to be modified during the development program for the following reasons:

• More people have been added to the project
• People have left the project
• Tasks have been added or removed from the project
• Unanticipated dependencies have been discovered
• Time estimates need to be revisited based on experience.

Schedules model human behavior

Unlike the other examples of design models which model physical things – bridges, computer chips, buildings – schedules model how a team of people will work together to develop a product. This is human behavior. Human behavior is complex and therefore difficult to model accurately.

Time estimates model human behavior

To be more specific, it is the time estimates within the schedules that are modeling human behavior. The time it will actually take a person to finish a task depends on so many factors!

• Skill and experience of the person doing the work
• Mental alertness and motivation of the person doing the work
• Availability (or lack) of resources
• Quality of development tools
• Support (or lack of support) from managers and other people on the team
• Work environment that is conducive to (or detrimental to) productivity
• Earlier dependent tasks having (or not having) been completed and validated

Because of all these factors, there will be significant variation between how long we estimate that a task will take and how long it will actually take. If we have made estimates with a certain amount of care and objectivity, we can hope that the under-estimates and the over-estimates balance out and our overall schedule models how long a project will take with sufficient accuracy to make plans.

Using a scientific model to estimate task times

Given all this, it would appear that the time estimates in schedules could be produced by a scientific model. The time it actually takes to finish a task is a phenomenon that depends on many factors, including the ones listed above. An organization that wanted to predict actual task completion time more accurately could develop a scientific model that takes into account all of the above factors to make a prediction. As this model is iteratively improved over several projects, it would gradually produce more accurate time estimates.

However, most organizations don’t create a scientific model to produce the time estimates in their schedules. It is a lot of work to create, evaluate and iterate a formal scientific model of such a complex phenomenon. It is much easier to rely on the ad hoc informal models used, usually unconsciously, by experienced people to come up with time estimates. The benefit of having somewhat more accurate time estimates in your schedule may not justify the effort required to support a more formal scientific model.

There is also another difficulty with improving time estimates. The people assigned to do the tasks know what the model says about how they are expected to behave; that is, how much time they are expected to take to complete the task. This knowledge changes their behavior in ways that compromise the accuracy of the schedule. See post on Parkinson’s Law for Schedules.

Managing time estimate uncertainty

Using time estimates as a contract

Program managers are tempted to look at the time estimates in a schedule as a contract: The person assigned the task has agreed to complete it by the estimated time. But when we consider that the time estimates in the schedule are the imperfect product of either an ad hoc or formal scientific model, we realize that this contract is actually an attempt to force reality to conform to a model. This betrays a fundamental misunderstanding of scientific models: If reality doesn’t conform to the model, it is the model and not reality that must be changed. If a task takes longer than expected, it is the schedule that must be changed.

A better approach

Focus on mitigating the factors (listed above) that cause variability in execution time. This of course is more work than simply ordering people to finish their assigned task in the time allocated by the schedule, berating them when they take longer than scheduled and wondering why tasks never get completed early! See post on Parkinson’s Law for Schedules. But it will be far more effective.

Make your schedule useful!

When you are planning a project, view the schedule as a model that you can use to determine the best way to proceed. Focus on identifying all of the tasks, figuring out the order in which they must be done, determining which groups of tasks can be done in parallel, defining what resources you will need and figuring out what to test and when.

When you are designing a product, work closely with the system architect. A well-architected design will have subsystems with simple interfaces which will allow for more parallel development and much easier unit and integration testing. This in turn will lead to a schedule with more concurrent tasks, less risk, faster integration and a shorter overall development time. See the post Product Development Lessons from a Model Car Kit.

When you are developing the product, recognize the inherent limitations of the time estimates in your schedule. Don’t obsess over getting people to match the time estimates. Work to minimize the factors that cause people to take more time than scheduled to complete a task.

Used properly, a schedule will greatly improve your chances of a successful project.