Background and Introduction
Project managers frequently work in environments of uncertainty. Managing a project is fraught with dynamics beyond the project manager’s control, yet sponsors are focused on project execution and results (Project Management Institute, 2021; Bentahar et al., 2023). Additionally, project managers must communicate the schedule, budget, activities, requirements, and other project-specific details to the team and other stakeholders. The key consideration is identifying focus areas for the project manager to avoid disruption (Fleming & Poole, 2016).
Historically, project managers divide the initiative into discrete work packages. This decomposition helps segment the work into minor activities, which can then be independently estimated to determine requirements, acceptance criteria, projected costs, and task durations. The development of the work decomposition is known as a work breakdown structure (WBS), which is used to define the work to be accomplished during the initiative’s execution (Lin, 2008). Additionally, the WBS can communicate the strategy for executing the work.
During the initiation, the project manager proposes the initiative to the sponsor, who will approve or disapprove the project charter (Project Management Institute, 2021). At this point, the project manager might have questions from their sponsor concerning costs and duration (Project Management Institute, 2019). Historically, this has been a very difficult-to-address question for project managers for numerous reasons. Some project managers do not account for risk costs properly, so they go over budget (Smart, 2020). Some project managers develop the schedule very aggressively, making their initiative more susceptible to schedule overages (Lorko et al., 2021).
This article proposes adapting known systems engineering methods toward an easy-to-use method of enabling project managers to respond to the questions posed by sponsors. It is the desire of many sponsors to have the project manager quantify the likelihood of the initiative going over budget and/or over schedule.
Project Planning
In predictive (also known as waterfall) project management environments, project managers sequence the WBS into a project network diagram. This document is used to communicate the project work, budget, and organization of the project to the project sponsor and stakeholders (Fleming & Poole, 2016). The WBS is developed by subdividing the work tasks into elements called work packages. Each work package represents a task, requirement, deliverable, or other logical subdivision of the work needing to be accomplished. By breaking the activities into work packages, the project manager can understand the tasks, resources, and durations related to each component of the work, which also provides a basis for estimating and monitoring execution (Project Management Institute, 2021).
The WBS elements can further be defined with the WBS dictionary. The WBS dictionary contains more detailed information concerning the work packages with relevant details such as requirements, individuals who are responsible for the work to be completed, the expected duration, risks, budget, and other information the project manager deems necessary to communicate the intention of the work in the work package. The project manager can use this information to develop a baseline (likely communicated via a Gantt chart) for the expected work. From this baseline, the project manager can communicate their vision for execution (Fleming & Poole, 2016).
Estimates concerning cost and schedule for each work package can be developed from the top down, estimated by a subject matter expert (SME)/executive or sponsor, or from the bottom up, by the individuals performing the work. In either case, the duration and financial requirements for the work package are determined (Larson & Gray, 2021).
After the work packages have been completely defined, the project manager can begin to sequence the project network by moving work packages to represent a logical sequence respecting task interdependencies and other work package-specific requirements (Littell, 2022). For example, several work packages might require the same large piece of equipment. Therefore, the project manager might want to consider this as a constraint and develop the project management plan around this constraint so that the required equipment can be utilized synergistically to execute the related work packages.
The Gantt chart can be developed once the project manager has sequenced the work packages into the project network. The Gantt chart is used to graphically communicate the timeline with task durations and interdependencies and is frequently used as the schedule to be communicated to the project sponsor and stakeholders (Littell, 2022).
A Reliability Approach to Project Management Confidence
If one considers a project as a system comprising the work packages and the sequencing of those work packages, one can gain insights into tools common in the systems engineering world. As Islam & Rokonuzzaman (2009) pointed out, the WBS and subsequent project network and Gantt chart are used in both systems engineering and project management. From this realization, the author applied a systems engineering tool, reliability calculations, to the project network to determine the reliability of the project network as though it were a system composed of parts. For example, if one considers a work package as a system component, one can also consider sequential work packages as a product sub-assembly. Suppose one considers that the project plan (Gantt) operates as a system, and that system is dependent upon the successful execution of each part (work package). In this case, one can then utilize standard reliability calculations to determine the percent likelihood that the as-designed project management plan can be executed without failure. In this instance, the author defines a failure as the complete execution of a work package exceeding the allowed duration or budget.
The capability described provides the project manager a new way to present data to their sponsor and stakeholders. Project managers commonly refer to an aggressive schedule as having a sensitive project network (Ballesteros-Pérez et al., 2019). By stating that the network is sensitive, the project manager is communicating that multiple work packages lie on the critical path of the network. This means that if any of the tasks involved in the critical path are delayed, the entire project will be delayed by that amount.
From a reliability perspective, the project manager must understand that these calculations are based on work packages failing or not failing. A failure in this context would result from exceeding the planned budget or duration for that specific work package. Therefore, the calculations described in the following sections do not determine the extent of the failure, only the likelihood of failure.
Series Reliability Calculations
When calculating the reliability of a system, the individual must first determine the reliability of each component of that system. Then, they must multiply these likelihoods of success together to determine how likely the system is to work as planned without failure of any component. One assumption is that the failure of one work package is statistically independent of the failure of any other work package. That is, the failure of one component does not increase or decrease the likelihood of another component to fail. When these reliabilities are calculated, one can see that the reliability of the project network is less reliable than any of the individual work packages (Krueger, 2022). For example, consider a simple system comprising five components, as illustrated in Figure 1. The first component has a 95% chance of working, the second has a 90% chance of working, and the third, fourth, and fifth components have an 85%, 90%, and 80% chance of working, respectively.
An example project network with the percentage likelihood of success at each work package.
The formula for determining the reliability of this system is executed by multiplying the determined.
Multiplying all the percentages likely determined for each part yields the total likelihood that the system will work as without a failure. In this case, it is (.95)(.90)(.85)(.90)(.80) = .52. This is interpreted to mean that with the stated reliability for each item in the system, this system is 52% likely to work without failure.
Parallel Reliability Calculations
Parallel processes can be accommodated by simplifying the reliability calculation for each parallel segment into one reliability calculation and then performing the reliability calculation across each process component as though it were in series (Krueger, 2022). Figure 2 illustrates a hypothetical project network with parallel activities.
An example of a parallel project network with percentage likelihood of success at each work package.
The first step is to calculate the reliability of each part of the process, which is parallel to the other legs of the network diagram. For this example, illustrated in Figure 3, the author designates the three parallel legs as B, C, and D, as indicated in the task ID for each work package. For example, tasks B.1, B.2, and B.3 indicate that these three tasks compose one parallel leg of the process.
An example of a parallel project network with percentage likelihood of success at each work package consolidated to a series network.
Next, calculate the simplified project network as though it was in series as illustrated in Figure 3.
This yields approximately a 27% chance that this process will work without failure.
How These Calculations Can Be Used By a Project Manager
For the project manager, these calculations can be helpful to address the sponsor’s questions of how likely this initiative is to go over budget or over schedule. To employ this methodology, the project manager can evaluate each work package to determine the likelihood that that work package will be completed on time. Once these percentages have been determined, the project manager can determine the project network reliability, which yields the likelihood that the project will succeed or fail. This methodology can be used to calculate the system’s reliability to achieve both the planned cost and schedule, as illustrated in Figure 4.
An example of a parallel project network with percentage likelihood of success at each work package with schedule (S) and cost (C) included.
In this case, the author has added a schedule of percentage likelihood for the successful completion of each work package, as indicated by S.XX. Likewise, a cost percentage determines how likely the work package is to be completed within the planned cost for each item, as indicated by C.XX. When these items are included, the project manager can now easily calculate the percentage likelihood for this project to exceed the cost or the schedule.
Calculating the percentage likelihood that the project will meet the schedule:
Calculating the percentage likelihood that the project will meet the cost requirements
Limitations
It is essential to recognize that this method does not predict project success or failure. Instead, it can be used to indicate which work packages are projected to be executed within the limits set by the project manager. This analysis does not respect the severity of overages; it only predicts the likelihood (reliability) of successfully executing the work packages as planned. This methodology also assumes that the failure rates of work packages are not correlated with the failure rates of any other work packages.
One weakness of this type of analysis is that it relies on honest input toward the confidence percentages for each work package. Because these percentages are predictions, the total calculation can be based on incorrect assumptions. One way this could be partially mitigated could be through a three-point (PERT) estimation methodology.
Another weakness of this type of analysis is concerning larger projects. As projects increase in duration and budget, the number of work packages also increases. If a project becomes large enough, the reliability of this type of analysis can approach 0, even if each element has a minimal likelihood of failure. For example, a project with 10 work packages, each with a reliability of .99 (meaning that they are 99% likely to be executed without exceeding time/budget), is still only 90% likely to be executed without exceeding the schedule/budget. With 20 work packages at 99% likelihood, the system reliability drops to 82% likelihood of the project being executed as planned. While these dynamics are likely accurate (although probably depressing), the project manager should know this dynamic to explain the phenomenon to a potential sponsor.
For this reason, the project manager might consider running a reliability analysis on only the project’s critical path(s), as any overages on these work packages will delay the project. This methodology could reduce noise in the calculations by neglecting work packages that have slack built into them by virtue of the project network. If the project manager is more interested in the cost components of the project, the project manager must consider the entire project network, not only the critical path.
The above recommendation would not apply if the project manager were interested in using the reliability calculation to calculate the likelihood that a project would be accomplished without any work package going over budget. That is, the project manager typically has tools that can be employed to recover time in networks with slack built into them. The budget aspect of the project network does not have slack. The budget is specific to the entire project, where the critical path determines the project’s overall duration. Therefore, reliability calculations applied to the project budget must include all work packages. If the project manager were to apply the reliability calculations to the project network and include work packages not on the critical path, the reliability of non-critical work packages would artificially damage the reliability calculations of the project as a whole.
Additionally, the project manager must understand that this type of analysis assumes that the project manager does nothing to intervene to remediate any overages. The project manager factor is a critical one for the success of the initiative, and most project managers have variables that can be manipulated to mitigate a poor-performing project.
Quantification of risk is another dynamic to consider for this type of analysis. Usually, risk calculations and risk budgeting are executed outside of the WBS. Therefore, this type of analysis would only consider risk as a component of the analysis if it is built into the WBS. Project managers are encouraged to review their risk register and appropriately incorporate risk relative to time and/or budget into the WBS to incorporate these items into the reliability calculations. If this is not possible, the project manager must be conscious of this dynamic to incorporate it into the project management plan as a separate item.
Another dynamic of this type of analysis is that, as the work packages are completed, they fall away from the reliability calculation. For example, as Task A, Task B.1, Task C.1, and Task D.1 have been completed, as illustrated in Figure 5, they should be removed from the calculation as they no longer contribute to the reliability calculations for the project network. The initial calculations determined that the project is 26% likely to meet the schedule and 74% likely to meet the budget. At this point of the project, these calculations could be recalculated, where it can be determined that there is a ∼38% chance of meeting the schedule and a ∼82% chance of meeting the budget.
An example of a parallel project network with percentage likelihood of success at each work package in a partially complete project.
Calculating the percentage likely that the project will meet the schedule:
Calculating the percentage likely that the project will meet the cost requirements:
Discussion
Viewing the WBS/project network as a system and evaluating the system’s elements as components of that system enables the project manager to utilize reliability calculation methods to quantify how likely the initiative is to meet both the cost and schedule as planned. Through these calculations, the project manager can respond to questions such as how likely this initiative is to meet the planned cost and schedule, and the calculations can provide the project manager with a tool to discuss how to make the project plan more robust.
For example, the project manager might seek to develop a project plan that has an 80% likelihood of being executed within budget and schedule. If the reliability calculations reveal this is not possible, the project manager can quickly adjust the project scope and schedule and recalculate by adjusting the percentage likelihoods for specific work packages. The project manager can then act to implement mitigation measures on those work packages to achieve the reliability needed to meet the threshold dictated by the sponsor.
The author hopes that project managers will implement this methodology as a tool within their project management environment and publish the findings. Other limitations of this methodology may exist and are yet to be identified. However, considering the potential value and ease of use of these calculations, the author believes that this type of analysis could be valuable for project managers seeking to quantify the likelihood of project failure easily and quickly based on the project plan.
References
Ballesteros-Pérez, P., Cerezo-Narváez, A., Otero-Mateo, M., Pastor-Fernández, A., & Vanhoucke, M. (2019). Performance comparison of activity sensitivity metrics in schedule risk analysis. Automation in Construction, 106, 102906. doi: https://doi.org/10.1016/j.autcon.2019.102906
Bentahar, O., Tywoniak, S., & Loilier, T. (2023). The project manager as chameleon? Changing project manager roles with technological uncertainty. Journal of Engineering and Technology Management, 69, 101767. doi: https://doi.org/10.1016/j.jengtecman.2023.101767
Fleming, J. F., & Poole, K. W. (2016). NASA work breakdown structure (WBS) handbook. NASA. https://ntrs.nasa.gov/citations/20160014629
Islam, S. M. S., & Rokonuzzaman, M. (2009). Process centric work breakdown structure for easing software project management challenges: Business case analysis example. 2009 12th International Conference on Computers and Information Technology, 508–513. doi: https://doi.org/10.1109/ICCIT.2009.5407291
Krueger, D. C. (2022). Reliability and maintainability. In B. Bidanda (Ed.), Maynard’s industrial & systems engineering handbook (6th ed., pp. 1005–1026). McGraw-Hill.
Larson, E., & Gray, C. (2021). Project management: The managerial process. 8th ed. McGraw-Hill.
Lin, F.-T. (2008). Fuzzy crashing problem on project management based on confidence-interval estimates. 2008 Eighth International Conference on Intelligent Systems Design and Applications, November 26–28, Kaohsuing, Taiwan. pp. 164–169. doi: https://doi.org/10.1109/ISDA.2008.190
Littell, W. N. (2022). Project management for the industrial engineer. In B. Bidanda (Ed.), Maynard’s industrial & systems engineering handbook (6th ed., pp. 1581–1596). McGraw-Hill.
Lorko, M., Servatka, M., & Zhang, L. (2021). Improving the accuracy of project schedules. Production and Operations Management, 30(6), 1633–1646.
Project Management Institute. (2021). A guide to the Project Management Body of Knowledge (PMBOK) guide and the standard for project management (7th ed.). Project Management Institute.
Project Management Institute. (2019). Practice standard for work breakdown structures (3rd ed.). Project Management Institute.
Smart, C. B. (2020). Solving for project risk management: Understanding the critical role of uncertainty in project management. McGraw-Hill Education.