Simulating a process DSM to study concurrency and iteration


A process DSM is a useful tool to capture dependencies between activities in a project. It is especially suited to study processes in which multiple teams require information from one another. In such situations, making assumptions enables more concurrency by allowing certain tasks to start earlier, but potentially creates rework if the assumptions later prove inaccurate.

Process DSM simulation using CAM and the Applied Signposting Model can help understand the impact of concurrency, iteration and information dependencies on a complex project.


Click any screenshot to enlarge it.

Simulating a process DSM using CAM requires the ASM toolbox. Using this toolbox, we can choose to visualise a project as either a DSM or a diagram (process flowchart). The whole example is illustrated in 30 steps below.

To get started, open CAM and create a new workbook of type ASM. We will start by using the default diagram view to construct a process model, then analyse it using the DSM view. The two views show exactly the same task network, but visualise the connectivity differently.

Create a set of tasks as shown below. Set the durations of the tasks to vary across a small range by using triangular probability distributions. This is not critical, but provides a more 'interesting' Gantt chart and simulation results.

The values chosen are not important for the example, the duration for most tasks for the model used to generate these screenshots were set as 1.0 days (min) 1.1 days (expected) and 1.5 days (max).

Now simulate this process by clicking the SIM button on the top toolbar or by selecting the Analysis->Monte Carlo simulation menu item. The number of simulation runs is not too important; to generate these screenshots we used 1000 runs.

When complete, the simulation will produce a histogram of process durations similar to that shown below. The highest peak on the histogram indicates the most likely durations for the simulated process. In this case, hovering the mouse over the highest peak has highlighted it.

Right-click the highest peak to obtain a popup menu, as shown below. Select 'View processes' from this popup menu to study all the processes that have duration in the range specified by the selected histogram bar (in this case, the horizontal axis labels in the screenshot above indicate that the processes in the pink bin have duration between about 8.05 days and 8.2 days)

This will bring up a screen showing all the selected processes (in the green DATAPOINTS tab at the left of the screen) and a Gantt chart view of one of those processes, shown in the main part of the screen. The Gantt chart shows the sequence of execution of tasks, which is determined by the dependencies (arrows) in the ASM model. You can examine different processes by selecting them on the DATAPOINTS tab. You can also select multiple processes using SHIFT to view a 'probabilistic' Gantt chart, and various display options are available on the toolbar just above the Gantt chart.

We are now ready to consider this project network as a process DSM. To do this, navigate back to the main diagram view (by clicking the appropriate tab just above the main window). Then select Window->Manage views from the main application menu, as shown below.

This will bring up a view manager dialog. The view manager shows all the different views available for the current worksheet. Different views provide different ways of visualising and editing the same dependency information. Adding, deleting or modifying an item or connection on any view will cause all the other views to be updated automatically.

The network of items and connections is thus synchronised across all views of a worksheet. On the other hand, 'visualisation' data, in particular the layout of nodes on a diagram view and the sequence and clustering of nodes on a DSM view, is unique to each view. (Thus we could, for instance, create several DSM views of a process, each showing a different sequence of the activities)

By default, an ASM worksheet is created with a single view of type "Diagram", as shown in the view manager of the screenshot below. Click 'New' in the View manager to create a new view of the current worksheet.

This will bring up a 'new view' dialog as shown below. Select "DSM" from the "Type" option, then click OK.

The new view is created and the screen will change to show it immediately, as shown below. We can see that a combo box at the top of the screen says "DSM1". This combo can be used to switch between views of the worksheet. (The two views will also be identified on the thumbnail screen when navigating the CAM workspace)

In a CAM DSM view, the rows and columns of the matrix represent nodes in the diagram. In this case, the nodes are all ASM tasks. Because our project network was not iterative, we should expect to find an ordering of rows and columns such that all marks appear below the leading diagonal of the DSM. However, when a DSM view is first created, CAM does not know what sequence the items should be listed. We can arrange them manually by grabbing row or column headers and dragging them up/down (or left/right). Alternatively, we can use the built-in partitioning (sequencing) algorithm. This is located on the bottom toolbar of the DSM view; the first item of the Algorithms toolbar.

Click the partitioning tool to select it. Then move the mouse over the DSM and click once to apply the algorithm, as shown below.

The algorithm should find a sequence of tasks that results in all dependencies aligning below the diagonal, as shown below (note, the partitioning tool will remain selected until you select another tool, such as the "Move" tool shown as a mouse pointer). This sequence should look very similar to the sequence that appeared in the Gantt chart, above.

Now we can use the DSM to consider the impact of increasing concurrency in the process. In effect, we can assess the impact of allowing certain activities to make assumptions of the inputs they require from predecessors. This allows those tasks to be 'moved earlier' in the sequence, and thus started earlier in the project.

To do this, grab a couple of tasks low down in the order and drag them 'up' so that marks appear above the diagonal, as shown in the screenshot below. In this case, we have allowed task 9 to start earlier by allowing it to assume the input it needs from task 8. In the DSM, all marks above the diagonal denote making assumptions, while marks below denote waiting to receive information from another task. Because all marks in the Task 9 row appear above the diagonal, this means that 9 can make assumptions about all its input and therefore start right at the beginning of the project. The same is true of Task 7, which has been allowed to make an assumption from its only input, 6.

To simulate this model with assumptions and concurrency, we need to change the properties of the ASM tasks. To do this, we first need to switch back to the diagram view using the "Views" combo box on the top toolbar.

Recall that the reordered process had allowed tasks 9 and 7 to make assumptions of the information from their predecessors, so that they could start earlier and the process could be more concurrent, potentially finishing earlier.

To simulate this scenario using the ASM, we need to modify the model slightly.

We must first identify the tasks that would normally create the inputs that can be assumed in the reconfigured process. In this case, the input to task 9 came from task 8. In the ASM model, we will change the type of task 8 to an iteration construct. This means that when 8 is complete, it may, or may not, feed information to task 9. The ASM simulation logic will interpret this situation by not forcing Task 9 to wait for task 8 to complete before starting. Because Task 9 has no other inputs, it will start from the outset of the simulated project. However, if task 8 does feed information into task 9 later on during a simulation, task 9 will be reworked along with all its successors that had already been executed when the feed occurs.

To change the type of task 8 to an iteration construct, right-click it and select "Task properties" from the popup menu as shown below.

In the task properties dialog, change the type of the task to "Iteration construct" and click OK as shown below.

In the network, we can see the type of the task change as shown below. We can also see that the flow from task 8 to task 9 is now labelled as "Continue process". This denotes that Task 8 will feed into task 9 when it completes successfully. We need to alter this so that the feed only occurs in case of error (ie. in case the assumption made by Task 9 to start early turned out to be wrong, necessitating rework).

To do this, delete the connection between Task 8 and Task 9 (labelled "Continue process").

Now, use the connect tool to recreate the edge you just deleted. You will be prompted to select an output scenario for the edge. Select "Iterate again" and press OK, as shown below.

Repeat the whole process to convert task 6 into an iteration construct, delete its outgoing edge, and replace it with an "Iterate again" flow. The network should look like the one shown below.

If we navigate back to the DSM view, we will now see the above-diagonal marks shown in red. These are the same flows shown as red in the diagram view above.

The reconfigured model, with additional assumptions and concurrency, may now be simulated. Push the SIM button on the top toolbar again or choose Analysis->Monte Carlo simulation from the main application menu. This will produce another duration histogram, as before.

If we now view the processes in the most likely (tallest) histogram bin, we can see the impact of the reconfiguration. Tasks 7 and 9 now start in parallel, at the beginning of the project. The overall duration may be shorter (although this depends on the dependencies in the specific process; starting a task earlier need not make the whole project quicker if that task was not previously on the critical path).

The solid black dots at the end of the two green bars in the Gantt chart above indicate that tasks 6 and 8 finished without feeding any information to any successor. In other words, the assumption was successful and the process was parallelised without creating any iteration. However, it is perfectly possible that an assumption has a certain likelihood of being 'wrong', such that when tasks 6 or 8 complete, there is a certain likelihood that they reveal that 7 and 9 will have to be redone, creating rework. Such rework might reduce or even overwhelm the time that was previously gained by making an assumption.

In the ASM, we can model this effect easily. Go back to the network view and select task 6 (the first iteration construct). Open its property dialog by double-clicking. Click the 'Behaviour" button on the left of the dialog to view teh simulation options. Go to the "Outcome" tab as shown below, and enter 0.4 in the Iterate again box and 0.6 in the Continbue process box. This means that there will be a 40% likelihood of the red arrow being activated, and the downstream tasks reworked, when task 6 is completed.

Do the same for the other iteration construct.

Now run simulations again. We can clearly see that the possibility of making a poor assumption, leading to rework, causes the histogram to skew out towards the right and assume a bimodal shape. Investigation of the Gantt charts resulting from different bins will show that the left-hand peak corresponds to those cases where rework never occurs, ie. the assumption was 'right first time'. The right-hand peak corresponds to cases where one, other or both of the assumptions turned out to be wrong (there is some overlap in the middle of the distribution)

We can see these 'invalid assumption' situations in the three example Gantt charts picked out below. Note the Gantt chart bars now show a different symbol in case of iteration (a line within the green bar that goes up at the end of the bar).

<Click images to enlarge them>


Finally,we can view the impact of the possibility of iteration on effort as well as process duration. Go to the datasets and charting tab that appeared on the bottom left of the screen when you ran simulations. Double click the Datasets node if no items are visible. Then right-click the latest dataset (they are shown in sequence that they were created). In the popup menu, under default charts, select "Duration histogram and duration vs. effort XY plot", as shown below.

If there is no iteration, effort will generally stay the same as process concurrency is increased through making assumptions. The chart shows that when iteration occurs, the duration of this process is signififcantly increased, although the total effort tends to increase only slightly.

In a further step, we could also assign resources to tasks in the ASM model to study the effect of resource constraints on effort and time.

For more information on simulating and studying iterative processes using the ASM, see the ASM toolbox documentation, the critical path analysis use case, and our publications.

The CAM tool can be downloaded from the Download page.