The DCMA 14-Point schedule assessment process was part of a suite of systems developed by the Defense Contract Management Agency (DCMA) starting in 2005. Its purpose was to standardize the assessment by DCMA staff of contractor developed Integrated Master Schedules.
The DCMA is an agency of the United States federal government reporting to the Under Secretary of Defense for Acquisition and Sustainment, responsible for administering contracts for the Department of Defense (DoD), and other authorized federal agencies. It was created in February 1990 as the Defense Contract Management Command (DCMC) within the Defense Logistics Agency (DLA), then in March 2000, the DCMC was renamed as the Defense Contract Management Agency (DCMA) and made an independent agency.
The DCMA works directly with defense suppliers and contractors to oversee their time, cost, and technical performance, by monitoring the contractors’ performance and management systems to ensure that cost, product performance, and delivery schedules comply with the terms and conditions of the contracts.
The DOD had published specifications for an Integrated Master Schedule since 1991. In March 2005, the USA Under Secretary of Defense for Acquisition and Technology (USDA(AT&L)) issued a memo mandating the use of an Integrated Master Schedule (IMS) for contracts greater than $20 million and requiring the DCMA to establish guidelines and procedures to monitor and evaluate these schedules.
In response, the DCMA developed their 14-Point Assessment Checks as a protocol to be used for CPM schedule reviews made by their staff. The initial documentation describing this protocol appears to have consisted of an internal training course provided by the DCMA. The training was deployed as an on-line course in late 2007 and updated and re-issued on 21st November 2009 (none of these training materials appear to be available – there may have been other changes).
The validity of some of the ‘checks’ are questionable, they do not conform to standards set by various scheduling authorities.
And, the relevance of the DCMA 14-Points is also questionable. The publication of the U.S. Government Accountability Office (GAO) Schedule Assessment Guide in December 2015 appears to provide a more realistic basis for assessment.
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.
The Port of Melbourne is the largest port for containerized and general cargo in Australia. Anyone visiting the port, or Melbourne generally, would think the Yarra River must have been a useful harbor at the time of settlement, and the various docks were built to enhance this natural asset. Modern maps, and the view out to Port Philip Bay reinforce this concept.
Aerial view of the Port of Melbourne
View to the South West of the port and bay.
The truth is very different, almost everything shown in the pictures above is man made.
Settlement
The settlement of Melbourne started in 1835. To put this date in context, it is 20 years after the Battle of Waterloo and 2 years before the coronation of Queen Victoria[1]. The original settlement was located in the area of the current day CBD. This site was chosen for its access to fresh water from the stream running through the site, rather than its potential as a port.
An underwater sand bar at the entrance of the Yarra River ruled out the entry of vessels drawing more than about nine feet of water and access up river was blocked at ‘The Falls’, a rock bar running across the river which was used as a crossing point by the local Aboriginal peoples.
This limited access meant ships arriving from overseas had to drop anchor in Hobson’s Bay, or moor at the Sandridge (Port Melbourne) Pier. Passengers and goods then had to walk, use carts, or be transshipped up the river in smaller vessels or ‘lighters’ as they were called. Costs were excessive! It has been recorded that it cost 30 shillings per ton (half the entire freight costs for the voyage from England) to have goods taken the eight miles from sea to city.
The discovery of gold in 1850 exacerbated the problems of the port. In just one week in 1853 nearly 4000 passengers from 138 ships arrived in Hobson’s Bay and in 1858 the average delay moving goods from the port into the city was three weeks.
The initial solution to this problem was the construction in 1854 of the first steam railway in Australia from piers built at Sandridge (now the suburb of Port Melbourne) to the city this railway is discussed in The First Steam Powered Railway in Australia, but a better solution was needed for cargo.
Developing the Port of Melbourne – 1839 to 1877
The Yarra River was progressively improved to facilitate trade. Jetties were built along the banks of the river from 1839 onwards funded by wharfage charges. This 1857 photograph shows the wharfs downstream from ‘The Falls’.
1857 – Yarra River downstream from ‘The Falls’
The 1864 map of Melbourne shows the limitations outlined above were still limiting the development of Melbourne despite the massive influx of money from the Victorian gold rush. The Falls effectively dammed the river causing major flooding and the restrictions caused by the swamps bends and shoals in the Yarra restricted trade.
To overcome the problems, the Melbourne Harbor Trust was formed in 1877 and engaged English engineer, Sir John Coode to recommend solutions.
Starting in 1879 Sir John Coode made three key recommendations: – the development of a canal to improve access for ships, – the demolition of The Falls to reduce flooding, and – the deepening of the narrow entrance to Port Phillip Bay from the ocean.
Based on Sir John’s recommendation, the course of the lower Yarra’s was significantly altered. This visionary feat of engineering involved 2,000 workers for 20 years. The proposal not only significantly shortened travel time up the river for ships, but also created Victoria Harbour and Victoria Dock.
Plan for Coode Canal and Victoria Dock (the dock was changed to a single body of water later)
The original wide loop in the river was eliminated through the construction of the 1.5 km Coode Canal which opened in 1886, and West Melbourne Dock (now Victoria Dock) opened to shipping in 1893. The canal created Coode Island and caused the shallow, narrow and winding Fishermans Bend to be cut off along with other sections of the river including Humbug Reach and the original junction with the Maribyrnong River. The Coode Canal was deepened to 25 feet and widened from 100 to 145 feet in 1902.
The plan to remove ‘The Falls’ involved clearing the reef to a uniform depth of 15 feet 6 inches, at an estimate cost of £20,000. The demolition was complete by 1883, having been funded by a combination of the Victorian Government and the Harbour Trust. The reduction in flooding caused by the improved river flows converted flood plains and swamps into dry land, encouraging the development of South Melbourne discussed in The evolution of South Melbourne. The lake in Albert Park is all that remains of the freshwater lagoons and seasonal swamps South of the Yarra.
The Rip at Port Phillip Heads was also deepened in 1883 using explosives.
Developing the Port of Melbourne – 1902 onward.
The piers at Sandridge (Port Melbourne) continued to be important, but mainly for passengers. A new pier, built to the west of Railway Pier, opened in 1916, called the New Railway Pier. This was renamed Prince’s Pier in 1921. These piers were important locations for the departure and return of troops to the Boer War in South Africa and WW1 &2, as well as the arrival of many thousands of migrants after WW2.
The Piers at Port Melbourne c1950.
The current Station Pier, which replaced the original Railway Pier, was built between 1922 and 1930 and remains the primary passenger arrival point in Melbourne with cruise ships visiting throughout summer. Princes Pier has been demolished.
Meanwhile, most cargo shipments were handled by the Victoria Dock, and by 1908 it was handling ninety per cent of Victoria’s imports. In 1914 its capacity was enlarged by the addition of a central pier and in 1925 the entrance was widened. But with rapidly increasing imports and exports further renovation and development was needed. Also, as ships increased in size there was a need for larger wharves and deeper berths to accommodate them.
The growth of the city also encroached on the Eastern end of the docks. The construction of the Spencer Street Bridge in 1927-28 meant that all port traffic had to be handled further downstream, foreshadowing the need for even more docks, and the expansion of the port towards the West and the bay.
Construction of Spencer St. Bridge
Port development at Coode Island in 1958
To overcome these challenges, the docks spread to the West, and no cover all of the land between the land from Moonee Ponds Creek to the Maribyrnong River, totally absorbing Coode Island.
The original Victoria Dock and the adjacent North Wharf on the river continued to play a vital role, handling up to half of the Port of Melbourne’s trade until the shift to containerisation and then the construction of the Bolte Bridge in 1999, made the old port facilities redundant. From 2000 the Victoria Docks became Docklands, and were revitalised as commercial and residential areas, while the Port of Melbourne continues to expand downstream.
The last major expansion of the port was the construction of Webb Dock at the mouth of the Yarra River in 1960.
Webb dock at the mouth of the Yarra
Improvements in both wharf-side and land-side facilities continue, but despite all of these improvements, the Port of Melbourne is approaching capacity, the next developments are not far off but need political decisions on the location, either in Port Phillip Bay or Westernport Bay to allow the next transformation to start.
Footnote on the names
The rock bar called ‘The Falls’ in this post was called Yarro- Yarro meaning “waterfall or ever flowing” by the local peoples. The river was known as the Birrarung by the Wurundjeri people. The first settlers confused the names and called the river Yarra.
The , Yarro Yarro Falls were important to the local Aboriginal tribes, the Woiwurrung and the Boonerwrung, who used it as a crossing point between their lands, in order to negotiate trade and marriages. This was the only means of crossing the Yarra River until ferries and punts began operating c 1838. The first bridge was constructed c 1845, a little further upstream, at the location very near what is now known as the ‘Princes Bridge’.
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:
A definition phase undertaken by the client organization to define the capabilities of the product being developed
A procurement phase where the client selects a delivery agent for the development of the product
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
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.
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.
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).
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.
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
We all know (or should know) that when a project is running late, the predicted completion date calculated by the ‘critical path method’ (CPM) at an update tends to be optimistic, and this bias remains true for predictions based on simple time analysis as well as schedule calculations made using resource leveling.
There are two primary reasons for this:
The assumption in CPM is that all future work will occur exactly as planned regardless of performance to date. The planned durations of future activities do not change.
The burning of float has no effect of the calculated completion date until after the float is 100% consumed and the activity become critical.
Having an optimistic schedule for the motivation of resources to perform in not all bad – the updated CPM schedule shows the minimum level of performance needed to stop the situation deteriorating. The problem is more senior managers also need a reliable prediction of when the project can realistically be expected to finish and CPM cannot provide this. A more realistic / pessimistic view is obtained by apply the principles of Work Performance Management (WPM) to a CPM schedule, using ‘activity days’ taken from the CPM schedule as the metric.
Our latest article, WPM Solves CPM Optimism, uses a simple CPM schedule to demonstrate the differences in the calculated project completion dates between CPM and WPM. The value of WPM is stripping away the optimism bias inherent in CPM scheduling (particularly early in the project), thereby providing management with a clear indication of where the project is likely to finish if work continues at the current levels of productivity. These predictions are not a statement of fact, change the productivity and you change the outcome! A similar approach can be used to assess projected completion dates based on a simple manual bar chart.
The publication of BS 202002:2023 – Applying benefits management on portfolios, programmes and projects, last year has prompted an update to our Value and Benefits Realization page, including a link to the new Standard’s home page.
As we know, organizations invest resources in projects to derive benefits and create value. But those benefits don’t happen by themselves, they need to be managed. BS 202002:2023 is a new British standard on how to deliver the planned benefits of projects, programmes and portfolios to create value for the organization and its customers.
While the Standard is quite expensive to buy, all of the publications on the Mosaic ‘Value and Benefits’ page are free to download and use and cover: – Value and Benefits Overview, – Defining project success, – Benefits Management, – Value Management and Value Engineering, and – Useful External Web-links & Resources.
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:
Developing the realistic time and cost estimates needed to enter into a contract.
Monitoring and controlling the project work to optimize the delivery of the contracted requirements within the contract timeframe.
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.
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
Pat Weaver
Lynda Bourne
Aavssitedev's Blog