Startup incubators often promote a few common themes:

• Let customers/market dictate the product
• Scale it down – start small and go live fast
• Do the research and learn about the market
• Get feedback as quickly as possible
• Fail silently – incorporate lessons learned without dragging the whole effort down

These techniques suggest that the traditional high-profile, enterprise-wide rollout of a new ERM program may not always be the best way to launch. Instead, focusing on the smallest scale project—one with the potential to yield meaningful results—and relying on a customer-driven approach may be the key to creating a sustainable, effective ERM program.

Creating a customer-centric ERM product

When viewing ERM as a product, the primary “consumers” are the board and executive team. Without understanding what the customer expects, you can spend a ton of time and resources creating something that nobody actually wants or uses. The COSO guide Embracing Enterprise Risk Management: Practical Approaches for Getting Started notes the importance of understanding customer expectations:

“The board and senior management should agree on their initial objectives regarding ERM, its benefits and their expectations for successful ERM. At a high level, there should be clear agreement and alignment of the board’s and senior management’s expectations, timing and expected results. This should include agreement on the resources to be made available and targets dates for the effort. The board should also consider the timing and level of status reporting that will be required to effectively monitor and oversee the ERM effort.”

A customer-centric view first asks how a product will help address a customer’s needs. From the perspective of the board, ERM’s purpose is to trigger discussions about risks that lead to making informed decisions and taking responsive actions. A customer-centric approach to developing an ERM product begins with two central questions:

• What language/format/approach do your customers need in order to do that?
• How should the raw data collected be translated into insight?

The answers to these questions are critical to designing a viable, effective product.

Quick wins – the appeal of the MVP

In startup lingo, the minimum viable product (MVP) is the most scaled-down version of a product that is still usable. The Techopedia definition states:

“A minimum viable product (MVP) is the most pared down version of a product that can still be released. An MVP has three key characteristics:

•  It has enough value that people are willing to use it or buy it initially.
• It demonstrates enough future benefit to retain early adopters.
• It provides a feedback loop to guide future development.

The catch to this development technique is that it assumes that early adopters can see the vision or promise of the final product and provide the valuable feedback needed to guide developers forward.”

Applying this concept to version 1.0 of the ERM program can scale back the planning effort considerably. For example, instead of mapping out a program across the enterprise, the initial rollout may involve a single department. The development of effective controls can wait until after the language and procedures for communicating risk status and severity have been established. In fact, by focusing on just the R portion of ERM initially, you'll be able to ensure the MVP remains at a manageable size, while gaining insight that informs the E and M components later on.

Built-in research—leveraging crowdsourcing through the strategic plan

Jason Fried, Founder and CEO of Basecamp, has said that “nothing gets you more focused on solving a problem than actually having that problem.” As with any new product, establishing relevance is always a primary concern. If the scaled-down ERM program (your MVP) is designed to help the organization address potential risks, how can you start with a manageable list of highly relevant risks?

Fortunately, most organizations already invest considerable resources in developing strategic plans. Treating that plan as market research for your MVP and working backward to any risk that could impact those objectives ensures that the output of the ERM program is connected with the central goals of the organization. Leveraging this work to identify the initial list of risks to focus on saves time. In Fried’s view, this also increases the odds of solving problems the organization actually has.

Real-world feedback

Up to the point at which the MVP is shown to the board, ERM has been a concept. Once the board begins consuming the reports, the “product” is officially launched. That means gaining feedback and making adjustments. Potentially lots of adjustments. Many startup incubators, for example, won’t even offer assistance until there is actual real-world customer feedback to drill into. This is neither a bad thing nor an indication that the original process was flawed. No matter how detailed and meticulously executed the MVP plan is, you’ll most likely need to make adjustments after seeing how it operates in the real world. Paul Moynaugh relates this concept back to a famous boxer commenting on his opponent’s plan for the upcoming fight:

“When Mike Tyson was asked by a reporter whether he was worried about Evander Holyfield and his fight plan he answered; ‘Everyone has a plan until they get punched in the mouth.’” While receiving feedback from ERM consumers is probably considerably less painful than a Mike Tyson punch, making initial changes to the plan after spending time developing it can still be difficult.

Failing silently—the benefit of a small ERM program

The advantage of the MVP approach, especially when faced with a high likelihood of “getting punched in the mouth,” is that adjusting the process is far easier and less disruptive. The goal of the MVP, in this case, is to get the board to see what this ERM process could deliver. Actually viewing the reports may make them rethink what they want, as well as how the process itself should work.

Use that feedback to figure out the next steps. If this doesn’t trigger the conversations that lead to action, then examine the lessons learned and try a different approach (without the expense and deadweight of a year(s)-long high profile failure to combat). Not carrying the expectation and resource justification that comes with a large-scale, enterprise-wide project allows for greater flexibility and responsiveness.

The iterative next steps

The MVP serves as a proof of concept. Where do you go once the concept is proven? Let conversations drive the next actions. Discussions about risks inevitably lead to discussions about controls. You could start this same process over again with a focus on adding controls (and more robust reporting) to the mix. While the MVP focused on a narrow subset of risks (perhaps looking only at a specific department or unit), examining the question of how to expand the process across the enterprise may become more pressing. Next steps might also take into account how to include both risks and opportunities in the process, adjust reporting based on the organization’s risk tolerance, and incorporate established frameworks.

In every case, the next steps are based on real-world feedback from the MVP. With the right technology, you can keep the expansion process controlled and intentional. Rather than trying to figure it all out at once, move at the pace of your organization. With this approach, launching a sustainable ERM program becomes far less daunting and much more manageable.

Get in touch with our experts to figure out how an MVP approach could help make launching your ERM program easier and more sustainable.