Managing Culture Shock


Woman at KeyboardOver 90% of our new clients already own project control software. It’s a tough statistic to come to terms with generally and it implies a particular environment in which, in our firm, we live most of the time. If you’ve been involved with the implementation of project control systems in the past, you know that it is often the case that you are replacing a system rather than installing and implementing into an unsullied environment. The nature of the project management software industry is that it changes quickly and, unlike many systems, there is often huge returns on investment for getting the latest, fastest algorithm to calculate critically required project resources.

Dealing with the culture shock of a new system is bad enough but, as is the case with project control systems, that environment is “mission-critical” to the organization, the pressures of the entrenched culture can be fatal to the implementation.

Culture shock is inevitable in any major change of a system. It refers to the general upset that occurs when familiar systems are replaced with unfamiliar ones. Generally these systems are the oldest, most entrenched systems in the organization. Often, paradoxically, these systems are not even well liked and are complained about by the very people who will be most upset at them being removed. It is a testament to how much we crave the familiar to see what we will put up with rather than change. However, the phenomena can be a huge upset to personnel who are attempting to update systems and to make the organization more effective. If a successful implementation is essential to the success of the organization or the project, then this situation must be allowed for and dealt with.

Actions by those experiencing culture shock can be varied. Some users, faced with a new system will resist actively, stating their objections and demanding satisfaction. These are the easiest to deal with as the dialog to resolve their concerns has already been started by them. Other users will simply not use the new system, sticking with the old system if it is still available or not using anything at all and not speaking out about it. Perhaps the difficult type of reaction are the “covert resisters”. These people will pay lip service to the success of the implementation, declaring themselves to support it yet, their every action will do the opposite. In particular, the longest standing staff members are most susceptible to this shock reaction and are most likely to have close contacts in upper management where a few well-placed words can wreak havoc on the implementation plan.

The effects of this culture shock can be significant. Users of the new system may experience a long period of confusion with the new system, insisting in vain that it work like the “old system” even if the old system was flawed and inaccurate. This confusion can rapidly lead to general ineffectiveness across the organization.

Recently we were involved in an organization-wide implementation of a new project control system on a significant project. As anyone who is working on large projects knows, the pressure on the project team, indeed on the whole organization is intense. In this case, the project management group had determined that the cost of staying with an outdated project control system outweighed the disruption of replacing a system which was used across the enterprise.

With time being of the essence, training, consulting, data-conversion and system configuration were all on the “fast-track” with many tasks working in parallel to get them up to speed in the minimum time possible. However, with the core project management team focused and working overtime to get the system up and ready, they were less available for the human element, spending time with the remote office users or working on focus groups and sitting in on training sessions. The result? Not surprisingly, the initial “go-live” week wasn’t as successful as we’d hoped. The system was rolled out, worked with little technical difficulties for about four days. However, the reaction from almost every corner is that the system “doesn’t work the same way as the old system”. So may users reported that they couldn’t deliver key project data in a timely fashion that after the first four days, the project management team relented and instructed users to return temporarily to the old familiar system for several days while these “issues” were resolved. An intense retraining and internal marketing campaign restating the returns that the end user could expect along with some key support from upper management at just the right time made a second run at the implementation much more successful about 2 weeks later.

This implementation was successful but over the years, I’ve seen many that are not. The culture shock reaction from the end users is so unexpected and, so intense, that the implementation dies on the starting blocks and never recovers.

So what should you do to avoid this scenario in your own implementations?

First of all, expect it to happen. The most vulnerable implementations are those where the implementors naively assume that the new system will be welcomed with open arms by all involved.

One of the most significant elements that should be part of any enterprise-wide implementation is upper management support. Find a champion for the implementation who won’t shy away at the first grumblings and make sure that someone has enough authority in the organization to make sure the implementation will not be abandoned. Also, (do I need to say this?) make sure that person is apprised of the potential for culture shock and prepares for it.

Next, plan on a significant effort communicating with and informing as widespread a range of users as possible. Run focus groups, or information seminars, or just get a newsletter going. Make sure there is some mechanism for feedback by the end users. Nothing ticks people off more than not being able to be heard.

Three words: Training, Training and Training. Can I say this enough? Spend more time training than you’ve already planned. Planned a lot of training? Put some more into the plan. Even if the training sessions become more of a user-group meeting or bull-session, all the better. The more users are able to get out of the new system, the more likely they’ll be to support it.

If it’s possible, a phased approach will often help in this kind of implementation. Start with the group most likely to succeed, not the group making the loudest noise about what’s not working.

Finally, keep selling this solution. Many groups will do a selling job for the new system one time early on in the plan then not return to it again until the software is actually installed. You’ve got to keep selling the new solution until it becomes the new culture.