The “Tyranny of the Deliverable”, and other short stories about why you’re struggling to realize big value with Power Platform
A little more than a year ago I put forth a vision for the “Cloud Application Platform” as the next generation approach to Cloud technology. A vision, I argued, best achieved through the use of the Microsoft Cloud specifically. And though I think we’re well far along—over a decade in—on the infrastructure and productivity components of this vision, I speak with very few enterprise CIOs or their teams that have achieved maximum value from their work in the apps and data components generally and Power Platform specifically.
Put simply: Too many organizations are still struggling to go big with Power Platform not because of limitations in technology, but because of their own outmoded ways of doing business.
Now of course, in the early days (way back in 2019) there was a popular line of quasi-acceptable thinking that the technology was unproven and skipping an investment in application platform technology (of which Power Platform is a part) all together was reasonable. That was untrue then—when I was helping a Fortune 100 financial services firm run $2b USD per year through Power Platform solutions—and it is certainly untrue now. Technically speaking, Power Platform has matured to the point where it is essentially a collection of Azure services with a marketing wrapper. And from a business value perspective, well, don’t take it from me. Take it from Forrester, instead, who in August 2022 published The Total Economic Impact of Microsoft Power Platform Premium Capabilities. I’ll let you do your own weekend reading on this one, but will summarize my take below.
Forrester’s composite organization derived significant quantifiable benefits from enterprise-scale, premium Power Platform adoption. A selection of these benefits are shown above.
First, Forrester interviewed and analyzed the experience of IT decision makers across a collection of organizations. My sense is that this was a good sample because industry representation is quite varied, including (amongst the industries where I am spending most of my time right now) professional services (15% of the sample), public sector and related (15%), retail (12%), financial services (12%), and manufacturing (3%). Using this data Forrester followed its usual practice building an anonymized “composite organization” with the following characteristics:
Global enterprise
$3b USD in annual revenue
10,000 employees worldwide
So, to be clear, we’re talking about an enterprise-scale organization, here.
The findings are tremendous, both quantitatively (see first graphic), and qualitatively (see second graphic) in terms of the percentage of IT decision makers in the study who agreed their organization had derived a series of benefits such as “improved IT governance” or “improved compliance for external audit and regulations”.
I’ve worked with a lot of IT and business decision makers throughout my career, and I struggle to think of many circumstances in which such significant positive results could be delivered to an organization via technology adoption… and where such claims were supported by independent research.
IT decision makers in Forrester’s study widely agreed (shown as percentage who agreed) that enterprise-scale, premium Power Platform adoption returned significant qualitative benefits to their organizations. Read this chart as, for example, “91% of IT leaders felt that enterprise-scale, premium Power Platform adoption increased security and visibility around data connections”, “75% of IT leaders felt that enterprise-scale, premium Power Platform adoption facilitated the work of professional developers”, and so on.
That is to say: I know of no other move that IT decision makers in organizations across the economy and around the world can make that is likely to achieve results of this magnitude by—in effect—doing more with less. It is an opportunity that absolutely must be seized, and a can’t-afford-not-to-situation when your peers inevitably do. As such, it’s a transformation on which IT decision makers must lead from the front.
But these benefits are often dampened by three big, non-technical reasons that I see so many organizations failing or underperforming in their scaled, enterprise Power Platform adoption:
Use Case Death Spiral where fixation on workload number forty-two impedes development of workloads one, two, and three (by the way, I feel compelled to credit my friend Dana Siegal with turning me on to the phrase “Use Case Death Spiral”)
IT Tower of Babel where IT teams siloed by specific technologies and lacking common language prevent platform-first approaches, closely related to the “Apples and Oranges Fallacy” that I will also discuss below
Tyranny of the Deliverable under which budgets tied to baskets of requirements are inflexible, difficult to scale, and limiting to continuous innovation
Which is why straight away in a discussion with one of those leaders I want to understand where they stand on the million (or $14.25 million) dollar question:
Are you committed to undertaking a program of cloud transformation using this technology?
I cannot possibly overstate how important it is for IT leaders, their teams, their partners and consultants, and everyone else in your ecosystem to have a really clear, executive-driven answer to this question. The value that Forrester found in successful organizations didn’t just happen. It is not spontaneous, and it is not easy. It’s the product of commitment to and sustained effort towards achieving that value. And from my personal perspective, there are too many organizations out there now whose leaders are committed for me to spend much time on those who are not; I work (and write) to help the committed achieve great things, not to persuade the lingering skeptics.
So… Fantastic if you are! At the very least you’ll have incentive to keep reading as I dig further into the three major obstacles standing in almost everyone’s way.
Use Case Death Spiral
I cannot tell you the number of times that I have sat down with an IT executive who first asks me to enumerate specific use cases for Power Platform. This is a natural question for those who grew up in the “Point Solution Era”, that is to say, anyone whose technical coming of age happened before circa 2020 who has not yet fully joined the “Platform-First Era”. You can read more about the “Point Solution Era” here, but suffice it to say that implementing point solutions (be they your own custom legacy app, Microsoft Dynamics, SalesForce, SAP, Workday, or the multitude other such solutions out there) is about solving for a specific number of known use cases. What we’re doing with cloud platform technologies (which include Power Platform of course) is solving for an infinite number of unknown things.
Let’s pause for a moment so that you can internalize this: Point solutions are about solving for a specific number of known things; platform is about solving for an infinite number of unknown things.
Back to my conversations with IT execs, where at this point I usually explain that the use cases are theoretically infinite, and entirely driven by a specific organization’s particular needs. In other words, though I can give you an idea of what others in your industry are doing, I can’t tell you what problems you yourself are trying to solve. This is about you, not me, and not the technology.
The Use Case Death Spiral, shown above, is a seemingly innocent yet nasty trap into which almost every organization falls at one point or another as they try to evaluate, deploy, and scale Power Platform.
At this point most organizations will set to work identifying, designing, and maybe even prototyping the first use case (or “workload”, as we should really be calling them). Then—and I again I am speaking from nearly every experience I have had seeing an organization go through this—someone or a group of someones will see the first workload identified and want to see more. So they’ll workshop it to the point where they have a big ‘ole stack ‘o use cases.
And just as they feel like they’re really 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 Power Platform 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 shelf ware 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, Power Platform carries with it what Admiral James Loy, a long-ago mentor of mine, 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 I’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, the fallacy of the approach is that it positions Power Platform 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?”.
Escape the Use Case Death Spiral by baking Power Platform into your app rationalization, migration, and modernization program rather than pawing around for here-and-there use cases that may or may not come your way.
Meanwhile, IT organizations the world over engage in what we call “app rationalization” as part of their app modernization efforts. These usually focus on whether a particular app in a rather vast portfolio of enterprise apps is worthy to be migrated to Azure (or to Amazon Web Services, or to Google Cloud, or to whichever is your organization’s cloud platform of choice), and—if “yes, it is worthy of migration”—then which “six Rs approach” should we employ for this particular app? This is a foundational concept in the world of cloud adoption, wherein an organization looks at the legacy apps it has and decides whether to allow the app to Remain in its current state (on-prem or elsewhere), Rehost by “lifting and shifting” it to cloud infrastructure (think virtual machines), Refactor the app by—say—augmenting it with capabilities such as Power Automate or RPA or Logic Apps, Rebuild the existing app using cloud services, Replace it entirely by absorbing the workload into other truly PaaS based services, or Retire it as would be appropriate for workloads in service of obsolete business needs.
Power Platform enters the equation in very few of all app rationalization, migration, and modernization efforts I have seen, though. This is in spite of the fact that (as discussed earlier) 75% of all IT decision makers who have done so say that Power Platform facilitated their digital transformation and move-to-cloud strategy. Likely this is because adoption increases developer efficiency by +22.6%, IT and DevOps efficiency by +18.8%, DBA efficiency by +18.3%, and so on. See, as you move up the ladder from “rehost” (where in the Microsoft world, workloads are primarily bound for Azure infrastructure) you find that cost, time, and ongoing technical debt are reduced by blending Power Platform, Azure, and even some Microsoft 365 technical services. So it’s important to ask yourself:
Don’t I want for my Cloud transformation effort to harness these efficiencies?
This really begins to get at the crux of the matter, that we’re talking about transforming not just technically, but in the way the IT (and the business) does business. So in summary, overcoming the Use Case Death Spiral requires the organization to:
Quickly identify and prioritize your initial roadmap of workloads, but resist the temptation to go on a workload treasure hunt by obsessing over workload “forty-two” and beyond;
Take a bias for action approach, and get your first workload (and those that follow) from POC to production quickly;
Intentionally incorporate Power Platform into your app rationalization, migration, and modernization effort alongside other cloud services so that you begin to realize the efficiencies that other CIOs have enjoyed.
IT Tower of Babel
Next, assuming that you’ve escaped the Use Case Death Spiral you are likely to find that you—like many your peer organizations—suffer from what we’ll call the IT Tower of Babel.
In this conundrum we find how many IT departments have organized their teams around specific technologies or technology genres, examples of which might include:
Cloud Infrastructure
Productivity
Data Services
App Dev
RPA
…and plenty more.
These teams usually work in siloes (or “towers”) focused on their own particular technology, and in so doing they fail to develop a common language which enables cross-technology problem solving that most business challenges require. The cloud infrastructure people do cloud infrastructure, the productivity people do productivity, the data services people do—you know—things with the data, the app dev people build apps, the RPA people build bots, and on, and on it goes.
I should take a moment here to explain how the IT Tower of Babel is related to another common malady that we’ll call the Apples and Oranges Fallacy wherein the decision to adopt a specific technology is driven only by the immediate requirements of that technology. This leads decision makers to compare apples and oranges, in other words, to make technology selection choices by comparing the wrong technologies. That’s a bit confusing, so instead let’s consider an example that Ana Demeny and I cooked up…
Your organization has heard about RPA (“Robotic Process Automation”). You think that automating some of your business processes is a good idea, so you set out to select an RPA technology on which to standardize. After looking into various options in the market, you’ve narrowed down the choice to market-leading UI Path or Microsoft’s Power Automate. For the purpose of this short story it’s not particularly important which of the two you select, because the mistake has already been made.
You see, UI Path is an RPA tool. Full stop. RPA is what UI Path does. All it does. If the answer to a particular business challenge isn’t RPA, then the answer can’t be UI Path. It’s a point solution (and, at the risk of sounding like a broken record, more on that here). But RPA is expensive and fragile, a “last mile solution” best used when you don’t have a cheaper or more durable option such as a proper data integration via an API. Conversely, in Power Automate, Microsoft isn’t claiming to offer an RPA solution to solve all problems. Rather it is putting forth an RPA solution as but a single tool in a collection of many tools to solve for a vast array of business and technical challenges. The proper comparison is not “UI Path vs. Power Automate”, but “UI Path vs. the Microsoft Cloud”. The latter offers you an array of services—including RPA—from which you can choose the best for the job (such as that cheaper, more durable data integration). The former offers you expensive, fragile (though sometimes really necessary) RPA.
In the IT Tower of Babel, baskets of requirements are given to teams siloed around specific technologies. This creates a “when all you have is a hammer, everything is a nail” problem resulting in infrastructure teams solving problems with their tech, productivity teams solving problems with their tech, etc.
Anyway, back to that lack of common language. You’ll find the IT Tower of Babel in organizations where the the cloud infrastructure team does its thing with its tech, the productivity team does its thing with its tech, the data team does its thing with its tech, the app dev team does its thing with its tech, the RPA team does its thing with its tech, and so on. Power Platform is part of the answer to this problem, providing the connective tissue woven through app dev, RPA, productivity, and even data services in the form of Dataverse together with cloud infrastructure services you may already be using. It forms part of the common language necessary to start knitting these things together.
Yet it isn’t a silver bullet. The trouble doesn’t end with language. In many cases, IT organizations have baskets of requirements that align to a particular business problem or workload. These baskets are then given to one of our tech-aligned teams to solve. You’ve surely been part of conversations that sound like these:
“Ah, yes, it looks like we need an app for this. Let’s give this basket of requirements to the app dev team.”
“Oh yeah! I see. We need to automate this. Let’s give this basket to the RPA team.”
“Yeaaaaaaaah that is a real legacy app. We need to migrate it. Let’s give it to the infrastructure team to lift and shift.”
“100% this is a productivity issue. Doesn’t Teams have something to fix it?”
“Wow that is super tough. Not sure how to make sense of all the disparate data sources we have here. Let’s give it to the data team.”
I think you get the idea.
When we allocate baskets of requirements to too narrowly defined technology-specific teams to solve, we create the conditions for business challenges to be solved in predictably sub-optimal ways. Give something to the app dev team, and you’re going to get the thing that the app dev people built. Give something to the data team, and you’re going to get the thing that data people built. It’s the classic “when all you have is a hammer, everything is a nail” problem.
Imploding our IT Tower of Babel goes beyond establishing a common language. You must create the organizational conditions under which all the common language speakers work together. For many organizations this means building cross-technology “solution teams” that are focused on applying the breadth of available tech to solving problems. Power Platform facilitates this, but the answer cannot be purely technical.
So, to overcome your IT Tower of Babel challenge, consider:
Adopting platform-first technology like Power Platform to serve as the connective tissue woven through your technical siloes;
Organize your technical teams into cross-technology solution teams that create conditions under which practitioners of different technologies work together;
Break free of the worn out pattern of giving baskets of requirements to the RPA team or the app dev team, etc.
Tyranny of the Deliverable
Which, at long last, brings us to The Tyranny of the Deliverable and a big part of the reason that getting beyond “baskets of requirements” mode is so difficult.
The Tyranny of the Deliverable obliterates many of the benefits of “platform-first” by tying projects (“baskets of requirements”) to specific budget line items, then parceling out those requirements to technically-siloed teams. Each technical silo then understands that it has 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.
Many of the IT organizations I 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 previously. This approach is perhaps the single biggest way that non-technical models from the Point Solution Era prevent us from getting the most value from our platform-first 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. Fair plan all around.
But this approach absolutely crushes platform-first innovation 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 platform-first cloud transformation (so that is to say nearly every organization on the planet) find themselves living something of the experience below…
Your organization has decided that it would like to undertake a program of cloud transformation using platform-first technologies and techniques. 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 infrastructure team or the productivity team or the RPA team or the app dev team or the data team and so on. Each technical silo then understands that it has 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 need to be baked into your IT organization’s DNA if you’re to truly maximize the benefit of platform-first.
This is, by far, the most difficult challenge to overcome of that several we’ve discussed. Difficult because this isn’t just about adopting a technology or re-organizing a team, rather about fundamentally rethinking the way we fund the work of IT and measure its success. Consider several strategies to throw off the Tyranny of the Deliverable.
First, commitment to undertaking a program of cloud transformation using this technology absolutely must begin with executive-level vision that hangs a “north star” in the sky, that is to say 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? Are they amongst those that big majorities of IT decision makers cited for Forrester, i.e. increased security around data connections, eliminating or reining in shadow IT, increasing employee satisfaction with their tools? Are they cost reductions and / or O&M efficiency gains to come app migration that allow legacy technologies to be retired? Backlog reduction? Improvements to operational efficiency? And, importantly, are we prepared as an organization to measure our success in terms of outcomes achieved rather than deliverables crossed off a list?
Second, start by taking some of those budget line items that you have allocated to specific baskets of requirements, and re-direct these funds to a cross-technology solution team(s) 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. How aggressive you are with this depends on your organization’s internal dynamics, but I think it’s likely that few if any organizations will go all-in on an approach like this until they’ve seen it produce value. That’s fine. After all, those legacy ERP systems aren’t going to modernize themselves, so you may find value keeping some momentum on that side of your house as well.
Finally, this commitment must be sustained. Executive vision should be forward looking so as to not become obsolete next quarter. Your focus on outcomes needs to be sustained long enough to actually see outcomes start to be realized. In practice, if you’re commitment to undertaking a program of cloud transformation—and to the executive vision you have articulated—can’t be sustained for a year or more, then you have already failed.
I’ve spent a great deal of time on these challenges, seeing some organizations succeed, and others fail. So I’ve also put great effort into re-imagining specifics of the journey that organizations ought to be taking as they get started. The above has been a lot, so such will be another story for another time. For now I will leave you with this:
I get it. This is a challenging road. Forrester’s study was built around a three-year time horizon, so consider the benefits that IT can drive for the broader organization if you really do commit. That’s why I always want to understand where a CIO stands early in our work together. More importantly, you should understand it in yourself, for your own organization. The outcomes available to you are tremendous.
