I was recently asked a question by an up and coming PM who had been tasked with migrating their business’s ERP off an old mainframe, the PM was a new customer of mine so I wanted to protect him if I could, he asked “what was the most important thing to do when managing large ERP migration projects”?, my quipped response was “well..aiming to keep your job is a great starting place”. This led to the immediate question “no, seriously, what are your thoughts” and after a moments pause, I further validated my previous answer.
I substantiated it by explaining the difference between a large bridge building project and any large IT project. A large bridge building project doesn’t change destination halfway through, the priorities will never change from finishing the bridge. A large bridge building project has a fairly fixed and pretty well-known set of costs, the pre-project investigations, surveys and the like are normally very thorough and ultimately the objective, to get to the other side is finite and well understood by all.
A large IT project requirement is more often than not, not completely understood by customers or the solution delivery agent, we tend to look at the same steeple but from different sides of the church (if you ever want to test this go draw the church from one side and compare a colleagues view of the other side, they are never the same), but the gap in understanding can be a chasm which will invariably create a delta between the requirement and the deliverable.
Often, large IT projects can be born in minutes, with very little or a cursory amount of work done to survey the current situation. In addition, those doing the surveying may not fully understand the current and historical business challenges, the technology in place, its limitations or its strengths, often leading to an ill-informed project which will carry way more risk than was necessary to deliver a given set of business outcomes.
Balance is a constant state of recovery
I’ve seen many IT projects start out as one thing and then mid-flight by capability epiphany or a new business priority evolve and or change the requirement. This is quite normal and in the world of liquid tools for liquid needs, this essentially has to be accepted, moreover, the person that embraces this with the right skills and awareness will be the ring bearer to rule all others.
I remember running a project to build a production workflow system that halfway through because of the workflow element and the timing of World Com & Enron debacles also then became the solution for achieving Sarbanes-Oxley compliance in limited time. In fairness, I can’t remember which branch of the project ended up being delivered first, but it certainly didn’t end where the project was destined at the beginning.
If you, therefore, accept that the destination of any large IT project may not be where you know the bridge build ends, then really you are more likely to have the realisation that you are in a constant state of change or recovery, constantly reacting to changes in business requirement and or business priorities.
Life is a Journey, not a Destination
All of a sudden the deliverables on the journey become way more important than the summit that may never be reached as essentially they may be the only wins that are achieved. Knowing how to divide the journey into a clear set of separate business wins is the key to success here, if you can get the business to agree to them as mini projects rather than one big project then all the better.
The tantalisation of swapping out the old tech beast for a new shiny playmate fades and is quickly replaced with a desire to tie immediate effort directly and quickly to a set of great business outcomes. As an aside and for the politically aware and upwardly mobile, outcomes that are aligned to new revenue are always celebrated with more bubbly than making the old horse run a little faster, that is not to say that there isn’t value in the latter, occasional sorties here are where the respect of the old guard will be earned.
I said to the PM “how long do you estimate that this project will take”? he said, “I think I can get it done in 3 ½ years”. I said “in my experience leaving a mainframe will take you at least 7 years, so that is double your estimate”, I then gave him the usual stack of reasons, unknown unknowns, unforeseen costs and the shifting priorities of the business.
I asked him “what the business wanted to achieve”? he said, “we wanted to reduce the cost of running IT and become agiler”. I asked him to articulate how much they wanted to save and what new agility they hoped to gain. You won’t be surprised to hear there was no exact or detailed answer to either question.
Rolex or Timex, the time is still the same isn’t it
Drilling further there were some projects that had been difficult to deliver because of integrating with the old ERP. So their first answer was to throw the baby out with the bath water. At this point, I led him to a few articles and software tools that would have opened all the doors they wrongly perceived were locked. A simple search on the web could have found the same answers, but they failed to articulate the question and were wedded to the self-perpetuated belief that the problem was the old ERP, this in addition to how much shinier the new Rolex looked compared to their perception of what they had being a Timex.
As it turned out they actually only had a few significant projects that were bottlenecked, the two most significant ones were a customer self-service suite (mobile app and website) and modern CRM, they had decided on Dynamics. He said “we think we will be using the new CRM system in 3 years”, I said, “you could be using it in 3 months without putting your job on the line or your entire business at risk”.
The conversation went on and he was listening and moreover wanted others to listen too, so I also imparted some best practice advice around legacy technical debt reduction to his broader team, so that now they have a way forward that gives them agility today, reduces technical debt and commoditises their asset portfolio over time.
Armed with the new knowledge I said why not go and ask the business stakeholders what is important to them. You won’t be surprised that 2 weeks later the plans had changed from the lengthy pluming change project to quite an exciting set of new revenue related business projects that were going to be delivered within the next 6 months. Being halfway up the mountain reduces risk, delivers business wins sooner and the PM will get given medals, not his cards.
The Net Net
If you can’t bracket a business deliverable to 3 months then look harder until you can. Don’t fall into the trap of believing new technology will increase business agility with a straight line to revenue and bubbly in the boardroom. When it takes too long to deliver and you aren’t responsive to in-flight business needs, it won’t matter how shiny the new toy will be if/when it eventually arrives, you won’t be there to see it.
New shiny tech IN and old rusty tech OUT is great and sometimes it is the only way but in the majority of cases, it’s a fools’ errand. Remember if you can enhance the old rusty tech with some new shiny bells and whistles, you won’t waste time reinventing the wheel and will invariably deliver great business outcomes more swiftly and in turn reap the accolades and rewards.