STREAMLINE: Optimising the interdisciplinary work sequence

This is the third in this series of articles that describe the underpinning steps of the FLOW methodology for capturing complex processes, integrating and streamlining the overall process, and ‘managing, controlling, and reporting’ the ultimate project using the detailed understanding of the information-driven process. This article addresses the difficult tasks of optimising the sequence in which design activities should be undertaken to maximise positive iteration (which drives innovation and coordination) and negative re-work cycles (which result from undertaking activities in the wrong order).

FLOW should be adopted by any organisation or project management professional faced with managing information intensive processes in any sector: construction, infrastructure, software development, marine, aerospace, discovery research, and others.

Introduction

This is the third article in a series of articles that describe the underpinning steps of the FLOW methodology for capturing complex processes, integrating and streamlining the overall process, and ‘managing, controlling, and reporting’ the ultimate project using the detailed understanding of the information-driven process. 

Determining the Optimum FLOW of Information

Once the team has agreed the design / engineering network (activities and information dependencies), the optimum sequence in which to undertake the work must be established. Many organisations apply a lean methodology known as ‘reverse phase scheduling’ or ‘pull planning’ to determine the optimum sequence of events that must be undertaken to achieve a pre-determined end goal. This involves identifying an end point (typically a milestone in scheduling terms) and then working backwards to determine what activities must be completed in what sequence to get there. Whilst this is a useful approach for optimising linear processes, it can be problematic for design / engineering processes owing to their iterative nature. For example, teams can ‘reverse phase schedule’ through a series of design activities without realising that they have pulled through an iterative loop and simply identified a single chain of events – in essence the approach can give highly iterative processes the appearance of being linear.

To overcome this, a different, yet complimentary, approach is utilised. The team is asked to initially identify those activities that have no predecessors (i.e., need no information in order to be progressed) and these become the anchors for the “start” of the process. Owing to the fact that each of the activities within the network has its information requirements defined, along with the activity that produces each piece of information, the next step simply involves the team locating the activities that can be undertaken using only the information that has been produced by the preceding activities. As each activity is positioned relative to its information-producing predecessor, more information becomes available and activities can be located accordingly. This is a simple collaborative approach, which is based on a detailed understanding of the ideal world sequence of events.

If this was a linear process, this approach would continue until all activities were positioned (and it would provide the same sequence as if reverse phase scheduling was utilized). However, owing to the fact that the process is iterative, the team will quickly reach a point in which activities are interdependent (i.e., dependent upon information from one another)—this represents an iterative loop. The scale of these iterative loops can vary from two activities (which cause few problems for the team) to many hundreds of activities, which are far more difficult to reconcile in practice and can leave the team in a state of uncertainty over how to proceed.

The value of the approach, however, is to find these iterations in the process as it is here that tactics can be applied to focus the collective understanding and expertise of the team on determining the scale of the iteration and how it can be worked through once the project proceeds. There are many tactics that can be applied to address, or further breakdown, an iterative cycle. Irrespective of the tactic that is applied (e.g., to create zoning strategies in the horizontal or vertical dimension to ensure that systems will never clash with one another as long as they are designed within the dimensions set by their zone), the agreement on, and commitment to, this decision by all parties is of paramount importance, as when the design process commences this decision will have to be adhered to by all members of the team if disruption is to be avoided. For this reason: the reasoning behind all ‘process-based’ decisions must be captured and maintained to ensure that rationale is available for reference when implementing the schedule once the process is in motion (these are sometime referred to as ‘tear’ registers and become the basis for the project ‘Design / Engineering’ risk register).

It is important to recognise that the aim of this approach is not to remove all of the iteration from the design / engineering process; to do this would reduce design to a linear production process. The approach is simply to reduce the volume of activities that are held within any single, iterative loop and, instead, focus the iteration on smaller, manageable “chunks.” Owing to the fact that information flow dictates the whereabouts of the iterative loops and informs decisions that will result in a focusing of design effort, the negative iteration (that typically results in wasteful re-work cycles) associated with out of sequence design/decision making is already removed. The iterative loops that remain tend to represent highly integrated sets of systems/sub-systems, with the activities held within the loop being owned by a number of functional groups and as such, requiring integrated collaborative design to ensure coordination, integration, and to prevent clashes as the design/engineering solution evolves. Once an iterative loop has been identified and its boundaries have been determined, it can be treated as a single, collaborative design exercise (for the purposes of scheduling). The process of identifying the next activity in the sequence is then followed as described above; basically, identifying which activity can now proceed with certainty given the information that has been produced by preceding activities.

Avoiding Unnecessary Assumption-Making

All too often, designers/engineers are forced to start and complete a design without having all the information that they need to do so with certainty. Unlike the construction process, in which predecessor activities typically produce a tangible output without which a successor activity cannot physically commence (e.g., two columns in place enable the placement of a beam), design is dependent upon information, which is intangible and thus can be assumed if it is unavailable. A construction worker would not consider starting an activity if everything required to complete it was not available; doing so, if physically possible, would only serve to create delays and risks for the project. Conversely, designers are continuously pestered to produce “documentation” to enable approvals to commence or work packages to be procured. Because the drawing, as opposed to the information that it contains, is deemed to be the deliverable, designers/engineers can be pressured into making “guesses” about important pieces of design information in order for them to produce an output. In this respect, many designers believe that assumption making “comes with the territory,” whether or not it is a genuine necessity (i.e., the activity is part of an iterative loop) or just the result of poor planning (i.e., sub-optimal sequencing of work). This type of ad hoc assumption making can have catastrophic effects on the overall project delivery process, particularly when fast-track delivery is utilized, and design change can lead not only to re-worked design but also aborted manufacturing/construction. The primary reason for using information flow to drive the sequence of activities is to generate a process that ensures that the individual responsible for completing any activity has as much information as possible with which to complete his or her work, thus driving certainty into the design solution and reducing the risk of unnecessary re-working of the design/engineering process later in the project.

Having created the dependency network (DEFINE), and then optimised the sequence in which the activities are undertaken to STREAMLINE the process, the next step is to introduce time to generate the schedule (i.e., PLAN) and integrate with linear production sequence to generate the integrated project programme (full lifecycle)

Adept Management offers Flow implementation as a service, with our team of consultants implementing the methodology and software on behalf of our customers. The Flow software can also be purchased as a standalone application with training and support packages available to suit all needs. Contact us to learn more.