Destined to Fail
In this segment, I am going to talk about failure. If you’ve been around long enough, you’ve heard the statistic that 70% of all large projects fail. You may have heard the softened version: 70% of projects are challenged or fail. But make no mistake. A challenged project is a failed project. It didn’t meet its stated goals. The challenged bit is a euphemism to capture that it didn’t fail by much. Your favourite sports team didn’t fail to win the championship. They merely experienced a challenged victory. But they got close. How can you possibly fault them for that?
Business transformation qualifies as a large project. And, yes, business transformations, by whatever name, actually fail at a higher rate. 84%, not just 70%. We’ll revisit this in a few minutes.
Iron Triangles
What do we mean when we say that a project has failed or is challenged? At the start of any project, there are expectations. These don’t really come in any order, but there are essentially four aspects to consider. In project management parlance, this is usually demonstrated by the so-called iron triangle.
First, there’s scope. What do we consider to be included as part of a project? It is common for larger projects to be executed in phases. In fact, the manner in which we even assemble a project has a lifecycle of its own. There are some methodologies that attempt to blur the phases within a lifecycle, but that’s a topic for another segment. Incumbent in the scope conversation is the expectation of features or capabilities, so we also need to have an agreed definition of done. When is done done? Well come back to this in a moment.
Second, there are expectations of cost, so we’ve got budgets. There are different ways to establish and manage a budget, whether one-hundred percent pre-allocated, stage-gates, periodic reviews, and such. But however a project gets funded, there is an expectation of what the amount might be. Even if we consider the approach of allowing for variation, which commonly establishes a range—X plus or minus some percentage. And, although the point figure, X, establishes a psychological anchor, we can still view the upper boundary of this range as a maximum budget. So if budget X is 1,000,000 dollars, pounds, euros, shekels, or whatever—plus or minus 10%, —we have established that 1,100,000 as the top of the range. If this threshold is exceeded, our project has failed.
Third, there are expectations of time. We’ve got deadlines. What more to say? Let’s keep going.
Fourth, there’s an expectation of quality. We have in our heads a notion of what’s good enough. Are we building Rolls Royces or Yugos? A project can succeed on all other accounts, but if we’ve produced a Yugo in a Rolls Royce factory, I think we can all agree that the project may have been, let’s say, challenged.
Without getting to deep into Project Management 101, let’s revisit the iron triangle. It’s got three sides: scope, cost, and time. You are free to name the vertices instead of the sides. No one will judge you. Contained within the boundaries of this triangle is quality. This triangle conveys a sense of the relationship between these items. We can alter any one of these elements, but that will alter at least one of the other elements. More likely, it will affect more than just one. To borrow a concept from statistics, you’ve got 2-degrees of freedom. If you need to shorten the timeline, it will come at the expense of either the number of features or quality. So, you can descope your project, or you may need to have your development staff work additional hours, and you may introduce bugs or add technical debt by taking shortcuts. You may have already used time planning for certain items, and this time could have been better applied to meeting the deadline instead of against a feature that didn’t need to be on the critical path.
It’s no coincidence that enterprise business architecture has become more prominent with the advent of large digital transformation projects. Part of this was in response to the failure rate. And, to be honest, it is necessary, but in and of itself, it’s not sufficient.
Now, let’s discuss some causes and reasons why these transformation projects fail, and how enterprise business architects can shift the odds of success to your favour.
There are many reasons why large transformation projects fail, and there are even more ways to fix them. Let’s talk about the biggest reasons and go from there.
No expectations
Expectations are an easy target. And, ultimately, any failure is a failure of expectations. But primarily, more was expected than could have been accomplished, and expectations weren’t effectively managed from the start.
In my experience, a typical scenario might play out in one of two fashions. First, a project that’s given a deadline before the scope and scale are even known. “This needs to be done by the end of the year”, or, “This needs to be completed in this budget cycle”. We’ve likely all encountered a project with this constraint. Second is a reaction to a project that “needs” to be completed sooner than estimated.
Ignorance is not bliss
Ignorance is another reason projects fail. The word ignorance is laden with connotation. I’m using the term in the denotative sense. Unless you’ve been through at least one transformation, how would you know? This is not knowledge you can get from reading books or blog posts. You really need the experience. And an unsuccessful experience may help you to not repeat mistakes, but it won’t necessarily equip you with enough to succeed. This is the ignorance we’re talking about. At a failure rate of 70%, this is not a risk you should be taking.
Culture Shock
The culture within an organisation is either a catalyst or an impediment. Given the 70% failure rate. I think you can guess how that breaks down.
The resistance of culture to accept or facilitate transformation cannot be underestimated. It’s a notable contributor to failure. This creates a failure to adopt. I discuss adoption challenges in a future segment.
Ownership
Ownership might just be my biggest pet peeve. I’ve been called out by several CIOs and a couple CEOs for pointing out that ownership is a problem. But it’s more than happenstance that 70% of transformation projects fail and, not coincidentally, 70% of transformation projects are led by CIOs.
The reason I take this position is two-fold. Primarily, transformation is centred on the customer and customer experience, so the owner should be close to the customer. The criticism I’ve received for holding this stance has been uniformly a response in the vein of, “Do you think my CIO doesn’t know our customers or our business?” Or the CIO, who indignantly defends the same line of reasoning.
CIO Lives Matter
So, allow me to preempt this by saying that’s not my claim. I am not saying that a CIO doesn’t know these things or can’t know these things. I’m saying that their knowledge is not likely to be intimate enough. And it’s not firsthand. Besides, they are likely to be incentivised in a manner that prioritises cost over value. And I’ll add, I don’t believe that CIOs genuinely value, or know how to value experience. They’ll tell you that they do, but the evidence is in the implementation. Actions speak louder than words. The proof is in the pudding.
If you are familiar with the segment on Defining Enterprise Business Architecture, you’ll have seen a parallel problem. In that case, we were talking about how enterprise business architects are closer to the business by definition and closer to the customer by extension than enterprise solution architects. The same logic applies here.
And, before you conclude that I’ve just got some vendetta against CIOs, I assure you, this is not the case. If a CIO has taken on the task of transformation, they had better find a strong partner on the business side of the house, a person with deep firsthand customer insights. And this person needs to be an equal or near equal partner. My advice here, hire an expert. Either go the management consultant route or appoint a transformation officer.
Indulge me for a few moments whilst I explain. In an enterprise of almost any scale, a C-level executive or someone just on the cusp should be given the responsibility of a transformation. The accountable person should be given between 3 to 5 years to succeed. If in this time the person succeeds, Hooray! It’s no longer time to transform. At least not this iteration. It’s time to operate and optimise. It may be time for the next transformation, but paradigms don’t switch that fast, so you’ll probably be afforded some breathing room.
If the transformation is not successful, then you are among the 70%. You’ve put your faith in the wrong person. You’ve backed the wrong horse. It’s time to dust yourself off, and find someone else. As I’ve already hammered home, the odds of the CIO being the right person are not in your favour.
No kidding
If you decide to take the management consulting route, be sure you’ve hired a trusted advisor, not just a cadre of yes-men. That’s the last thing you need, but it’s all too common. You need someone who can stand up and play the adult when you need to hear “no”. When you need to hear that you are not focusing enough attention to the customer experience. And this includes employee experience. If your employees are struggling, then your customers are paying the price. Or they’re not paying your price because they can get a better experience elsewhere.
I’ve already discussed how important it is to establish and manage expectations. One expectation is to grasp the sheer scale of an enterprise transformation. If you have a number in your head, double it. Or triple it. But it’s not likely the number in your head. Much of the cost is in the adoption. It’s relatively easy to manage infrastructure, licensing, and implementation fees. In fact, that’s something squarely in a CIO’s wheelhouse. It’s culture change that’s the big gotcha.
I’m going to keep my promise to defer the adoption conversation, but here’s a quick sidebar analogy. When I was in the custom software development business, I had to contribute to estimates and get buy-in from the customer. ten times out of ten. Okay, maybe 99 times in 100, the client would ask if we could cut back on quality assurance. It was even worse if it was a B2B application, or, worse yet, for their employees. But the reasoning was always the same. Why was the development team so shoddy they couldn’t produce bug-free software? They were sure that someone on their end could take on this function. I think you can guess where I am going with this. That’s a hard no.
It seems that the average organisation has some cognitive bias in play that it will just work. Build it, and they’ll use it. They don’t really have a choice do they. It turns out they do.
At your service
An enterprise business architect can help and organisation navigate an enterprise transformation. Particularly, one who has been involved with at least one successful transformation. By now, you should be noticing a trend. Experience is paramount. Every successful transformation starts with a relevant strategy aligned to a vision with stated objectives. The perfect team to implement this strategy would be an enterprise business architect, an enterprise solution architect, an organisational change management expert with experience in the enterprise transformation realm, and program management oversight to keep the pieces organised and maintain momentum.
For more information on enterprise business architecture and how it relates to enterprise solution architecture within the enterprise architecture framework, I suggest the segment on Defining Enterprise Business Architecture. I expect to discussing adoption management, organisational change management, and program portfolio management in future segments. As well, I expect to discuss how organisations attempt to beat the odds by changing how they play the game. Inevitably, they come up short and shoot themselves in the foot. Aim higher.
3 thoughts on “Is Enterprise Transformation Failure Inevitable?”