Shared Services: Search For Missing Benefits Continues

Deloitte 2013 Global Shared Services Survey ResultsDeloitte’s 2013 Global Shared Services Survey report, just published, confirms that things are progressing as expected. There’s growth – in the breadth of services offered, and in the spread of locations – and more complexity and sophistication, with more multifunction SSCs, more hybrid delivery models and more stand-alone GBS organizations.

This year, Deloitte is not publishing the main survey findings, listing only the questions asked of the 270+ respondents.  But one line in the executive summary hints at what is perhaps the most interesting story of all:

“A multifaceted approach to addressing the retained organization is required to realize the intended benefits.”

The word on the street is that few shared services programmes deliver their business case. They may do great things, they may employ very talented people, but often there seems to be a question mark over benefits realization. And although the 2013 Survey report doesn’t comment on this directly, a (separate) Deloitte webinar last week seemed to confirm that there’s no smoke without fire.

Now it’s true that that webinar was focussed on HR Shared Services. But many SSCs are now multi-functional, and Deloitte claims to have worked on 900 shared services projects. So it seems a credible source.

In Global HR Shared Services: Emerging Trends, Brett Walsh and colleagues from Deloitte shed light on Shared Services ‘optimisation’ challenges:

“Much has been said about the role of shared services in the transformation of the Human Resources function. Yet for many companies, the benefits expected from transformation are proving elusive.”

“Long after project go-live, when systems and delivery models are in place, organisations still struggle to release the full potential of their investment in HR Shared Services. In fact, many organisations report either failure or significant underperformance compared to their original business case.”

There’s no single solution. Every organization is different.  But I’m going to stake a claim that one of the root causes for the ‘missing’ benefits – maybe the root cause – is a laid-back approach to process management.  It’s the attitude that defining process is simply an overhead and a non-value-add activity; that it doesn’t matter if process is in duplicated and overlapping fragments, in different tools and formats, unconnected with real work, and ‘governed’ only by email.

Without the rigour and support of a process management platform, effective collaboration among the stakeholders on the design and implementation of change must be in jeopardy.  We see it mostly obviously, and dramatically, in the chasm that can appear between IT and the business, but it undermines effective collaboration between all the other stakeholders too.

Related Posts

21 Feb 2013    When Process Standardization Backfires

15 Nov 2012    Outsourcing’s Secret Sauce

© 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