Share via

Are we there yet?

This article is part of our "From the Ttrenches" collection. It describes how enterprise system implementations need to able to adapt and evolve to be successful.

To download the Word version of this article, see Are we there yet?.

To see more articles, see "From the Trenches" white papers.

Are we there yet?

Over the years one of the biggest pitfalls I've seen to the selection and deployment of enterprise software is the thinking of the implementation as fulfilling a static purpose. It's possible this is just a sign of our times as we attempt to sound-bite everything in our world. "It manages our projects" "It's our timesheet" or "It's our ERP system" or "We have an EPM system" minimizes our having to continuously think of all the aspects of our business that may be touched by our enterprise system. Yet those organizations I've encountered which have been the most successful at deploying an enterprise project or enterprise timesheet system inevitably think of them as a "living system"; a system which is continually evolving by design.

Why think of it as a static system?

If it's true that there is a better chance of success in an enterprise system being thought of as a dynamic environment, why do so many organizations consider their enterprise system as a fixed piece of software?

There are many possible reasons.

Perhaps getting the enterprise system accepted meant making a business case in a complex budgeting environment where there would be one chance and one chance only to get a budget approved for the system. Going back each year or each budget cycle to ask for another phase and then another is politically impossible.

Or, perhaps you've inherited the system and certain promises were made about what it was to deliver or perhaps it has been there awhile and everyone in the organization thinks of the system as delivering only a set list of business features.

Or, perhaps inside politics are at work and there are those elsewhere in the organization who would be scared of a system without boundaries.

What may be wrong about that thinking?

It's odd that we even think of a software system as static. We don't usually think of the problem it is to solve as static. The problem statements that we associate to the implementation of an enterprise system are almost always evolving. They are dependent on changing economic conditions, changing business conditions, changes in what competitors do, changes in personnel or changes in technological architecture. An organization that thinks that business conditions will never change is unlikely to stay in business long. If we think of enterprise software, think of how quickly the technology aspect of the solution changes. In our own TimeControl timesheet business, we've gone through 6 major technology architectural changes in 20 years. We started in 1994 with a DOS version, then followed up in 1995 with a Windows version, then a Client/Server version in 1997, then a browser-based version in 1999, and then a hosted in-the-cloud and a mobile version in 2010. That's just technology architecture. Additional evolution occurred thanks to changing economic conditions, competitors and just from experience. For those of us in the enterprise project or enterprise timesheet software publishing business, we accept that change is a constant.

It's no different thinking of the deployment of an enterprise system. In the time it takes to implement an enterprise system like Project Server, the organization implementing it is bound to change. There will be new clients, new personnel and personnel who depart. In the time it takes to choose and deploy the EPM system, other competing products will emerge. We've seen organizations paralyzed by this phenomenon. Due to concern that they will not select the perfect product, the release of another product by another vendor has the selection group pause its work to consider the new product. Or, the release of a new version of one of the products being considered has everyone worry that their evaluation will not consider all alternatives. These groups start over and over and over again. A final decision is never realized because the organization requirements and the solution options never stop changing.

The problem for these organizations is that the business challenge that had them look for a solution in the first place doesn't go away, and in the absence of a decision, they are not solved.

So if not static, then what?

Enterprise system deployments will have a better chance of success if they are living environments. They should grow, evolve and adapt to the changing conditions around them. And, yes, perhaps at some point in the future when they're old, they will need to be retired. The most critical change to this way of thinking is that the perfect solution is not the starting point. The priorities become choosing a solution that meets the most critical needs but which has the capacity to adapt to more complex needs in the future even if these have not been perfectly articulated yet. One of the most important selection criteria becomes flexibility rather than breadth of functionality.

How can we avoid static cling?

There are a number of things we can do in order to avoid being stuck in a static deployment paradigm.

  • Make phases in your implementation plan and never run out of phases.

    If we adopt a phased approach to the enterprise implementation, we can concentrate on a first phase that is much more modest. Our consulting staff are taught to identify not the most we could do but the least. We tell them to "look for the most minimal deployment, the deploying of which will produce an ongoing positive return on investment." The great news about this is that value from the system will start much, much more quickly and in the use of the system, even at a more minimal level, the requirements for future use will become clearer.

  • Make a budget that allows for evolution.

    One challenge we've seen in many deployments is the "one visit to the well" thinking where a request for an enterprise system can be made only one time. Making a phased budget instead with the expectation that the first couple of phase budgets are quite detailed but future phases are less so is inevitably more successful.

  • Pick highly flexible solutions.

    Our staff have adopted the motto "Semper Gumby" (after the flexible toy Mr. Gumby). It's a play on words first coined in the US military but it fits our thinking perfectly. Just like Mr. Gumby, we never know what shape we'll be twisted into next so we think in terms of flexibility. In whatever enterprise solution you choose, placing a premium on flexibility is a success criteria.

  • Don't abandon all of your implementation team when you go operational.

    Keep key resources going forward. This is an extremely common challenge. Often in an enterprise deployment, the organization is drawn to assigning its most experienced and skilled resources and that certainly helps get the system selected and implemented. However those resources are the very ones who will be needed on the next critical project and they are likely to be pulled off of this one just as the system goes live and is at its most critical juncture. Planning in advance to have certain key resources stay with the implementation for a longer period can make an enormous difference.

  • Make a permanent system enhancement team, small perhaps, but skilled.

    The team that assembles the requirements for the enterprise system will be looking at business processes, system functionality, integration with other key enterprise systems and more. Having these people abandon the system once it's installed makes future evolution very challenging. Put this enterprise system and perhaps other related systems into long term evolutionary care where the needs of the organization and the system capabilities are evaluated on a regular basis.

Learn from actual use

  • Get your system into production early.

    This is so much easier in today's world than it was even 5 years ago. You can take advantage of cloud-based installations and remotely-accessible services to get your system running quickly. Most enterprise systems which have both cloud and on-premises offerings have methods of evolving from one to the other. This is certainly true with Project Server. It's true for our systems also.

  • Ensure there is a feedback loop that results in system enhancement.

    It's good to see things that can be improved, not bad. Some implementation teams discourage suggestions for improvement, concerned that they will keep people from using the system they have already deployed. Our experience is that those who make suggestions for improvement are usually the biggest allies of the enterprise system. Even if an idea can't be implemented right away, it should be welcomed. Creating a system for identifying and encouraging new ideas for the enterprise system keeps everyone invested and can bring enormous benefits.

  • Don't abandon hope too quickly.

    Some firms will say "The problem is in the software" and jump ship before there's a chance of success.

Are we there yet?

So when will we get there?

Hopefully never.

That's not to say that the way stations along the way won't be great places to pause. Your first target for a new implementation of enterprise software such as an enterprise project or enterprise timesheet system should be a production environment that is delivering a positive return on investment. Look for a system that can deploy in layers or phases and with enough flexibility to be able to grow, adapt and change and you're likely to find more productivity along the way than you might find waiting to pick the perfect destination.

About the Author

Chris Vandersluis is the president and founder of Montreal, Canada-based HMS Software, a Microsoft Certified Partner. He has an economics degree from McGill University and over 30 years experience in the automation of project control systems. He is a long-standing member of the Project Management Institute (PMI) and helped found the Montreal, Toronto, and Quebec chapters of the Microsoft Project Users Group (MPUG). Publications for which Chris has written include Fortune, Heavy Construction News, Computing Canada magazine, and PMI's PMNetwork, and he is a regular columnist for Project Times. He teaches Advanced Project Management at McGill University and often speaks at project management association functions across North America and around the world. HMS Software is the publisher of the TimeControl project-oriented timekeeping system and has been a Microsoft Project Solution Partner since 1995.

Chris Vandersluis can be contacted by e-mail at:

If you would like to read more EPM-related articles by Chris Vandersluis, see HMS's EPM Guidance site (