One of the most common problems that organizations doing a big enterprise project management or enterprise timesheet deployment run into is trying to do more than one enterprise deployment at once. You would think that no one would deliberately put themselves into harm’s way by doing this but it happens often and that’s partly because of how insidious the problem is.
The road to trouble is paved with good intentions
Imagine if you will, being in a conference room in the very earliest days of an enterprise system deployment. The world is full of possibility. You’re working with management to identify key gaps in your organization’s processes. You’re looking at a myriad number of tools that promise to solve all evils. You’re narrowing down how you’ll attack the business challenges with the proposed system.
As you all look together at the processes that will be affected, it occurs to you that one of these processes reaches outside your original mandate. Perhaps you’re looking at creating a resource capacity planning system but it becomes clear as you design that solution that you’ll need to change the current time and attendance system. Or perhaps you’re creating a work management system and you realize that you really need to update the old CRM system. Or, perhaps you’re changing the way you do billing with a new ERP and you realize that you really need to update the document management system.
It’s the easiest thing in the world to let your mandate go beyond its borders and it’s the easiest while you’re in that honeymoon period of designing the new enterprise solution that you started with.
“Let’s just include that 2nd system while we’re doing the first one,” says one well-wisher and now you’ve got not one but two enterprise systems to deploy.
Being pulled in two directions
Enterprise systems are change management projects. What that means is that they’re less about the particular functionality included and more about how they change business processes. By their very nature, enterprise system deployments reach deep into the operational behaviour of the organization and changes it to something that is hopefully more productive. Virtually any enterprise system can have this effect and the effect can be far reaching. A CRM system doesn’t just touch the sales people. It can also touch production, marketing, engineering, support and, of course, management.
With any enterprise system, we must go to senior management and ask what they wish to accomplish. My standard question for management is, “What business decisions can you not make now or can you make only with great difficulty, the making of which would be improved with this system?” That’s true for enterprise project management systems but it should also be true for virtually every system.
If you aren’t going to improve business decision making or operational efficiency in some manner, then there’s little point in deploying such systems.
But when we try to deploy two such systems simultaneously, we run the risk of pulling management in two directions at once. Even if the end result seems like a rational flow of decisions from Point A to Point B, the deployment of one of these systems will change behaviour and not just of management but of everyone the system touches. When we deploy a second system before the effects of the first stabilizes, not only will the second system be almost impossible to get established, the risk is to destabilize the first system as well.
The most common result is a complete failure of both systems.
Let’s take an easy example to see how this happens. An organization sees the need to improve efficiency in the area of project management. They decide to deploy a new enterprise project management (EPM) system to do so.
At the same time, the organization sees the need to improve resource management and decides that this can be done by deploying a new HR system, affecting all employees.
The two projects seem mutually exclusive and, indeed, for some time, the deployment teams might not even be aware of each other.
As the design of each of the enterprise systems evolves however, the changes driven by the design and deployment of the new systems start to run over each other.
The EPM system designers request a list of all departments, staff approval hierarchy and skills for populating the EPM system. These lists are delivered to EPM.
Over on the HR system deployment, a need has been revealed for better definition of departments staff hierarchical staff management and skill definition. The departments are realigned and redefined.
The HR changes are revealed to the EPM team who have already moved forward on their structure reworks the area that is affected by the changes in HR.
HR is informed by the EPM team that they will be implementing a resource management calendar for EPM and will require all vacation definitions updated weekly. They also send a list of new skills to augment the existing skill set.
HR has already redesigned the skill set for employees and the new definitions by EPM don’t fit. They begin to re-re-design the skills area of the new HR system.
And so it begins.
The most likely outcome is that a certain level of frustration will be reached and the original notion of integrating the EPM and HR data at the points it touches will be abandoned. Each team will go its own way. This might reduce or eliminate a key element of the expected benefits of the new system.
A less common but usually more damaging outcome is that as the frustration of the back and forth changes increases, someone in management figures that this could be resolved by putting both initiatives into one monstrously big initiative and working the projects together. This is rarely successful.
Moving from in parallel to in sequence
For most business initiatives, working multiple tasks in parallel is highly efficient. Deploying multiple enterprise systems is not in that category. When it becomes clear that there are two enterprise system initiatives that can touch each other, the most prudent action is to advance one of them and slow down the other.
Determining which enterprise deployment should go first will not be a popular task. It does, however, offer a great opportunity for benefit because this type of decision can really only be made by senior management.
One of the leading causes of enterprise system deployment failure is the absence of management involvement. Technical and operational personnel are often given deployment projects without direct involvement from senior management to determine what benefits are expected from those systems. When two such projects get underway at once, it’s a good moment to re-involve management in the process to identify what is expected by the organization from each system so that a decision can be made as to which one should be done first.
Some of the decision making criteria for deciding which system should go first might include: expected benefits, costs, return on investment, speed to deploy, severity of impact on existing processes and risk.
Only once the first project is in production and is stable should the second project’s design restart. A stable, in-production system is one where the organization has fully adopted its use, has changed its processes to adapt to the new environment and where the benefits of that system are already being realized.
In the meantime, if your project is the one that has been slowed down, all is not lost. Knowing that you won’t be able to count on a shiny new enterprise system to solve your problems sends you back to the drawing board to think of how to solve your problems without it. We’ve seen countless examples of where an organization realizes other ways to improve their processes while waiting for the new enterprise system deployment to restart.
Whether your enterprise project is going first or going second, it’ll be better than having it go together. Doing two enterprise projects at once is a worst case scenario.
“How long will it take us to get completely trained?” I was asked recently.
