Within any project organisation, inflight projects can be interrupted (preemption/shutdown) for any number of reasons. Part 2-of-2.
Projects can be shut down at a scheduled time, such as for vacations or machine maintenance, else in response to a random event, such as for equipment failures or emergency leave. Projects can also be shut down based on some other factor, for instance, when a downstream Queue is full. Shutdown is either a constant else a random value, and can be used to block the entry of additional projects while in effect.
A queuing system can be modelled in such a way that once a shutdown is in effect, the shutdown items are handled in one of four ways,
- The service can restart processing the deliverable after the shutdown ends.
- The service can resume processing the deliverable after the shutdown ends.
- The deliverable can be discarded, such as when an environment cannot be restored.
- The service can finish processing the deliverable before shutting down, such as when part of scheduled maintenance.
Shown below are three models,
- Schedule Shutdown Model: References a shutdown schedule that causes all projects being serviced to be shutdown and service will resume once the shutdown ends.
- Random Shutdown Model: References a shutdown block that has a Time Between Failure (TBF) exponential distribution with a Mean of 9 and a Time To Repair (TTR) triangular distribution of Minimum of 1, Maximum of 3 and Most Likely of 2.
- Explicit Shutdown Model: References a downstream buffer from a project activity that reaches a limit. So that the queue length will control shutdown events, the Full (F) connector from the Queue block is connected to the Shutdown (SD) input on the upstream activity block.
In project organisations, it is common to experience shutdowns. The Scheduled Shutdown and Random Shutdown models show how to shut down a project in isolation from other events in the model. Project activities can also be shut down based on model factors such as the length of a waiting line or whether another activity is in progress.
Organisations experiencing continued project shutdowns indicate there is a likely systemic upstream planning or downstream delivery failure the root cause of which needs to be investigated and resolved.
Employee breaks, equipment maintenance, inventory-taking closings and tools failure all involve interruptions to projects for a period of time called downtime. If interruptions are significant, projects should include provisions for shutting down projects to avoid overly optimistic predictions.
If you found this article informative, then please show your appreciation by liking this post.
If you would like to know more about leveraging data-driven actionable insights for your project portfolio, then feel free to contact me on firstname.lastname@example.org.