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.
Recently, I’ve been experiencing frequent brief loss of Internet connectivity issues at home. I live in a major urban area, no internal or external home renovations have happened which would affect cabling, and my cable modem was recently swapped. Thankfully, the technician who swapped the modem did provide me with his mobile number and recommended that I call him if I had further issues within a few weeks.
We have all heard that the Internet is becoming a critical utility and hence we should demand the same reliability as we do with power, water or our telephone dial tone. While this is a reasonable expectation, few Internet Service Providers (ISPs) have focused on this in their marketing campaigns to the personal market. Commercial customers are a different story – they enjoy real SLAs but at a higher cost. Most of the ISPs who service residential customers will hype their transmission speed or capacity in their advertising. While those are important, guaranteed up time would be a more welcome benefit in the long run, and would likely contribute to greater customer loyalty. ISPs are under pressure to scale their infrastructure to support greater speeds at lower costs, but the side effect of this “arms race” might be reliability.
This situation brought to mind the challenges we face when communicating delivery metrics as part of an agile transformation.
Many of the leaders I’ve worked with focus on schedule metrics: reducing time to market, lead time, time between releases, and so on. While these are important, an overemphasis on reducing lead time may unconsciously encourage delivery teams to kick quality concerns down the road. Having effective Definition of Done working agreements can help, but these can also be diluted to favor speed over quality. Defect reporting and customer satisfaction surveys provide opportunities to identify whether there is an unhealthy focus on delivering faster, but these are lagging indicators.
This is why it is so important that the communication campaign supporting the transformation, including the sound bites from top-level executives, reflect an equal footing for speed AND quality. And mid-level managers need to walk this talk in their daily interactions with their teams.
Don’t sacrifice quality at the altar of speed.
Project management practices have been used since human beings first started to work together to achieve greater outcomes than they could have accomplished as individuals. Modern practice of the profession started in the 1950’s so it is natural that certain practices, tools and nomenclature will be discarded as the profession evolves.
Unfortunately, some anachronistic project management terms still linger in spite of overwhelming evidence that their time has passed.
Waterfall & Traditional
Waterfalls usually provide a one-way journey for those unlucky enough to take a ride over them. Even the most deterministic lifecycle will provide some instances (no matter how small) of iterating back. Traditional is a subjective term. The Manifesto for Agile Software Development was signed in 2001 and before its arrival launched agile into the mainstream, adaptive lifecycles had been used for many years. Traditional could be equally applied to deterministic and adaptive lifecycles when we consider that many new project managers were born around Y2K!
Resources (when referring to people)
The PMBOK’s Project Resource Management knowledge area might cover the management of both people and materials, but calling our team members “resources” encourages poor management practices by equating them to commodities and furthers the myth and resulting risks of fungibility. There are many positive synonyms which can be used to reference the people on our teams including their names(!), “talent”, “contributors” and “performers” so there’s no reason to use such a divisive term.
I applaud the efforts of the PMBOK Guide, Sixth Edition volunteer team in adding the Tailoring Considerations section to each knowledge area chapter but this is just the first step in a long journey of providing guidance for adapting project management practices and tools to the context of a specific project and organizational culture. Certain other professions might have standard procedures which are appropriate in all circumstances (e.g. turn the power off before working on an electrical circuit) but while the principles of project management are universally applicable, specific practices or tools are not.
The practice of trepanation was used in ancient times as a cure for the evil spirits possessing sick people’s heads. However, if a doctor was to approach your head with a drill, in all except the most extreme circumstances, you would be forgiven for running away! If we wish to demonstrate the evolution of the project management profession, similar Spring cleaning is needed with our lexicon.