Maintenance, Inspection Results and Project Schedule
Submarine and other types of complex maintenance operations, such as aircraft maintenance, occurs in a dynamic environment where although individual projects start and end (e.g., the maintenance of a particular submarine with its subsequent return to the ocean), the individual projects occur in a multi-project environment that leverage many/all of the same resources. Therefore, when a new project is introduced with its subsequent planning and scheduling, this will occur and thus be affected by the current mix of other projects occurring or planned to occurring during the time of the individual project of interest.
All projects do not execute to the original plan, however, complex maintenance operations projects have all the normal variation of most projects, but then also necessarily include another layer of variation due to of maintenance tasks not being fully understood until an initial inspection occurs for certain parts (e.g., pumps, hydraulic equipment) that can not occur until the submarine is in port and the part can be removed from the vessel and inspected.
Some of the complexity and sources for variation can be see in the graphic below.
When planning for an availability or avail (the name given to a submarine maintenance project), the Preventive maintenance is known and much of the Corrective maintenance is know. The Corrective maintenance is partially known since the submarine can inform the depot about failures while still deployed. Therefore, the planning of the maintenance schedule can be started with this information.
However, both preventive and corrective maintenance may include and inspection phase. The results of the inspection determines the details of the maintenance and thus the tasking for the maintenance. That is, the level of effort and the associated number and duration of the tasks can vary significantly depending on the results of the inspection.
For planning purposes a
for the maintenance steps of items that require inspection before a final set of tasks is used to build an initial schedule. The template may be optimistic or pessimistic, that is, the prototypical situation may be the most routine / shortest maintenance possible (optimistic) or the longest maintenance possible (pessimistic). So when the inspection occurs, the result will be:
- the prototypical template being retained as the actual set of tasks used for the executed schedule (which should happen most of the time since the template is prototypical)
- replacement of the template with an apropos set of tasks required to complete the maintenance.
Any additional maintenance discovered after the initial schedule is developed (such as after the submarine is in port and the work has started) will be injected into the project as new tasks.
Once an initial plan is developed using the knowledge available to date, it needs to be inserted into the ongoing set of projects of the overall multi-project environment. The plan will include the technical relationships between tasks and the resource requirements for the tasks. Due to the resource requirements and the fact that all the projects utilize the common pool of resources, each project affects the scheduling of all other projects.
When a new project is inserted into the dynamic multi-project environment many what-if analyses may be required before the best overall balance of goals is achieved.
The following steps can be used to perform What-ifs until a satisfactory result is generated.
- Use the latest update of the executing multi-project environment as the basis for the what-ifs
- Insert the latest version of the new avail’s plan into the current multi-project schedule.
- Save this configuration as the basis for what-ifs
- Set restrictions on the changes that can be made to the other projects and/or set or change priorities of the various projects.
- Re-schedule the multi-project schedule.
- Review the results
- IF the results are satisfactory, THEN use the new schedule as the new master multi-project schedule to be used for current and future execution.
- ELSE the results are not satisfactory, so continue to the next step
- Dealing with unsatisfactory results (there are many reasons for unsatisfactory results)
- A common result will be that the new multi-project configuration will NOT be able to schedule with the current constraints. For example, if the new project is desired to be completed in a month and the current projects are also restricted in duration, there may not be enough resources to complete all the tasks in time to meet all the deadlines. In this case, various options can be tried to make a viable schedule, including
- extending the allowed duration of a project
- eliminating Jobs that can be delayed until a later avail
- increasing the resources on shifts, such as night or weekend.
- The new multi-project configuration may be able to schedule but the results are still not satisfactory. Why? Because the Aurora model does not include all knowledge regarding the real world, so there are reasons to leave as much flexibility in the model as possible so Aurora can find options.
For example, a Job might be gated by a delivery, the delivery is scheduled to occur on a certain date but after that date the Job depending on the delivery is delayed because Aurora determines that the efficiency of the overall schedule is better if resources for that Job are used for other Jobs first. By changing the priority of the Job and rescheduling the Job after the delivery might now be worked immediately after the delivery, and the decrease in overall efficiency may be found to be small, so after the change the is considered to be satisfactory.
- At this point a satisfactory result has been accomplished and this new model for the multi-project environment becomes the master.
During execution there are two major types of variability that will be discussed here:
- Variability in the duration of tasks versus the duration used during planning.
- Variability in the ACTUAL tasks used in execution versus the tasks of the initial plan.
This section discusses how to deal with the second type of variability, which will be referred to as inspection-based variability.
As discussed above, actual tasks may vary from the initial plan because
- the details of many Jobs are not known ahead of time due to an inspection being required, and only after the inspection can the work and thus tasks required be fully understood
- there may be additional corrective maintenance required then planned for because this corrective maintenance is not discovered until after the submarine is in port.
The level of change to the overall multi-project environment cased by inspection-based variability is not as large as that caused by inserting a new project. After an inspection occurs only those situations that are found to be different from the prototypical situation, will even have a modification. In addition, there may be situations where the inspection find a situation that requires less work than in the initial plan.
Additional corrective maintenance will always result in new tasks and thus the end date of one or more projects.
Depending on the affect of inspection-based variability what-if analyses may or may not be required.
The steps to perform for the What-ifs are similar to those shown above, just re-word (2) above to read
2. Modify the prototypical template with the
new set of tasks based on the results of the inspection, or
insert the new tasks per the additional corrective maintenance.