In the TeamPort Platform, Forecasts are generated by a simulator based on a project model. A simulator takes into account various settings to allow exploration of different methods and real world project dynamics on the projects likely outcomes. See Set up a Simulation for instructions on operating simulator controls.

Running A Simulation

1. From the Tools menu, click Run Simulator.
2. In the Simulator box that appears, enter a description of the simulation run.
3. Choose the settings you wish to configure the simulator.
4. Click Start.

Note: Setting the project start date in the Project Detail Pane will ensure that the Forecast begins on the desired date.  If location or team calendars include exceptions for vacations and holidays the correct project start date can impact the forecast project duration.

Strategies for Simulation

This article discusses strategies for running simulations. It answers questions such as:

• What is a simulation run and how many should I set?
• Why should I exclude trends?
• How do I stop a simulation from running for too long when I know the problem is with the project model?
• What are the other settings for and when should I change them?

This article does not cover interpreting Forecast results. Other articles in this commentary section break down and cover this topic.

Prerequisites

To successfully create a forecast the project model must be complete. A complete model can be compact but must an minimum include:

1. One or more locations
2. One or more teams, each team must have at least one member
3. One or more products
4. One or more activities associated with at least one product
5. All activities must have a contract with a team. Activities in contract with teams must have at least one hour of effort required

Optional:

• Dependencies
• Phases
• Meetings, travel time, travel cost
• Calendar settings for locations and teams

Reasons for Simulating

Forecasts are typically used for three purposes:

1. Health check a model to ensure that it is complete
2. Evaluate the decisions modeled in Designer
3. Compare the project model to project plans created in other systems

Health Check: GPD recommends running simulations as the project model is being built

Simulations should be run after the addition of 30-50 activities or at logical times during stages of model building. These simulations ensure that the model is complete as it is being built and saves time correcting the model when Forecasts are needed.

Simulation requires that all activities have contracts (For the activity, at least one primary role (P), at lesat one decision role (D), and 1 or more Quality (Q) roles.)

Modeling can include the full build-out of the PBS and OBS first or these structures can be built up as the activities are created. However, the WBS cannot be built ahead of the OBS or activities will have no contracts.

In general models should be build in layers of detail: create the basic model elements, link them appropriately, then adjust details as needed to refine the model. This modeling approach will ensure that the model is complete and that as details are added the model still simulates.

Evaluation

Design is an iterative process: synthesize, render, and evaluate. The modeling process in TeamPort Designer allows users to easily synthesize and render a project model. To evaluate the model a forecast must be created through simulation. Byrepeatedly creating forecasts and understanding their results, a group modeling a project can effectively understand the implications of changes and make better decisions. Without this understanding from early stage modeling later stage decisions are harder to understand.

Early simulations can be far off target. The purpose of running the early simulations is two-fold: to make sure the model is complete, and to create the start point for a design vector that will converge on an achievable project with desired results. Familiarity with the early simulations will give a context for evaluating later forecasts and give a "feel" for the model. Understanding where the model is sensitive to change will provide insight to make adjustments to achieve desired results while balancing scope, duration, effort, risk, and cost.

As the project model is developed the modeling team should note key points in the modeling process and run simulations. Being able to refer back to these key points can be valuable to understand what worked well on part of the model or to efficiently return to an earlier version of the model when a design path is not working.

Reports can be created at any time and provide a high level of detail that can be used for further analysis.

Comparison to Projects in Other Systems

The simulator can be set to imitate a project scheduler.  These comparisons can be valuable when a part of a larger project has already been created in a project scheduling tool and the modeling team wants to make sure that the TeamPort model reflects the other project.

To mimic the scheduling algorithm in common project scheduling tools:

 On the simulator settings pane select Critical Path Method (CPM)