Are regulatory projects a better fit for adaptive or deterministic delivery approaches?

During a presentation at a local agile meetup this past week I asked the audience to think about what sorts of projects, products or organizations wouldn’t be a good fit for the use of agile or adaptive approaches and one of the attendees felt that regulatory projects weren’t suitable.

Non-discretionary compliance projects present many challenges, but does this make them help or hinder their delivery via agile approaches?

Here are some advantages to using adaptive life cycles with such projects.

• The “what” is inflexible, but there is usually wiggle room around the “how”. Once external regulations have been translated into a set of internal business requirements there are many ways in which those requirements can be met. With deterministic approaches, a business owner might be tempted to go for a “Cadillac” fully automated solution whereas with an adaptive approach, the focus might be on minimally meeting the requirements through a combination of manual and automated steps and then letting empirical data and budgetary and schedule constraints dictate what incremental enhancements get made.
• Adaptive approaches encourage fixing schedule and cost and letting scope remain variable. With regulatory projects, schedule is usually externally fixed and since there is no business value in going above and beyond the regulatory requirements, a ceiling on costs could also be set.
• Frequent feedback from end users on what is getting delivered increases the likelihood that complex regulatory requirements are correctly understood.
• Early and regular releases will reduce the learning curve for sustaining the process changes.
• Risk exposure can be used as a criterion for prioritizing the backlog of regulatory requirements. With this approach, a regulatory business owner can feel confident that those requirements posing the highest risk exposure to the company get delivered first.

However, there might also be some good reasons to follow a deterministic approach.

• These projects often involve changing multiple legacy processes and systems. Such changes might require heavy governance oversight and there could be blockers such as a lack of automated test capabilities or dedicated environments.
• Regulatory staff are often unable to dedicate themselves to the delivery project given their operational responsibilities so it might be difficult to secure a product owner or other business users.
• Regulatory projects often require participation of external partners such as vendors and government regulators. These stakeholders might be unwilling or incapable of working with an adaptive delivery approach.
• Regulatory business owners might be uncomfortable with not fully reviewing and approving the details of the “how” upfront. While this could be said of any business owner who hasn’t previously worked with adaptive delivery approaches, the perceived risks and impact of failure are much higher for regulatory projects.

As usual, when deciding what delivery approach to take, the specific context of the project and supporting organization have to be taken into consideration.