KM in project-based & temporary organisations: Part 8 – An agile approach to program management

This article is part 8 in a series of articles on knowledge management (KM) in project-based and temporary organisations.

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 was the overall program management approach that I used, as well as the project management approaches used by the six project managers.

In this article, I discuss this approach, with the aim of stimulating the further development and application of agile methods to program management.

Agile methods

An agile method relies upon incremental and iterative completion of goals with a self-managing team. It is often presented in opposition to a “waterfall” process (Figure 1) that sequentially gathers requirements, completes a design, and then builds a final product.

Hirotaka Takeuchi and Ikujiro Nonaka proposed the core agile concept of iterative, continuous delivery in 1986¹. They are acknowledged² as the inspiration for Scrum (Figure 2), a popular methodology for delivering IT projects today.

Co-created by Ken Schwaber, Jeff Sutherland, John Scumniotales and Jeff McKenna, the term “Scrum” is often used interchangeably with “agile”. However, properly speaking, “Scrum” is a specific methodology whereas “agile” can be any technique that focuses on iterative delivery and empowerment. Agile primarily focuses on efficiently segmenting the business processing cycle of the problem-solving pattern into “chunks” that can be executed in parallel.

While initially focused on IT projects, agile methods have now been extended to wider business and management applications. For example, the late Mike Beedle, an Agile Manifesto signatory and described as a business agility visionary, developed Enterprise Scrum which “offers a way to agilize and entire company from top to bottom (hierarchy), or from “side to side” (collaboration), or even in subsumption (dependent knowledge levels).”

Program management vs. project management

Before exploring the application of agile methods 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 Differences³, 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:

1. 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.

2. Program management is entirely cross-functional, while project management focuses on a single function, or limited cross-functional alignment at best.

3. Program management integrates the individual elements of the projects in order to achieve a common objective.

Additionally:

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 focuses on the application of agile methods 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.

Applying agile methods to program management

With the degradation of 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 additional 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, as discussed in part 7 of this series

• 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.

These requirements have parallels with the three questions asked in the daily meetings that are a fundamental part of the Scrum framework mentioned above.

The additional requirements had the effect of turning each three-monthly reporting period into an incremental and iterative agile stage. Breaking down the overall program timeline into the smaller iterative cycles meant that the project teams were focused on reaching immediate and much more readily achievable goals, rather than feeling overwhelmed and highly stressed by everything that must be achieved in the overall program.

To emphasise the three-monthly cycles, they were also tracked through Basecamp where information from across the program was also shared.

Critically, through the three-monthly iterative approach, unexpected “Black Swan” events that could otherwise have derailed the Hawkesbury-Nepean River Recovery Program were identified and addressed at the earliest possible opportunity.

In his book The Black Swan: The Impact of the Highly Improbable⁴ 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 example of a “Black Swan” event experienced during the Hawkesbury-Nepean River Recovery Program is delays in the water sharing plan for the Hawkesbury-Nepean catchment, which created serious 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.

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. I was not the line manager of the project managers, rather having the role of a central coordinator. The recommendations of the Final Report⁵ 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.

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.

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.

See also: Does discomfort help to explain the effectiveness of agile and other incremental / cyclic methods?

Editor’s note: This article was first published on 3 March 2016 as “Case study: An agile approach to program management.” It has been updated and added to the series of articles on knowledge management (KM) in project-based and temporary organisations.

Header image source: Alvaro Reyes on Unsplash.

References: