In May 2009, the Australian Government announced up to $77.4 million of funding for the Hawkesbury-Nepean River Recovery Program with the aim of improving the health of an iconic river system in New South Wales (NSW), Australia. The program comprised seven projects carried out by six different NSW Government agencies.
I commenced in the role of overall Program Manager in June 2009. The program concluded two and a half years later, having exceeded its intended outcomes. It was completed on time and under budget, despite significant challenges, and subsequently won two major awards.
Pivotal to the success of the Hawkesbury-Nepean River Recovery Program were the management approaches that I and the six Project Managers used. I have recently become aware of the agile movement and its alternative approaches to software development, and have been struck by how closely the approach I used in the program corresponds to the values and principles of agile.
Agile approaches have application beyond software development, so in this article I discuss the agile approach I took to program management of the Hawkesbury-Nepean River Recovery Program, with the aim of stimulating the further development and application of this approach.
The agile movement
The agile movement has advanced alternative approaches to software development. As described in the Agile Manifesto, the agile movement values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,
the agile movement values the items on the left more.
The agile movement follows these 12 principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity – the art of maximizing the amount
of work not done – is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
The Scrum Training Series advises that Scrum is an agile framework for complex work. Rather than taking a traditional “waterfall” approach (Figure 1), Scrum is iterative and incremental.
Figure 1. Traditional “waterfall” process (source: Scrum Reference Card)
Last century, the work of most people was defined and predictable, with little need for innovation. But now, we need to adapt to change more quickly, and cope with greater uncertainty. Scrum achieves this through “Sprints” that are one to four weeks long (Figure 2).
Figure 2. Scrum framework (source: scruminc.)
The key roles in Scrum are:
- Product Owner: Single individual responsible for return on investment (ROI), and the final arbiter of requirements questions. Their focus is more on the what than the how.
- Team: This is a cross-functional group that attempts to create a tangible product increment every Sprint. The team is collaborative and self-organising.
- ScrumMaster: Has no management authority over the team, and doesn’t have a project manager role. Project management responsibilities are split up between the Product Owner and the Team, with the ScrumMaster acting more as a facilitator.
The differences between program and project management
Before exploring an agile approach to program management, an understanding of the differences between program and project management is necessary.
As discussed in the paper Program and Project Management: Understanding the Differences1, the terms “program management” and “project management” are often used interchangeably, but the two are actually distinctively different disciplines. The three most important differences are:
- Program management is strategic in nature, while project management is tactical in nature … program management focuses on achievement of the intended strategic business results through the coordination of multiple projects.
- Program management is entirely cross-functional, while project management focuses on a single function, or limited cross-functional alignment at best.
- Program management integrates the individual elements of the projects in order to achieve a common objective.
Coordinated management of multiple projects means that the activities for each project are synchronized through the framework of a common lifecycle executed at the program level. If an organization is using a phase-gate lifecycle model for example, all projects within the program pass through the phases and gates simultaneously. Program management ensures the effective coordination and synchronization of the multiple projects through the lifecycle.
This article explores an agile approach to program management rather than project management, in this case an agile approach to the overall program management of the Hawkesbury-Nepean River Recovery Program rather than any of its seven projects.
Black swans and program management
In his book The Black Swan: The Impact of the Highly Improbable2 Nassim Nicholas Taleb proposes what has become known as “Black Swan Theory”.
He uses the unexpected discovery of black swans to highlight the limitations of knowledge:
Before the discovery of Australia, people in the old world were convinced that all swans were white, an unassailable belief as it seemed completely confirmed by empirical evidence. The sighting of the first black swan might have been an interesting surprise for a few ornithologists (and others extremely concerned with the coloring of birds), but that is not where the significance of the story lies. It illustrates a severe limitation to our learning from observations or experience and the fragility of our knowledge. One single observation can invalidate a general statement derived from millennia of confirmatory sightings of millions of white swans.
He describes such “Black Swan” events as having three attributes:
First, it is an outlier, as it lies outside the realm of regular expectations, because nothing in the past can convincingly point to its possibility. Second, it carries an extreme impact. Third, in spite of its outlier status, human nature makes us concoct explanations for its occurrence after the fact, making it explainable and predictable.
He states that rather than trying to predict such events, we should instead build resilience against the impacts of negative “Black Swans” and be poised to take advantage of positive ones.
There’s no shortage of examples of programs that have failed or run over time or budget due to the occurrence of unexpected events. However, because of our tendency to concoct explanations after the fact, we draw the wrong conclusions about what went wrong, for example we believe that our risk management was inadequate.
But while risk management can often be done better, Black Swan Theory tells us that it is impossible to anticipate outlier events. Rather, we need frameworks that enable us to quickly respond to such events when they do occur.
An agile approach to program management
With weed infestations in the Hawkesbury-Nepean River having been the focus of considerable media attention, both the Australian and NSW Governments were keen to ensure that the Hawkesbury-Nepean River Recovery Program was delivered successfully in accordance with its original objectives.
Consistent with this, the Australian Government required three-monthly progress reporting, rather than reports on the normal six-monthly cycle. The reports were required to be reviewed by a Program Steering Committee before being submitted to the Australian Government. I recommended that the Program Steering Committee primarily comprise the Project Managers of the seven projects, and determined that the three-monthly reports the Project Managers submitted to the Program Steering Committee at the review meeting would include more than just the basic reporting of progress.
I also included the following requirements in the three-monthly project reports:
- An explanation of any delays that occurred in the reporting period and the actions to be taken to address the delays.
- Risk assessment review, involving the review of the project schedule of the comprehensive risk management report prepared at the beginning of the program.
- A detailed explanation of the work to be undertaken in the next reporting period.
- Any potential difficulties, issues or risks anticipated in the next reporting period and the actions that would be taken to mitigate these potential difficulties.
To emphasise the three-monthly cycles, they were also tracked through Basecamp where information from across the program was also shared.
These requirements had the effect of turning each three-monthly reporting period into an incremental and iterative stage.
Through this approach, unexpected issues that could otherwise have derailed the Hawkesbury-Nepean River Recovery Program were identified and addressed at the earliest possible opportunity. An example is delays in the water sharing plan for the Hawkesbury-Nepean catchment, which created problems in regard to securing water savings from the program. The three-monthly incremental and iterative cycle created the drive to quickly identify this issue and resolve it through an interim legislative amendment.
The three-monthly cycles at program management level equate to the Sprints of one to four weeks at a project level. Cycles shorter than three months at a program management level would negatively impact on the effective management of the projects, and cycles longer than three months would make issue identification and resolution too slow.
As Program Manager, I was located within the former NSW Office of the Hawkesbury-Nepean, a separate entity to the agencies responsible for the projects. The recommendations of the Final Report3 of the Hawkesbury-Nepean River Recovery Program include that:
Future programs should appoint a central coordinating body with overall responsibility for the program. The Office of the Hawkesbury-Nepean played a critical role as broker and coordinator for the Hawkesbury-Nepean River Recovery Program.
I was not the line manager of the Project Managers, but effectively more a facilitator which equates to the ScrumMaster role. The Program Steering Committee equated to the Scrum Team, and the Australian Government was the Product Owner.
The Program Steering Committee always met face-to-face for its three-monthly meetings despite being widely dispersed, and for much of the program the meetings were followed by one or two days of field visits to inspect sites from all seven projects. This further enhanced both the three-monthly cycle emphasis and knowledge sharing across the projects of the program.
Based on an exploration of an agile approach to the program management of the Hawkesbury-Nepean River Recovery Program, the following recommendations are made:
- Program management Sprints should have a duration of three months.
- Programs need mechanisms or measures to clearly establish the Sprints as three-monthly iterative increments.
- The project managers of the projects within a program should make up the Scrum Team.
- An independent central coordinating body should be established to play the role of ScrumMaster.
Comments on these recommendations or any aspect of this article are most welcome.
Image source: Hawkesbury-Nepean River Recovery Program Steering Committee visit to Penrith Weir by Bruce Boyes is licenced by CC BY 2.0.
- Martinelli, R. and Waddell, J. (2005). Program and Project Management: Understanding the Differences. PMForum. ↩
- Taleb, N.N. (2007). The Black Swan: The Impact of the Highly Improbable, Random House. ↩
- NSW Government (2013). Hawkesbury-Nepean River Recovery Program – Final Report. NSW Department of Primary Industries, Office of Water, Sydney. ↩