Project Management (PM) Modeling Capabilities for Increased Submarine Production and Maintenance Throughput

Submarine production and maintenance has benefited significantly from more detailed project management modeling capabilities allowing for more accurate scheduling during planning and execution. Project management tools provide various capabilities for modeling and analyzing projects, including methods for modeling tasks, their relationships, e.g., finish-to-start constraints, calendars, assignment of resources to tasks, and deadlines. These capabilities provide a great foundation for modeling many types of projects, but they often fall short of capturing enough real-world details especially with regard to submarine production and maintenance projects in order to maximize throughput.

That is, without further real-world project modeling capabilities project managers in complex domains, including submarine production/maintenance, are overwhelmed by the inaccuracies of the resulting schedule during execution resulting in delays. This paper explores modeling capabilities that bridge this gap, many of which have been developed and used through collaboration with General Dynamics Electric Boat and the US Navy’s Naval Submarine Support Facility.

Beneficial modeling capabilities include: hazard constraints, progress-based lead and lag constraints, maximum lag constraints, preference constraints, ability to handle as-soon-as-possible and as-late-as-possible tasks in the same project, shift-based constraints, resource definitions and assignments based on occupations plus skills/certifications; and risk analysis that can be performed on models using all the advanced capabilities.

By presenting these advanced modeling techniques and their practical applications, this paper aims to bridge the gap between idealized project plans and real-world execution complexities. These capabilities offer benefits that maximizes the throughput of complex projects such as submarine production and maintenance.

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 submarine production and maintenance to aircraft manufacturing to pharmaceutical production to various space related scheduling, including for NASA, 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 General Dynamics Electric Boat (GDEB), and GDEB  now benefits from many of these capabilities for submarine production.

2. Summary of Subset of Beneficial Modeling Capabilities

This section provides an overview of modeling and other 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. 

• Shift Related Constraints – This is a set of constraints 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, can it only start only if a certain length of time before a shift ends is available, 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). 

• Mixed-mode scheduling  – Providing both as-soon-as-possible (ASAP) and as-late-as-possible (ALAP) scheduling, available on a task-by-task basis. Sometimes it is important to have certain tasks scheduled as early as possible, while in the same project, other tasks should be scheduled as late as possible, for example, complete as much of the project as possible before taking delivery of a very expensive piece of equipment that needs to be installed as part of the project.

• 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 Submarine Production & Maintenance Scheduling

Many lessons were learned due to the work we have done with General Dynamics Electric Boat as well as the US Navy for both submarine construction and submarine maintenance.  Many similar lessons apply to our work in the aerospace domain, including with The Boeing Company, 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.

Due to the nature of submarine production and maintenance as well as 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 re-install the panel.

Expanding on the Alternative Resource Combinations capability.  Many times, there is a 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 are shift-based modeling constraints.  Modeling needs may include:

• Task needs to be completed during a 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

There are other modeling lessons that have been learned from our experience working with General Dynamics Electric Boat (GDEB) for the scheduling of various aspects of submarine construction.

GDEB 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.  GDEB has 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

Possibly, the overall concept of preferences and the lack of their availability in project management tools is the largest contributor to project plan brittleness during execution. An initial plan may be better thought of as a guideline that will obviously need to be changed through time. The entire project plan is the best guideline that can be developed at the time of planning.  Just as one may need to improvise during small projects, e.g., I prefer the appropriate socket size with a rachet to tighten a bolt, if I find it is missing from my toolbox, it may be best to improvise with a crescent wrench or a vise-grip locking pliers, instead of stopping to go to the store to purchase a socket set; projects of all sizes need to adapt to the reality of the current situation to determine how to best move forward.

Of course, one cannot plan for every contingency, so a balance needs to be determined regarding which preferences or options should be modeled and which ones are best left to human decision-making.

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. In this case, a preference constraint could be associated with activities that are preferred to be done with SHOP_A, but if SHOP_A is at capacity and SHOP_B or SHOP_C is not, then the scheduling tool would schedule the activity in SHOP_B or SHOP_C, maximizing utilization and throughput while maintaining activities in their preferred shop as much as possible.

Another example from our work with General Dynamics Electric Boat (GDEB) consists of scheduling various aspects of submarine construction. There is a vast number and variation of components that flow through the machine shop. Oftentimes, the components needed for an assembly will have a long lead time say, for example, up to six months. These components normally need to go through many different processing steps before they are considered complete, this may include milling, lathing, work in a multi access CNC machine, and welding. The part may be worked on by one machine and then there is a delay before it can be worked on again. GDEB has a preference that the delays between operations should not be “too long,” In addition, the overall time that a component takes to flow through all its steps should also not be “too long.”  Working with machine shop personnel, Aurora was adapted to balance the need for overall potential throughput with keeping components, once started, flowing through the process at least as fast as the preferred as determined by the actual machine shop personnel responsible for scheduling.

A related situation that occurs in the same GDEB shop is changing the preference for future work on components used in the same assembly if the assembly process has been started before all the components have been fabricated. That is, some assemblies may consist of a large enough number of components that work can be started on assembling the components into a complete product even though all the components have not been manufactured.  This occurs to keep the assembly workers busy and/or to increase the speed that the final product will be ready. The planning model is built so that all the components are predecessors to the assembly task(s). If the assembly is started before all the components are completed, then all the unfinished components make the assembly task(s) violate the predecessor-successor constraints.  To handle the situation, the default configuration is defined as a preference, but if the assembly process is started, this will trigger the other option, in this case what occurs is: 1) the remaining components have their successor changed to the completion of the assembly milestone; and 2) the priority of the remaining components is increased.  The priorities are increased, so that, if an assembly is started, it is normally desired to have it completed sooner rather than later.

Providing the capability to model Preference Constraints greatly complicates the scheduling process (for the software), which shows why most project management tools do not provide the option.

As the project modeling capability expands, there is also a need to enhance the visualizations available to better comprehend the project model.

There are many types of constraints that may be required to best model the project, so there needs to be options to distinguish them and to have the option to show or hide.  See Figure 3 that provides options for displaying the various constraints and coloring and formatting to visually distinguish between the various constraint types including Preference constraints.

Figure 4. Constraint Display Options

6. Capabilities Used in Many Domains

Besides some version of preference constraints, Concurrent and especially non-concurrent constraints are a good example of a capability found to be useful almost universally.

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

Aurora already had the concept of both concurrent constraints and non-concurrent constraints as described previously. An Aurora version initially build for NASA’s Kennedy Space Center, Aurora-KSC [4] added the capability to mark activities as being ‘hazardous’ to other activities.  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 various graphics, 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 were 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. See the section below on Monte Carlo Simulation for more info.

• 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. Monte Carlo Simulation

Monte Carlo simulation 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 by assessing the impacts of various risks on project cost and timeline, thereby helping identify potential schedule and cost overruns.

Aurora provides both infinite resource and limited resource Monte Carlo analyses. One of Aurora’s most powerful capabilities is to solve the NP-hard problem of resource-loaded scheduling more optimally than other solutions, while the solution time grows linearly with the size of the project [2][3].

The most important consideration is that, if a project uses ANY of the capabilities of Aurora that is not available in other Monte Carlo simulation tools, then the results will be incorrect. This is the main reason Monte Carlo analysis is provided in Aurora since users of Aurora almost always use some unique capability of Aurora and thus would be prevented from receiving the benefits of accurate Monte Carlo analysis.

To this end, one now has the option of building much more realistic models that adapt more correctly to real-world changes and then simulating these changes realistically and rapidly even when considering full resource-loaded schedules. Figure 9 shows the Monte-Carlo Simulation Options dialog for Aurora.

Figure 9. Monte Carlo Simulation Options

10. 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 General Dynamics Electric Boat to Siemens, to NASA to Boeing, to Pfizer, to Spirit AeroSystems, to the US Air Force, to Los Alamos National Laboratory, amongst others.  Most project management and scheduling tools provide a basic 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 far from 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 to consider the real-world situation, future predictions regarding how the rest of the project will progress will still be inaccurate.

For example, experience has demonstrated the real-world need for Preference Constraints, and without this modeling capability project efficiency in many cases is 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. Remember Occam’s Razor, −entia non sunt multiplicanda praeter necessitate. The balance may have been better articulated as “Make everything as simple as possible, but not simpler”, Albert Einstein. 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.