Process Models in Design and Development

Read this article. It provides an overview of planning models. Pay particular attention to Figure 1 as it visually provides a global view of planning models. Then review Figures 2 -17 for more in-depth visual planning processes.

Meso-level models

Queueing models

When a process is considered in context of the organisation that executes it, scarcity of resource and the need for workers to divide their effort among tasks from several sources often cause workload congestion and, consequently, delays. Queueing models provide a means to investigate and manage these macro-level issues.

The first group of models in this category incorporate dynamic simulations. For example, Adler et al. develop a queueing model to study workload and congestion effects in firms that handle multiple development projects concurrently. In such situations, even when a task has the information required to start, it must compete for attention with tasks from other projects. In their model, Adler et al. assume that projects can be grouped into different types, each of which is represented as an iterative task network that incorporates probability density functions to represent variation in individual project characteristics. The organisation is represented as a set of processing stations, each of which has a fixed capacity representing the number of individuals who can work on tasks of a certain type. In the simulation, projects are assumed to arrive at stochastic intervals, such that several are in progress at any time. The tasks from each project-in-progress are generated according to the precedence network for the corresponding project type, and queue for attention at the appropriate processing stations. Thus, the model captures the time which a project spends waiting for attention as well as the time spent performing tasks. Adler et al. argue that their model can accordingly predict cycle time more accurately than single-project approaches and, through what-if analysis, can provide useful insight into resourcing and congestion effects. Narahari et al. build on this work, arguing that similar insights can be gained through a simplified model in which each project is represented as a single job that flows through a network of processing stations, each representing a project stage. The stations are organised in a reentrant line to simulate loop-backs between stages. Although it does not represent complex concurrency within each project, this model can be used to assess project processing times and indicates how they can be improved through insights from queueing theory. In particular Narahari et al. recommend that workers prioritise jobs using policies designed to reduce variability, and that companies throttle the number of projects they take on concurrently.

Queueing models also often appear in engineering practice as the basis of tools that manage the queues of tasks in administrative processes such as the review and approval of design releases or of change orders. For example, this functionality is offered by commercial PLM solutions. The emphasis is to automate the logistics of information flow and make people aware of tasks awaiting their attention, based on a process model which sets out the series of steps through which all jobs flow. Although providing useful infrastructure, these tools are in practice often associated with long process lead times which can cause many secondary problems, some of which are discussed by Oppenheim. One approach to managing this is to provide visual depictions of the work-in-progress, through manually arranged or computerised visual management dashboards. Such dashboards usually show the sequence of process steps horizontally across the top of a computer screen or meeting room wall, and jobs awaiting attention are aligned underneath each step. They may be discussed among a team on a regular basis with a view to managing priorities and bottlenecks. Other authors develop metrics for monitoring queueing in the DDP to enable and support continuous improvement.

Value stream mapping (VSM) is a workshop-based process mapping method that can help teams to identify bottlenecks, long lead times, unnecessary activity, and other wasteful situations in queueing processes, prior to understanding and addressing the root causes. These problems commonly develop when responsibility for queueing processes is decomposed across departments or sites, such that no-one has overall responsibility for ensuring timely end-to-end flow. This often occurs for important back office processes in product development as well as in the production processes for which VSM was originally developed. Seeking to build on successes in this context, the VSM method has been adopted as the basis of the product development VSM (PDVSM) which is intended for the typically less-structured design processes. The PDVSM manual published by MIT Lean Aerospace Initiative states that 50–75% reduction in lead times of development processes can typically be expected when applying this method. VSM is included in this section because it was originally developed to model and improve queueing systems in which inventory can accumulate between processing steps, although PDVSM arguably blurs the boundary between this idea and the task precedence models such as ASM that were discussed earlier.

Overall, queueing models are arguably most useful for handling relatively routine processes that can be perceived as workflows in which numerous jobs must follow the same sequence of operations. While these situations do frequently occur in development projects, the models may be less applicable to core design processes that involve less routineness.