Monday

Category Archives: Agile Ideas

Waterfall is Dead

The PMI 2024 Pulse of the Profession has introduced a framework for categorizing projects based on the management approach being used of: Predictive – Hybrid – Agile.  If generally adopted, this framework will at long last kill of the notion of waterfall as a project delivery methodology.

As shown in our historical research The History of Agile, Lean, and Allied Concepts, the idea of waterfall as a project delivery methodology was a mistake, and its value as a software development approach was limited.

The PMI framework has some problems but the predictive project delivery paradigm is described as focused on schedule, scope, and budget. The projects tend to use a phase-based approach and are plan driven.  This describes most hard projects and many soft projects that are not using an unconstrained agile approach.

For a detailed review of the PMI 2024 Pulse of the Profession report, and how the classification system works see How should the different types of project management be described?, download from: https://mosaicprojects.com.au/Mag_Articles/AA026_How_should_different_types_of_PM_be_described.pdf

For more on project classification see: https://mosaicprojects.com.au/PMKI-ORG-035.php#Class

A Brief History of Agile

The history of agile software development is not what most people think, and is nothing like the story pushed by most Agile Evangelists.

Our latest publication A Brief History of Agile shows that from the beginning of large system software development the people managing the software engineering understood the need for prototyping and iterative and incremental development. This approach has always been part of the way good software is developed.

The environment the authors of the early papers referenced and linked in the article were operating in, satellite software and ‘cold-war’ control systems, plus the limitations of the computers they were working on, did require a focus on testing and documentation – it’s too late for a bug-fix once WW3 has started…..  But this is no different to modern day control systems development where people’s lives are at stake. Otherwise, nothing much has changed, good software is built incrementally, and tested progressively,  

The side-track into ‘waterfall’ seems to have bee started by people with a focus on requirements management and configuration management, both approached from a document heavy bureaucratic perspective. Add the desire of middle-management for the illusion of control and you get waterfall imposed on software developers by people who knew little about the development of large software systems. As predicted in 1970, ‘doing waterfall’ doubles to cost of software development. The fact waterfall survives in some organisations through to the present time is a factor of culture and the desire for control, even if it is an illusion.

The message from history, echoed in the Agile Manifesto, is you need to tailor the documentation, discipline, and control processes, to meet the requirements of the project. Developing a simple website with easy access to fix issues is very different to developing the control systems for a satellite that is intended to work for years, millions of miles from earth.

To read the full article and access many of the referenced papers and third-party analysis see: https://mosaicprojects.com.au/PMKI-ZSY-010.php#Agile

Agile’s Hidden Secret!

The two fundamental questions standard agile metrics cannot answer consistently are:

1.  How far ahead or behind schedule are we currently?

2.  When are we expected to finish?

Most of the tools and techniques used to manage Agile projects are good at defining the work (done, in-progress, or not started) and can indicate if the work is ahead or behind a nominated planned rate of production, but there is no direct calculation of the time the work is currently ahead or behind the required production rate, or what this is likely to mean for the completion of the project. A full discussion of this topic is in Calculating Completion.  However, most project sponsors and clients need to know when the project they are funding will actually finish, they have other people that need to make use of the project’s outputs to achieve their objectives. At present all Agile can offer is an educated assessment based on the project teams understanding of the work.

Work Performance Management (WPM) has been designed to solve this challenge by providing answers to these questions based on consistent, repeatable, and defensible calculations.

WPM is a simple, practical tool that uses project metrics that are already being used for other purposes within the project, to assess progress and calculate a predicted completion date by comparing the amount of work achieved at a point in time with the amount of work needed to have been achieved. Based on this data WPM calculates the project status and the expected completion date assuming the rate of progress remains constant.

Our latest article, WPM for Agile Projects identifies the cause of this information gap in Agile project management, explains the inability of current tools to accurately predict completion and demonstrates how WPM will effectively close this critical information gap.
Download WPM for Agile Projects: https://mosaicprojects.com.au/Mag_Articles/AA040_-_WPM_for_Agile_Projects.pdf

For more on the practical use of WPM, free sample files, and access to the tool see: https://mosaicprojects.com.au/PMKI-SCH-041.php  

The Problem with Waterfall

The term ‘waterfall’ is seen in lots of different posts without any clear definition of what the writers of those posts mean by the term.  The only constant seems to be in each of the writer’s view ‘waterfall’ is not Agile, and generally represents bad project management practice. In summary, the agile advocates view seems to be:

Agile: A well-defined flexible project delivery process, based on the Agile Manifesto, applicable to software development and a wide range of other “soft projects” such as business change. Agile = Good!

Waterfall: Any project delivery process that is not Agile. Waterfall = Bad!

There are many problems with this simplistic viewpoint starting with the fact the concept of ‘waterfall’ had a very short life and with the possible exception of a few, very traditional, software development organizations, no one uses waterfall for anything.

History of Waterfall.

To the best of my knowledge, the first publication to use the term Waterfall was in the 1976 paper Software Requirements: Are They Really a Problem, by T.E. Bell and T.A. Thayer. This paper misrepresented the 1970 paper Managing the development of large software systems, by Dr Winston Royce[1]. Royce proposed an iterative approach to the development of large systems, but Bell and Thayer falsely claimed he supported ‘waterfall’[2].  

Summary diagram from Royce 1970.

The real start of Waterfall was the publication in 1988 of DOD-STD-2167A by the US Department of Defense, which established uniform requirements for the development of software based on the Waterfall approach[3].   

Extract from DOD-STD-2167A

Problems with the Waterfall approach were quickly identified and in 1996 MIL-STD-498 was released by the US Department of Defense to correct the problems. Officially Waterfall was dead and buried but many companies had adopted waterfall and because waterfall projects were slow and subject to delay, hourly paid staff and contractors had a powerful incentive not to change despite many better software development processes being developed starting from the early 1980s.   

Other types of projects and project delivery.

Waterfall was a short-lived software development methodology. The vast majority of projects in the construction, engineering, oil & gas, defence, and aerospace industries use project delivery methods based on the approaches described in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Sixth Edition, and a range of other standards. These other projects generally have three phases:

  1. definition phase undertaken by the client organization to define the capabilities of the product being developed
  2. procurement phase where the client selects a delivery agent for the development of the product
  3. delivery phase where the delivery agent builds and delivers the product

The design of the product (ship, building, rocket, etc.) may be undertaken in full or in part during any one of the three phases. A minimum level of design is required to initiate procurement, but for simple buildings and civil engineering projects, it is not unusual for a complete design and specification to be provided by the client.

The procurement phase may be a simple pricing exercise, or a complex, and phased, design process (sometimes even involving the production of working prototypes), with selection being based on the capabilities of the design produced by the successful tenderer.

Then, in many projects, a significant amount of detailed design is still required during the delivery phase, including shop drawings produced by subcontractors and suppliers.

Similarly, the procurement arrangements vary widely. The client may choose to enter into some form of alliance or partnership with the preferred delivery agent based on shared risk and profits, or the client may choose a hard-dollar contract based on a fixed price to deliver a fixed scope, or some other form of contractual arrangement.

The only certainties are that the typical project approaches used for the vast majority of ‘other’ projects bear no resemblance to the waterfall approach, and this ‘other’ classification includes more than two-thirds of the world’s projects by value.

Conclusions

  1. I suggest it is time to follow the US DOD lead from 1994 and bury the concept of ‘waterfall’ – using the name 30 years after it was officially dropped is long enough.
  2. People involved in the ‘Agile’ industry need to wake up to the fact that software development is only one of many types of project. Most of the ‘other’ types of project do not use Agile, and they certainly don’t use waterfall.
  3. Agile and agility are not synonymous – all organisations benefit from a degree of agility, but this has nothing to do with selecting the best project delivery methodology (more on this later).
  4. In the 21st century, Waterfall is not synonymous with over documentation and/or bad project management. There is plenty of bad project management practice around. But bad management needs to be called out for what it is – 99.999% of the time the bad managers are not trying to use waterfall in their work.   

Ditching the concept of waterfall does create a couple of challenges – we all have an understanding what Agile means as a project delivery process, we need similar generally accepted classifications for other types of project delivery – more on this later. Similarly, the bad management practices branded as ‘waterfall’ need to be identified and understood, you cannot improve a bad process until the root cause of the problem is understood.

For more on Agile management see: https://mosaicprojects.com.au/PMKI-ITC-040.php#Process1

Note: THE MYTH OF THE ‘WATERFALL’ SDLC by expands on this post in far greater detail and is highly recommended as a reference: http://www.bawiki.com/wiki/Waterfall.html


[1] Download a copy of the 1970 Royce paper: https://mosaicprojects.com.au/PDF-Gen/Royce_-_Managing_the_development_of_large_software_systems.pdf  See Fig. 10.

[2] Download a copy of the 1976 Bell & Thayer paper: https://mosaicprojects.com.au/PDF-Gen/software_requirements_are_they_really_a_problem.pdf

[3] Download DOD-STD-2167A Defense System Software Development (1988): https://mosaicprojects.com.au/PDF-Gen/DOD-STD-2167A.pdf

Commercializing Agile

Agile in its various forms is becoming mainstream, and this means an increasing number of commercial contracts are being delivered by contractors who either choose, or are required, to use an agile methodology to create their contracted deliverables. While this is probably a good thing, this shift in approach can cause a number of problems. The major shift in approach is managing the legally imposed, contractual requirement to deliver 100% of the designated project deliverables on time.  The funds available to the contractor to do this work are defined by the contract price, and failure to deliver the contracted deliverables within the contracted timeframe can lead to significant cost penalties being applied[1].  

The requirement to deliver a project as promised in the agreed contract is business-as-usual for most construction and engineering project and is common across many other industries. While relatively rare software companies have also been successfully sued for breach of contract when their deliverables did not meet the contracted obligations, some early cases are discussed in Software sales hype and the law, and IT Business Sued for US$300 million+.  In short, choosing to use Agile as a project delivery methodology will not change the laws of contract, which means organizations using the agile methodology will need to become more commercial  and adapt their processes to include:

  1. Developing the realistic time and cost estimates needed to enter into a contract.
  2. Monitoring and controlling the project work to optimize the delivery of the contracted requirements within the contract timeframe.
  3. Enhancing their contract administration to deal with changes, variations, reporting, claims and other contractual requirements and issues.

This post is a start in looking for practical solutions to some of these challenges.

Contract Claim Administration

Two of the core tenets of Agile are welcoming change when it creates additional value for the client, and working with the client to discuss and resolve problems. While these are highly desirable attributes that should be welcomed in any contractual situation, what happens when the relationship breaks down, as it will on occasions?

The simple answer is that every contract is subject to law, and the ultimate solution to a dispute is a trial, after which a judge will decide the outcome based on applying the law to the evidence provided to the court. The process is impartial and focused on delivering justice, but justice is not synonymous with a fair and reasonable outcome.  To obtain a fair and reasonable outcome, evidence is needed that can prove, or disprove each of the propositions being put before the court.

The core elements in dispute in 90% of court cases relating to contract performance are about money and time. The contractor claims the client changed, or did, something (or things) that increased the time and cost of completing the work under the contract; the client denies this and counterclaims that the contractor was late in finishing because it failed to properly manage the work of the contract.    

The traditional approach to solving these areas of dispute was to obtain expert evidence as to the cost of each change and the time needed to implement each of the changes and its effect on the completion date. Determining the cost of a change is not particularly affected by the methodology used to deliver the work. The additional work involved in the change and its cost can be determined for a change in an ‘agile’ project in a similar way to most other projects. Where there are major issues is in assessing a reasonable delay.

For the last 50+ years, courts have been told by many hundreds of experts, the appropriate way to assess project delay is by using a critical path (CPM) schedule. Critical path theory is based on an assumption that to deliver a project successfully there is one best sequence of activities that have to be completed in a pre-defined way to achieve the best result. Consequently, this arrangement of the work can be modelled in a logic network and based on this model, the effect of any change can be assessed.

Agile approaches the work of a project from a completely different perspective. The approach assumes there is a ‘backlog’ of work to be accomplished, and the best people to decide what to do next are the project team when they are framing the next sprint or iteration. Ideally, the team making these decisions will have the active participation of a client representative, but this is not always the case. The best sequence of working emerges, it is not predetermined and therefore a CPM schedule cannot be developed before the work is started. 

Assessing and separating the delay caused by a change requested/approved by the client from delays and inefficiencies caused by the contractor is difficult at the best of times, this process becomes more difficult in projects using an agile approach to the work but is essential for assessing time related claims under a contract.

There are some control tools available in Agile, but diagrams such as a burndown (or burnup) chart are not able to show the effect of a client instructing the team to stop work on a particular feature for several weeks, or adding some new elements to the work. The instructions may have no effect, the team simply work on other things, or they may have a major effect. The problem is quantifying the effect to a standard that will be accepted as evidence in court proceedings.  CPM has major flaws, but it can be used to show a precise delay as a specific consequence of a change in the logic diagram. Nothing similar seems to have emerged in the Agile domain.

These challenges are discussed in WPM – Schedule Control in Agile and Distributed Projects (and are the focus of ongoing work).

The agile paradigm has a lot to offer, but to become a commercially effective option, the project controls and contractual frameworks will need a major overhaul.  For more on managing agile see: https://mosaicprojects.com.au/PMKI-ITC-040.php#Process1


[1] Developing and defending contractual claims is discussed in Forensic analysis and reporting (cost & time): https://mosaicprojects.com.au/PMKI-ITC-020.php#Process1

How WPM Works

Work Performance Management (WPM) is a methodology developed by Mosaic Project Services Pty Ltd to offer a simple, robust solution to the challenges of providing rigorous project controls information on projects that cannot (or are not) using CPM and/or EVM. It works by setting an expected rate of working using an appropriate metric, then measuring the actual work achieved to date. Based on this data, WPM can assess how far ahead or behind plan the work currently is, and using this information calculate the likely project completion date and VAC.

The basis of the calculations used in WPM are the same as is used in Earned Schedule (ES), however, WPM is much simpler to set up and use. The only two requirements to implement WPM are:

  • A consistent metric to measure the work planned and accomplished, and
  • A simple but robust assessment of when the work was planned to be done.

Our latest article, How WPM Works, explains in detail the processes and calculations used in WPM, and the outputs produced.

Understanding the current status and projected completion is invaluable management information for Agile and other projects where CPM schedules are not used, and even where a project has a good CPM schedule in place this additional information is useful. Then by plotting the trends for both the current variance (WV) and VAC management also knows how the project is tracking overall.

Download How WPM Works: https://mosaicprojects.com.au/Mag_Articles/AA038_-_How_WPM_Works.pdf

For more on WPM see: https://mosaicprojects.com.au/PMKI-SCH-041.php#Overview

Work Performance Management (WPM)

Work Performance Management (WPM) is a new project controls tool that is being developed by Mosaic Project Services. WPM is designed to calculate the current status, and predicted completion date for any project in a consistent, repeatable, and defensible way. It is primarily intended for use in projects, applying Agile or Lean Construction management approaches, where traditional CPM scheduling cannot be used effectively, but will add value on most projects. The types of projects where WPM can provide an effective controls tool include:

  • Relatively small projects requiring a straightforward controls system
  • Large projects with a single primary deliverable that is easy to measure
  • Large projects using CPM where there is a need to overcome the CPM optimism bias[1]
  • All project applying Agile[2] and Lean Construction approaches where the project team determine the sequence of working
  • Distributed projects[3] where CPM is inappropriate, and management has chosen not to use the ES extension to EVM.

WPM is an easy to use, robust, performance measurement system. The two requirements to implement WPM are:

  • A consistent metric to measure the work planned and accomplished, and
  • A simple but robust assessment of when the work was planned to be done

Based on this data, WPM can calculate how far ahead or behind plan the work currently is, and based on this information, the likely project completion date (assuming work will continue at the current rate). Recording the status and expected completion at each update provides reliable trend information. This means there is no longer any excuse for, a project team, senior management, and/or the organization’s governing body, ‘not to know’ how the work of each project is progressing.

For a more detailed overview of WPM, see: https://mosaicprojects.com.au/PMKI-SCH-041.php#Overview

Or download Overview of WPM: https://mosaicprojects.com.au/Mag_Articles/AA037_-_Overview_of_WPM.pdf


[1]     For more on WPM and the CPM optimism bias see:
https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM-CPM

[2]     For more on applying WPM to Agile and Lean projects see:
https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM-Agile

[3]     For more on applying WPM to distributed projects (and a definition of distributed projects) see: https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM-Dist

Estimating Updates

Over the last couple of weeks, we have been updating the estimating pages on our website, partly in response to the #NoEstimating idiocy.

There is no way an organization that intends to survive will undertake future work without an idea of the required resources, time, and cost needed to achieve the objective and an understanding of the anticipated benefits – this is an elementary aspect of governance. This requires estimating! BUT there are two distinctly different approaches to estimating software development and maintenance:

1.  Where the objective is to maintain and enhance an existing capability the estimate is part of the forward budgeting cycle and focuses on the size of the team needed to keep the system functioning appropriately.  Management’s objective is to create a stable team that ‘owns’ the application. Methodologies such as Scrum and Kanban work well, and the validity of the estimate is measured by metrics such as trends in the size of the backlog.  For more on this download De-Projectizing IT Maintenance from: https://mosaicprojects.com.au/PMKI-ITC-040.php#Process1

2.  Where the objective is to create a new capability, project management cuts in.  Projects need an approved scope and budget which requires an estimate! The degree of detail in the estimate needs to be based on the level of detail in the scope documents. If the scope, or objectives, are only defined at the overall level, there’s no point in trying to second guess future developments and create an artificially detailed estimate. But, with appropriate data high level estimates can be remarkably useful. Then, once the project is approved, normal PM processes cut in and work well. Some of the sources of useful benchmarking data are included in our update estimating software list at: https://mosaicprojects.com.au/PMKI-SCH-030.php#Cost

The #NoEstimating fallacies include:

The fantasy that software is ‘different’ – its not! All projects have a degree of uncertainty which creates risk. Some classes of project may be less certain than others, but using reliable benchmarking data will tell you what the risks and the range of outcomes are likely to be.

Estimates should be accurate – this is simply WRONG (but is a widely held myth in the wider management and general community)! Every estimate of a future outcome will be incorrect to some degree.  The purpose of the estimate is to document what you thought should occur which provides a baseline for comparing with what is actually occurring. This comparison highlights the difference (variance) between the planned and actual to create management information. This information is invaluable for directing attention towards understanding why the variance is occurring and adjusting future management actions (or budget allowances) to optimize outcomes.

Conclusion

The fundamental flaw in #NoEstimating is its idiotic assumption that an organization that commits funding and resources to doing something without any concept of how long its is going to take, or what it will cost will survive.  Good governance requires the organizational leadership to manage the organization’s assets for the benefit of the organization’s stakeholders. This does not preclude risk taking (in many industries risk taking is essential). But effective risk taking requires a framework to determine when a current objective is no longer viable so the work can be closed down, and the resources redeployed to more beneficial objectives. For more on portfolio management and governance see: https://mosaicprojects.com.au/PMKI-ORG.php  

In summary #NoEstimating is stupid, but trying to produce a fully detailed estimate based on limited information is nearly as bad.  Prudent estimating requires a balance between what is known about the project at the time, a proper assessment of risk, and the effective use of historical benchmarking data to produce a usable estimate which can be improved and updated as better information becomes available.  For more on cost estimating see: https://mosaicprojects.com.au/PMKI-PBK-025.php#Process1

Costain vs Haswell Revisited

One of the ways the law tries to maintain consistency across multiple court cases in literally hundreds of court rooms is by following the same decision-making process used in previous cases to decide an outcome where similar matters are in dispute. This has the advantage of providing a degree of certainty, or at least consistency in the way laws and contracts are interpreted. But can make the law relatively slow to change when business practice changes. However, there are times when the Judges identify problems well before the practitioners! Costain Ltd v Charles Haswell & Partners Ltd [2009] EWHC B25 (TCC) (24 September 2009) is one example. This case related to the construction of the eleven separate structures, that constitute the Lostock and Rivington Water Treatment Works in Lancashire, UK.

As part of this court case, the design and construction contractor, Costain Limited, sought costs from its consulting civil engineer, Charles Haswell & Partners Ltd (Haswell), for the cost of delays caused by incorrect geotechnical advice provided by Haswell. Costain alleged that Haswell’s original design for pre-foundation ground treatment works failed to achieve the specified design criteria for two of the eleven project structures. This resulted in the need for unplanned piling works to support the two structures, which Costain alleged caused a critical delay to the project. As a consequence, Costain was seeking to recover the costs of the delay (prolongation costs) from Haswell.

The quantum experts in the case agreed on two tests for establishing Costain’s entitlement to prolongation costs:

  • First, whether the assumed delay to completion caused by the remedial piling had crystallised into the same actual delay to the completion of the project some sixteen months later, and
  • Second, whether all of the project’s activities were delayed by the piling to just two of the eleven structures.

The parties’ programming experts agreed on a common methodology for assessing the delay, which the judgment refers to as a ‘time impact analysis’ or ‘windows slice analysis’. The method described in the judgement appears the same as the Time Impact Analysis defined in the SCL Delay and Disruption Protocol and AACEi MIP 3.7 (for more detail on this see: https://mosaicprojects.com.au/PDF_Papers/P216_Assessing_Delay_The_SCL_Options.pdf).

There were some points of disagreement between the experts but ultimately, the Court found that the remedial piling on two structures was critical to the project at the time considered in the ‘windows analysis’  noting the experts have agreed that the delays to the RGF and IW were critical delays since those buildings were on the critical path of the project at the relevant time.  Ordinarily therefore one would expect, other things being equal, that the project completion date would be pushed out at the end of the job by the same or a similar period to the period of delay to those buildings.  However, as experience shows on construction sites, many supervening events can take place which will falsify such an assumed result.  For example, the Contractor may rearrange his programme so that other activities are accelerated or carried out in a different sequence thereby reducing the initial delays. [Clause 233]

The assumption underpinning the expert’s ‘window’ analysis showing that a critical delay had occurred and the entitlement to a delay was based on the premise that the work on the rest of the project would follow the logic as shown in the CPM network. The Court rejected this assumption because the assumed flow-on of the delay to the overall completion of the works was not demonstrated: ‘I find that it has not been shown by Costain that the critical delay caused to the project by the late provision of piled foundations to the RGF and IW buildings necessarily pushed out the contract completion date by that period or at all’. [Clause 200 (ii)]

The second test asked whether a delay to work on part of the project would cause all of the project’s activities to be prolonged. In considering this test, the Court rejected Costain’s assumption that the remedial piling to two of the structures on the project prolonged all eleven structures: ‘If the contractor establishes [a critical, excusable delay], he is entitled to an extension of time to the whole project including, of course all those activities which were not in fact delayed … But the contractor will not recover the general site overheads of carrying out all the activities on site as a matter of course unless he can establish that the delaying event to one activity in fact impacted on all the other site activities’. [Clause 183-184]

The Court also found no evidence has been called to establish that the delaying events in question in fact caused delay to any activities on site apart from the RGF and IW buildings.  That being so, it follows, in my judgment, that the prolongation claim advanced by Costain based on recovery of the whole of the site costs of the Lostock site, fails for want of proof’. [Clause 185]

Costain failed in its claim for time related prolongation costs and only recovered the additional costs of installing the piled foundations, because ‘In the absence of any analysis between all the operative delays from the start to the finish, which is absent in this case, in my judgment it is simply not possible for the Court to be satisfied on the balance of probabilities that the assumption upon which this part of Costain’s case depends, is correct’. [Clause 235]

Conclusion – Distributed Projects are Different!

The fundamental problem outlined above was caused by the distributed nature of the project work. The Critical Path Method (CPM) assumes there is one best way to accomplish the work of the project and this is described in the schedule. In distributed projects there are multiple different ways the work could be accomplished. Therefore, any delay analysis technique based on the assumption that the sequence of work shown in a CPM schedule is the only way to accomplish the work is unlikely to prove the delay.  A different approach is needed!

We are working on this challenge.

  • Scheduling Challenges in Agile & Distributed Projects defines the problem and classifies four different types of project from a CPM and controls perspective. Using this classification, the Lostock and Rivington Water Treatment Works was a ‘Class 4’ project where a CPM schedule was imposed, but is unlikely to prove effective. Distributed projects fall under Class3, where a detailed CPM schedule is not accepted as an effective controls approach – different processes are needed.

  • Predicting Completion in Agile & Distributed Projects (due for publication in the May edition of PMWJ) will define a process for measuring progress and predicting completion in Class 3 projects.

  • Assessing Delays in Agile & Distributed Projects (due for publication in the June edition of PMWJ) will define a process for reliably determining the effect of delay or disruption in Class 3 projects.  

As work progresses, we will be updating the Schedule control in Agile and Distributed projects section of the Mosaic website and welcome feedback: https://mosaicprojects.com.au/PMKI-SCH-010.php#Issues-A+D  

The full Costain judgement can be downloaded from: https://mosaicprojects.com.au/PMKI-ITC-020.php#Cases

Scheduling Challenges in Agile & Distributed Projects

Our paper looking at the scheduling challenges in agile and distributed projects has been published in the February 2003 edition of PM World Journal: https://pmworldjournal.com/

Critical path theory is based on an assumption that to deliver a project successfully there is one best sequence of activities to be completed in a pre-defined way. Consequently, this arrangement of the work can be modelled in a logic network. However, while CPM has proved to be an effective controls tool for many types of projects, it is equally apparent the CPM paradigm does not apply to a wide range of other project types including soft projects and distributed projects.

The focus of this paper is to:

  • Briefly define the management assumptions that support the use of CPM scheduling, its origins, and limitations
  • Develop a classification framework of project characteristics to help define the potential usefulness of CPM scheduling
  • Briefly describe some of the management approaches currently used in non-CPM projects including agile and lean, their benefits and limitations
  • Consider the application of the framework discussed above applied to a typical wind farm project
  • Develop general recommendations for the management of non-CPM projects focused on optimizing the efficient use of resources.

Based on this foundation, two additional papers will look at:

  1. Implementing a robust system for reporting progress and predicting completion in agile and distributed projects that can be applied to any class of project.
  2. Assessing delay and disruption in agile and distributed projects where the use of a CPM schedule is not viable.

Download Scheduling Challenges in Agile & Distributed Projects: https://mosaicprojects.com.au/PDF_Papers/P208_Scheduling_Challenges_in_Agile_+_Distributed_Projects.pdf  

For more on this topic see: https://mosaicprojects.com.au/PMKI-SCH-010.php#Issues-A+D