Author: Aric Katz

Aric Katz is president of Katsoft, an Israeli project management consulting firm. Aric has experience in applications, utilities, and methodologies and is highly skilled with problem solving and systems design. Contact him at or (972)-(0)72-2324655.

How to Achieve a More Realistic Schedule in Your Project Planning

08/27/2022 Project management has moved front and center in organizations as an antidote to heightened competitiveness, greater appetite for innovation, and ever-shrinking budgets and resources. The project management profession is rapidly evolving, bringing in new methodologies, tools, and utilities to do the best job possible. Yet, quite often project managers still lack some key techniques for achieving better project planning and scheduling. In this article, I share some tools and methods that can aid PMs in improving the quality of their planning and in achieving a more realistic project plan that they feel confident of committing to. The Nature of the Scheduling Challenge Statistics show that between 60 and 70 percent of projects don’t meet their schedule, budget, or predefined scope. Why is this In many companies the process of planning a project consists of compiling a predefined list of tasks with logical connections and duration estimates in a deterministic or constant quantity. Some companies do this plus also add in information about resource assignments. Still others use enterprise project management applications as a timing engine with no resource constraints. An additional means of honing a schedule is to analyze various scenarios, performing resource leveling to discover conflicts and critical chains, and mapping critical paths that could cause the entire project to deviate from its planned finish date. Another challenge that directly affects the quality of planning is the experience level of the project manager in charge of maintaining the schedule. Frequently, these newbies have no planning experience, no management experience, and no project management experience. All of a sudden they’re expected to deal for the first time with building a project plan, assigning resources, creating a budget, and managing the scope. Is it any wonder that so many projects start off underfunded or under-scheduled from their very first day? In all of these cases, scheduling is a critical ingredient during the first stages of a project, no more so than in companies where pricing of projects is done according to a project’s Gantt chart with some added predefined cost buffer. There must be a better way to achieve a more realistic schedule and map critical paths/chains. Pre-measuring a One-time Event A project is a concentrated effort done once to achieve a product or a service. If it’s unique (done once), how can the effort it will require be measured accurately? By using known tools, you can “release” the constraint of uniqueness and of those deterministic durations that don’t reflect the “real world.” What it takes is the application of simple Monte-Carlo techniques. Running each project numerous times using simulation wears away the uniqueness constraint. Each simulation represents a different scenario or a different mix of durations for the same project plan. Each time a new random duration is produced for each task — based on the task’s distribution/curve and the predefined deviation range — a new project plan or scenario is created. What’s a task’s distribution Time for a quick stats lesson. A task distribution is a random occurrence that can be defined as an asymmetric right-tailed beta curve/distribution. (The use of a triangular distribution is a common way to simplify statistical problems in project management.) What’s that right-tail curve with an asymptote at y=0 represent The project or task may never end, but with a minor probability. That means the minimal expected duration of a task will always have a positive value. It’s common to assume 80 percent success for a given task’s duration, meaning that if that task were done 10 times, then eight out of 10 times it would meet its deadline or finish before it. Figure 1: A task’s duration according to beta and triangular distribution. For each scenario we need to concoct for our Monte Carlo simulation, relevant data is collected and stored as for the project’s finish date/remaining duration, the critical path/chain, and the critical resources. The exit point for each batch we run is the definition of estimated task deviations. This can be one range for all tasks, such as 30 percent above and 10 percent below, or it can be defined task by task. Here are some key points to keep in mind as you’re building a simulation utility in your project plan. Say you’re going to use a defined task deviation of 30 percent probability that the project will be late and a 10 percent probability of it being early. That sets a task with an estimate of 10 days to an upper bound or delay of 13 days and a lower bound or early delivery of nine days. The deviated data can be entered into the project’s pert fields by task or can be set as a generic deviation to all tasks. The former configuration combined with a random function to randomly set task durations between the pre-configured deviations would create a large range of different scenarios for a single project. Work with “remaining work.” Bolster your analysis in both the planning stage and the execution stage by using the durations of tasks that haven’t begun and the remaining durations of tasks that have begun. Exploit what you already know. Use the built-in leveling algorithm in Project to differentiate between critical path and critical chains. Confused about the difference? A critical path is the longest path of tasks that starts at a projects start date and ends at a projects finish date; as I mentioned, any delay on a task in this path will cause the entire project to deviate from its planned finish date. The emphasis is on the task order. A critical chain is just like a critical path in regards to resource constraints. But in a critical chain if two tasks share the same resource and are in parallel to one another, they’ll shift in priority according to the predefined resource leveling settings. The emphasis is on the resource. Display the results of the calculated finish dates and durations in a descending order (Pareto) to see the percentile for each total duration/finish date and the number of times it occurred in the simulation run. Once you have the simulation run, what’s next? The outputs are the result of a wide range of scenarios where each scenario has tasks with both optimistic durations and pessimistic durations. These have been randomly generated according to the predefined distribution function. These task deviations can cause planned serial connected tasks to become parallel and vice versa. For example, let’s say a project’s deterministic duration is 18 months. That’s what your initial plan calls for (deterministic durations). Yet the simulation utility shows that in 85 percent of the cases (from all of the checked scenarios), the project actually finishes in 24 months. This insight should raise a red flag. If this project is priced predicated on being finished in 18 months, both the client and the contractor would lose — the contractor because he or she had resources planned for 18 months, yet there’s a high probability they’ll still be working on the project for another six months, and the customer because not getting the project done on time may affect the viability of the effort as well as his or her reputation in the organization. Map Hidden Paths or Chains The hidden critical chains or paths in a project is an array of feasible paths that connect a project from its beginning to its end, yet in their deterministic state they don’t hold the longest path. A hidden critical path or chain can become the critical path or chain if one of its tasks deviates — takes more time than planned — causing that hidden path or chain to become the longest path from start to end. How do you counter this possibility? Go through the simulation process keeping in mind the project’s critical path or chain for each iteration. Due to a different scenario generated (tasks take longer or shorter than their original duration) different paths and chains show up. For example, a critical path in the deterministic project might be based on tasks 1, 2, 5, 7, and 9. Yet the output from the simulation runs might show that 70 percent of the time the path might follow 1, 2, 3, 7, 8, and 9. How would that affect the schedule? Improve the Quality of the Project Plan The project plan is the base for all project progress and status. A well-built project plan is a key factor for estimating the project’s progress and overall success. The closer the project plan is to reality, the more successful it’s likely to be. So how can you improve a project’s plan? An obvious solution is to reuse historical knowledge that can supply immediate feedback to a project’s manager during all stages of the initiative regarding its progress and its chances of finishing on time, in scope, and on budget. I suggest adding as part of a company’s project management process a list of automated checks. The checklist can be run manually. Or, if you have the capabilities, you can automate it. This involves running through business rules. An initial set of rules can be marked as critical. Saving or publishing of project plans can be blocked if a critical rule doesn’t pass. I’d advise dividing the project’s checklist into three parts: project level checks, resource level checks, and task level checks. The checklist can be used in all stages of a project (initiation, progress, and so on) as can be seen in the following predefined checklist: The total slack for this task is negative. There is no work planned for… The task is critical and was scheduled to be finished by now. The task has no predecessors. According to ______ the task’s progress it is going to miss its planned schedule. The task should have started but is 0% completed. The task is scheduled to start in the future yet it is partially complete. The task is not a summary task nor is it a milestone, yet there are no resources assigned to it. The task is partially complete, yet not all of its predecessors are done. This checklist is an infrastructure element that can be modified, added to, or deleted from, enabling companies to force their own business rules or just relay best practices. Continuous Improvement is the Goal In this article I’ve pointed out a few of the more common challenges regarding project plans; yet these are only a small portion of the daily problems project managers and companies face every day. I’ve also offered some techniques for improving a project plan. With just a small effort, you can achieve great added value from analyzing what you already know in different ways as part of your on-going process for continuous improvement.