The best intentions and greatest attention to the people, platform, process, and AI portfolio at large are unlikely to suffice, though, in organizations that are not themselves structured for the era of AI (which is to say, “almost every firm on the planet”). Most IT organizations have carried forward significant relics from their legacy, pre-cloud models. Take care that you do not fall into these traps.

Use Case Death Spiral
First is the Use Case Death Spiral, wherein our classic IT approach focused on point solutions causing us to lose sight of the cloud ecosystem while we obsess about use cases. We always see knowing smiles and head nods when we discuss this topic at conferences, so you are likely to immediately recognize the phenomenon.

Most IT leaders “grew up” in our field during the long era of point solutions, so it is natural that they reflexively ask, “what’s the use case?” when considering new technologies. The problem is that in platform technology - be it AI, ecosystem-oriented architecture, modern data platform technologies like Microsoft Fabric or low code technologies like Power Platform, and others - the use cases are essentially infinite, and they’re driven by the organization adopting the technology, not by the vendor (Microsoft, in this case) providing it.

Organizations fall into the use case death spiral when they grow increasingly focused on enumerating and planning for every individual workload that they can conjure. They set to work identifying, designing, and prototyping the first workload. There is often, then, a demand to identify more workloads, so they workshop these until they have a big ol' stack o' use cases.

And just as they feel like they’re close to a breakthrough, potentially with their dozens (or hundreds) of use cases identified, someone in the organization will pop up and ask:

But what are we going to do with AI after that?

They go round and round on this so that months later they find that they’ve built nothing, achieved no value, and are little further than they were on day one. They will have produced fantastic shelfware in the form of analysis, lists of things, rumination of the art of the possible, etc. But they will have delivered no value to the organization.

You see, AI and other modern cloud technologies carry what Admiral James Loy, one of our co-author’s long-ago mentors, called a “bias for action.” Get as close as you can, analytically, and then press forward. Incrementally, sure, so that you see your value grow over time. But you must get moving lest you fall into the use case death spiral where a fixation on workload number forty-two (and beyond) impedes development of workloads one, two, and three.

But there is a deeper problem at play here. Think about the story we’ve just shared and notice how it was largely a tale of pawing around for use cases, often going from one business stakeholder or group to the next asking them “what do you need?” or “how can we help you?” Whilst it’s important to engage business stakeholders like this (see the Workload Prioritization pillar), the fallacy of the approach is that it positions AI and its ilk as a solution in search of a problem. You’re asking, in other words, “hey, we have this thing that may be able to help you, but… umm, do you need help with anything?”

Overcoming the Use Case Death Spiral requires IT organizations to adopt a more rigorous approach to application rationalization, road mapping, and prioritization, and CI/CD around their AI and other cloud workloads, which leads us to our next organizational consideration…

IT Tower of Babel
Since (tech) time immemorial IT organizations have structured themselves in siloed, technology-specific teams. This organizational model tends to produce a phenomenon that we call the “IT Tower of Babel”, wherein baskets of requirements are given to specific teams built around specific technologies. Give a basket to the RPA team, and they will build you a solution out of RPA. Give a basket to the data services team, and they will build you a solution out of data services. AI is a team sport requiring artificial intelligence and machine learning expertise alongside expertise in data science, data platform and integration, infrastructure, security, as well as application development.

AI is not a mountain made of its own tech somewhere off in the distance, visible through the clouds from the traditional IT mountain we’re already standing on. Scaling AI is not about building out an AI team with AI baskets of requirements to produce AI workloads. Rather it is about weaving AI into the proverbial fabric of your cloud ecosystem.

Organizations that insist on treating AI as a distinct technology owned by a distinct team do so at their peril. We are working in an age where engineering teams must be as cross-pollinated as the technologies they represent. Better for leaders to spend their energy breaking down their IT Towers of Babel, not building new ones.

Tyranny of the Deliverable
Re-building your IT organization to scale innovation by co-mingling different technical expertise throughout the org chart will be instrumental in creating a real culture of AI within any organization.

This is easier said than done thanks to the way that many of these teams are allocated funding and resourced from a budgeting perspective.

Many of the organizations we have worked with over the years build their annual budgets with line items tied to specific projects or deliverables, those “baskets of requirements” that we discussed. This approach is perhaps the single biggest way that organizational models from the pre-AI era prevent us from getting the most value from our AI investments. Consider an example of this model in action…

Your organization decides that it’s time to modernize its ERP solution. This is a worthy goal, so a bucket of money is created in next year’s (and likely a few years following) IT budget. This makes some sense in the context of big point solutions with multi-year implementation patterns. IT wants to reserve budget for an ongoing project, hold itself and its vendors accountable, monitor burn, correct for cost overruns, and in the end have some confidence that it will deliver a modern ERP solution to the business.

Unfortunately, this approach absolutely crushes innovation around AI and the development patterns through which you achieve it. Organizations that combine the IT Tower of Babel with the budget model from long-running point solution implementations applied to AI and other ecosystem-oriented technologies find themselves living something of the experience below…

Your organization has decided that it would like to embrace AI. This is a worthy goal, so a pile of workloads or business demands are prioritized on your roadmap. They each become a basket of requirements that get their own budget line item. Those requirements are then parceled out to the AI team, whose leaders understand that they have X budget to “deliver” a solution that addresses Y basket of requirements. They (and their partners / consultancies / vendors / what have-you) are now incentivized not to deliver truly valuable outcomes to the organization, but rather to check off as many pre-defined deliverables as possible. Management of these disconnected efforts causes overhead costs to skyrocket, as well.

And so it is that the organization succumbs to the Tyranny of the Deliverable, robbing itself the benefit of the shorter development cycles, opportunity to knit together multiple cloud technologies to solve problems, and agility that needs to be baked into your IT organization’s DNA if you’re to truly maximize the benefit of AI.

This is, by far, the most difficult challenge to overcome of the several we’ve discussed. Difficult because this isn’t just about adopting a technology or re-organizing a team, rather it's about fundamentally rethinking the way we fund the work of IT and measure its success. Consider several approaches to throw off the Tyranny of the Deliverable:

• Commitment to AI and your strategy around it absolutely must begin with executive vision that hangs a “north star” in the sky. This provides a clear answer to the question of why we are adopting this technology and what outcomes we seek as an IT organization and a broader business. What outcomes do we seek to achieve? And, importantly, are we prepared as an organization to measure our success in terms of outcomes achieved rather than deliverables crossed off a list?

• Start by taking some of those budget line items that you have allocated to specific baskets of requirements, and re-direct these funds to cross-technology solution teams and / or a trusted partner vendor whose mission is to execute on that vision and work towards the outcomes you’ve defined. Empower them to work flexibly, knock down problems quickly, modernize workloads rapidly, etc. And above all, to be outcome focused rather than deliverable-constrained;

• This commitment must be sustained. Executive vision should be forward looking to not become obsolete next quarter. Your focus on outcomes needs to be sustained long enough to see those outcomes realized. In practice, if your commitment to the AI strategy - and to the executive vision you have articulated - can’t be sustained for a year or more, then you have already failed.

Very early we explained that your organization is (probably) not ready for AI, because almost none are.

Very few - if any - organizations are truly prepared to make the most of the AI wave crashing on their shore. Very few have done the hard work to build the kind of proper, modern data platform required to make AI work at scale across their organization.

We’ve created the AI Strategy Framework and AI Maturity Model - and have written this extensive guidance - to prepare you, and the world’s many other organizations like yours, to seize the moment and thrive in whatever future AI has to offer us. We will continue to evolve this guidance as the technology and our lessons learned about the technology evolve. Until then, remember that your AI strategy must be flexible, able to absorb tomorrow what we don’t fully grasp today. Onwards.