For me, the real value of project management lies in noticing that something is moving away from expectations while there is still time to make a decision. This is also the foundation of better project forecasting. An academic study called Dynamic Prediction of Delays in Software Projects using Delay Patterns and Bayesian Modeling, also available in an open version on arXiv, starts from exactly this idea.

The study shows how continuously updated models can predict delays during the early stages of a project. Instead of relying only on the estimate created at the beginning, the risk is recalculated as new execution and team-performance data become available. This approach seems much closer to reality to me, because no project remains exactly the same after it starts.

1. The forecasted deadline starts moving away from the project baseline

The project baseline, also known as the schedule baseline, is the reference that shows how the project was expected to progress. It includes the dates, milestones, durations and deliverables approved during planning. When the current forecast begins to move away from that reference, we have one of the first signs that execution is no longer following the original plan. This is one of the clearest signals to monitor in schedule management.

This distance can appear in different ways. The projected end date may be pushed forward repeatedly, milestones may start being completed later than planned, or the team may deliver less work than expected during a given period. In earned value management, Schedule Variance shows an unfavorable result when the value of work performed is below the value planned, while a Schedule Performance Index, or SPI, below 1 indicates that the project is progressing at a slower rate than expected. The United States Department of Energy guide to Earned Value Management explains these indicators in more detail.

I do not consider a single unfavorable result enough to declare that a project is delayed. What concerns me is the trend. If the SPI remains below 1, Schedule Variance continues to be unfavorable and the completion forecast is revised several times, the project is producing evidence that the original plan no longer represents the reality of execution.

In Saint Jude, the Project Module continuously compares what was planned with what was actually delivered. This comparison helps identify which activities are contributing to the deviation, which deliverables are falling behind and when the difference between the plan and execution begins to threaten the final deadline.

2. Critical-path slack starts to shrink

Not every delayed activity has the same impact. A task may be a few days late while there is still enough slack for the project to finish on time. Another apparently small activity may be on the critical path and directly determine when a deliverable can be completed.

That is why I do not like analyzing a schedule simply by counting how many tasks are late. Ten delayed activities may have little impact if they still have enough margin. A single critical activity, on the other hand, can block other teams, consume all available slack and change the project end date.

The Schedule Assessment Guide from the Government Accountability Office explains the importance of correctly structuring dependencies, durations and the activities that control the project’s completion. I also explore this topic in the article Critical Path in Project Management: How to Identify Dependencies That Can Delay Your Project.

For me, the most important point is understanding that the critical path is not a photograph taken at the beginning of the project. An activity that once had slack may start consuming it. A dependency may become riskier. A change in duration may cause another path to control the delivery. The schedule has to follow reality, because reality keeps changing.

In Saint Jude, the Schedule Module helps track relationships between activities, milestones and the possible consequences of a delay. This allows the project manager to focus attention on the work that can actually change the final date, instead of treating every task as if it had the same importance.

3. Work in progress (WIP) grows beyond the team’s capacity

There is a situation I often see in projects: the board is full of activities in progress, but very few are being completed. At first glance, this may look like productivity. Many people are busy and several tasks have been started. In practice, however, too much work in progress may indicate that the team is overloaded and struggling to finish what it started. It is also a sign that team capacity planning may no longer reflect the way work is actually flowing.

WIP, or Work in Progress, represents the amount of work that is open or being executed. When it grows beyond the team’s actual capacity, context switching, interruptions and waiting between stages increase. People start many activities, but take longer to complete each one. The Kanban University guide presents WIP limits as an important practice for improving flow.

What matters to me is not simply knowing how many tasks are open. I want to understand how many are actually moving forward, how many depend on the same people, which ones are blocked and whether the volume of work is growing faster than the team’s ability to finish it. When a queue of tasks begins to build up, the delay may not yet be visible in the schedule, but it is already being formed in the workflow.

In Saint Jude, the Team Performance and Capacity Module compares work in progress with the team’s observed execution capacity. This analysis helps identify overload, concentration of activities among specific people and situations in which the team appears busy but is not turning effort into completed deliverables. You can also learn more in our article about team productivity metrics for software teams.

4. Lead time and cycle time become longer and less predictable

Lead time shows how long a request takes from the moment it enters the workflow until it is completed. Cycle time measures the period between the actual start of the work and its completion. I like these indicators because they show how deliveries behave in reality, rather than only what was estimated during planning.

When lead time and cycle time start increasing, the team is taking longer to complete similar activities. When they also become less predictable, the problem is even greater: even if the average looks acceptable, some tasks begin taking much longer than others. The Kanban University presents lead time as an important indicator of predictability.

A team can continue delivering and still be losing predictability. Sprints end, but activities take longer and longer. Estimates need to be revised frequently, and future dates start depending on a capacity that no longer behaves as it did before. To me, this is a signal that appears before the delay becomes officially visible.

In Saint Jude’s Project Module, we validate productivity in every sprint and observe how delivery performance evolves over time. This analysis helps identify when flow is slowing down, when the team is delivering less than planned and when future forecasts should no longer use the same assumptions made at the beginning of the project.

5. Changing requirements and scope keep affecting the project

Scope changes are part of the reality of many projects. A new requirement may appear because the client learned something during execution, because a technical constraint was discovered or because a strategic priority changed. The problem is not necessarily the existence of the change, but the lack of visibility into its impact.

When requirements continue changing after the work has started, activities can lose clarity, estimates stop representing the actual effort and the team begins working on something different from what was originally planned. This is the operational side of scope creep. A task may appear small, but need to be reopened several times because its objective or acceptance criteria are still unclear.

The NASA documentation on requirements volatility shows how frequent changes can affect development stability. In my experience, this is also one of the most difficult signals to notice, because the schedule may continue to be updated while the project is accumulating work that was never part of the original plan.

In Saint Jude’s Project Module, we analyze whether activities are clear enough and whether their estimates are aligned with similar tasks that have already been completed. This comparison helps identify generic activities, estimates outside the normal pattern and situations in which scope changes are increasing the required effort without the management team clearly seeing it.

6. Dependencies, blocked tasks and waiting time begin to accumulate

Not every delayed activity is late because the team stopped working. Often, it is waiting for an approval, information, another team, a supplier, a technical environment or a client decision. When this waiting time is not visible, it can be interpreted as low individual productivity, even though the problem lies in the way the work is connected.

A dependency, by itself, is not necessarily a risk. If the team we depend on is progressing normally, has enough capacity and there is still slack in the schedule, the dependency may be under control. The risk changes when the estimate is revised, the activity becomes blocked, the responsible person is overloaded or the next deliverable no longer has enough margin to wait.

The GAO material on interdependencies and the critical path shows how project dependencies can affect the schedule. A short wait on one activity can spread to several others, especially when there is a sequence of dependent tasks or when different teams need to work in a specific order.

This is also the point at which the risk of delay needs to be reassessed continuously. The initial estimate may have been appropriate when the project began, but new blockers, changes in performance and accumulated waiting time alter the probability of completion. It does not make sense to look at risk only because it was recorded at the beginning. We need to observe what is happening now.

In Saint Jude’s Risk Module, risks are continuously assessed in a proactive way by our Artificial Intelligence. When a potential problem is identified, risk mitigation actions are automatically assigned to the responsible user on the platform. The goal is to allow the team to address the risk while there is still time to act, before a dependency becomes a concrete delay.

7. Rework, defects and delivery-quality problems increase

A project can continue recording completed activities and still be moving toward a delay. This happens when part of the work needs to be done again. A task is closed but returns to development. A deliverable is sent for validation but comes back with new problems. A change causes a regression and forces the team to fix something that should already have been finished.

Rework consumes capacity that was not included in the original estimate. The team remains busy, but an increasing share of its effort is directed toward corrections, reviews and reopened activities. Over time, new tasks start to accumulate, cycle time increases and the project delivers less value than the amount of work performed would suggest.

The Software Engineering Institute highlights the importance of using development-flow data to understand delivery quality and efficiency. Research on the factors that influence on-time delivery, such as the study published by the IEEE, also reinforces that quality problems and rework can undermine predictability.

For me, the main signal is not an isolated defect. What deserves attention is when similar tasks begin to be reopened more often, when the number of corrections increases or when the effort required to complete a deliverable grows even though the scope has not changed. At that point, the team may be generating a lot of activity but very little real progress.

In Saint Jude, project performance metrics can be analyzed together with project data to identify when effort is being consumed by rework, reviews or activities that do not move toward a definitive completion. This view helps us understand not only how much was done, but how much of the work actually became an accepted deliverable.

Project risk management is about combining the signals

None of these signals, by itself, proves that a project will be delayed. An SPI below 1 may represent a temporary variation. An increase in lead time may be related to an exceptionally complex task. A scope change may be necessary to protect the project’s outcome. What concerns me is when several of these signals begin appearing at the same time.

When the forecasted deadline moves away from the baseline, critical-path slack decreases, WIP grows, deliveries become slower, requirements continue changing and blockers accumulate, the project is telling us a story. The delay may not have officially happened yet, but the data are already showing that the current way of working may not be enough to meet the plan.

That is why I do not believe in project management based only on static reports or status meetings. A report shows what happened. A meeting can help discuss what is happening. But we also need to interpret what the data indicate about what may happen a few weeks from now. Project risk management needs to be updated as execution changes, rather than remaining tied to the initial estimate.

How AI project management gives you more time to react

I do not believe there is a platform capable of eliminating every risk from a project. People change, suppliers are late, estimates are wrong, clients change priorities and important decisions can take longer than expected. Uncertainty will always be part of management work.

The difference lies in when we notice that something is moving away from the planned direction. If we discover the problem on the day the deliverable is due, our options are limited. If we identify the risk a few weeks earlier, we may still be able to redistribute capacity, adjust a priority, divide the scope, negotiate a dependency or create a mitigation plan.

Saint Jude does not replace tools such as Jira, Azure DevOps, ClickUp, Monday.com or Asana. Those platforms remain essential for organizing and executing the work. Saint Jude operates at a different layer: it uses the data that projects already produce to help project managers, PMOs and leaders understand project health, identify patterns and make decisions earlier.

In the end, predicting delays does not mean guessing the future. It means observing the present carefully enough to notice when the project’s behavior starts moving away from expectations. It means understanding that a delayed task may be a simple variation or the beginning of a chain reaction.

And perhaps this is the most important question: in your project, are you waiting for the date to be missed before taking action, or can you already identify the signals that indicate it may be missed?

Until next time!

Erik Scaranello