Scaling Up Excellence

How’s your process excellence initiative going? Frustration and confusion everywhere, pummelled by unpredictable and unpleasant events, the stench of failure in the air?  So far so good, then. That’s according to Robert Sutton and Huggy Rao, Stanford professors whose research convinces them that ‘organizations that scale well are filled with people who talk and act as if they are in the middle of a manageable mess’.

Scaling is fraught with risks and uncertainties. Even the best leaders and teams recognise that muddling through can be inevitable, sometimes for months, while searching for the best way forward. Scaling stars have grit. ‘It’s not simply a marathon. It’s like running a long race where you don’t know the right path, often what seems like the right path turns out to be the wrong one, and you don’t know how long the race will last, where or how it will end, or where the finish line is located’.

It’s refreshingly candid advice, and Scaling Up Excellence is full of it.  On a seven year journey that started with a Stanford management education program on ‘Customer-Focused Innovation’, Sutton and Rao set out to explore The Problem of More:

“Executives could always point to pockets in their organizations where people were doing a great job of uncovering and meeting customer needs. There was always some excellence – there just wasn’t enough of it. What drove them crazy, kept them up at night, and devoured their weekdays was the difficulty of spreading that excellence to more people and more places. They also emphasized that the Problem of More (which they often called “scaling” or “scaling up”) wasn’t limited to building customer-focused organizations; it was a barrier to spreading excellence of every stripe.”

Scaling Up Excellence is a thoughtful, easy-to-read and intensely practical book about successful business transformation and innovation: how to start it, lead it, nurture it and sustain it. Continue reading

Goobledegook And The Bottom Line

ChaosThere’s a parable for our times over on the FT. It’s a story about the real-life rebellion of a senior director who refused to approve a new IT system because he had “not understood a word” of the presentation to the board. Initially the lone dissenting voice in the room, his fellow board members eventually admitted that they had not really understood the project either, which had been explained in “baffling goobledegook”.

In this particular re-enactment of Twelve Angry Men, no innocent man was saved from the gallows but the board did go on to demand that the CIO come back after translating the plans into plain English. As the author Gillian Tett notes, it’s a story that should challenge us all:

“For when we look back at 2013, one of the big themes was the regularity with which computing systems produced costly glitches.”

There’s been a lot written on IT failures and their impact, which can be devastatingly expensive. The evidence points overwhelmingly to poor communication as the most common root cause. Between all the stakeholders, but most critically between IT and the business. Successful IT project teams, as McKinsey has noted, continually engage with stakeholders – at all levels, internally and externally – within a rigorous governance framework for managing change.

What happens most often of course is that the board blindly nods the project through. But this isn’t just a problem of poor communication at board level.  At every level, there’s often a stilted and meagre dialogue running between IT and the business, increasing risk and undermining business benefits. And it’s mostly hidden in plain sight just because expectations are so low.  Caring too much about clarity and accountability can even be career-limiting.

How then do we fix this? Continue reading

Why Are So Many IT Projects Successful?

It’s bizarre how many major IT projects are ‘successful’.

Imagine buying dinner for your loved ones at a restaurant where the service was always slow, the bill was usually way beyond the prices shown on the menu, and the dishes were less than half as delicious as you had expected.  And, 17% of the time, the evening would be so disastrous that it would threaten your marriage. Not sure that many of us would call that successful? But when it comes to ERP, that’s what people most often do.

A new survey on ERP implementations, published on Michael Krigsman’s Beyond IT Failure blog, records:

  • over 50% of projects experienced cost overruns
  • over 60% experienced schedule overruns
  • 60%  of respondents received under half of the expected benefits.

It’s another piece of evidence to add to the bulging portfolio marked ‘IT Project Failure’ (the root causes for which I’ve rehearsed elsewhere).

But it leaves the intriguing question: How can it be that 60% of respondents in this survey thought their ERP implementation was successful?  It’s not an aberration. The hard data and the shot-through business case may point conclusively in the opposite direction, but most often organizations define their major IT projects as ‘successful’.

Maybe it’s a mix of Stockholm Syndrome and exhaustion.  It may feel initially like a comforting embrace, but the SI relationship frequently turns sour (only 25% of respondents in this survey were satisfied with their implementation partner). As the project challenges mount, the client’s expectations plummet.  In the end, there’s relief that it simply finished. And at that point, the client is happy to draw a veil over its own shortcomings and declare success.

Which is understandable but a pity. There’s a colossal waste of resources going on here, and, as McKinsey has warned, maybe 17% of major IT projects are black swans that can threaten the very existence of the organization.

Related Posts

07 Jan 2013    Cloud Without Risk: Pie In The Sky

08 Nov 2012    IT Success: Don’t Let The SI Take The Wheel

© Text Michael Gammage 2013

Cloud Without Risk: Pie In The Sky

We know that systems failures are surprisingly common, hugely wasteful and can bring a company to its knees.

Best example last year must be Knight Capital, a market-maker responsible for 10% of US equity trading volumes. In two hours of trading on the afternoon of 1st August, a ‘software glitch’ lost the firm $460m. The subsequent rescue package cost the owners 70% of their equity.

Arguably though there’s no such thing as an IT failure. If all work is ultimately process, then ultimately it’s always a process failure.

At one level, Knight Capital went down because of a flawed implementation of a software upgrade. But it’s probably more true to say that, somewhere along the line (and maybe we’ll find out once the legal battles are done), there was a flawed process, or a good enough process that was poorly executed.

Probably both. And almost certainly – because this is the continual theme – the root cause was ineffective collaboration.  Vital stakeholders were missed out from the consultation. People thought that they had a common understanding of an end-to-end process and missed the gaps. There was no governance framework to ensure that people used the latest document. No-one realised that there were two different versions of the same process…

So McKinsey is right when it warned last week of the new risks in the migration to cloud services, making it clear that this is not simply a technical IT challenge:

“IT organizations must now adopt a business-focused risk-management approach that engages business leaders in making trade-offs between the economic gains that cloud solutions promise and the risks they entail.”

In cloud migrations, as in every other business transformation program, it’s effective collaboration that underpins innovation and sustainable improvement – and ensures that risks are properly managed.

It’s extraordinary therefore that so many organizations flirt with disaster, blithely assuming that they don’t need an enterprise-wide process management platform equipped to enable effective collaboration.

They may say otherwise but in practice they rely on definitions of their business based on process fragments, in multiple formats and tools, often in arcane technical languages, of unclear provenance, scattered across multiple repositories, only tenuously linked with operational realities, and ‘managed’ with the flimsiest of governance.

Amazingly, Gartner’s dramatic prediction, announced two years ago this month, that: “Between now and year-end 2014, overlooked but easily detectable business process defects will topple 10 Global 2000 companies” still looks a safe bet.

Related Posts

11 Dec 2012    Process Management and Google Maps

19 Nov 2012    No Other Corporate Asset Is Wasted So Spectacularly

© Text Michael Gammage 2013

IT Success: Never Let The SI Take The Wheel

Large IT projects frequently fail. One of the SIs (the usual suspects) is invariably involved. So are the SIs in some way the villains – or just unlucky to find themselves, so often, innocent bystanders at the scene of the crime?

Client organizations don’t do major systems projects every year.  SIs do them for a living. So it’s natural that clients look to leverage their SI’s expertise, a tendency reinforced by the SI’s pitch: ‘We’ve done it a hundred times. Just trust us…’.

It’s understandable too that, once the SI has been selected, clients most often sigh with relief – and surrender to their comforting embrace. Willingly seduced, they allow their SI’s methodologies and tools to dictate almost every aspect of their program.

The client and the SI have conflicting agendas of course, in at least two vital areas:

Business Transformation vs IT Project. The SI is hired ultimately to deliver an IT project.  So the SI will always focus on the technology issues.  But all the evidence suggests that projects fail when they neglect business stakeholder engagement and lose sight of wider business perspectives.

Sustainability. The SI has a project focus, often strongly reinforced by contractual incentives.  The SI needs to get the system delivered so it can get paid and move on. Whereas the client has a longer term and more holistic perspective. The client is looking for sustainable improvement.

These conflicting agendas can be worked out – through an ongoing dialog driven by the client, which must retain responsibility for staying in control of the SI relationship.

But most client organizations just don’t have a collaborative framework to enable this essential dialog in any productive way. The result is that the SI usually takes the wheel.  And so the focus shifts to the IT aspects and the system go-live, significantly increasing the risk of project failure.

Straws in the wind suggest that things are changing. IT projects that I know of which have adopted Nimbus have also reduced the SI’s role.  By spending less, they seem to get more. The client avoids capture by the SI, and so can ensure the effective collaboration that prevents ‘a business transformation project enabled by IT’ degrading into ‘another IT project’ – significantly increasing the chances of sustainable success.

Essentially, the client gets to focus the SI on its core competences – and avoids the cost of man-years of consultants leading low-value process workshops in airport hotels.

Related Posts

29 Oct 2012    IT Project Failure: How Did We End Up Here?

23 Oct 2012    Mapping The Stakeholders in GBS Success

© Text Michael Gammage 2013

IT Project Failure: How Did We End Up Here?

McKinsey’s report last week, drawn from an analysis of 5,400 IT projects, deserves reflection. It makes sober reading:

“Our research, conducted in collaboration with the University of Oxford, suggests that half of all large IT projects massively blow their budgets. On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Software projects run the highest risk of cost and schedule overruns.”

Conspiracy theorists and crime fiction fans will likely read it and claim skullduggery amongst the SI consulting firms invariably associated with large IT projects.  Resisting the inner detective, let’s just stay analytical and ask: how did we end up here?

At the heart of McKinsey’s prescription for delivering IT success is “helping IT and the business to join forces” – the need for effective collaboration.

Successful IT project teams, says McKinsey, continually engage with stakeholders – at all levels, internally and externally – within a rigorous governance framework for managing change.

IT program teams use email, Sharepoint, shared desktops, conference calls and social media.  They typically have budgets to allow substantial groups to convene for months of workshops in airport hotels. And the people involved, by and large, want to do a good job and to be associated with a successful project.

So, with all these resources: If effective collaboration is the key to success, and the costs of failure are so enormous, why do large IT projects so often fail?

In my experience, the two biggest barriers to effective collaboration between IT and the business are that:

#1 They don’t speak the same language. Theoretically, their lingua franca is ‘business process’.  But, most often, the IT program team adopts a technical language and systems mindset. So the business is forced to adopt swimlanes and other IT constructs. Without the business properly engaged in discussions of the current operational reality and the target operating model, the project is immediately vulnerable to what McKinsey identifies as a common pitfall: ‘teams focus disproportionately on technology issues and targets’.

#2 Holistic perspectives are lost or ignored. Most often, the IT systems mindset comes to dominate: if it’s not automated, it’s secondary. And so the business stakeholders come to focus only on the process fragments linked to system transactions, which limits creative thinking about transformation possibilities and hampers change management.  Far too few of those involved, if any, can see the whole. What starts out as a business transformation project enabled by IT slowly degrades to become an IT project with business consequences.

Which is how, most often, business stakeholders find themselves forced to approve enormous documents (400 pages is the biggest I’ve seen, others claim to have seen 600+ page documents), with each process fragment annotated with technical flowchart diagrams and multi-column tables of requirements extending over many pages. It might as well be in Egyptian hieroglyphs. Even worse, that document becomes simply a project milestone, the end of a requirements capture stage. It totally undermines the idea of the rich ongoing collaboration between IT and the business that defines successful projects.

That document is the smoking gun at the heart of IT project failure.

Related Posts

26 Oct 2012    Avoiding IT Failure (and Bankruptcy)

28 Aug 2012    The ROI on Process Visualization

© Text Michael Gammage 2012

Avoiding IT Failure (And Bankruptcy)

News from a colleague yesterday of another SAP project using Nimbus: unforeseen delays, a shredded budget and a bewildered client. Another huge success in fact.

This European manufacturer was told by a leading analyst firm to expect to take at least 8-12 months for its Finance transformation and SAP consolidation project across 8 countries and 7 lines of business.

Opting to use Nimbus, the program team worked with stakeholders from across the European business units to agree common business processes – in blueprints that included KPI’s, policies, local variants and all the detailed requirements necessary to implement a single SAP instance.

Their results were completed, presented and approved by all the country CFOs and other CxO stakeholders in just 4 months.

Which leaves the program team with an unforeseen delay while the rest of the business scrambles to catch up (it was widely assumed that the program team would take at least 12 months to complete the blueprinting phase).

And the client’s budget is shredded.  The program timescale has been dramatically shortened, significantly reducing the consulting days required (as well as the equally expensive number of days required from internal resources).

This client’s savings are not at the expense of quality. The reverse in fact. As it happened, the client’s chosen SI implementation partner had no Nimbus expertise. So the client decided that they would not be required for the blueprinting phase. It was a gamble that paid off handsomely.  When the SI was recently re-introduced back into the project, at the completion of the blueprinting, its verdict was that this is “the best SAP blueprint we have ever seen”.

It’s another example of the power of Nimbus as a platform for effective collaboration across complex and dynamic environments (yawn…). But it’s extraordinarily relevant in a week when McKinsey has published results from a survey of 5,400 IT projects (with a combined cost over-run of $66bn).

As McKinsey notes, the keys to IT project success are not rocket science: good stakeholder management, effective teamwork and avoiding ‘the common pitfall of focussing disproportionately on technology issues’.

So a platform that provides visualization of end-to-end processes – intuitive, in their complete business context, and in the language of the business – and wrapped within a robust governance framework won’t just cut costs.  It’s the best possible insurance against a ‘black swan’ – the 17 percent of IT projects which McKinsey reckon go so bad that they can threaten the very existence of the company.

Related Posts

28 Aug 2012    The ROI On Process Visualization

24 Aug 2011    The Root Cause of IT Failures

© Text Michael Gammage 2012