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

To-Be Or Not To-Be

hamletA frantic call from a managing consultant at a Nimbus partner, asking for help on his way into a client meeting, reminds me of our own little Da Vinci code.

Only we, the process cognoscenti, know what Shakespeare really meant. Hamlet’s original soliloquy was not merely about the most noble course to follow. It directly addressed the more fundamental issues in process discovery:

‘To-Be or As-Is, that is the question…’

My friend’s client may be at the bottom of the process maturity curve but they have aspirations, and an urgency (hence my friend’s assignment). But, as is so often the case, they only want to focus on the future. When your organization is largely dysfunctional and you have finally gathered the energy to act, it’s natural to want to focus on the sunlit uplands of process maturity: ‘Let’s not waste time with the As-Is, let’s just focus on the To-Be processes’.

It’s fair to say that consultants themselves often disagree on how important it is to capture the As-Is processes. But none that I know would ignore them. You can’t plan a journey without a startpoint. Transformation plans without an adequate understanding of the As-Is processes are very likely to fail. So, at the very least, capturing the As-Is processes reduces transition risks.

But paying attention to the As-Is processes helps in other important ways too. It can expose gaps, overlaps and inconsistencies that were overlooked because the organization’s focus has been on heroic fire-fighting. It reveals connections and hidden dependencies. Often it throws up new ideas for the future state, and highlights issues that will be need to be addressed in the transition. It grounds the definition of the To-Be processes. Above all, it gets people collaborating across functional silos, using the language of end-to-end process.

Process maturity is ultimately founded on an organization’s cultural mindset. Jumping straight to the To-Be processes is a quick-fix mindset. We’ll always need to execute quick fixes – but process maturity requires the organization to be able to operate in a more detached and analytical mode as well.

My friend’s client of course doesn’t see it this way (hence his call for help). So he will take on ‘the slings and arrows of outrageous fortune’ and risk arguing that his client needs to do an elementary capture of the As-Is processes, just to reduce transition risk. And be confident that the client will gradually come to realize that time invested in capture of the As-Is can be consulting budget very well spent.

Which we all know is pretty much what Hamlet would have advised in the circumstances:

Thus conscience doth make cowards of us all,
And thus the native hue of resolution
Is sicklied o’er with the pale cast of thought,
And enterprises of great pith and moment,
With this regard their currents turn awry,
And lose the name of action…