DSM sequential rework process simulation
This material is under development; the toolbox will be available for download soon
This toolbox can help to understand the issues involved with task sequences, cyclic dependencies and rework in a process.
It is essentially an implementation of the algorithm described by Browning and Eppinger in their 2002 IEEE TEM paper (see the reference given at the bottom of this page for further information). In our implementation, some enhancements have been made to the simulation logic so that it can better handle certain scenarios. These are not critical to the approach and thus are not discussed here.
A process can be decomposed into tasks, each of which requires information from other tasks. In an ideal process, it would be possible to find a sequence (a plan) such that each task only depends on information from tasks that had been completed previously. In such a situation, the process would be 'linear'. It could be easily scheduled using a Gantt chart and the duration predicted with some confidence. Techniques such as Critical Path could be used to manage the execution.
However, linear processes rarely exist in practice, especially in design and development. For instance, two tasks may each need information from the other. Consider the case of bridge design, where the structure determines the weight, yet the weight is required to understand the static load to design the structure. Neither of the tasks can be started without 'breaking' one of the dependencies, for instance by making an assumption of the weight to create a first pass of the structure design. This is a very simple example. In real situations, it is common to find complex 'knots' of information dependency that involve many tasks.
The example illustrates that tasks in a process must often be started without all the information they would ideally have. To actually execute the process, a sequence of the tasks must be chosen. Assumptions of the input information for some tasks will need to be made, because that information comes from tasks that will only be completed later in the process. When the tasks that actually generate the information are completed, it will require rework of the task where an input information was made (or, at least, the task should be revisited to check its output is still valid). If the task must be redone, its outputs will be changed. In turn this may require rework of the reworked task's successors, and so on.
Because a complex process involves complex knots of information dependency, it is often not possible to avoid these situations entirely. However, a good understanding of the process and the dynamics of rework helps to find ways to minimise this 'unproductive' iteration. A sequence of tasks might be found that is less prone to rework and its effects. It might be possible to move some tasks earlier in the plan, so that some of the most critical rework-generating assumptions are not required at all. Other times it might be possible to remove a feed-back dependency between certain tasks, or reduce the amount of rework the dependency is likely to cause, by restructuring the work (for instance, by splitting interdependent work into planned iterations. A low-fidelity calculation of the bridge weight based on a concept design might provide the information needed for more detailed structural design, with sufficient precision to avoid rework)
The DSM sequential rework simulation toolbox provides a way to understand the impact of cyclic dependencies and task sequence on the duration and risk of a process. It is called 'sequential rework' because each task is reattempted in turn when its information is updated by a predecessor. This differs from parallel rework models, where interdependent tasks are assumed to execute concurrently, continuously exchanging information with one another as it evolves.
Installing the toolbox
Using the toolbox
The basic logic of sequential rework and rework propagation is also included in the ASM toolbox. The differences are largely due to the user interface, because the underlying logic is similar. The DSM sequential rework toolbox is much easier set up to assess the impact of different task sequences, although it offers less overall flexibility. In DSM all iteration is treated as 'rework' which is initiated and propagated probabilistically. It is not possible to study other situations such as 'productive' or structured iterations. In ASM, rework-generating tasks must be explicitly specified using 'Iteration constructs', so the model must be manually reconfigured to evaluate different sequences. But, it is possible to configure in detail the situations in which iteration occurs, and what its effects are.
The approaches are complementary; the DSM can be used to understand the impact of 'baseline sequence' for minimising rework, for instance in one-off projects. The ASM can help to optimise more structured projects, for instance in variant design where the sequence of tasks is mostly fixed and iterations are 'planned'. DSM is quicker and easier to apply as a 'first pass' analysis. ASM can be programmed to closely reflect a given scenario.
The original paper by Browning and Eppinger contains more information on the model: Browning, T.R. and Eppinger, S.D. "Modeling impacts of process architecture on cost and schedule risk in product development" IEEE Transactions on Engineering Management, Vol. 49, No. 4, 2002.
If you find our implementation useful, please consider supporting our work by citing publications on CAM.