Delivering Regulatory Change
All corporations fear the risk of upsetting the “person on the street” and consequential loss of reputation, immediately impacting today's bottom line and annihilating any prospect of growth tomorrow. Gerald Ratner (a.k.a. “the Ratner effect”) and BP’s Tony Hayward (Deepwater Horizon oil spill) may be extreme cases, but ably demonstrate how severe the fall from grace can be. Beyond the reputational damage, we have seen companies in regulated industries facing heavy fines and criminal proceedings for executive board members in extreme cases.
And the regulator is increasingly on the side of the consumer. The level of scrutiny can seem excruciating. Just ten (or even one) customer offending issue in a single functional area (e.g. incorrect billing), can cause the regulator to initiate significant and widespread reviews across all enterprise functions.
We’ve seen companies that logged record profits in 2012 and 13 are now being subjected to a whole portfolio of regulatory initiatives to drive further benefits to the consumer. Here, we’ve outlined three key areas to focus attention:
The approach to quality usually reflects the predominant culture. If your organisation doesn't have Quality Principles coursing through its DNA, you have a problem. Stakeholders often agree with the principles in words but not in practice; when they see a potential increase in overheads, they look to circumvent the process where they believe they can get away with it.
People at all levels in an organisation need to understand the implications of failing to meet quality standards, and communicating what's most important is a significant challenge. A robust and appropriate approach to Quality requires effective leadership and sponsorship in respect of major change. If the sponsor doesn't demonstrate the appetite for quality, it is likely that this will filter into the project teams and affected business area. And for some projects consider appointing a Business QA lead, assuring quality through the life of the project, aligned to checkpoints, and reporting straight to the sponsor.
Testing becomes a safety net. If you rely on the testing function to find and fix faults to ensure the quality (whilst at the same time squeezing them on time and budget), then worst case: testing isn't joined up with the quality regime and sub prime solutions are implemented; and best case: testing finds the problems and assures the quality of the solution but at a significant cost (look at the stats on cost of rework vs. getting it right first time).
Manage quality proactively. Define your quality requirements/thresholds up front and build a "no test surprises" expectation where testing is proving quality not defining it.
You believe a waterfall approach keeps you safe in the knowledge that key project design and build documents will intrinsically link your project outputs to the regulatory requirements and thereby secure your quality targets. In reality often due to time and cost pressure, that connection between requirements and output isn’t made.
In adopting an agile method, the quality criteria are clearly visible up front, and business users are sufficiently involved and empowered to ensure they are embedded at every stage of development. No method will guarantee success. People can get caught up in the method. How do we know we've really succeeded?
Flex the quality levels in your projects (one size does not fit all). Choose strong elements of different methods and use a mixture (pick and mix). The approach to quality is clearly dependent on the project type - you'd expect a far more robust quality management process for development of aerospace engines than a back office CRM implementation. As a start, think about two types of change: 1) above the waterline - have a go, see how it goes, (works with agile); and 2) below the waterline - if you get it wrong your ship will sink (probably a no-go for agile).
There’s a tendency to over rely on process and conformance to that process becomes king. As a minimum establish an approach to quality – ensure it is auditable on every project but primarily focus on the people, ethos and principles, not just process and frameworks to drive success.
So challenge yourselves! If any key project stakeholder cannot explain the quality regime confidently and accurately in 30 seconds, you can be confident that quality is NOT embedded across the project, you might want to prepare for the worst!
And finally, don’t let it go unnoticed that the level of regulatory-driven change dominates the change portfolio, leaving less room for discretionary improvements (and potentially non delivery of essential business strategy). As a consequence people may "piggy back" these initiatives, integrating them with regulatory change projects and mashing up the scope and business need.
Contributors: Ade Brant, Peter Mayer, Alan Ogrizovic, Alice Budd and Rachel Wagstaff.
Many thanks to all who attended the Intelligent Projects Forum on 10th June 2015 and participated in this discussion.