Rapid Decision Making - The Bain Model

There are countless variations of IT governance but no matter the size or flavor, at its core, IT governance is about decision-making. Sound IT governance ensures an enterprise realizes the most value from information technology by providing the mechanisms capable of assuring optimal, reasoned and rational information technology decisions. There are two types of IT governance mechanisms, processes and relationships.

The majority of enterprises focus their IT governance efforts on the relationship dimension by assigning decision-making authority to governance bodies, mostly in the form of committees. I have encountered far too few organizations that realize they are implementing governance when an individual is assigned decision-making authority. I have found even fewer organizations that recognize they are implementing governance when they establish policies, standards, and formal processes. Recognized as governance or not, these common mechanisms play a significant role in decision-making due to their mandatory nature and the notion that personnel are subject to their authority.

Whether they are implemented as formal governance or simply under the guise of executive say-so, decision-making mechanisms don’t always ensure the best decisions because despite their recognized authority, they don’t necessarily assure the appropriate decision-making accountability. Many people subject to the decisions of an enterprise are not included in the decision-making process, or the establishment of the decision-making mechanisms. This exclusion results in many of the mechanisms being perceived as autocratic, bureaucratic, arbitrary, or just plain wrong. People are subject to the decision-making authority but they are not accountable for the decision.

Thoughtful solicitation and collection of the right input has long been recognized to produce the best business processes, policies, and standards. The same is true for decision-making bodies. The challenge is to correctly and optimally define the roles and responsibilities involved in the establishment and subsequent execution of decision-making mechanisms. This is not a simple undertaking.

I recently encountered an elegant option to the clarification of decision accountability roles and responsibilities when one of my clients asked me what I thought of Bain’s RAPID® model. I had never seen the model and I was surprised to find it was developed three years ago. I did a little research and I liked what I found. Though the approach was designed to address making individual decisions, I am convinced it could be useful in the design, implementation, and management of governance mechanisms.

According to Bain & Company, “High-quality decision making and strong performance go hand in hand. Yet, in many companies, even clear, well framed decisions can be derailed by uncertainty over roles and responsibilities.” To address this common problem, Bain created RAPID®, a tool to clarify decision accountability. R-A-P-I-D is a “loose” acronym for: Input; Recommend; Agree; Decide; and Perform. RAPID® assigns owners to these five key roles in any decision. “When the roles involved in decisions are clearly delineated, teams and organizations make the right choices—swiftly and effectively.”

I like Bain’s RAPID®model. I am a fan of just about ANY approach that makes decision-making accountability explicit and transparent. And therein lies the rub. Many enterprise cultures are averse to the ideas of explicit accountability and transparency. There is no place to hide. So first and foremost, the organization using the model needs to ensure the culture of the enterprise is conducive to functioning with clear, steadfast rules and total transparency. Executive sponsorship and mid-manager leadership is essential. (Believe it or not, the latter is more important than the former.)

And though I like the model and its acronym, I believe it has two inherent challenges:

1) It is RIRARDP, not RAPID. Everyone will remember the acronym, but they won’t necessarily remember each of the associated roles and responsibilities or their progression. As Bain admittedly notes, it is a “loose acronym”.  I think their “loose” characterization refers to the fact that the sequence is not indicated in the acronym – otherwise it would be RIRARDP. Recommenders solicit input from the Inputers so they can Recommend to the Agreers to obtain the agreement necessary to Recommend to the Deciders who ensure the decision is Performed if it is indeed decided. Given this sequence, it is easy to see why BAIN chose the quite memorable but emblematic RAPID acronym.

2) The acronym may be RAPID, but I’m not convinced it will be “swift” as Bain claims because using the tool involves many people and interfaces. I believe in many cases it will slow existing decision-making cycle time, especially in the case of unilateral decision-making. The number of roles and level of participation creates multiple interactions and the potential for numerous consensus-driven adjustments. The upside is that decisions will ultimately be made and they are far more likely to succeed given their inclusive nature. To justify the additional time required to make inclusive decisions, I suggest this model should only be applied in an organization with a history of having trouble making decisions and/or one that frequently makes unsuccessful decisions.

Despite the challenges, Bain has produced a compelling model designed to foster inclusion and transparency in decision-making. It has the potential to produce incredible results, but only when it is applied appropriately. I think it would be a mistake for organizations to automatically or indiscriminately use it on each and every decision. They should start by using it on the most critical decisions – when they foresee barriers to those decisions being made, and/or being made well.

If you have used Bain’s RAPID® model I would love to hear about the experience and its results. 

~ Steve ~

Conducting a ‘Fair’ and Ultimately Successful IT Governance Audit

The most challenging aspect of an IT Governance audit for most enterprises is the fact they don’t have a defined IT governance policy, standard, methodology, or practice to use as a target or baseline. Formal audits are generally conducted to assure compliance to corporate mandates or legal/regulatory requirements. IT governance is not a legal or regulatory requirement per se and few enterprises have taken it upon themselves to establish IT governance policy or standards. Given this omission, against what is the audit being conducted? How can it be fair?

The lack of established enterprise IT governance policies is exacerbated (if not caused) by the fact there is not a singular industry-accepted definition of IT governance - despite the fact ISO published a standard in 2008 (ISO/IEC38500). By ISO’s own admission, the standard is a guideline for “directors” – and they don’t even specifically define who the directors are. I have encountered few organizations who embrace ISO38500 as the benchmark for IT governance. And this is a shame, because the standard is very closely aligned to the original academic views of IT Governance published by the IT Governance Institute (an adjunct of ISACA) in 1998. In my opinion, the ITGI documents on IT governance are still the best you can find on the subject. But even though this collateral has been available for more than 15 years, too few enterprises even know it exists, let alone use it. 

Click to read more ...

The Need for Sound IT Financial Management

This post was inspired by an article I read today in the Enterprise CIO Forum on the topic of IT financial managent http://bit.ly/Nxe7dr. I wanted to leave a comment but I thought it would be much easier if the author of the article simply read an excerpt from my book, “Eliminating ‘Us and Them’ – Making IT and the Business One.” So in the interst of saving me the time of writing a lengthy reply to his article, I decided to post an excerpt from my book and simply leave a link to this post in my comments. Here it is.

IT Financial Management is another great example of an IT governance process that can be found to some degree in every enterprise with an IT organization. Every enterprise has mechanisms for managing their finances. But once again, they seldom recognize and manage them as IT governance mechanisms. And it is the lack of governance context that relegates most IT financial processes to little more than book keeping versus decision-making support mechanisms

Click to read more ...

What’s New in COBIT 5® and The Greatest Challenge to COBIT Success

This past April, the Information Systems Audit Control Association (ISACA) came out with a new version of the COBIT framework. For the uninitiated, COBIT was first released in 1996 with the mission is “to research, develop, publish and promote an authoritative, up-to-date, international set of generally accepted information technology control objectives for day-to-day use by business managers, IT professionals and assurance professionals.” The previous version of COBIT, initially an acronym for 'Control objectives for information and related technology' defined 34 generic processes to manage IT. The latest version of COBIT is now comprised of 37 processes – 5 governance processes, and 32 management processes. Here is ISACA’s new description of the framework:

“COBIT 5 provides a comprehensive framework that assists enterprises in achieving their objectives for the governance and management of enterprise IT. Simply stated, it helps enterprises create optimal value from IT by maintaining a balance between realising benefits and optimising risk levels and resource use. COBIT 5 enables IT to be governed and managed in a holistic manner for the entire enterprise, taking in the full end-to-end business and IT functional areas of responsibility, considering the IT-related interests of internal and external stakeholders. COBIT 5 is generic and useful for enterprises of all sizes, whether commercial, not-for-profit or in the public sector.”

As with previous versions of the framework, COBIT 5 defines each process with process inputs and outputs, key process activities, process objectives, performance measures and a maturity model. Much of the previous version is carried over but the latest version of COBIT has some significant changes. These are the changes highlighted by ISACA:

Click to read more ...

Taming the Change-Resistance Beast

I recently started delivering project success workshops for Gantthead and regional Project Management Institute (PMI) chapters. The workshop consists of three modules, the first focusing on Project and Portfolio Management (PPM) given project success is founded on sound project and portfolio decisions. The second module addresses project management offices (PMO) and the how to elevate them from ‘paper-pushers’ and ‘process police’ to participants in project success. The last module is the most unorthodox of the workshop as it tackles the widely neglected and misunderstood discipline of process management. Mastering the art and science of process management is essential to project success given PPM, PMOs, and project management, are all quite process-dependent.

Though most of the participants in my workshops come from organizations practicing some form PPM and almost all of them have PMOs, the workshop helps them to realize their processes leave much to be desired. The threefold discussion enables them to recognize their project-related processes are not suitably defined and designed, not thoughtfully and thoroughly implemented, and not properly and passionately managed. At the conclusion of the workshop attendees are often overwhelmed by the prospect that they have much work to do when they return to their offices.  And though they foresee numerous obstacles to fostering increased project success, the challenge folks find most troubling is the inevitable resistance to the changes they know they much impose on their coworkers. Most would choose dragon-slaying over facing the change-resitance beast.

Click to read more ...