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.
In addition to rapidly creating a project plans -- simulations are also used for these three purposes:
Simulations should be run after the addition of an initial set of 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. Build out a high levle model, an dont wait for a fully detailed model before a first simulation.
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.
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.
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 a model, a forecast is generated through simulation. The project plan is an output, including Gantt chart, utilization, and other estimates. By repeatedly 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 can become difficult and less effective.
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.
We can think of the project model as a prototype. Once we get the project model "running", the early benefit is to gain quick feedback and insight, rapidly and agily responding by imrpoving the model and the design of the project. Early prototypes that fail are not bad -- they are helpful, especially when we gain insights about counter intuitive effects.
As the project model is developed the modeling team should note insights -- aspects of the project design that work and those that surprisingly do not -- in the modeling and 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 out.
Reports can be created at any time and provide a high level of detail that can be used for further analysis.
The simulator can be set to imitate a traditional; 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 team wants to make sure that the TeamPort model reflects the other project.
To mimic the assumptions from CPM in algorithms in common project scheduling tools: On the simulator settings pane select Critical Path Method (CPM)