Building Capacity Through Project Agility.

Author:Booth, Darryl

You are an educated professional, a leader, a driver of business and process improvement. You bring experience and passion and intuition. In our professional lives, however, we've each certainly observed or led projects that flopped in part or in full.

You might never lead a multimillion-dollar software project, but you will lead or participate in important projects. This column introduces a method for approaching projects of any size and for reducing risk. The method is known as Agile.

Agile got its start in software development where--and at great effort--project requirements were routinely specified in writing before programmers or users got a first peek. When we run projects where half or more of our budget is spent writing requirements before our users are engaged, we bear the risk that the result won't delight our users. Then, because these project budgets are often fixed once initiated, there's no capacity to go back and redo (or even optimize) what was delivered. This method is known as Waterfall, a metaphor to illustrate the idea that once water--or in this case, project planning--cascades beyond a certain milestone, there is no going back.

Yet, even with Waterfall's potential pitfalls, most government procurement rules are wired to get the whole project (the requirements, timeline, budget, and team) locked in far in advance.

In the April 2018 Journal of Environmental Health (, we proposed methods to hack your system implementation. Agile takes these hacks to the next level and is steadily becoming the new norm in local government.

At its essence, Agile means taking a project into smaller time-boxed subprojects. These subprojects can be as short as 2 weeks, with each defined, completed, and potentially delivered individually. Then subsequent iterations, naturally, reflect the user feedback and priorities from the previous iterations. The expectation is that circumstances will change, priorities will shift, users will change their minds or become more in tune as they observe work to date, and negative impacts of any misjudgment are generally limited to the smaller work periods. It's wading into the swimming hole instead of diving.

Figure 1 identifies the component parts of each smaller iteration as projects are designed, developed, tested, deployed, and reviewed. The whole project is bookended by planning at the beginning and launch at the finish.

Do not think, however, of Agile only in the context of...

To continue reading