Musings on Successful Systems Integration Engagements

InspireXT-Team line diagram
Table of Contents
Manish Popli
Manish Popli

As some of you may be aware, I recently made the switch from a big corporate career to pursuing an opportunity that was a long time coming – becoming a part of InspireXT, a specialised technology-enabled Supply Chain consulting organisation.

A momentous (at least for me) change like this brings about many memories and reflections on past events, colleagues, clients, and much more. Yes, there is plenty to reflect on and look back in satisfaction – and while there are a few engagements I wished went better than what transpired in practice, my memories are largely of satisfied customers and lasting friendships and mutual respect gained over the years. And, the minority of cases where things could have been better, have their benefit as well – as a source of hard-won wisdom and grey hair. After all, if all had been perfect, how would I know ‘what works’ and ‘what does not’.

So here I am, putting my thoughts on the most important markers of a successful Systems Integration engagement. This is not an exhaustive list and I am sure there is a complete and academic list of legitimate markers out there – and I would readily accept that ‘long-list’. This is just my ‘short-list’ and what I would definitely keep an eye out for right at the start of the engagement and ensure things stay within the control lines during the engagement. Some of these may be blindingly obvious, but I can vouch for the number of times these ‘blindingly obvious’ facts get de-prioritised (or ignored at times) for very legitimate reasons – from ‘organisational dynamics’, to ‘wilful ignorance’ to a myriad of reasons in between.

Is there a Business Case for the initiative?

It’s a cliché statement and everyone agrees having one is a good idea. How many times is it maintained? Yes, the cost picture usually is, but the benefit side of the equation is suspect. Many engagements start with a good idea and the proper ‘maths’, but most lack the discipline to do periodic checks to ensure that the business case still stacks up.

Why is this fundamental principle not adhered to? It is usually a function of ‘organisational dynamics’, the umbrella term that encapsulates the unique facets of an organisation – from ‘what the executives want to hear’ to ‘we are too far down this road to challenge’ to ‘it is difficult to put a finger on it’ and so on.

Of course, organisations that have the discipline to ensure that the compass is continually pointing in the right direction reap enormous benefits and make mid-course corrections in Programmes/Projects and derive the maximum bang from their buck. Some excellent examples I have seen keep track of multiple elements of benefits, both tangible and intangible constantly in the radar through the lifecycle of the engagement and beyond.

Is the Business intrinsically engaged?

An alien reading this would wonder at the sheer stupidity of this question. Of course, everything in an Organisation has to add value to the Business and as a result, business should be a part and parcel of the engagement. I wish that was true and particularly in the world of Systems Integration, it can deviate from this foundational principle.

I have seen large multi-million-dollar initiatives that are driven by ‘non-business’ parts of the enterprise and frequently have a ‘mystery’ team at client premises getting quizzical looks by the Business.

These technology demonstrators (yes, most of these fall in this bracket) or vanity projects eventually cause huge frustration. And should they have the (mis)fortune to see a change in client leadership mid-way, they are amongst the first to be axed.

Do the people delivering understand the difference between ‘Project Management Process’ and ‘Project Life-cycle’?

Admittedly, this third one is a far more nuanced topic. Let me clarify the difference between the two – ‘whereas the project management process describes what you do to manage the project, the project life cycle describes what you need to do to complete the work’.

A good analogy to make this clear is a project to build a bridge. The ‘project life cycle’ here will involve the engineering and the actual build activities to make the piers and lay the spans and build the bridge. The ‘project management process’ would be the controls around it to ensure there is a WBS, and dependencies with relevant monitoring and control processes to ensure the bridge gets built on time and budget.

Now, in the world of Systems Integration, with its well-publicised proportion of projects that went above and beyond their timeline and/or budget, there is a small problem. The general lack of understanding, or at least the desire or discipline to follow it, (even if the understanding is there) – of these two constituent parts and how they combine to deliver success. The simple act of following a well-respected ‘Method’ that effectively combines both the project management process and project life-cycle will ensure that the ’right recipe’ is being followed to create the ‘desired dish’. When the ingredients being mixed together are for a ‘risotto’, the oven is unlikely to manifest a ‘lasagne’. Or if I continue with the ‘bridge’ analogy, you do want to deliver the bridge with all the ‘rights’ under control – specifications, cost, timeline.

Now there are plenty of organisations that follow the principles discussed here – and they are the high performing organisations. I will end with these three. There are many more and perhaps further musings and your comments may spur me to write a sequel.

More blogs
InspireXT announces strategic partnership with Walpole Partnership, a consultancy formed of CPQ and Customer Experience…
InspireXT announce plans to expand its presence in the US and Canada regions….

Request for services

Find out more about how we can help your organisation navigate its next. Let us know your areas of interest so that we can serve you better.