12

Managing Project Dynamics

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

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 planningand execution activities. In the next article we will expand our discussion by describing an application of a top-down SD modelthat alerted a project to delays and increased costs before they were visible through traditional project management tools.

CLD ModelingTo start, I would like to describe a recent exchange in a Startup Workshop that begins to illustrate what is meant by ‘systemdynamics’. One of our workshop discussions centered on the need for an emergency shutdown (ESD) commissioningprocedure to test the performance of a variable frequency drive (VFD). As loading the VFD during commissioning was goingto be a challenge, a suggestion was made to simply call the vendor and operators of the VFD to answer the performancequestion. This approach was accepted by everyone in the room, except for one person who advocated the project run anadditional 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 performsatisfactorily in an ESD condition,” he said. “We’ve learned many times, however, that surprising things happen…thingsnobody anticipated…when the pieces are tested while they are connected. It is the ‘system dynamics’ we are testing withthis procedure,” he added. His comment struck a chord about the importance of understanding the dynamics of the entiresystem 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 thenon-equipment elements of our project planning and execution systems can interact, often surprisingly, and negatively impactHSSE, cost, schedule, and quality (operability) performance. With this knowledge, projects are equipped to make betterdecisions 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, timepressure, etc.

To varying degrees, we all may have some experience with these interactions and side-effects. You may have decided towork overtime to get back on schedule, only to find that though you increase your work rate, in time fatigue sets in andprogress 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 tostay on schedule, only to learn the construction progress suffers due to out-of-sequence work; or where staff was added to

Figure 1

R3

13

compensate for a delay and the project still finished late because the experienced staff diverted their attention to training thenew staff.

Each of the examples cited above depict impact caused by the interdependencies and the resulting interactions of projectelements in continuous feedback processes. These feedback processes are influenced by a wide range of natural or imposeddelays 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, proportionalrelationships, 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 thatthe problem behaviour we are experiencing today in one part of the project was probably caused by a past decision or eventin an entirely different part of the same project. This is especially troublesome if we cross project-team boundaries, projectphases, or, even worse, multiple projects. This condition can make it more difficult for people and organizations to learn andimprove.

CLD modeling involves mapping the causal interdependencies of key project planning and execution elements to identify andunderstand the controlling feedback processes. Undertaking the CLD modeling process and utilizing its resulting model canhelp 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 thatthey will not unintentionally overlook or misunderstand the critical feedback processes that will drive actual project dynamicsand outcomes. These CLD models also can be used to conceptualize, mentally test and communicate potential decisionsthat improve performance while avoiding the creation of undesirable, and often delayed, side-effects. Within Projects we areespecially interested in identifying the potential for undesirable side-effects so they can be avoided or mitigated to achieveRisk Management objectives.

In the next issue of R3 we will discuss how SD computer modeling and simulation can compliment traditional project planningand execution tools by providing visibility and more control over project dynamic complexities.

The CLD model (Figure 2) illustrateshow two policy choices: workingovertime and spending less time oneach task, can work to reduce schedulepressure in the short-term butultimately fail due to undesirable side-effects. The arrow indicates a causalrelationship between elements: a ‘+’sign indicates there is a directrelationship while a ‘-‘ sign indicates aninverse relationship. The balancingloops (B1, B2) will attempt tocontinuously return the system to thegoal. When the reinforcing loops (R1,R2, & R3) become active, they will,unfortunately, continuously drive thesystem away from the goal.

timeremaining

schedulepressure

WorkRemaining

completionrate

overtime

Fatigue

productivity

error rate

time pertask

-

-+

-

+

-

- +

+

--

+

+

R3

Haste MakesWaste

CornerCutting

B2

B1

MidnightOil

Burnout

R1

Delay

Delay

R2

Too TiredTo Think

Figure 2

Scott T. JohnsonBusiness Dynamics

Scott Johnson is a Houston-based member of the Concept Development & Modeling Team, ProjectsTechnology Unit, EPTG.

Additional information and a range of resources to get started using CLD modeling are available directly fromScott or through the Project Dynamics Workshop he delivers through the Project Management College.For more information, contact Scott.Johnson2@bp.com.