Need for and Benefits of Additional Real-World Project Modeling Capabilities

Project management tools provide various capabilities for modeling and analyzing projects and or a portfolio of projects, these tools provide methods for modeling tasks, their relationships to each other, e.g., finish-to-start constraints, the resources that are available, assignment of resources to tasks, calendars for resources and tasks, and various other modeling capabilities. These capabilities provide a great foundation for modeling many types of projects, and in many cases provide all the modeling capabilities necessary to execute the project successfully.

However, there are many cases where without further real-world project modeling capabilities, the human project managers will be overwhelmed by the inaccuracies of the resulting schedule during execution since so many real-world details are not taken into consideration.  For example, NASA and others have benefited from hazard constraints, this constraint allows the modeling of hazardous activities in conjunction with the activities it is hazardous to, then during execution hazardous activities will never occur simultaneously with any of the activities it is hazardous to. Without this constraint, the project manager would need to determine the order of activities during planning and put in finish-to-start constraints to control the ordering, however, during execution if the ordering should be updated the human scheduler would need to constantly check if the ordering should be updated to maximize throughput.

Another real-world project modeling capability, preference, is useful and many times necessary to maximize project efficiency.  A preference constraint can have many different incarnations. For example, there are many cases where an activity may be associated with a specific organization, such as a shop, however, it is not absolutely necessary that the activity be performed by that organization. So, a preference constraint could be associated with activities that are preferred to be done with SHOPA, but if SHOPA is at capacity and SHOPB or SHOPC is not then the scheduling tool would schedule the activity in SHOPB or SHOPC, maximizing utilization and throughput while maintaining activities in their preferred shop as much as possible.

Other types of modeling capabilities that are important include shift-based resource constraints.  For example, there are situations where work should not be performed if it is likely to span more than one shift.  Another shift-related case is for activities that do span multiple shifts, sometimes due to the nature of the activity they should be performed by some or all of the same human resources.  There are other cases, some painting situations, where if it takes more than one shift to complete completely different people can work on completing the activity.

There is a plethora of other modeling capabilities that have been found to be useful/necessary to model and execute projects efficiently.  This paper will draw from a diverse range of domains ranging from aerospace to manufacturing to pharmaceutical production to mortgage audit scheduling, demonstrating how better modeling leads to better outcomes and how generally applicable these modeling options are to most domains.

1. Introduction

Scheduling, at its most basic, is the process of assigning tasks to resources over time, with the goal of optimizing the result according to one or more objectives [1]. Scheduling is heavily used in construction, manufacturing, defense, and service industries to minimize the time and cost associated with the completion or production of small to large, simple to complex projects.

Project management tools provide various capabilities for modeling and analyzing projects and or a portfolio of projects, these tools provide methods for modeling tasks, their relationships to each other, e.g., finish-to-start constraints, the resources that are available, assignment of resources to tasks, calendars for resources and tasks, and various other modeling capabilities. These capabilities provide a great foundation for modeling many types of projects, and in many cases provide all the modeling capabilities necessary to execute the project successfully.

However, there are many cases where without further real-world project modeling capabilities, the human project managers will be overwhelmed by the inaccuracies of the resulting schedule during execution since so many real-world details are not taken into consideration.

This paper draws from a diverse range of domains ranging from aerospace to manufacturing to pharmaceutical production to medical resident scheduling, demonstrating how better modeling leads to better outcomes and how generally applicable these modeling options are to most domains. These capabilities have been incorporated into the project management and intelligent scheduling tool, Aurora.  Aurora [2][3] is a software application used by NASA, and NASA has needed and now benefits from many of these capabilities.

2. Summary of Subset of Beneficial Modeling Capabilities

This section provides an overview of modeling capabilities that have been found useful across one or more project / production domains.  Later sections provide more details on their application.

• Ability to handle physical space constraints, including considering the creation and elimination of the space during the project.

• Ability to model human resources with details beyond just an occupation, such as occupation plus a set of specializations and/or certifications.

• Concurrent Constraints – Specify that two jobs need to happen at the same time in the schedule. 

• Exclusivities / non-concurrent constraints – Specify that a job cannot happen at the same time as another job or class of jobs. 

• Preferred Resources – Specify a preference order when defining a set of resources that are mostly interchangeable. 

• Alternative Resource Combinations – Specify different combinations of requirements that could be used to complete a task, including variants with different durations. 

• Ergonomic Constraints – Consider human physical limitations.  For example, workers may have limitations on how long they can work on their knees, both in one sitting and throughout the whole shift.

• Variable Duration Jobs – Specify that a job could use more people and get done more quickly, or fewer people and get done more slowly.

• Special Manufacturing/Shift Control Properties – This is a set of properties that allows the user to control how jobs interact with shift breaks (can it go between shifts, can it go from one day to another, does it have to complete a certain length of time before a shift ends, etc.) 

• Capacity Change Constraints – This allows the user to specify a relationship between a task and a resource. Some tasks may make a resource available (e.g., adding a space zone that can subsequently be used for work), others may make a resource unavailable (e.g., installing panels that block access to a space zone). 

• Jig Support – This is specialized support that ensures that a jig is assigned to a series of work and will be retained throughout the work statement.

• Tabular Editor – Most project management tools provide some kind of tabular view.  Depending on the functionality this tabular view can be just a read-only view, or as we have found a powerful analytical tool and data transfer tool. By providing an Excel-style view into the model and schedule data, the tabular editor allows the user to easily filter, analyze, extract, and enter data. Experience has shown that a “referenced paste” feature that effectively performs a VLookup cross-referencing incoming data with data in the Tabular Editor on key matching criteria provides a robust transfer data option without perfect row alignment. 

3. Modeling Capabilities Benefiting Aviation Scheduling

Many lessons were learned due to the work we have done with The Boeing Company since about 2005 until the present. In addition, we have also learned from our work with Bombardier, Spirit AeroSystems, and others in the aviation domain.

Below we expand upon some of the enhancements that have proven valuable in providing greater transparency and increased throughput to Boeing and various other aviation clients.

Due to the nature of aircraft production and aircraft maintenance, repair & overhaul (MRO), physical space is many times an issue.  So being able to flexibly model physical space constraints in conjunction with capacity change constraints is very powerful.  So not only should the scheduler consider the competing needs for physical space to accomplish certain tasks, but the scheduler also needs to be able to understand and optimize due the physical space zones being created by certain tasks and then eliminated or made less available by others.  For example, an operation my install a panel that blocks access to a physical space zone, so if a task still needs to be performed in that area, additional tasks need to be included, at least one to remove the panel and another to replace the panel.

Expanding on the Alternative Resource Combinations capability.  Aviation has the need to model sophisticated options for resources that are required on a task.  For example, a task may require a Plumber and a Mechanic; however, there may also be Cross-trained person that can perform Plumber and Mechanic operations.  So, the resource requirements for a task could be

(Plumb & Mech) OR (Cross-trained).

For cases where the same number of people are always needed, the resource requirement could be

 ((Plumb & Mech) OR (Cross-trained & Mech) OR (Plumb & Cross-trained) OR (2 Cross-trained)).

An example of the need for the ability to model human resources with details beyond just an occupation, such as occupation plus a set of specializations and/or certifications, includes specializations that certain welders have.  For example, there may be a resource set of welders, all of whom can perform Shielded Metal Arc Welding, then there may be subsets that can also perform Gas Tungsten Arc Welding, there can also be different levels such as apprentice or master.  So, one welder may fall into many different subsets and to make a different resource set by hand for each and maintain this is overly complicated. It is better to have a dataset with the welders and the skills and let the project management tool deal with the details and allocate the welders optimally. See Figure 1 for further illustration of breaking down welders into various skillsets.

Figure 1. Occupation Skills Example for Welders

Another modeling capability important to many domains including aviation scheduling are shift based modeling.  Modeling needs may include:

• Task needs to be completed during single shift, so only schedule if this is possible based on duration of task and some % or specified time buffer amount.
• Do not start a task unless x% of time left in shift
• If spanning shifts only schedule if the same resources can be used, that is, assign the same people and possibly other resources to the tasks so it is always worked on by the same set of resources.

Ergonomic Constraints were introduced to Aurora to support the needs of Boeing originally, however, they are common across many industries. Ergonomic constraints take into consideration human physical limitations.  Limitations can include working in positions that cause strain or are otherwise uncomfortable; or may be necessary to limit exposure to something that may cause harm if exposed to for too long.  See Figure 2 for examples of work conditions that have ergonomic limitations. Aurora allows these ergonomic constraints to be explicitly tracked, and thus resources assigned so no ergonomic constraints are violated.

Figure 2. Ergonomic constraints – individual limitations on work conditions

4. General Dynamics Electric Boat

Other modeling lessons have been learned from our experience working with General Dynamics Electric Boat (EB) for the scheduling of various aspects of submarine construction.

EB has some of the most sophisticated fabrication capabilities in the world, however, to increase efficiency sometimes it is best to outsource/farm out less specialized work.  EB had benefited from graphical and tabular reports that help the user determine what is best to outsource. Specifically, productivity has been enhanced via a convenient interface for visualizing what tasks can be outsourced and providing a one-click option to outsource a task that also adjusts the actual model appropriately, see Figure 3.

Figure 3. Farmout /Outsource interface

When an operation is outsourced to a vendor, the scheduling tool now sees these tasks as started, and they do not consume any internal resources and the previously determined end time for the tasks is now the promised delivery date from the vendor.   So, by automating this functionality the model does not need to be manually edited, eliminating the potential modeling errors that might occur during the manual update process.

Electric Boat, as well as others, need to schedule various jigs / fixtures that may be used independently and in conjunction with other jigs. For example, certain types or specific jigs may be required to support a sequence of tasks, however, certain jigs may be released during the sequence, these may be used for other tasks if the scheduler can determine the released jigs will be available again when then are required for the sequence of tasks that are not to be interrupted.

5. Preference Constraints Example Mortgage Audit Scheduling

Mortgage auditing is routinely performed on lenders to guarantee that mortgage approvals are appropriate and unbiased. A large mortgage auditing company may perform thousands of audits for dozens of clients in a given week. Each audit goes through multiple synchronized steps, and all steps must be completed by a hard deadline. There are a number of constraints on how those audits should be allocated to auditors to create a schedule: Training: There are a wide variety of mortgage types, and audits must be assigned to personnel with the correct training; Consistency: Assignment of a consistent, minimal subset of auditors is advantageous; and Thoroughness: At least two auditors are required.

Some of these constraints are soft (e.g., using consistent auditors for a client, or preferring a small number of auditors), while others are hard (e.g., training requirements or deadline satisfaction), the soft constraints are an example of Preference Constraints.

Providing the capability to model Preference Constraints greatly complicates the scheduling process, which shows why most project management tools do not provide the option. To demonstrate one technique to handle these preferences efficiently is to model a queue for each auditor, with logic to determine on which day a given audit will be completed. By populating this queue in due-date order, starting with the most preferred formulation but shifting work based on a variety of heuristics, the scheduler is able to quickly find a solution that maximizes the soft/preference constraints, (while still satisfying the hard constraints). In this case, the customized Aurora software solution allows automated scheduling of thousands of audits, a process that used to require a human scheduler to devote a person-day to each week. Because it is automated, Aurora can also update the schedule as frequently as needed to support rapid adaptation to changing circumstances.

Figure 4 shows one of the custom interfaces developed to show the human auditor schedules; the team assignment display that dynamically shows the auditors who are considered acceptable for the client.

Figure 4. Team assignment display

6. Benefits To NASA

All of NASA has access to the capabilities described above via the Aurora software that NASA has licenses to.  Many of the capabilities illustrated are partially the result of modeling capabilities that NASA needed also, to wit many of Aurora’s capabilities have evolved directly from working with NASA, some from other implementations and many result from both NASA in conjunction with other implementations.

Hazardous Constraints are a good example of evolving from multiple sources. Aurora already had the concept of both concurrent constraints and non-concurrent constraints as described previously.

Figure 5 shows non-concurrent constraint for tasks A, B and Figure 6 shows concurrent constraints for task B, A, & C.

Figure 5. Non-concurrent tasks

Figure 6. Concurrent tasks

The Aurora-KSC [4] implementation of Aurora added the capability to mark activities as being ‘hazardous’ to other activities, (KSC means Kennedy Space Center).  The result of such a hazardous marking means that Aurora will never schedule the hazardous activities to occur simultaneously with any of the activities it is hazardous to. Thus, the hazardous constraint is a variation of the non-concurrent constraint. Graphical enhancements now allow for hazard activities to be denoted in the PERT Chart, with special arrows (color and style can be customized) emanating from the activity causing the hazard and pointing to the activities affected. Figure 7 illustrates hazardous constraints.

Figure 7. Hazardous constraints shown with red arrows

7. Beneficial Execution and Iteration Support Capabilities

An operational scheduling system needs to work well for

• planning ahead (scheduling in the future),

• execution (scheduling something that is in progress),

• iteration (taking execution information from earlier projects and applying that to later projects).

In addition, it is beneficial to provide support to help respond to critical model updates (e.g., emergent work) while preventing churn. Below are some capabilities that support the above that have proven very useful in real-world situations.

• Stable Schedule Mode – Provides a mode that prefers to retain the previous schedule, with the minimum updates necessary to incorporate emergent work or updated resource availability. This permits updates to take new data (e.g., emergent work) into account while avoiding churn.

• Resource Constrained Critical Path Analysis – The user can analyze the Resource Constrained Critical Path Analysis of the whole schedule or a subset of the schedule to better understand what is preventing the schedule from being shorter. This is both a valuable execution and a valuable analytic tool.

• Actuals Analysis – The user can analyze the actuals (what actually happened when) against the model to mark constraints that were not satisfied (e.g., a successor started before a predecessor was completed). This makes it easier to update models for greater accuracy in the future. 

8. Beneficial Analytics

A variety of additional analytic features help project managers better understand their model and schedule.

• Upstream/Downstream Task Analysis – These analyses start with a given job or jobs and walks up/down the network to find the jobs it is dependent on, or the jobs that are dependent on it. The upstream analysis can help in understanding a key task and what it is dependent on; the downstream analysis can help in understanding a key task and what is impacted by it. 

• Point-to-Point Analysis – This finds the path through the network from the first task to the second task (if there is such a path). It can be valuable for analyzing a subset of the network that is connected (e.g., all the work linking Milestone 1 and Milestone 2). 

• Sensitivity Analysis – If duration distribution information is provided then sensitivity analysis may be used to explore what would happen to the schedule if certain key jobs are faster than expected or slower than expected. 

• Monte Carlo Simulation – This takes advantage of duration distribution information to simulate multiple executions of the schedule to show how things are likely to play out. This provides insight into how brittle the schedule is, how likely it will be to run late, etc. 

• Schedule Explanations – In the course of scheduling, Aurora captures a variety of information about why things scheduled the way they did.

• API – Since various other tools provide a myriad of other analytic capabilities, any project management tools should  provide many options to share information.  In our experience  a programmatic API that can be used to exchange entire model data or programmatically load data, has proven incredibly useful in many situations.

Figure 8 shows an example of the Explanation capability in Aurora.

Figure 8. Automatically generated explanation

The text shown in the explanation box is:

The end date was affected by the maximum flow time of 7300.00 days, which set to 12/27/2033 00:00

The start date was affected by Hypergol Servicing for Booster Aft Skirts(s), which set it to 01/03/2014 00:00

The end date was affected by Establish Hazardous Control Area for Ordnance Ops, which set to 12/25/2033 10:49

The start date was affected by Hypergol Servicing for Booster Aft Skirts(s), which set it to 01/04/2014 22:00

The start date was affected by ForwardSchedule, restricted by availability of Hazardous Pad-1: waiting for Pre-Ordnance Operations for Orion Pyro Safe and Test Panels, which set it to 01/05/2014

The end date was affected by ForwardSchedule, based on duration and start time, which set to 01/05/2014 15:00

As shown in the figure the explanation capability shows the rationale for why every task is scheduled where it is, that is, each task includes the reasons why it is scheduled at its current time. This is a powerful capability that provides transparency into why the schedule is scheduled the way it is and builds trust by the users.  What is usually seen is that the start date may be affected by a start-no-earlier than constraint, then the start date may be later due to one or more predecessors not completing until later, and then finally the actual scheduled start date may be further delayed due to a particular resource not becoming available until after all the predecessors have completed, since the constraining resource will be released by a non-predecessor task.  Thus, the explanation capability has proven very valuable in understanding why a project cannot be completed more quickly. This information can then be used to determine whether reformulating some aspects of the model may permit a faster schedule, or why a bottleneck is constraining the overall throughput.

9. Conclusions

Stottler Henke has had and continues to have the opportunity to work on some of the world’s most complex scheduling challenges with organizations ranging from NASA to Boeing, to Pfizer, to Spirit AeroSystems, the US Air Force, General Dynamics, Los Alamos National Laboratory, amongst others.  Most project management and scheduling tools provide a good foundation of modeling and analysis capabilities, this foundation is unfortunately inadequate in many real-world situations.  Also unfortunate is that it is not easy to discern how inaccurate the model and analysis is when the required capabilities are absent. Thus, it is not clear how inaccurate one’s model and analyses are until experience during the execution phase reveals that the project management results are not accurate.

The human project managers try to deal with these inaccuracies, by constantly having to adjust the schedule during execution.  However, since the model does not accurately enough consider the real-world situation future predictions regarding how the rest of the project will progress will still be inaccurate.

Experience has demonstrated the real-world need for and the diversity of Preference Constraints, and without this modeling capability project efficiency may be severely degraded.  A preference constraint can have many different incarnations, ranging from preferring a more experienced worker in certain situations to preferring one type of machine versus another. The result of having a preference constraint might allow two tasks that both prefer a certain skill level or machine to occur in parallel since the other task may still be allowed to work with the less preferred option. Specifically, the task on the critical path might get the preferred resource, will a task that has few downstream dependences might be allowed to use the less preferred resource since of the duration is longer than expected or some re-work is needed this has little chance of affecting the overall project duration in the negative, while doing the non-critical work with the less preferred resource is likely to benefit the project throughput.  Without this capability, the resources have been unnecessarily idle, and the project completion could be delayed.

Of course, there is always a balance between the amount of detail in a model and what should be left to the human project managers and schedulers.  There are so many variables in real-world situations that we need to strike the correct balance between computer modeling and human knowledge.  The goal should be to allow the humans to model in the project management / scheduling tool to the level of detail they determine is best, which then frees the humans to perform higher value project management and scheduling.