Agility is not the cure to Transformation Myopia

When you've been a technology advisor to the Global 500 for as long as I have, you tend to have a feel for which business transformations seem to be headed the wrong way. This is especially true when neither, the executives you speak to nor the RFP you peruse actually answer the question "What is it specifically you want to achieve from the initiative?" or otherwise put, "What exactly do you wish to transform through this transformation?"

Transformation myopia, or the inability to see past the stated technology buzzwords (and likely benefits) is the chief reason why many organizations feel underwhelmed at the end of programs that sink millions of dollars - only to ask "Was this truly worth it?"

You'd think that Fortune 500 organizations with their Ivy League executives and renowned leadership would be immune to such problems. But sometimes, a conversation at the C-suite level could pretty much look like this:

CEO: Our numbers look like crap. We need to tell the street a better story about why we haven't been able to grow our customer base.

CSO: We are on-boarding new customers at x% but our churn rate is what's causing the numbers to stay flat. We need to figure out a way to increase brand loyalty and allow for more cross-selling and up-selling the existing customers to spend more with us.

CMO: I met Paul who runs marketing at ABC Enterprises and he was telling me how they're doing wonders with this new system that tracks and rewards customer loyalty. He was telling me how its reduced churn and increased wallet-share (gives cool examples of geo-location, targeted marketing, viral marketing, etc. being used at ABC)

CEO: So what's stopping us from doing the same? Or better? Aren't we already spending millions on our technology? Didn't we just spend $30 million for that fancy project last year? Something about an upgrade? Shouldn't that have taken care of it?

CIO: Well, what we just spent was to perform a necessary technical ERP upgrade to allow for our support costs to stay within levels or not have to pay extended support. Also, it allows for better reliability and redundancy (Everyone else's eyes glaze at this point)

CEO: Sounds like we could have spent the money better. We are in the business of XXX and not in just maintaining systems. I want you to look at how ABC is improving their business with that technology and do something similar here. We need to do this fast. Let us know your plan in the next DH meeting.

The first logical suspect in an organization's inability to execute on its agenda is it's (lack of) technological capabilities which is somehow the easiest answer to what is preventing it from meeting its true potential

I've sat in meeting after meeting, in the company of functional thought leaders and corporate stewards and what I saw was illuminating especially around the programs we started this article with (you know...the doomed ones?).

Doomed transformation programs were often conceived like this...

• A discussion at the executive level around the CEO's desire to do something dramatic, Other functional heads blaming a catch-all lack of capability which then gets somehow aided by a lack of technology. Other executives providing folklore and anecdotes on how some competitor or partner has become so much better after they implemented some system, platform, technology. The CIO then put on the spot and sent to investigate a possible solution fast. More progressive organizations designate the functional head as a co-owner.
• Lots of politicking later...a decision is made to commence, the software and SI selection starts and RFPs are floated with a set expectation around timeline and cost but not so much on what is exactly set to be achieved in business and functional terms.

That's where the rub is. Organizations focus their transformation around execution rather than truly analyze the "what" needs to be transformed, "how much" needs to be transformed or the ability (non-technologically speaking) to be able to transform in the first place. So RFPs and Project Charters end up with wishy-washy homilies around capability without actually detailing any of what needs to be achieved.

Without an answer to "What specifically do I need to transform (people, process and technology)?", a business transformation is merely a software or a technology implementation rather than providing any real as-designed Business Value.

And the problem in the past for most organizations trying to transform through technology was that most business transformation projects were multi-year and waterfall in nature. Which merely delayed the realization of the inevitable at the end of the project rather than before. That the project hadn't lived up to the hype. And it seemed easier to blame the timeframe and speed of execution than what actually happened in business terms.

ENTER AGILE...

The software industry has been doing it for years. Nimble, smaller components that can bring value faster rather than waiting. and if they can do, why can't we? So, you hear organizations hiring scrum masters, talking about design thinking, building in DEVOPS and delivering in sprints.

So what's happened is that organizations are using the software implementation process in identifying value out of the transformation. So they use agile techniques (like design thinking workshops) to create empathy and journey maps, feature and function mockups and use that to derive the value they are going to create. And they hope to get the business transformation agenda from their design sessions with a consulting partner driving the discussion.

And here's what they get - a system/ technology solution driven agenda that has people and process as peripheral support rather than equal partners in the transformation ?journey.

I've seen scores of these projects. And everyone uses words like "Software-derived best practices" or "Delivered processes" or "unified methodology including change". But let's be real. The process is heavily technology skewed and puts that front and center limiting the organization vision to what the technology selected can deliver.

Remember the ERP projects of the past that ended up being multi-year, multi-million dollar technology behemoths that underwhelmed the business when they were finally completed? We thought the problem was the projects took too long and didn't deliver the value they intended to effect because the business needs moved before the project was completed. But really, the problem was that the business needs were never comprehensively articulated in the first place. We did function and feature analysis and requirements gathering rather than setting a comprehensive transformation agenda that had the technology in an equal if not supporting role to the business needs (process and people).

What Agile has done is reduced the timeframe for disappointment. So now, you can feel underwhelmed in a shorter period of time. What it cannot do is be the replacement for solid business strategy and setting the true goals for why an inordinate amount of money or effort needs to be spun in the first place.

I am not an Agile Basher. I am a firm proponent of the method and its tool. And we can use the design thinking method to come up with a more comprehensive transformation slate. But if we put the cart before the horse and make the process subservient to the technology selected, what you still end up with is a technology project rather than a true business transformation.