Agile Project Controls

This article will likely stir up incredulity and ire among the most deeply devoted practitioners of waterfall (predictive per PMI nomenclature) and Agile management methodologies, respectively. Agile enthusiasts will balk at waterfall phrases like “Controls,” and ardent supporters of the Critical Path Method will wonder at how an approach that emphasizes flexible scope and deferred decision-making can possibly be applied in a Capital Projects environment. However, each side has something to learn from the other and, if you read on, you will learn how Agile management can help Project Controls efforts. Let us examine why and how these two disciplines are compatible.

Project Controls is Knowledge Work

Project Controls Analysts do not lay bricks, dig trenches, or install equipment. They don’t even use power tools. Their tools are equations, scheduling practices, dashboards, queries, and ERP software. Rather than turning raw materials into a tangible object more useful than its constituent parts, Project Controllers turn data into information.

Project Controls Produces a Product

Reports, dashboards, and metrics are the solutions delivered by a Project Controls division or analyst. They synthesize data points into a pattern of information. Their worth is not measured by the hum of a Step-up Transformer, but by the business value of the questions they answer. The best Project Controllers build and tune systems and processes that facilitate and—dare we say—automate the distillation of project data into insights that help make decisions, reduce costs, and keep projects on track.

Products Have Customers

The systems and insights that Project Controllers deliver are used by The People Who Ask the Questions. Project Managers and Senior Management alike consume these insights: they are the customer. They are the ones buying what PCA’s are selling. Sometimes customers need some help figuring out what they want and need. Sometimes they need help figuring out what they do not want. Either way, the relationship between those who develop products—especially information products—and those who consume them is notoriously fraught with fuzzy requirements, critique, revision, and iteration.

Agile is for Product Development and Knowledge Work

Agile methods are suited to knowledge work because of the qualitative nature of that work’s product. It reduces waste by measuring against customer value rather than against a preordained plan and gives customers more than one opportunity to determine and express what they want. It also assumes that no one is going to “get it right” the first time: it has expectation management built right into its iterative, customer-engaging cycles. It is ideal for product development because it checks in with the customer frequently and adjusts the solution to changes and refinements in understanding of needs. Perhaps most importantly, it emphasizes the needs of the customer over formal, up-front requirements.

If you work in project controls, you have probably created an amazing dashboard or a report that you thought was exactly what was needed and that no one ever looked at. If you are a consumer of dashboards and reports, you have probably asked for some metrics and report widgets that didn’t ultimately drive business value the way you thought they would. If you made that request from a position of power, somebody probably spent time and resources to build that thing for you. Agile methods aim at maximizing the value delivered for time spent.

Iteration and Rapid Delivery

“I don’t need it perfect, I just need it Wednesday.”

Projects stakeholders need to understand what is going on with their projects, like, yesterday. Agile’s focus on rapid delivery is ideal for delivering something. It does this by emphasizing the Minimum Viable Product. What is the smallest, most valuable thing we can release with a high degree of quality? From that starting point, the team adds or refine functionality and deliver it at regular, rapid intervals. The key is that the developers (or in this case the project controls personnel) get valuable feedback at each iteration and their customers get a chance to learn more about what actually helps them instead of trying to solve the problem in their heads or rely on what worked in the past.

Exciters and Delighters

One tool commonly used in Agile and product development is the Kano model.

Kano grouped product features into Basic Needs, Performance Needs, and Delighters (or Exciters). Delighters are the features that are better than anything the customer could have asked for. Think in terms of the touch screen on the first iPhone. I’ll repeat that for the Critical Path folks in the back. Better. Than. The. Customer. Could. Have. Asked. For. This is, by definition, something that up-front requirements vetting cannot provide and which is even less likely to be achieved through ad hoc reporting requests. The Agile User Story turns a functional requirement into a problem statement that leaves room for stakeholders to be pleasantly surprised by the solution.

These pleasant surprises might occasionally happen organically, but this generally comes at the expense of either something the customer actually asked for or the analyst’s work-life balance. A related tenet of Agile is sustainable, consistent work outputs. These are enabled by Empirical Process Control, which is a fancy way of saying that you predict the team’s output by its actual output rather than what somebody else thinks they should be able to do: it is the ultimate in bottom-up estimating, because it is based on real data that is definitively relevant. When stakeholders set their expectations based on what the team can deliver rather than what the team wants to deliver or what stakeholders want delivered, there is time to produce quality work, continuously.

Agile management approaches are ideal for domains where the relationship between effort and result is not well-established. A skilled project team can design and build a substation or a transmission line and know what right looks like before they break ground: no need for Agile there. When the effects of a report or dashboard ripple through a project and its stakeholders, new questions arise and new requirements are discovered, uncovering new layers of complexity in the needs of project teams.

Conclusion

Project Controls Professionals should think of themselves and their colleagues as developers of products for consumption by the Project Manager, the Project Team, and Senior Management. The focus on human interaction and value-based delivery is what makes Agile methodologies the best way to manage that element of Project Controls work. The more effectively PCA’s deliver systems for producing insights that drive project outcomes, the more of an impact they will have in their organization.