See my previous post for some context, and my definition of what a big horrible technology program is, but let’s just say I’ve ridden at a few rodeos, namely, in multiple industries, in business critical situations, I have managed and completed IT and digital programs successfully in less time than many thought possible, and often faster than anyone has heard of in their respective industry.
This series of topics covers the reality of things you are unlikely to be able to change during the implementation phase, the implications of those things, along with a series of axioms I have applied successfully over the years. My reference point for these thoughts is a big core system change in a variety of industries including accounting, insurance policy, hotel or cruise reservations, bank account systems, primary e-commerce platforms etc. Here we go:
Slow and sure is fundamentally flawed
Fast and friendly just doesn’t exist
Want to go faster?, cut the team in half
The laggards will never stop being laggards
Aim small, miss small
Advance the ball with every play
It’s going to get worse, then much worse, then stable, then better, eventually
Just keep swimming
It’s like riding a motorcycle, everyone else is out to kill you
S**t happens
Be Prepared to stand alone
Grow a thick but sensitive skin
You manage success, you measure failure
There are no hard and fast rules, and all rules are made to be broken ade to be broken
The list is too long to elaborate on in a single post, so I’m going to attack the list a little at a time. This post is the start of this effort.
Slow and sure is fundamentally flawed
There is an argument, particularly from large management consulting firms, that the key to success with large scale business critical programs is a carefully controlled process, where detailed planning followed by controlled execution, and constant validation with the business, will effectively deliver business benefit. I thoroughly reject this hypothesis, and see it as merely a way of consultants extracting obscene fees over long periods of time.
Those of us who have dealt with large scale IT systems realize that there is a tendency towards entropy (increased chaos over time) in computer systems, which in part, causes ongoing maintenance requirements and drives maintenance teams to struggle with increasingly complex technology performing increasingly diverse tasks. To replace an enterprise IT system and get business benefit from it, the project team needs the new system to catch up and overtake the old system’s capabilities.
Hopefully the new system has some inherent advantages which are easily recognizable when the choice is made; but there tends to be less control than is typically anticipated about functional divergence after the change process starts. New regulations, a market shift, new competitors with a different business model, as well as a lack of true understanding about how the new system works, can all affect the viability or perceived viability of the program.
Other factors affect an organization’s ability to carry out a complex system transition including costs, scarcity of expert resources, logistical issues, political resistance, availability of executive support, and on a more positive note, underlying business growth.
All of these factors are adversely affected when you choose to proceed more slowly, carefully, and in a highly structured manner. The opposite effect is that these are all contained and/or their impact reduced to some degree by going more quickly; the faster you move, the smaller the impact on the business.
The IT industry has a dreadful history of failed projects, where the only perceived way of improving is to increase control, slow down, get more sign-offs, be more careful. Actually, I have found that big technology programs are like riding a bicycle, stability comes with speed.
Let me set out some of the positive aspects of going faster, acknowledging that the concept of “Change” is hard and disruptive regardless of the velocity of the program.
The faster it’s done, the sooner the organization can focus on the new system, and the sooner the grumbling about change stops.
The faster it’s done, the sooner you can exploit the advantages the organization wanted in the first place.
The faster it’s done, the cheaper it will be (I have had to help many clients get control of their long term consultancy “partners”!)
The faster you commit to the new system, the faster the organization can learn to live with the new system's idiosyncrasies (they all have them).
The faster it's done, the sooner you get to the next program on the never ending list most organizations carry.
The faster it's done, the less likely is the program to get stuck in a quagmire of politics.
The faster it's done, the easier it is for the business to focus on understanding and adopting the minimum set of mandatory requirements, therefore reducing scope.
The faster it's done, the less likely is the program to lose subject matter experts through natural attrition.
I postulate that going as quickly as absolutely possible exponentially increases the probability of success. The key is to attack a program like your life depended on it, because the program's life does.