Managing Project Dynamics

Overview
System Dynamics (SD), one of the courses taught at the Projects Academy, is consistently voted by attendees as having one of the highest impacts on their learning experience. While seen as complimentary to traditional scheduling and project management tools, SD is distinctive in its objectives and capabilities to help teams better manage the dynamic complexities created by interdependencies, feedback, time delays, and nonlinearities in projects, especially large-scale projects. Some examples of specific project planning and execution outcomes that can be improved through the application of SD are as follows:

Figure 1 In this first of a series of articles designed to raise awareness and influence uptake, we will focus on causal loop diagram (CLD) modeling, as it is relatively easy for project teams to learn and it integrates nicely with many traditional project planning and execution activities. In the next article we will expand our discussion by describing an application of a top-down SD model that alerted a project to delays and increased costs before they were visible through traditional project management tools.

CLD Modeling
To start, I would like to describe a recent exchange in a Startup Workshop that begins to illustrate what is meant by system dynamics. One of our workshop discussions centered on the need for an emergency shutdown (ESD) commissioning procedure to test the performance of a variable frequency drive (VFD). As loading the VFD during commissioning was going to be a challenge, a suggestion was made to simply call the vendor and operators of the VFD to answer the performance question. This approach was accepted by everyone in the room, except for one person who advocated the project run an additional test of its own. He justified a separate test by pointing out that the VFD is connected to other pieces of equipment. Individually, each of the vendors will produce credible information describing how their piece of kit is designed to perform satisfactorily in an ESD condition, he said. Weve learned many times, however, that surprising things happenthings nobody anticipatedwhen the pieces are tested while they are connected. It is the system dynamics we are testing with this procedure, he added. His comment struck a chord about the importance of understanding the dynamics of the entire system and not just the individual components. While the example cited above relates to physical equipment, in our projects we are also interested in understanding how the non-equipment elements of our project planning and execution systems can interact, often surprisingly, and negatively impact HSSE, cost, schedule, and quality (operability) performance. With this knowledge, projects are equipped to make better decisions for avoiding these effects. Examples of important non-equipment project elements include work scope, changes, work quality, staff levels, staff experience, overtime, fatigue, weather, equipment availability, out-of-sequence work, time pressure, etc. To varying degrees, we all may have some experience with these interactions and side-effects. You may have decided to work overtime to get back on schedule, only to find that though you increase your work rate, in time fatigue sets in and progress slows down. At the extreme, you keep working only to discover later that the work you produced contains errors. You may also know of projects where teams decided to proceed into construction with incomplete engineering in order to stay on schedule, only to learn the construction progress suffers due to out-of-sequence work; or where staff was added to

12

compensate for a delay and the project still finished late because the experienced staff diverted their attention to training the new staff. Each of the examples cited above depict impact caused by the interdependencies and the resulting interactions of project elements in continuous feedback processes. These feedback processes are influenced by a wide range of natural or imposed delays impacting such areas as hiring, reporting, procurement, obtaining partner approvals, etc. and nonlinear relationships. An example of a nonlinear relationship, where cause and effect between project elements do not have simple, proportional relationships, is the use of overtime: while a little is effective, too much can have undesirable effects on the outcome. Another important aspect of system dynamics is the separation of cause and effect in both time and space. This means that the problem behaviour we are experiencing today in one part of the project was probably caused by a past decision or event in an entirely different part of the same project. This is especially troublesome if we cross project-team boundaries, project phases, or, even worse, multiple projects. This condition can make it more difficult for people and organizations to learn and improve. CLD modeling involves mapping the causal interdependencies of key project planning and execution elements to identify and understand the controlling feedback processes. Undertaking the CLD modeling process and utilizing its resulting model can help teams gain a common and transparent understanding of the dynamic complexities in a project. By taking the time to develop these models, project members examine and improve their collective mental models so that they will not unintentionally overlook or misunderstand the critical feedback processes that will drive actual project dynamics and outcomes. These CLD models also can be used to conceptualize, mentally test and communicate potential decisions that improve performance while avoiding the creation of undesirable, and often delayed, side-effects. Within Projects we are especially interested in identifying the potential for undesirable side-effects so they can be avoided or mitigated to achieve Risk Management objectives. The CLD model (Figure 2) illustrates how two policy choices: working overtime and spending less time on each task, can work to reduce schedule pressure in the short-term but ultimately fail due to undesirable sideeffects. The arrow indicates a causal relationship between elements: a + sign indicates there is a direct relationship while a - sign indicates an inverse relationship. The balancing loops (B1, B2) will attempt to continuously return the system to the goal. When the reinforcing loops (R1, R2, & R3) become active, they will, unfortunately, continuously drive the system away from the goal.
time remaining Work Remaining + + completion rate + productivity R1 Burnout Delay R3 Too Tired To Think B2 Corner Cutting error rate + Delay Fatigue + R2 Haste Makes Waste time per task overtime + B1 Midnight Oil schedule pressure

Figure 2

In the next issue of R3 we will discuss how SD computer modeling and simulation can compliment traditional project planning and execution tools by providing visibility and more control over project dynamic complexities. Scott T. Johnson Business Dynamics Scott Johnson is a Houston-based member of the Concept Development & Modeling Team, Projects Technology Unit, EPTG. Additional information and a range of resources to get started using CLD modeling are available directly from Scott or through the Project Dynamics Workshop he delivers through the Project Management College. For more information, contact Scott.Johnson2@bp.com.

13