How to Implement Bimodal IT: Focus on the 4 P’s

on October 26, 2015

By now, most CIOs have heard the term bimodal IT. The approach was conceptualized to balance the competing priorities of maintaining mission-critical systems and delivering the innovative applications required for successful digital transformation.

According to Gartner, “In Mode 1, IT operates traditional IT services, emphasizing safety and accuracy… Mode 2 emphasizes agility and speed, like a digital startup.” In other words, bimodal IT allows organizations to embark upon their digital journey without disrupting what already exists. Mode 2 teams sit alongside, and augment, Mode 1 teams, allowing each to focus on what they do best.

Recent survey data suggests that this approach is gaining popularity. Nearly 40% of CIOs have embraced bimodal IT, with the majority of the remainder planning to follow in the next three years. What’s more, the survey revealed that one of the worst things CIOs can do is to delay bimodal IT, with those who have not yet taken steps faring worst in terms of digital strategy performance.

Despite the overwhelming interest, CIOs and IT teams are hungry for practical insight into implementing bimodal IT within their own organizations. Drawing from our experience guiding more than 500 customers along their digital journey, we’ve identified four key aspects to successfully develop the Mode 2 capabilities required to drive digital innovation. We call them the 4 P’s:

1. Portfolio

The starting point is really the application portfolio. You must be able to effectively identify and prioritize your projects ideas, so it’s clear which requires a differentiated Mode 2 approach. Initially, this means identifying the right first projects. But as your Mode 2 team grows and matures, you’ll need to develop a more structured approach to your roadmap, implement criteria for determining which projects to do when, and leverage frameworks like Gartner’s Pace Layered Application Strategy to manage your portfolio on an ongoing basis. Remember: innovation projects are almost always urgent, but don’t always have a clearly defined business case so you’ll need to develop your own criteria and adapt them as you learn.

In addition, it’s important to define multiple project stages (e.g. Research, Prototype, Pilot, In Market) as well as success criteria and budget guidelines for each stage, to ensure you’re methodically developing ideas and measuring progress. For instance, the Prototype phase might prove out the technical feasibility of an idea while the Pilot phase might focus on identifying the target audience. In addition, Research phase projects might have lower average budgets, knowing that the risks are greater and more ideas are likely to fail. Like an early stage VC, making multiple, smaller bets allows you to absorb the cost of failure as you search for the next big breakthroughs.

2. People

Once you’ve identified your application portfolio and priorities, you can then define the people who will deliver on those projects. As we’ve discussed previously, this generally entails creating a small, cross-functional team made up of tech-savvy business people and/or business-savvy tech people. It’s key to have developers who are able to collaborate closely with end users, bridging the gap between business needs and technical possibilities. Depending on the specifics of your projects, though, you may also require additional specialties and skillsets.

Equally important, this team needs the right level of executive sponsorship and organization structure to be successful. Senior executive buy-in is absolutely crucial for successful digital transformation programs. At the same time, we’ve found that it’s less than optimal if one executive is responsible for both Mode 1 and Mode 2—the reason being that they have entirely different goals and KPIs. Instead, it’s preferable to have Mode 2 roll up to a separate C-level executive, such as a Chief Digital Officer (CDO) or Chief Innovation Officer. That’s not to say the two teams should be isolated from each other. In fact, the two will ultimately need to work closely together, whether to integrate a digital application with a system of record or to transfer maintenance of a digital application to Mode 1 once it becomes mission critical.

3. Process

The biggest misconception about Process is that it’s only focused on agile development methodologies. Don’t get me wrong; they are critically important to Mode 2. Because requirements for digital applications are often fuzzy, teams need to work in short, iterative cycles, breaking an application into small components, creating functionality, releasing it, and iterating continually based on user feedback. Closely related to iterative development is collaboration between business and IT.

But as you begin to scale your innovation program, you also need to establish DevOps practices. A lot of organizations focus only on agile and release a Minimal Viable Product (MVP), only to find they lack the deployment agility required to continuously release and iterate based on user feedback.

Lastly, Mode 2 projects require an entirely different governance framework. Instead of defining detailed governance designs that specify how a solution should be built and are reviewed at the end of every project, it’s better to provide a set of architectural guidelines that illustrate how a solution should operate and then embed these principles into a continuous development process.

4. Platform

Lastly, there’s platform. Modern cloud application platforms eliminate constraints associated with traditional development tools, delivering the speed and agility required for Mode 2 projects. However, the focus here is not about selecting the platform but rather positioning it within your application landscape (e.g. being able to clearly identify projects for which it is best suited) and defining your deployment strategy. Cloud offers numerous advantages, including cost savings, time to market, easy scalability and more, but it also comes with potential downsides like more difficult integration with certain systems and the inevitable privacy/security issues. For that reason, it’s important to have conscious guidelines for your use of cloud in order to manage and mitigate these concerns.

Another important consideration is how to facilitate reuse in order to further accelerate productivity and maintainability. Platforms like Mendix enable component-based development and offer a public and private app store for sharing and consumption of reusable application components. But it’s important to set this up properly, including making people aware of what’s available, how to find it, how to implement it, and where to go if they get stuck.

Rome wasn’t built in a day

The biggest challenge driving digital innovation is not technology, but leading change. The most effective way to do this is to implement a bimodal IT strategy, combining the rock-solid conventional capabilities of Mode 1 with new Mode 2 capabilities to deal with uncertainty and achieve the speed and agility required for digital transformation.

While all of the topics covered by the 4 P’s might sound like a lot, here’s the thing. Just as Rome wasn’t built in a day, you don’t need to tackle everything at once. Leveraging our proven methodology and three-phase Digital Transformation Roadmap, we guide our customers on what to do when, so that you’re able to focus on what matter most now, without needing to worry that you’re forgetting something that will be painful to correct later on.

  • Gunnar Eriksen

    Last March I was in Norway and among other meetings, I met with the CIO of a bank/insurance company (an old friend from my EY days in Oslo), who said his biggest challenge was to bridge ICT and the business community. Now I have the solution for my next visit to Oslo, hopefully later in August or in September.