Frequently Asked Questions

There is no fixed definition of the baseline case, and clients might prefer to add more or less detail to this case for their initial model validation. However, when building the Baseline case, you should balance how long the case takes to build with how many critical project elements are represented. As a minimum, the Baseline case should include:

1. A single project, with placeholders for other projects. You can give a placeholder project a single task that lasts the entire duration of the project so that the simulation results reflect the correct duration. Link the projects appropriately with Project Successor links, using lags if appropriate.
2. All tasks and milestones in the fully modeled project, connected appropriately with Successor links.
3. All positions in the fully modeled project with their names, roles, FTE values, and Application Experience level requirements.
4. All positions linked with assignment links to their tasks. Use only primary assignment links in the Baseline case.
5. Task work volumes.
6. Rework and communications links.
7. Optionally, you can add task skill requirements and position skills. However, if these are matched, the simulation results will be the same as if you leave all required task skills and positions skills set to Generic Medium.

When you simulate the initial Baseline case, the CPM and simulated end dates should match or be only a very few days apart.

You should complete the Baseline case of the program before creating a second case that has the probabilities set. To do this, add the following to the project that you fleshed out for the initial Baseline case:

1. Meetings linked to the appropriate participants, and with properties such as duration, start time, and start lag.
2. Project connector pairs linked with Successor, Rework, or Communications links.
3. Organizations, linked if appropriate to projects.
4. Departments and persons in the organizations.
5. As in the initial Baseline case, you can optionally add task skill requirements and position skills. However, if these are matched, the simulation results will be the same as if you leave all required task skills and positions skills set to Generic Medium.
6. Optionally, you can also staff positions with persons. However, if you know your organization has the required resources with the right skills, staffing is a time-consuming and unnecessary step. Another alternative is to leave positions unstaffed unless you find it necessary to reallocate underused resources to help out on at-risk tasks. At that point, you can staff positions, add skills and skill levels, and then use Secondary Assignment links to spread the at-risk work across positions with the required skills.

When you simulate the refined Baseline case, the CPM and simulated end dates should still closely match, although the simulated end date usually moves out a bit to reflect added coordination work for positions, such as meeting attendance.

Planned milestone dates are a valuable visual aid when you simulate a program. They allow you to model the dates the customer would like their milestones to occur. When you simulate, the program and project Gantt charts display planned milestone dates as green diamonds. You can compare these green diamonds with the grey and black diamonds of the CPM and simulated dates and see at a glance how far off the customer’s targets the schedule is.

Don’t confuse the program’s Start Date with the planned date for the program’s Start milestone. The former sets the date from which all simulation data is calculated. The latter is ignored by the simulator, but represented by a green diamond for the Start milestone in the program’s Gantt Chart for the purposes of comparison. You set the former by changing the Start Date property when the Program tab is selected. You set the latter by selecting the program’s Start milestone and changing the Planned Date property from Relative to Absolute with an absolute date. Setting the program’s planned Start milestone date is not nearly as useful as setting project planned Start milestone dates, since the program’s Start date should match the planned Start date, whereas project start dates might be staggered.

A seed is an integer that specifies how the simulator will randomize aspects of the simulation. This value determines where the random number generator that drives the simulation starts generating values. The simulator assumes a seed of zero, unless you specify something different. A zero seed means the random number generator will start at random. This is recommended as it produces the greatest stochastic variation and minimizes the chances of aliasing artifacts appearing in your results. If you set the program’s Seed property to a non-zero value, you will be able to reproduce your simulation results for a model on the machine you built it on. This might be useful if you are doing a training exercise or tutorial. However, if you open the model in a version of SimVision running on another operating system, results might vary.

If you decide to add real skills as task and position requirements, add position skills before you staff the model. The Staffing dialog box lists person skills and how many matching skills each person has for the tasks assigned to the selected position. Therefore, if you add position skills before staffing, the Staffing dialog box can really help you to staff the positions with the appropriate people. Otherwise, you have to remember which persons have the required skills.

If you decide to staff the model, don’t do so until you have validated the Baseline case and run a simulation of the model with probabilities set. Staffing should occur at a stage in the program where task growth risk and backlog has already been identified. Staffing can then be used as a tool to address existing problems. For example, you can choose more highly skilled persons to staff positions with significant backlog or multiple parallel tasks, and you can choose less skilled persons to staff positions that are responsible for tasks showing slack in the project Gantt charts.

It’s essential to match skills across tasks, positions, and their staffing persons. For example, if a task requires the Software Engineering skill, the position responsible for that task should have Software Engineering as part of its skill set. Additionally, all persons staffing that position should have the skill at the appropriate level (matching the level required by the position—Low, Medium, or High). Failure to match skills can cause high task growth risk, high position and person backlog, increased cost and project quality risk, and increased project duration.

Since using secondary assignments could cause the CPM and Simulated results to differ widely, is it inadvisable to use secondary assignments in setting up the baseline case?

Not exactly. The baseline case represents the modeler's best attempt to faithfully represent the planned Program elements. Typically, a first pass baseline won't include staffing and organizational details in order to focus on getting the direct work model in place. Running the first simulation with all probabilities set to zero should produce a CPM schedule on the Gantt chart that roughly corresponds to a traditionally-planned schedule. This is because most traditional scheduling tools account only for linear direct work. The simulated Gantt chart will show a resource-constrained schedule that accounts for concurrent tasks and primary/secondary resource allocations. This is still very much a 'baseline' in the sense that it is deterministic and accounts for direct work only. More recent planning tools (MS Project and PrimaVera) provide for resource-constrained scheduling similar to this.

The unique capability and value of SimVision is the ability to model, simulate, and interactively explore the effects of rework, coordination work, supervision work, communication work, exceptions, skill matching, organizational behaviors, and many more factors. These elements are combined stochastically in a non-deterministic and highly informative analysis tool. This is the art and science of simulating cases beyond the baseline.

Connectors are SimVision shapes that enable you to link a task in one project to a task in another project. Using two connectors—one in each project—you can connect two tasks with a successor, rework, or communication link, thereby directly linking the two projects. To use connectors, you add one to each project containing the tasks you wish to connect, then draw links between each task and its connector. (For detailed instructions on how to add connectors to your model, see “Linking Projects with Connectors” in chapter 7 of the SimVision 3.1 User Guide.) Each connector links only one set of tasks. To link two other tasks between projects, you must create another pair of connectors.

While connectors enable you to model the interdependencies that sometimes exist between projects, you should use them with discretion. Even though the simulator detects endless loops, it cannot always determine which link has created the loop. Using connectors can, thus, make inadvertently building successor loops possible.

Also, because projects are, by definition, independent entities, you should use connectors sparingly.

I understand that Communications links are intended to be used between parallel tasks, to model the increased information flow necessary to accomplish interdependent operations. However, I’ve seen them used between sequential tasks and even tasks sharing the same responsible position. Are these uses correct?

Communications links between tasks indicate the need for information exchange between the tasks’ responsible positions. During simulation, SimVision generates information exchange items for these links, “depositing” them in the responsible positions’ “in-trays.” If the affected tasks are on the critical path, this process can affect the project’s duration, as it creates coordination volume for the linked tasks. This behavior applies whether the tasks are sequential or concurrent (“parallel”).

A communications link’s primary function is to model the increased interdependency created by moving sequential tasks into parallel (otherwise known as “fast-tracking”). Because successor links are designed to model a complete passing of information from a predecessor to a successor, sequential tasks theoretically require no added communication. In reality, however, a “complete” exchange can be hard to judge, as successors must sometimes return to predecessors for more information. In these cases, communications links between sequential tasks model the necessary relationship more accurately. (Note that SimVision considers this “going back” for more information to be distinct from rework, so placing a rework link between tasks does not model added need for communication.) You might also consider adding communications links between sequential tasks that are intended to be moved into parallel in a “what if” scenario.

In most cases, communications links connect tasks with separate responsible positions. On rare occasions, however, a position responsible for two sequential tasks might need to communicate with itself about the first task while working on the second. In this case, it is appropriate to model a "communicate-with-oneself" relationship.

How much time does it take to develop strategic versus tactical models in SimVision?

A basic SimVision model can be developed quite quickly. The goal of modeling is to capture “80% of the value in 20% of the work.” Early in the planning process, the distinction should be made between a Strategic (long lead) model and a Tactical (immediate or implementation) model. A strategic model can produce value in a very short time, and be developed in as little as a week or two. Tactical models typically do not produce as much leverage, but they can be just as vital to decision-making. Tactical models usually involve greater detail and are more time-consuming to develop. Their value is in the interventions that can be developed to minimize project pressures and improve schedule.

The amount of time spent on any individual model depends on the outcome required. In one actual case the model required slightly more than one week for the modeler, three days from the client planner, and several consulting days for model review and preparation for demonstration to the client.

Each of my projects is succeeded by a software release milestone with an absolute date at the program level. When constructing the task details for a project, does the Finish milestone have to be set with the same absolute date, or will it inherit it from the Program milestone?

You need to set the finish milestone at the project level as well. It will not be inherited from the program.

How do I model a maintenance task that requires a constant 30% of everyone’s time throughout the project?

If each position is busy 30% of the time on this maintenance task, that means positions are only available 70% of the time for their other tasks. Model this by giving each positon only 0.7 of the total FTE value you intend it to have. Similarly, if you are staffing your positions with persons, staff with 0.7 of the full FTE value you intend the position to have. For example, if you have two persons staffing a position, the position will have 1.4 FTEs instead of 2 FTEs.

There are projects in my program for which an end date has not been specified, and I don’t foresee this changing soon. How can I model these projects?

Simply leave the projects with no specified end date. Planned dates are ignored by the simulator, so leaving an end date unspecified will have no effect on the simulation data.

I want to express some task durations in terms of man-months and some in terms of man-days. Can I mix and match task volume measurements in a single model?

Yes, there is no problem mixing and matching different work volume measurements.

The Cost Breakdown chart for my model shows significant coordination for certain tasks, even though I’ve set Information Exchange and Project Error probabilities to zero. Though I’ve set Functional Error probability greater than zero, shouldn’t tasks in such a project show no coordination?

No. In fact, coordination volume is always greater than zero whenever Functional Error or Project Error probability is greater than zero. When it has processed enough work volume, a task produces a work exception which, in turn, produces coordination volume.

Will a simulation automatically extend the schedule when I change the model’s probabilities from zero?

Yes. Increasing any of the probability rates increases the schedule duration. However, what should be examined is the duration of the tasks themselves. By design, SimVision applies statistical probabilities of behavior to a baseline of actual work (the base task duration). If baseline tasks are modeled that contain error, rework, and float, their duration is extended by the application of the behavior matrix. The ultimate goal of modeling is to examine where the inefficiencies are introduced and how to minimize them. The goal is not to allow additional time in anticipation of rework that may or may not occur. Since algorithms used in deterministic scheduling (for example, as in Primavera P3®) start with a statistically optimistic duration bias, a probabilistic algorithm (such as that used in SimVision) can overcome that bias and more accurately predict schedule outcomes. SimVision quickly exposes those tasks that have a high risk of duration growth, communication failure, and rework.

Open SimVision with the default model. Add two tasks in series with the default Task1 in Project1, and set assignment links to them from Position 1. Change all task work volumes to 100 days to support statistical interpretation. Set Functional and Project exception probabilities to 0.1. Rename case to “Set Probs ST”. This highlights the fact that the position has the default Role of ST. Run simulation.

Derive a case from Set Probs ST and name it Set Probs PM. Change the Role of Position1 to PM. Run simulation.

Derive a case from “Set Probs PM” and name it “Rework Backward”. Draw a rework link from Task3 (last task) to Task1 (first task), using default settings. Run simulation.

Derive another case from “Set Probs PM” and name it “Rework Forward”. Draw a rework link from Task1 to Task3, using default settings. Run simulation.

In the “Set Probs” cases, no rework links exist. In each of these two cases, we see on the Project’s Task Statistics chart that the number of Project exceptions is zero. If we examine the Project Work Breakdown chart we see that a modest amount of rework and communication work volume arises from the functional exceptions. A very important fact is that project exception probability ONLY applies in the presence of rework links, so that project exceptions can only occur in a task that has a rework link connected OUT from it.

Consider a 100 day task with a 0.1 functional exception probability and a 0.1 project exception probability. On average, if no rework link is connected OR if a rework link is connected TO the task, there will be 10 functional exceptions and 0 project exceptions generated. If the position’s Role is PM, decisions are quickly made that favor rework. On average, this results in about 8 days rework assigned for the 10 exceptions and low coordination work (0.6 days). If we look at the Set Probs ST case, we see the same average 10 exceptions, but the decision maker’s Role is ST so fewer exceptions result in rework (3 days) and more coordination work is incurred (1.4 days) due to the longer time-for-decision of that Role. (Hover cursor over bars in Breakdown Chart to see values in pop-up tooltips).

If one or more rework links are connected FROM a task, on average there will be 10 functional AND 10 project exceptions generated for that task. The task will accrue approximately twice the internal rework as when no link was attached (based on the equal 0.1 Probs). There are also separate effects at the downstream end of the rework link that are discussed below.

Note: this distinction between Project and Functional exceptions implies the modeler should carefully consider each probability separately for the proper influence in the simulation.

The “classic” understanding of rework is when an exception occurs during work on one task that requires work already completed on another task to be redone. This potential dependence is modeled in SimVision by connecting a rework link from the “driver” task to the “dependent” task, which is usually upstream or roughly parallel in the chain of precedence. When project exceptions arise in the driver task, a certain volume of rework may be scheduled in the dependent task based on the rework strength. The dependent task also has its current VFP adjusted based on the exception decision: ignoring exceptions increases VFP while reworking exceptions decreases VFP.

Look at the Project Work Breakdown chart for the Rework Backward case. Select Set Probs PM to be the comparison case. We see that Task2 has identical work breakdown for both cases. In Task3 where the rework link begins, Functional AND Project exceptions contributed to rework decisions with the result that roughly double the amount of internal rework was performed. The rework link also caused additional rework to be performed in Task1, AFTER it had finished. Task1 had previously finished with statistics identical to the comparison case. Because the direct work and functional rework was already done, subsequent VFP adjustments had little effect. But the assigned rework from the link (multiplied by Rework Strength) accounts for the extra rework volume shown. The VFP adjustment affects exception rates for ongoing and future work. In this case, only newly scheduled rework is affected with negligible impact on exceptions. In the case where the dependent task is roughly parallel in the work flow and much work volume remains, the VFP adjustments due to Project exceptions may have very significant effect on subsequent exception rates.

It is also possible and reasonable to connect a rework link from a driver task to a dependent task that occurs later in the work flow. When project exceptions arise in the driver task, rework assignments and VFP adjustments are passed to the dependent task. However, if the dependent task hasn’t started, no work has been done so there is no work to be redone. It is assumed that the changes implied in the rework assignment are just incorporated into the direct work assignment and it proceeds normally. Thus, no rework volume is accumulated and a non-critical warning is generated to alert the modeler to this occurrence. However, the VFP adjustment DOES have an effect, and it is very important. Placing a forward rework link like this is the recommended way to model a relationship where problems in one task have an effect upon the quality of the work performed later in dependent tasks.

(Note: these results valid for SV 3.7 RC5 or later)

Look at the Project Work Breakdown chart for the Rework Forward case. Select Set Probs PM to be the comparison case. Again we see that Task2 has identical work breakdown in both cases. Task1 is the driver task in this case and so generates both Project and Functional exceptions. This leads to roughly double the amount of internal rework, as we saw before for the driver task. In this case, Task3 is the dependent task, and since it occurred later, it had no rework volume assigned through the link. However, it does reflect the fact that its starting VFP has been adjusted via the rework link. We see that the rework and coordination work volumes are SMALLER than the comparison case without a rework link. That is the result expected because the PM chose to rework the majority of the driver exceptions, thus REDUCING the dependent VFP. If the position’s role had been ST, the VFP would have increased due to the rework link and the usual decision to ignore exceptions.

The rework strength parameter is very different in SimVision from the attribute in ViteProject. That attribute was a multiplier applied to the workItemSize for the activity doing rework. The workItemSize was 1/20^th of the activity volume, so it could vary widely. A default 5% strength value resulted in rework volumes that were each always 0.25% of the total activity volume.

The current definition of the strength parameter in the rework link is: rework volume will be the set percentage of the dependent task’s CPM volume for each reworked exception. The default 10% value is probably too high for many realistic models, but the modeler must estimate the strength based on the sensitivity of the work in the dependent task and the Project exception probability.

What are the differences between the various risk metrics in SimVision, and how they are calculated?

SimVision reports the following six risk metrics:

• Growth Risk = Sim Duration - CPM Duration
  This is reported for Projects on the Program Growth Risk chart and for Tasks on the Project Growth Risk charts.
• Communication Risk = Missed Communications / Requested Communications
  This is reported for Tasks on the Project Communications Risk chart, and for Tasks, Projects, and the Program on appropriate Stats forms. The same calculation appeared in ViteProject 2.2 for Tasks
• Meeting Risk = Missed Meetings / Requested Meetings
  This is reported for all meetings on the Meeting Stats form. Note that statistics are accumulated per position, so that a one-time meeting with 3 attendees out of 4 assigned would have a risk of 0.25.
• Coordination Risk = (Communication Risk + Meeting Risk) / 2
  This is reported for Projects on the Program Coordination Risk chart. There is currently no display of the task's Coordination Risk at the Project level, since there is some theoretical ambiguity about the definition of Meeting Risk with respect to Tasks. Because there is no connection between tasks and meetings, the Meeting Risk value for the Coordination Risk calculation is found from the Meeting Risk of the task's primary responsible position. However, this position may attend meetings that have no relation to this particular task. Therefore, the Coordination Risk is not strictly correlated with this task, but is influenced by a mo
• FRI (Functional Risk Index) and PRI (Project Risk Index)
  These measurements reflect the risk that there are functional or project exceptions over the lifetime of the program or project. They are a measure of the impact of factors such as team experience, backlog, and the match between position skills and task requirements. Simulation reports FRI and PRI for tasks on the Project Quality Risk charts and for projects on the Program Quality Risk chart. They are also listed for tasks, projects and the program on the appropriate statistics forms.

For more information about the PRI and FRI measurements, see “Understanding FRI and PRI Measurements” in Chapter 6 of the SimVision User Guide.

What’s the difference between Communication risk and Coordination risk, and why isn’t the latter reported on project-level charts?

SimVision uses simulator data to express missed or ignored communications via both Communication risk and Coordination risk. For Communication risk, SimVision calculates values for all tasks in a project; for Coordination risk, it calculates values for all projects in a program. Additionally, in calculating Coordination risk, SimVision adds Meeting risk to the equation. Herein lie the fundamental differences between the two.

Communications risk is defined as missed or ignored communications divided by the total number of communications requested—that is:

Communication Risk = (Missed or Ignored Communications) / (Requested Communications).

The simulator calculates this value for every task in a model and reports it on the Communication Risk chart for projects.

Coordination Risk is defined as Communication Risk plus Meeting Risk, each multiplied by a weighting factor, then divided by the sum of the weighting factors:

Coordination Risk = ((α* Communication Risk) + (β * Meeting Risk) / (α + β)), where α and β are currently each 0.5.

The simulator calculates this value for every project in a model and reports it as a single total on the Program Coordination Risk chart.

The difficulty in reporting Coordination Risk at the project level—that is, for tasks—lies in the definition of Meeting Risk. Because tasks and meetings are not connected, the simulator must use the Meeting Risk for a task’s responsible position to calculate the Coordination Risk. Since this position may attend meetings that have no relation to the task, however, the simulator cannot strictly correlate Coordination Risk with the task. Because of this ambiguity, SimVision does not report Coordination Risk for tasks on the standard charts.

For those who need to know Coordination Risk for tasks (SimVision does calculate this value, even though it does not report it in standard models), SimVision makes the results available in models saved in the CSV file format.

Why does the Baseline case show no Functional Quality, Project Quality, or Coordination risk, even though it contains communications and rework links?

Adding communications and rework links to a model alone does not model functional, project, or coordination risk. Only the combination of adding these links and setting the probabilities models risk. When the probabilities are set to zero, the simulator assumes no rework or communication is being generated, and the risk metrics therefore show zero. When you set the probabilities, the simulator takes into account rework and coordination volume generated by the rework and communications links, and the risk metrics show corresponding risk on the Summary Stats chart.

The simulator “decides” when to generate an exception event for any given Work Item based on a Verification Failure Probability (VFP). SimVision dynamically adjusts the VFP in the simulation with a variety of inputs – noise, communication rate, organizational structure, experience, skills, and so on. The base value that these dynamic influences modifies is the Error Probability.

SimVision uses two types of error probabilities: Functional Error Probability and Project Error Probability. These probabilities lead to functional exceptions and project exceptions, respectively. Since, for each Work Item, SimVision determines which event type to use independent of the other, the program can possibly generate both exceptions for a single Work Item. Currently, if SimVision generates both exceptions, the simulator "flips a coin" to pick one type to report for that Work Item.

An exception message causes the Simulator to make a decision either to rework, to quick-fix, or to ignore the problem that caused the exception to occur. Supervision links, centralization, formalization and other parameters control who in your model’s decision-making hierarchy makes that decision, and the decision-maker's attributes influence which decision he makes. If the decision is to ignore the exception, no rework is generated, quality suffers, and the VFP (verification failure probability) increases. If the decision is to quick-fix the problem, 50% of the rework volume is scheduled, quality declines, and the VFP is nudged upward. If the decision is to rework, 100% of the rework volume is scheduled, quality improves, and the VFP decreases.

In contrast to Project exceptions (see the next topic), Functional exceptions are internal to the task where they are generated. If a quick-fix or rework decision is made, the volume of rework is the a percentage of the volume of the work item that generated the exception. That volume of rework is added to the task.

In contrast to Functional exceptions (see above question), Project exceptions affect other tasks within the project as well as the generating task. Every affected task must be explicitly connected to the exception-generating task with a Rework link. The exception-generating task accumulates internal rework volume exactly as described for the functional exception. In addition, every task linked with a Rework link receives rework based on the link’s Strength property.

The Strength property is very different in SimVision from the property in ViteProject. That attribute was a multiplier applied to the workItemSize for the activity doing rework. The workItemSize was 1/20 of the activity volume, so it could vary widely. A default 5% strength value resulted in rework volumes that were each always 0.25% of the total activity volume.

The current definition of the Strength property of the Rework link is: rework volume will be the set percentage of the dependent task’s CPM volume for each reworked exception. The default 10% value is probably too high for many realistic models, but the modeler must estimate the strength based on the sensitivity of the work in the dependent task and the Project exception probability.

The simulation of my model took a long time. Are there steps I can take to reduce simulation time?

Yes, you can reduce the number of trials that the simulator runs.

Some models are complex enough that running the default 100 trials during a simulation can take several minutes. Reducing the complexity of the model is clearly not feasible if the model is accurate and you need a realistic picture of its risks and how to address them. If the simulation you’re running isn’t critical—for example, if you’re merely testing a new case—you may be able to safely reduce the simulation’s run-time by decreasing its number of trials.

For all but the final case of the model, you can usually decrease the number of trials from the default of 100 to 10. This will still probably give you reliable results. You can change the number of trials the simulation runs by changing the value of the program’s Trials property in the Properties Pane. Once you’ve decreased the number of trials, running the simulation will take significantly less time.

Some models’ simulation results tend to be more variable than others. Running two simulations on the same case of a model, for example, may give widely varying results, especially when you’ve decreased the number of trials. Models with many parallel tasks, or those with high Noise probability values, tend to register highly variable simulation results. You can better judge the simulation’s precision by viewing the standard deviation in the charts where it’s available. Low standard deviation tends to indicate a more precise simulation and, therefore, one with more reliable results. High standard deviation— 20% or more of a measurement’s value —tends to indicate high variability.

To view standard deviation, select the Standard Deviation check box in a chart in which it appears. For programs, these charts are

1. Summary Stats
2. Coordination Risk
3. Quality Risk

For projects, standard deviation appears in

1. Summary Stats
2. Communications Risk
3. Quality Risk

Standard deviation appears as black bars appended to each of the colored bars in the chart.

Some models feature high variability no matter how many trials a simulation runs. If decreasing the number of trials gives you results you feel may be unreliable, you can, of course, test the results by setting the number of trials higher, preferably back to the default of 100. If restoring the number of trials does not significantly reduce the standard deviation, running the smaller number of trials probably gives results as reliable as the running the larger number.

The simulation for one case of my model was taking so long I stopped it. Are there conditions under which a simulation might run endlessly?

Theoretically, yes; effectively, no.

“Theoretically, yes” because, each time it runs, the simulator checks for loops and breaks and for incorrect flow in the model’s work, communication, supervision, and exception links. Even with these safeguards, you could theoretically construct a model that passes validation yet causes the simulation to run endlessly (or until memory overflow causes your computer to crash!). For example, creating a model with multiple high-strength rework links and high exception probabilities could cause rework volume to grow faster than the direct work’s rate of completion. Also, creating a model with multiple rework links, low exception probabilities, and serious skill mismatches could cause the direct work rate to fall behind the rate of increase in rework. In both of these cases, increase of rework exceeding work rate could lead to infinite work volume growth.

Fortunately, the Simulator employs two mechanisms for trapping runaway work conditions: Work Limit and Duration Limit. When a simulation reaches either type of limit, the simulator issues an error message and ceases simulation. Using Work Limit, a simulation exits when the simulated work volume of a task exceeds the total CPM work volume of the program by a factor of ten. The Simulator displays an error message that states “work volume exceeds Program maximum” and identifies the offending task. For Duration Limit, a simulation exits when the current event time passes the program’s CPM duration by a factor of ten. In this case, the simulator displays the error message “Simulated duration exceeds program maximum.”

The rationale behind both these two limiting mechanisms is simple. Presumably, if a real project or program has a task that grows to ten times the work scheduled for the entire program or remains incomplete beyond ten times the scheduled duration, the manager in charge would either stop the project or otherwise drastically intervene.

Why do SimVision’s Gantt chart dates differ from those of other scheduling software, such as Primavera’s P3®?

By design, SimVision is a strategic planning tool for managers. It differs in several key ways from common scheduling software, which are primarily control tools. A fundamental advantage of SimVision is its predictive ability to show pressures on a project plan. The SimVision Gantt chart demonstrates how these pressures will result in changes to forecast dates. The reality is that hard milestone dates will probably be achieved because people typically go to great lengths to ensure that the major events in a project happen according to plan. This ignores the fact that there are pressures to change those hard dates and that interventions can be tried to determine a better way to achieve them. SimVision shows those pressures graphically as changes in the Gantt chart output.

I constructed a model with a task that had a work volume of 5 days and no coordination or rework links. The responsible position had FTE = 1 and was staffed with FTE = 0.1. There was also a secondary responsible position assigned to the task. The Simulator calculated a CPM duration of 50 days and a Simulated duration of 12 days. Why is this?

The key facts in this example are:

1. A secondary responsible position also exists.
2. Unstaffed FTEs apply only when no staff are assigned.

The primary responsible position is staffed at 0.1 FTE. The secondary responsible position has 1.0 unstaffed FTE and 1.0 staffed FTE. The CPM calculation is essentially a resource-constrained direct work timeline layout that ignores any other links or work types. Therefore, the CPM calculation for this task’s duration includes only the primary responsible position, and is calculated as:

(5 work days) / (0.1 FTE) = 50 days.

The Simulation accounts for additional resources, other kinds of work, noise, and so on. This is done in a weighted discrete event simulation that accumulates all the pieces of work until the work has been accomplished. A rough calculation can ignore noise and exceptions since the probabilities are zero.

Thus (5 work days) / (0.1 FTE Primary + 1.0 Secondary) = 4.5 days.

But the Simulator reports a duration of 12 days. This indicates that the secondary responsible position must not have been available all the time to work the task. This is very likely because, by definition, secondary responsible positions only work the task when they do not have any primary work to do. So we can calculate (5 work days) / (12 days sim duration) = 0.41 FTE. Therefore, we can deduce that the secondary responsible position was available less than half the time for this task.

Generally, the position assigned to a task that is showing high growth risk will show high backlog.

The most common reasons for high task growth risk are:

1. Mismatched skills between position and task requirement, or between staffing persons and task requirement. Check all staffing persons have appropriate skills at appropriate levels.
2. Backlogged responsible position due to concurrent tasks, high coordination volume resulting from numerous communications links between tasks, or high rework volume resulting from numerous rework links between tasks.
3. Low application experience for responsible position or staffing persons. Check all staffing persons have appropriate application experience level.
4. High task uncertainty, requirement complexity, or solution complexity.
5. Large number of communications or rework links, especially combined with high info. exchange, noise, and error probabilities.

Both position and person backlog is derived from all the tasks that the position or person is responsible for. However, because a person can staff multiple positions and because multiple persons can staff a single position at different percentage allocations, all the persons staffing a position do not necessarily show the same backlog as the position. For example, if a person is staffing two positions at 50% allocation each, the person will show the sum of 50% of the backlog of each position. Similarly, if a position is staffed by 3 persons at 60%, 30%, and 10% allocation respectively, the first person will show 60% of that position’s backlog, the next 30%, and the last 10%. The only time a position and its staff show identical backlog is when a position is staffed 100% by a single person.

In calculating the actual cost of rework on a construction project, will SimVision break down the cost between labor and materials?

SimVision allows the modeler to specify "fixed cost" of all tasks (default = 0). Materials are a classic fixed cost. SimVision calculates the labor cost based on the number of hours of work done. This cost is broken out as the cost of direct work, coordination, rework, and wait time. However, SimVision does not adjust the growth in planned fixed cost for material spoilage, nor does it adjust the non-labor costs that depend on duration (for example, the monthly cost of renting equipment or office space).

SimVision can certainly help the user to plan, budget for, and manage project labor costs. For the design phase of a design-build project, the labor costs are the only significant costs. More importantly, SimVision allows the user to plan, budget for, and manage project duration. These are the most important risks for an owner and often for a contractor too.

The most common interventions should address the most common business objectives, which are schedule, cost, and quality. For example, if the client’s primary business goal is schedule, you should intervene first to reduce critical path task growth risk and related position backlog. Reducing these two will probably bring the schedule in. If the client’s primary objective is to keep the cost within a certain budget, you should intervene to make better use of resources, for example, by adding secondary task assignments or moving staff with appropriate skills between positions. In my experience, the most common interventions are:

• Adding FTEs to backlogged positions if cost is within budget.
• Assigning critical tasks to appropriately skilled positions that have slack using secondary assignment links.
• Fast-tracking by making sequential tasks parallel.
• Recommending increased training for positions/persons to increase skill levels.
• Recommending staffing positions with different persons that have higher application experience or more appropriate skill levels.
• Reusing information between projects that have identical tasks by adding Connectors.

NOTE: Use Connectors sparingly and with caution, as it is easy to inadvertently build endless loops with them.

If you’re a regular SimVision user, you probably know that Backlog chart results showing short periods of 2-4 days’ backlog are normal, even desirable, for positions and persons (for our purposes here, we’ll refer to both persons and positions generically as “actors.”) You’re probably also aware that a smooth backlog curve of more than four days indicates an actor needing attention. What you may not know, however, is that spikes that “saw-tooth” from many days and return immediately to zero, even if they occur repeatedly, do not indicate serious backlog. Such brief spikes occur because of the way SimVision distributes work to responsible actors: the distribution mechanism causes momentary backlog that gets worked off immediately. Thus, these spikes indicate no threat to the project or organization.

Additionally, while 2-4 days of backlog indicate that an actor has sufficient work to keep it busy, that same amount of backlog occurring over an extended period of time indicates a problem. Actors who are in subordinate positions may exhibit “delegation-by-default” behavior, wherein they tire of waiting for their supervisors to direct them how to handle exceptions and start to make their own decisions. Such actors will tend to exhibit sustained periods of low but significant backlog. These “plateaus” of more than two days deserve evaluation, to see if it they can be reduced.

Obviously, an actor with a 20-day backlog requires attention sooner than one with only a five-day backlog. However, even a 2-day backlog persisting over several weeks will noticeably affect process and product quality.