The Quest for Control.

In our paper A Brief History of Agile we looked at the evolution of the agile software development approach which briefly covered the ‘Waterfall Dead-end’.  This post looks in more detail at the factors that made Waterfall appear attractive to a large number of competent people although most of these were not involved in developing major software programs.  The people actually involved in managing major software developments were always largely in favor of iterative and incremental development approaches to software development which evolved into Agile some 20+ years later. The focus of this discussion is on the structured ‘Waterfall’ approach to developing software. 

Just for clarification, Waterfall has never been used for other types of projects, and is not a synonym for plan-driven, predictive projects.

In most hard[1] projects, the design has to be significantly progressed before much work can be done, and the work has to be done in a defined sequence. For example, before concreting this house slab, the precise position of every plumbing fitting and wall has to be known (ie, the Architectural plans finalized), so the right pipe of the right size is positioned to be exactly under a fitting or centered within a wall line.  The loadings on the slab also have to be known so the engineering design has correctly calculated the required thicknesses of slab, ground beams, and steel reinforcement. Once all of the necessary design has been done, the various trade works have to be completed in the right sequence and checked, before the slab can be poured. Once the concrete is set, any change is very expensive!  

This is quite different to software projects, which are a class of soft project that is particularly amenable to incorporating change and being developed incrementally and iteratively to minimize test failures and rework. This iterative and incremental approach was being used by most major software development projects prior to the introduction of Waterfall in 1988, so what was it that made the Waterfall concept seem attractive?  To understand this, we need to go back 30 years before the Agile Manifesto was published, to the USA Defense Department of the 1980s:

• The Cold war was in full swing and the fear of Russia’s perceived lead in technology was paramount. Sputnik 1 had been launched in 1957 and the USA still felt they were playing catch-up.
• Defense projects were becoming increasingly complex systems of systems and software was a major element in every defense program.
• Complexity theory was not generally understood, early developments were largely academic theories[2].
• CPM was dominant and appeared to offer control of workflows.
• EVM appeared to offer control of management performance.
• Disciplined cost controls were more than 100 years old.

The three dominant controls paradigms CPM, EVM, and Cost control appeared to offer certainty in most projects, but there seemed to be very little control over the development of software. This was largely true, none of these approaches offer much assistance in managing the creative processes needed to develop a new software program, and the concept of Agile was some 20+ years in the future.  

In this environment, Waterfall appeared to offer the opportunity to bring control software projects by mimicking other hard engineering projects:

1. The management paradigm most familiar to the decision makers was hard engineering – you need the design of an aircraft or missile to be close to 100% before cutting and riveting metal – computers were new big pieces of ‘metal’ why treat them differently?
2. For the cost of 1 hour’s computer time, you could buy a couple of months of software engineering time – spending time to get the design right before running the computer nominally made cost-sense. 
3. The ability to work on-line was only just emerging and computer memory was very limited. Most input was batch loaded using punch cards or tape (paper or magnetic). Therefor concept of: design the code right, load-it-once, and expect success may not have seemed too unrealistic.

The moon-landing software
written by Margaret Hamilton
(c 1969)

The problem was nothing actually worked. Iterative and incremental development means you are looking for errors in small sections of code and use the corrected, working code as the foundation for the next step.  Waterfall failures were ‘big-bang’ with the problems hidden in 1000s of lines of code and often nested, one within another. Finding and fixing errors was a major challenge.

To the US DoD’s credit, they ditched the idea of Waterfall in remarkably quick time for a large department. Waterfall was formally required by the US DoD for a period of 6 years between 1988 and 1994, before and after iterative and incremental approaches were allowed.  

The reasons why the name Waterfall still drags on is covered in two papers:
A Brief History of Agile
How should the different types of project management be described?

Conclusion

While Waterfall was an unmitigated failure, significantly increasing the time and cost needed to develop major software programs, the decision to implement Waterfall by the US DoD is understandable and reasonable in the circumstances.  The current (1980s) software development methods were largely iterative and incremental, and were failing to meet expectations. The new idea of Waterfall offered a solution. it was developed by people with little direct experience of major software development (who were therefore not tarnished with the perceived failures). The advice of people with significant software development experience was ignored – they were already perceived to be failing. The result was 6 years of even worse performance before Waterfall was dropped as a mandated method. The mistake was not listening to the managers with direct experience of developing major software systems. But these same people were the ones managing the development of software that was taking much longer and costing far more than allowed in the budget.  

The actual cause of the perceived failures (cost and time overruns) was unrealistic expectations caused by a lack of understanding of complexity leading to overly optimistic estimates. Everyone could see the problems with the current approach to software development and thought Waterfall was a ‘silver bullet’ to bring control to a difficult management challenge.

Unfortunately, the real issues were in a different area. Underestimating the difficulties involved in software development and a lack of appreciation of the challenges in managing complex projects. This issue is still not fully resolved, even today, the complexities of managing major software developments are underestimated most of the time.

For more on the history of Agile, see: https://mosaicprojects.com.au/PMKI-ZSY-010.php#Agile

---

[1] The definition of hard and soft projects can be found at: https://mosaicprojects.wordpress.com/2023/01/21/hard-v-soft-projects/

[2] For more on complexity see: https://mosaicprojects.com.au/PMKI-ORG-040.php#Overview

Understanding the Iron Triangle and Projects

The concept of the iron triangle as a framework for managing projects has long past its use-by date, almost everyone, including PMI, recognize the challenges faced by every project manage are multi-faceted, and multi-dimensional – three elements are not enough. But dig back into the original concepts behind the triangle, and you do uncover a useful framework for defining a project, and separating project management from general management.

The Iron Triangle

The origin of the project management triangle is accredited to Dr. Martin Barnes. In 1969[1], he developed the triangle as part of his course ‘Time and Money in Contract Control’ and labelled three tensions that needed to be balanced against each other in a project: time, cost, and output (the correct scope at the correct quality). The invention of the iron triangle is discussed in more depth in The Origins of Modern Project Management.

The concept of the triangle was widely accepted, and over the years different versions emerged:

• The time and cost components remained unchanged, but the ‘output’ became variously scope or quality and then to scope being one of the three components and quality in the middle of the triangle (or visa versa). These changes are semantic:
  • you have not delivered scope unless the scope complies with all contractual obligations including quality requirements
  • achieving quality required delivering 100% of what is required by the client.
    
    
• The shift from tensions to constraints changes the concept completely. A constraint is something that cannot be changed, or requires permission to change. Tensions vary based on external influences, the three tensions can work together or against each other.  
   
• The introduction of iron!  It seems likely, the iron triangle, based on the concept of the iron cage from Max Weber’s 1905 book The Protestant Ethic and the Spirit of Capitalism’s English translation (1930). The iron cage traps individuals in systems based purely on goal efficiency, rational calculation, and control[2].

So, while the concept of the iron triangle and/or triple constraint has been consigned to history, the original concept of the triangle, as a balance between the three elements that are always present in a project still has value.

Defining a project

Understanding precisely what work is a project, and what is operational (or some other forms of working) is becoming increasingly important as various methodologies such as Lean and Agile span between the operations and project domains. 

Some of the parameters used to define or categorize projects include:

• Hard -vs- Soft projects, see:
  https://mosaicprojects.wordpress.com/2023/01/21/hard-v-soft-projects/
  
  
• Size and Complexity usually seen as a continuum:

• The Methodology used to manage the work, ranging from Agile to Directed, see How should the different types of project management be described?

There are many other ways to categorize projects, some of which are discussed in the papers at: https://mosaicprojects.com.au/PMKI-ORG-035.php#Class. But these classifications do not really provide a concise definition of a project. And, while there are many different definitions, we consider the best definition of a project to be: 

Project:  A temporary organization established to accomplish an objective, under the leadership of a person (or people) nominated to fulfil the role of project manager[3].

The two key elements being:

1. The project is temporary, the project delivery team or organization closes and its people reallocated, or terminated, when the objective is achieved, and
   
   
2. The project is established to accomplish an objective for a client which may be internal or external to the delivery organization.

The concept of a project being temporary is straightforward (even though it is often ignored). Departments that are set up and funded to maintain and enhance plant, equipment and/or software systems on an ongoing basis are not projects, and neither is most of their work. We discussed this several years back in De-Projectizing IT Maintenance, and the concept seems to be becoming mainstream with the concept of ‘flow’ being introduced to Disciplined Agile.

The value of the project management triangle is identifying the three mandatory elements needed to describe the client’s objective. There are usually a number of additional elements but if any these three are not present, the work is not a project:

1. The expected outcome is understood. The project is commissioned to deliver a change to the status quo. This may be something new, altered, and/or removed; and the outcome may be tangible, intangible or a combination.  The outcome does not need to be precisely defined to start a project, and may evolve as the project progresses, but the key element is there is an understood objective the project is working to achieve.  
     
2. There is an anticipated completion time. This may be fixed by a contract completion date, or a softer target with some flexibility.  However, if there are no limitations on when the work is expected to finish (or it is assumed to be ongoing), you are on a journey, not working on a project. 
    
3. There is an anticipated budget to accomplish the work. Again, the budget may be fixed by a contract, or a softer target with some flexibility.  The budget is the client view of the amount they expect to pay to receive the objective. The actual cost of accomplishing the work may be higher or lower and who benefits or pays depends on the contractual arrangements. 

Conclusion

Understanding the difference between project work and non-project work is important.  Project overheads are useful when managing the challenges of delivering a project, including dealing with scope creep, cost overruns, schedule slippage, and change in general. The mission of the project team is to deliver the agreed objective as efficiently as possible.

The objective of an operational department is to maintain and enhance the organizational assets under its control. This typically needs different approaches and focuses on a wider range of outcomes.  Many techniques are common to both operational and project work, including various agile methodologies and lean, and many management traits such as agility are desirable across the spectrum.  The difference is understanding the overarching management objectives, and tailoring processes to suite.  

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

---

[1] We published and widely circulated this claim after a meeting with Dr. Barns in 2005 at his home in Cambridge. So far no one has suggested an alternative origin.  

[2] For more on the work of Max Weber, see The Origins of Modern Management: https://mosaicprojects.com.au/PDF_Papers/P050_Origins_of_Modern_Management.pdf

[3] The basis of this definition is described in Project Fact or fiction: https://mosaicprojects.com.au/PDF_Papers/P007_Project_Fact.pdf 

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. A definition phase undertaken by the client organization to define the capabilities of the product being developed
2. A procurement phase where the client selects a delivery agent for the development of the product
3. A 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 21^st 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

Predicting project outcomes is important!

The recent cancellation of the 2026 Commonwealth Games by the Victorian Government is a dramatic example of using predicted project outcomes to minimize damage to an organisation. The escalation in the predicted cost of delivery from $2.6 billion to above $6 billion suggests the original bid was wildly optimistic and discovering how such an error occurred should be worthy of enquiry, but that is not the focus of this post.

Once the predicted costs moved to a point where there was no benefit in continuing with the project, it was terminated. While the cancellation could have been done earlier and far more elegantly the fact remains cancelling the project was by far the best decision.

However, to be able to make this type of call, management need information they can rely on. Even then the decision is not simple.

Cost considerations

A decision to cancel a project has to balance: sunk costs, the cost to complete, the expected benefits, and the cost of not completing the project.  The three elements that matter are the cost to complete vs the benefits (sunk costs are lost either way), and the costs of not completing the project.

For more on sunk costs see: https://mosaicprojects.com.au/Mag_Articles/P022_Sunk_Costs.pdf

Time considerations

Time is usually a secondary consideration but can be vital – the Commonwealth Games facilities would need to be open before the games start!  For more normal projects knowing the current projected completion date and the variance at completion are still important for two reasons.

First, the cost of time matters and needs to be included in the cost to complete estimate. Delayed completion may also impact benefits.

Second and more important, time issues tend to emerge as problem well before cost issues show up. A project that is losing time and is expected to finish late will almost inevitably show negative cost variances sooner or later.  Conversely, fixing the root cause of the time issues will often have a positive effect on the overall costs as well.

The problem is most projects do not run systems that are capable of producing a reliable prediction of the expected completion date. Our recent paper Calculating Completion looked at seven different methodologies for managing a project, only two gave reliable predictions of the completion date; these were Earned Schedule and Work Performance Management.

Earned Schedule (ES) was the best option, but implementing ES requires a significant investment in skills and systems. 

Work Performance Management (WPM) achieved similar results to ES without the overhead. All that is required to use the WPM spreadsheet is three bits of information.  To set up the WPM model the amount of work to be accomplished and the time allowed is needed, any metric can be used provided it is applied consistently. This baseline gives you the amount of work expected to be accomplished by a given date. The other bit of information is the actual amount of work achieved by the date.  From this data the predicted completion date is calculated.

The assumption built into WPM is that work will continue at the current rate. If the result is not acceptable, management needs to do something to change the rate of working. If this is not feasible, then the viability of the project needs to be considered and/or the baseline reset to what is achievable. For more on WPM see: https://mosaicprojects.com.au/PMKI-SCH-041.php#Overview

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

Do project plans predict or create the future?

Our latest article, Is Planning Predictive or Persuasive suggests that project controls staff and management place too much emphasis on attempting to develop the ‘perfect plans’ that accurately predicts future outcomes (a passive process that is doomed to failure), and not enough on using the planning and scheduling processes to proactively influence the direction of the project’s future work.

Download Is Planning Predictive or Persuasive from: https://mosaicprojects.com.au/Mag_Articles/AA019_Is_Planning_Predictive_or_Persuasive.pdf

There’s Agile and there’s Agile, understand the difference!

One size does not fit every situation even in an agile world!  The focus of this new article is to identify the differences in management approach needed to maximize value in three different situations where an ‘Agile’ approach can be used.

For any Agile approach to achieve its promise, the upper echelons of the organisation need to become agile aware and adapt the way projects are initiated, funded and governed so that the project team can optimize their use of Agile processes to maximize the creation of value. Download the article from: https://mosaicprojects.com.au/Mag_Articles/SA1060_Agile_Spaces.pdf

For more papers on Managing Agile see: https://mosaicprojects.com.au/PMKI-XTR-010.php#Process1