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.
In my last article, I talked through the benefits of carrying out major IT/technological change as quickly as possible, and now I want to expand on some of the negative implications of IT programs at lightning speed. I know that many of these issues happen in slower programs as well, but I have found them to be exacerbated by the stress associated with increased velocity.
Let’s talk about organizations first, most environments have some form of hierarchy, where decisions (like replacing a major IT system) are made at the top and the implementation work affects lower levels of the organization. This is overly simplistic but useful for my needs here.
Assuming that the program is large and business critical, it’s pretty likely the new systems will affect hundreds, if not thousands of employees, clients, vendors, etc . There are some things specifically about the employees that are important.
They have probably been working there for an average of 4.6 years (per bureau of labor statistics). In my experience, in healthy companies, it tends to be longer, and longer still for more senior staff and in government entities.
Each day in that 4.7+ years, they have gained more experience in a system that is likely been in use for over 15 years, and was designed over 20 years ago. They have grown comfortable with that system, acknowledging its idiosyncrasies, and knowing how to work around them.
Some of those users are experts in the old system, their power base and professional self-esteem are wrapped up in the knowledge of that system, maybe they even helped pick it 15 years ago, maybe they have been helping it evolve for the last 15 years.
A good percentage of these employees are scared by the coming change. Psychologically these people may well be happier in a stable environment
By now you probably get the idea, while you are there to chart a new direction, based on an executive decision, the lives you are going to affect may be wary or scared already. Don’t get me wrong, there will be advocates and evangelists for the new system, but there will be plenty of suspicion at all levels in the organization. At the top, it is fairly common for an executive team to understand the need for a replacement system, but it’s much more rare for this team to agree on how to replace, and, critically, on timing. That, plus the horrendous failure rate of large IT projects means that you are unlikely to have many more than one positive forceful executive sponsor, and often less.
Within the hierarchy there will be some who see the potential benefit, and some who don’t, and they all have some voice in the program success.
One last point before we go on, most organizations don’t have a good understanding of the stresses and strains associated with a large IT program, often, amazingly, despite having failed previously.
It’s clear from the above that being the driver, and probably the face of that change, presents a series of delicate challenges; needing to be forceful enough to succeed, experienced enough to know when to stop pushing, and tactful enough to be able to talk about critical issues internal to the organization. The subtleties of all of these skills are mostly learned over time (or were in my case!).
This brings us to my premise, fast AND friendly just doesn’t exist. If you are an effective change agent, you will have detractors, and if you don’t, you’re not going fast enough, and that will incrementally increase the potential of failure.
How do I overcome these challenges? Here are a few of the “tools” I use:
Clearly set the expectations upfront that it’s going to hurt, there will be times when we won’t be friends, and the real benefit comes after the change, not during.
Be absolutely positive and enthusiastic about a specific big, simple to explain objective, and evangelize it, to your team and the team affected by the change.
Add a date, say it loudly, and make sure everybody knows that is your objective, the more loudly you say it, the more likely it is to come true.
Develop a simple, 1 page, 20 item Gantt chart that shows how it could be done. More detail is the enemy here, and the chances of it working out like this are basically zero, but it reinforces the date!
As soon as possible build a presentation giving high level concepts for the program: Gantt, Vision, top 3 objectives, top 3 risks, leadership. Again evangelize, and keep coming back to the simple messages. It’s your job to handle the complexity.
Be committed, professional but firm, more flexible about how, less about when, and be friendly when you can.
At the end of the program, you will have to operationalize the systems, that includes building some bridges to program detractors, making sure their needs are met, and helping them be successful getting the business benefit from the new systems.