Agile development, elongated deployment

Exchanging notes with some old friends, reminiscences of long drawn ERP or similar projects and some quick wins took us on a rollercoaster ride. Everyone had been through a couple of implementations that stretched patience and planned deployment timelines that now seem unreasonable. In those days 5-year multi-geography deployment was acceptable; after all the first implementation/deployment had to stabilize and learning imbibed before taking the next steps. Baby steps before running you know !

I remember my first ERP implementation almost two decades back that lasted almost a year; that company was the size of today’s small medium enterprise. But in those days business agility was measured in years and not in quarters or months or for that matter weeks. A decade later I was involved in a global deployment of a large back office system; we were at the tail of the global project spread over 5 years. Since the business impact was considered nominal, no one saw any issues with the 5 year cycle.

A debate then ensued attempting to answer the question that in the current uncertain world how long is long indeed and untenable ? In the age of SCRUM and hyper time sensitivity towards every change in business process or new business idea, what is an acceptable implementation plan for a project that spans multi-countries ? How long should it take to replace an ERP system or a financial accounting system across say 50 locations, each with some variances or country specific regulations or statutory reporting ? No easy answers here, I have not come across less than 3 year plans for such deployments.

It is an acknowledged fact of IT implementations that they bring about change; when we look at large scale projects, the change is always disruptive (the level of disruption varies from positive to extreme negative). The subject matter experts from the business end up with pressure of maintaining existing operations while dividing their time to project led improvements. Setting expectations and constant communication that is the hallmark of large projects rarely finds its way into the smaller innovation projects. But can this be sustained over 3-5 years ?

What about systems that are created with urgency portrayed by the business but languish in their use ? Many times IT organizations work under undue pressure to create solutions deemed critical towards continued success or to react to competition, but they end up as shelfware. Unanimous in their reality this thread triggered reactions on or lack of sign-offs. Can the CIO in such cases cite past instances and refuse to toe the line ? Probably not, the backlash of such behaviour would be extremely negative to IT.

When cloud based solutions deploy new releases, some offer customers options to use earlier versions for a short while. Not so in the case of consumer apps; when a change occurs, everyone is impacted and learns to live with the new. Why is it that we are willing to accept the change in our personal space but abhor it in the corporate environment ? Is it because that the stakes are higher or the risk averse nature of the corporate world ?

I believe the answer is in our ability to switch off and move to another in the personal space, which is not even a dream in the enterprise. If the production planning or financial accounting were to face issues post an implementation or change/upgrade, our ability is limited to rollback and not to explore new options at that time. But I am hoping there will be a day when what applies to our personal needs will also be good for the enterprise. Then the CIO will have to work harder to stay in the same place.