Delay Analysis in IT Projects: Why the Choice of Project Methodology Matters
IT projects are often large-scale and complex, demanding careful planning and diligent project management to stay on track and be completed successfully. The choice of methodology is typically identified by the specific needs of the project. Some of the most commonly used methodologies include agile, waterfall or hybrid.
Agile project management comprises incremental steps and iterative cycles, aiming to release benefits throughout the project in a flexible and collaborative manner, rather than only at the end. This affords more flexibility for changes to scope and delivery as phases (known as sprints) run iteratively, with continuous customer feedback.
The waterfall methodology adopts a sequential, more linear approach. For example, key phases such as requirements gathering are completed before design; design is completed before moving onto development; development before testing, etc. Each stage or phase typically requires a finish-to-start dependency.
A hybrid approach combines specific parts of each methodology, mixing the more traditional elements of waterfall with the flexibility of agile.
Projects can go off track for a variety of reasons. In many instances, the issues encountered can be overcome, allowing the project to recover and reach completion, albeit sometimes with delays. In other scenarios, delays may escalate to the point where parties proceed to formal dispute, and retrospective delay analysis needs to be undertaken to identify the root-cause of failures. In IT disputes, the project management or product development methodology used can be quite significant as it dictates the path the project follows. Failing to follow best practice in relation to the particular methodology deployed can result in project distress and delays.
Whilst a hybrid project management approach can provide adaptability for the delivery of a project, it can complicate delay analysis which involves identifying, assessing, addressing and attributing delays.
Increased Complexity in Identifying Delays
Elements of the project that are scheduled in a start-to-finish, linear and sequenced waterfall manner are typically baselined with an end date. Identifying delays here requires reviewing any deviation from the baseline. In contrast, agile components, which are typically accepted as being delivered iteratively with more flexibility, can be harder to baseline. For example, a delayed item in a sprint might not affect other stages of the project, as it could potentially be descoped from requirements or completed in another sprint. This can make it more difficult to ascertain whether a delay is critical or absorbable when conducting delay analysis. A hybrid approach can therefore create ambiguity in identifying delays. Where some items are immediately identifiable as delayed, others are less obvious.
Establishing the Critical Path
The critical path is a core concept in both delay analysis and in traditional project management, outlining the sequence of tasks that directly affect the project timeline. In sequential waterfall stages, start-to-finish dependencies naturally define the project’s completion timeline. Although agile frameworks may use expected completion dates, the dynamic nature of shifting priorities in agile phases can cause changes to the critical path. In hybrid approaches, the blend of these approaches can further complicate delay analysis, as:
- Not all tasks have fixed dependencies to measure impact to or from.
- Agile activities can change their priority and be difficult to isolate within overall project plans.
Where the critical path changes for the agile project components, this could affect the overall critical path of the entire project. Since critical path analysis is a widely recognised delay analysis technique, a hybrid project deployment can murky the water as a changing critical path is acceptably and frequently adopted.
Accountability
To identify the root-cause of a delay in order to effectively attribute it, an analyst needs to understand the roles and responsibilities of the parties. In more rigorous and structured project management methodologies, roles and responsibilities are usually defined upfront. In an agile methodology, accountability may be harder to assess since the boundaries of responsibility can be blurred by the consensus of collaboration. In a hybrid approach, grey areas related to governance and productivity can hinder analysis of accountability and therefore attribution.
Replanning
In waterfall methodologies with milestone payment gateways for specific phases, certain delays may trigger formal replanning processes to formally change the baseline schedule. In an agile approach, continuous backlog refinement makes replanning a regular, expected activity. In a hybrid approach, the continuous replanning inherent in agile can obscure the original timeline, therefore complicating delay tracking and analysis. It may be difficult to determine what activities need to be specifically prioritised, versus their natural completion for formal replanning purposes.
Delay Management
Delay analysis techniques conducted retrospectively and after project completion will differ from those conducted more contemporaneously to assess prospective delay. To manage delay in a hybrid project, project managers or delay analysts may choose to:
1. Develop a unified delay definition, agreeing delays are measurable from a specific phase end date regardless of iteration.
2. Implement integrated scheduling tools that accommodate hybrid project elements such as JIRA with Gantt Charts.
3. Conduct dual impact assessments that evaluate delays from two perspectives:
a. Delays against baseline milestones and the critical path.
b. Delay assessment in terms of impact on Minimum Viable Product (MVP) timelines.
4. Use Key Performance Indicators (KPIs) that balance agile and waterfall metrics, such as sprint velocity in agile, and baseline deviation in waterfall.
Whilst a hybrid methodology might be the optimal project management methodology for the delivery of a project, it can complicate traditional delay analysis when projects go awry. To mitigate encountered delay, analysts must navigate the duality of rigid milestones and iterative flexibility, reconcile differing definitions of delays, and understand the dynamic replanning processes that may have taken place mid-project. When a project ends up in a formal dispute, it is vital that any contemporaneous plans and variations are forensically preserved for retrospective delay analysis to be conducted effectively. In order to ascertain whether activities were effectively replanned, the accompaniment of stand-up / meeting minutes and other project management and/or working group documents and reports will be vital. As a preliminary measure, contractual review should be undertaken to assess whether relief notices and/or other formal advisory in relation to delays (where applicable) have been followed.
How A&M Can Help: Technology Dispute Services
Technology software and systems are a core facet in many of today’s civil and commercial disputes. A&M specializes in providing end-to-end IT dispute expert advisory. Whether the issue is a live frustrated IT project requiring root cause technical delay analysis, or a dispute requiring software analysis expert evidence, A&M has vast experience within complex, high-value information technology disputes across a variety of sectors and industries. A&M can assist at all stages of a project dispute or the litigation lifecycle, including pre-dispute project advisory to post-deal insurance claims. Our technology experts have extensive experience in identifying, collecting, documenting and analyzing complex technical platforms and information sources, and translating technical complexities into digestible outputs.