WorkFlow - Overview of Managing Projects
 
 
WorkFlow can realistically simulate project performance over time because of several capabilities that are above and beyond the typical inputs of today's project management tools.
 
WorkFlow requires the following inputs:
 
  • Work breakdown for a project,
  • Dependencies among work tasks,
  • Resources required for each work task,
  • Availability of resources,
  • Management rules, and
  • Relationships among variables.
 
Work Breakdown
 
The work breakdown is often called the WBS, or Work Breakdown Structure and it represents the hierarchy of work tasks, from large tasks down to smaller and smaller tasks that make up the larger project. Furthermore, WorkFlow supports multiple projects simultaneously.
 
Dependencies Among Work Tasks
 
Each individual work task within a project often depends on the status or completion of one or more other individual work tasks. Some tasks may work in parallel, while others must work sequentially so that a later task does not start until the previous task is complete. Still others may start when only a portion of work from another task is complete.
 
Resources Required for Each Work Task
 
WorkFlow classifies resources in one of three categories: labor, materials, and work stations. Within each category, there can be numerous types. For example, you can define as many types of labor as desired and further define individual categories for each labor type.
 
Availability of Resources
 
All resources exist in facilities (i.e., a location). With each facility, you specify how many people there are in each labor type, what inventories and deliveries exist for each type of material, and the quantities of each type of work station.
 
Management Rules
 
WorkFlow allows you to specify how management will respond to various conditions and situations. For instance, you can specify that as a task falls behind schedule, additional labor resources will be added to the task to accomplish more work to get it back on schedule. Or, you might specify that as a task falls behind schedule and schedule pressure builds, the labor resources assigned to the task will work overtime to get the task back on schedule. Lastly, you can specify that as a task falls behind schedule, other (dependent) tasks that are waiting for this preceding task to finish can begin to work out-of-sequence (OOS) so that they do not also become late.
 
Relationships Among Variables
 
To incorporate feedback loops, you must indicate the relationships among several variables. For instance, you can specify that as the labor assigned to a task begins to work large amounts of overtime, the productivity of the labor begins to decrease. Or, you may specify that as a dependent task works OOS in relation to its preceding task, the OOS work causes rework.
 
The Mechanics of System Dynamics Modeling
 
System dynamics models capture the key structural relationships that define a management system. The structure, in turn, produces the dynamic behavior of interest. The resulting simulation mirrors reality because the underlying model structure:
 
  • Incorporates feedback;
  • Distinguishes between correlation and causality; and
  • Captures nonlinear relationships.
 
Feedback
 
System dynamics models explicitly incorporate the feedback relationships that define complex systems. Understanding feedback is critical for understanding and controlling system behavior. Management systems like design, production, acquisition, logistics and technology development consist of complex, non-linear feedback interrelationships. Many variables, linked in complicated webs of interrelationships, affect each other in often surprising ways. We are sometimes surprised by dynamic behavior because, without the aid of computer models, we cannot anticipate how the myriad feedback linkages reinforce or offset each other over time. Most feedback systems are too complex to yield to mental analysis. Yet understanding these feedback mechanisms is essential for effective management of any complex system.
 
Within any management program, many feedback links connect decision-making with technology, costs, performance and risk. As an example of this feedback structure, Figure 1 diagrams the key relationships within a generic WorkFlow project.
 
 
Figure 1 - Example WorkFlow Feedback Diagram
 
One would be hard put, even with the aid of the figure, to quantify how a design change that increases the amount of Work To Do (1) will impact the Labor Hours (5), Schedule Pressure (8) and Work Quality (10). Decisions concerning design alternatives involve difficult tradeoffs among cost, schedule, and performance tradeoffs that demand considerable management experience and judgment skills.
 
In many programs, the real risk of managing a production project lies in unwittingly creating a decision environment in which none of the tradeoffs appear acceptable. Actions aimed at solving immediate problems can lead to unintended consequences that create new problems while, at the same time, seeming to limit management's options. Costs and performance projections can begin to spiral out of control while the schedule inevitably lengthens. By offering a control structure to test the consequences of alternative "what-if?" assumptions and scenarios, system dynamics simulation models can help managers to avoid ineffective actions, reduce program risk and develop an affordable strategy to meet program requirements.
 
One of the reasons it is so difficult to foresee the full impact of alternative choices is that, although all of the feedback loops in Figure 1 all affect system behavior, some loops act much faster than others, and some are more powerful than others. Although each loop can affect the system over time, different loops may provide maximum leverage at different points in the production cycle.
 
A powerful loop with short delays, for example, forces change very quickly. Identification of such loops is critical for controlling system behavior. Weak loops with long delays, on the other hand, offer little leverage, and seldom respond in the short-term to even heroic management efforts. System dynamics models allow decision-makers to differentiate between weak and strong feedback relationships and identify the critical leverage points within a complex system.
 
By itself, the model structure in Figure 1 is too aggregated to address the management issues that arise in such complex processes as engineering design or shipbuilding. However, the modular flexibility of system dynamics allows model-builders to create a single structural module, test it for parameter accuracy and behavioral realism, and replicate it. The model structure in Figure 1 can be replicated dozens or hundreds of times to depict each component or subsystem in a complex design. Further, each of the submodels is interrelated -- as in the real world, the rate of work progress on any one element can be dynamically linked to the rate of progress on related elements. An extremely sophisticated model, then, may be easily developed by aggregating a large number of simpler modules. The result is a complex, but realistic model that remains easy to understand.
 
A Look at the Application Architecture
 
The WorkFlow architecture allows you to create a simulation study, and define and change model parameters for testing and analysis purposes. Figure 2 shows how the interface is initially configured with the toolbars and four windows.
 
 
Figure 2 - WorkFlow Study Window
 
The upper left window is the Project Explorer, the upper right window is the main Workspace, the lower left window is the Check Model, and the lower right is the Variable Picker.
 
Project Explorer
 
The Project Explorer gives a hierarchical “tree” view of the contents of the Workspace for easy navigation. The top-most element is always the study. The second element in the tree view lists the “what-if?” scenarios and time series viewers contained within the study. Each “what-if?” contains the products and facilities that have been added to the “what-if?”. These elements can be further expanded in the tree view to display the hierarchy of their components.
 
In the Project Explorer, any element at any level of the tree can be double-clicked and its window appears in the Workspace. Also, at any time in the Workspace, you can click on the Sync to Explorer icon in the toolbar to highlight the element in the Project Explorer that is the current active window. Conversely, you can click on any element in the Project Explorer to jump to the active window in the Workspace.
 
Workspace
 
The Workspace is the main work area in WorkFlow; it always remains open while a file is open. In the Workspace, you can create and define objects to include in the simulation, view the contents of the current study, and obtain model output. Double-click on an icon in the Workspace to open the item and display its data page in the Workspace area. Closing the Workspace closes the current WorkFlow file.
 
Check Model
 
Check Model is used to verify that a “what-If?” scenario has all of the necessary inputs to run a simulation. You click on a specific “what-If?” scenario from a list in the Check Model window and then click on Check What-If? Scenario to have WorkFlow list any errors and warnings pertaining to the selected “what-If?” scenario. You must correct all of the errors listed in order to simulate the “what-If?” scenario. You do not have to correct warnings, but sometimes the warnings point out inconsistencies in data. For both errors and warnings, you can double-click on the error or warning from the list in the Check Model window and WorkFlow opens the proper window to locate the data page containing the error or warning.
 
Variable Picker
 
A list of every WorkFlow output variable is available for selection. When you select an element in the Project Explorer, its variables are listed in the Variable Picker. If you want to save the simulation results for a variable(s), you must first click the Save box for that variable. If there is a check mark in the Results box for a variable, results have already been saved and are available for plotting. If there is no check mark in the Results box for a variable and there is a check mark in the Save box, a simulation must first be run to obtain results for plotting.
 
Creating a WorkFlow Study
 
Just as a word processor creates “documents,” WorkFlow creates “studies” that allow you to develop and manage “what-if?” scenarios for analysis and comparison.
 
WorkFlow Icons
 
WorkFlow uses icons to describe graphic representations of the study elements that you can open in the Workspace. The elements in the Workspace are nestled in the same hierarchical manner as the Project Explorer. When you add elements to the study, icons are displayed in the Workspace and the Project Explorer.
 
To open a study element, double-click on its icon in the Workspace or on its name in the Project Explorer.
 
  A Study is the top-most element of WorkFlow. Within the study you can create Time Series Viewers and “What-if?” Scenarios. This icon only appears at the top of the Project Explorer tree.
  “What-if?” Scenario – holds all data and inputs for testing and analysis purposes.
  Time Series Viewer - for displaying simulation results in graph or tabular format.
  Gantt Chart Viewer – for displaying simulation results on a Gantt Chart.
 
The two main elements of a “what-if?” scenario are:
 
  Facility(s), and
  Product(s)
 
Within the facilities and products, you can define and change many objects and parameters, such as materials, labor, work stations, productivity and schedule.
 
The three main resource elements in a facility are:
 
  Labor Type(s),
  Material Type(s), and
  Work Station(s).
 
The two main elements in a product are:
 
  Assembly(s), and
  Task(s).
 
Study Elements
 
The two major elements of a WorkFlow study (facility and product) contain the maintenance resources and product definition for a scenario. WorkFlow allows you to create scenarios containing multiple products and facilities. You can place multiple icons in the Workspace and define each facility, and product with a different set of parameters and resource sets. This capability allows you to explore, for example, how production activities are performed simultaneously in multiple locations for different assemblies or products.
 
Facilities
 
A facility contains the pool of resources that are available for use in your scenario. You can define parameters associated with the material, labor and work stations. The data from a facility is used during simulation to dynamically assign resources to the tasks defined in the product(s). Keep in mind that a facility does not have to represent a physical facility or location. A facility is simply a pool of resources that are grouped together.
 
Products
 
A product definition contains the layout of assemblies and production tasks (activities) in a product oriented work breakdown structure (WBS). This layout of the product construction simulates fabrication, assembly and testing tasks from work release to completion. The definition includes linkages that define the relationships among the assemblies and tasks.
 
WorkFlow requires the following data inputs to provide this simulation:
 
  • Work breakdown for a project,
  • Dependencies among work tasks,
  • Resources required for each work task,
  • Availability of resources,
  • Management rules, and
  • Relationships among variables.
 
The parameters associated with each product definition are used to establish the initial parameter values for the simulation.
 
Defining Management Policies
 
The inputs within the Management tab view allow you to specify how management will respond to various conditions and situations that may occur during the execution of a project. For instance, what actions does management take when a project is behind schedule? When is a project even considered “behind schedule”? Most of the inputs within the Management tab are table functions, and some are single scalar values.
 
The Management tab view has seven management functions listed on the left side of the view with miniaturized thumbnail images of the current settings for the seven functions. When you click on a thumbnail view, the designated management function appears on the right side of the view and is available for editing.
 
Table Functions
 
In general, a table function input provides you with a way to describe a relationship between two variables in the model. The independent variable resides on the X-axis and the dependent variable resides on the Y-axis. The dependent variable on the Y-axis represents a multiplier that is applied to some other variable in the model. Thus, as the independent variable on the X-axis changes values during model simulation, the table function carries out the user-defined relationship by returning a multiplier that changes the value of another variable.
 
Global Settings
 
In addition to the Facility page, the Management tab also appears on the Product, Assembly and Task pages. Thus, you have the option of defining management functions on each of these pages for each facility, product, assembly and task created in a study. Often, you will want to have a common set of management functions that apply to all activities on a project. To save you the effort of entering the same table functions and scalar values on many of these pages, management functions defined on a Facility page are considered "global" and apply to all products, assemblies and tasks assigned to that facility. You would then only have to enter the management functions for each facility created in the study.
 
Management Settings
 
 
Figure 3 - Management Tab - Management Settings
 
Management Settings inputs are all single scalar values. In general, the Management Settings indicate how quickly management recognizes and responds to certain conditions and situations on a project.
 
Average Time to Respond to Schedule Pressure (Days)
 
This setting is the delay between the time when the true schedule pressure on a task (i.e., the Indicated Schedule Pressure) reaches a certain value and the time when the people working on that project recognize that the schedule pressure has reached that certain value. With this setting, you can indicate the average length of this delay. The default value is 5 days. A value of 0.0 indicates no delay and assumes an instantaneous flow of information, which may be reasonable on small tasks but not on large tasks.
 
The Average Time to Add Rework to Backlog (Days)
 
This setting is similar to the average time to respond to schedule pressure. Often there is a delay between the time when rework is created and the time when the people working on the task recognize this rework and incorporate it into their work plans. Rework represents the unanticipated additional work generated for a task as a result of poor or imperfect work.
 
With this setting, you can indicate the average length of this delay. The default value is 5 days. A value of 0.0 indicates no delay and assumes an instantaneous flow of information, which may be reasonable on small tasks but not on large tasks.
 
Begin Out-of-Sequence Work when Schedule Pressure Reaches
 
Sets the point at which out-of-sequence work can begin based on schedule pressure. Working out-of-sequence (OOS) means that a task is working ahead of its progress dependency as defined in the Task page, Precedence /OOS tab. With this scalar value, you can specify the level of schedule pressure (which ranges from 0 to 2) that must occur for a task to begin OOS work. The default value is 1.50. A value of 1.50 indicates that when the schedule pressure experienced by the task must be greater than 1.50, resources will be applied to the task to begin work even if it is OOS work.
 
Stop Working Out-of-sequence When Schedule Pressure Drops to
 
This sets the point at which OOS work will stop based on schedule pressure. Similar to the scalar value that turns on OOS work, this scalar value specifies the level of schedule pressure that must occur for a task to stop OOS work. The default value is 1.00. A value of 1.00 indicates that, once a task begins OOS work, the task will continue OOS work until the task is back on schedule (i.e., a schedule pressure of 1.00).
 
Indicated Schedule Pressure
 
The Indicated Schedule Pressure function allows you to specify how schedule pressure is measured for a task based on the Days Remaining Ratio for the task. The Days Remaining Ratio is the ratio of Scheduled Days Remaining over Projected Days Remaining. Thus, a Days Remaining Ratio greater than 1.0 indicates that the task is ahead of schedule, a Days Remaining Ratio between 0.0 and 1.0 indicates that the task is behind schedule, and a Days Remaining Ratio less than 0.0 indicates that the task is late (i.e., past the scheduled due date).
 
The Indicated Schedule Pressure represents the true schedule pressure for a task. The actual schedule pressure experienced by the people working on a task depends on the Average Time to Respond to Schedule Pressure delay from the Management Settings. For example, a five-day average time to respond to schedule pressure indicates that it takes five more days before the people working on the task experience the same schedule pressure as the Indicated Schedule Pressure.
 
Generally, you should set the Indicated Schedule Pressure equal to 1.0 for a Days Remaining Ratio value of 1.0, which indicates that the true schedule pressure for a task is "normal" (i.e., equal to 1.0) when the Days Remaining Ratio shows that the task appears to be on schedule. For Days Remaining Ratio values greater than 1.0, you should set the Indicated Schedule Pressure equal to or less than 1.0 (i.e., normal or low schedule pressure when the task is ahead of schedule). For Days Remaining Ratio values less than 1.0, you should set the Indicated Schedule Pressure equal to or greater than 1.0 (i.e., normal or high schedule pressure when the task is behind schedule).
 
You have two options for inputting data: the graphical input area and the table input area. The graphical area displays a line that represents the relationships between the independent variable (X-axis) Days Remaining Ratio and the dependent variable (Y-axis) Indicated Schedule Pressure.
 
The table input area numerically displays the (X , Y) coordinates of the major points in the graphical input area. In the table input area, the Input column lists X-axis (Days Remaining Ratio) values and the Output column lists the Y-axis (Indicated Schedule Pressure) values. The values in the Input column are fixed and you can only change the values in the Output column.
 
Labor Multiplier Due to Schedule Pressure
 
This table function allows you to specify how management will increase or decrease the level of labor working on a task in response to the experienced schedule pressure.
 
Note: When you assign specific labor to a task, you have the option of designating a minimum labor level, desired labor level, and maximum labor level for the specific labor on the task. If the current level of labor is less than the maximum labor level, then a Multiplier on Labor greater than 1.0 will add labor to the task up to the maximum labor level. A Multiplier on Labor less than 1.0 will remove labor from the task. If the Multiplier on Labor equals 0.0 then all labor will be removed from the task.
 
Generally, you should set the Multiplier on Labor equal to 1.0 for a Schedule Pressure value of 1.0, which indicates that there should be no changes in the level of labor while the task appears to be on schedule. For Schedule Pressure values greater than 1.0, you should set the Multiplier on Labor equal to or greater than 1.0 (i.e., labor will stay the same or increase when the schedule pressure is high). For Schedule Pressure values less than 1.0, you should set the Multiplier on Labor equal to or less than 1.0 (i.e., labor will stay the same or decrease when the schedule pressure is low).
 
Productivity Loss Due to Over/Under-manning
 
This table function allows you to specify how the productivity of the labor working on a task will increase or decrease based on the level of labor working on the task.
 
Note: When you assign specific labor to a task, you have the option of designating a minimum labor level, desired labor level, and maximum labor level for the specific labor on the task. If the current level of labor is greater than or less than the desired labor level, the productivity of the labor working on the task may increase or decrease relative to "normal" productivity. You can indicate a change in productivity with a Productivity Multiplier, which is a multiplier on "normal" productivity. A Productivity Multiplier greater than 1.0 designates an increase in productivity, while a Productivity Multiplier less than 1.0 designates a decrease in productivity.
 
The Fraction Over/Under Desired Labor is simply [(current labor level - desired labor level)/desired labor level].
 
Generally, you should set the Productivity Multiplier equal to 1.0 for a Fraction Over/Under Desired Labor value of 0.0, which indicates that labor productivity is normal when the current level of labor equals the desired level of labor. For Fraction Over/Under Desired Labor values greater than 0.0, you may want to set the Productivity Multiplier equal to or less than 1.0 (i.e., there are too many people working on the task to be fully productive). Similarly, for Fraction Over/Under Desired Labor values less than 0.0, you may also want to set the Productivity Multiplier equal to or less than 1.0 (i.e., labor are not enough people working on the task to be fully productive).
 
Overtime Worked Due to Schedule Pressure
 
This table function allows you to specify how management will add overtime hours to the labor working on a task in response to the experienced schedule pressure.
 
Generally, you should set the Added Overtime Hours equal to 0.0 for a Schedule Pressure value of 1.0 or less, which indicates that management will not assign overtime when a task appears to be on or ahead of schedule. For Schedule Pressure values greater than 1.0, you may want to set the Added Overtime Hours equal to or greater than 0.0 (i.e., management will assign overtime when a task is experiencing schedule pressure).
 
Productivity Loss Due to Fatigue
 
This table function allows you to specify how the level of fatigue currently experienced by the labor impacts the productivity of the labor working on a task.
 
The labor working on a task becomes fatigued as they work more than a normal shift. For instance, if the normal work shift is 8 hours, people working on the task will begin to fatigue if they work more than 8 hours during a day. The more days that they work overtime (or the more overtime per day that they work), the more they will fatigue. Fatigue ranges from 0% to 100%.  0% represents a “fresh” person who is experiencing no fatigue. 100% represents a "burned out" person who is totally fatigued.
 
Generally, you should set the Productivity Multiplier equal to 1.0 for a Percent Fatigue value of 0.0, which indicates that a "fresh" person suffers no loss in productivity. For Percent Fatigue values greater than 0.0, you may want to set the Productivity Multiplier equal to or less than 1.0 (i.e., as fatigue increases, productivity decreases).
 
Fatigue Dissipation Time
 
When a person experiences fatigue (i.e., Percent Fatigue is greater than 0.0), it usually takes some time for that person to recover from the fatigue. For instance, if the labor assigned to a task were required to work 8 hours of overtime for 3 days in a row, the labor would not be "fresh" at the beginning of the fourth day. They would still be tired and worn out from the extra hours worked on the previous days. This would have an impact on the productivity of the labor on the fourth day. It may take the labor on average 2 days (working just normal hours) to recover from all the overtime worked or it may take them 5 days (working just normal hours). Either way, some time is needed to recover. Generally, the more that a labor group works overtime, the longer it takes to recover from the resulting fatigue.
 
You can decide what Dissipation Time should be used for different values of Percent Fatigue by asking the question: If my fatigue level were x%, how long would it take me to recover completely? For example, if my fatigue level were 10%, it would take me 3 days to recover. However, if my fatigue level were 50%, it would take me 12 days to recover. If I was totally burned out and 100% fatigued, it would take me 20 days to recover completely and regain full productivity. Generally, the Dissipation Time will increase as Percent Fatigue increases.