I was asked recently to help an organization prioritize its enterprise project management (EPM) deployment. The outfit in question — we’ll call it Acme — had assembled a multi-departmental team to determine the aspects of EPM they considered important. Acme had worked over a series of months to articulate
their process and to evaluate vendors. Replacing an in-house timesheet system with a new one that would improve the time and billing process was the priority, and Acme had already purchased several hundred licences of this time and expense system.
Acme called me in because the scope of the deployment had undergone a significant increase and the head of the team was concerned their entire plan was now at risk. The original scope had included several aspects of EPM functionality including the timesheet, but also a complete enterprise project management system for resource capacity planning, schedule tracking and more.
The selection of the timesheet system included, in part, the ability to link to Microsoft Project, which had already been chosen as the preferred EPM system. The original plan was to deploy the timesheet first over a four-month schedule and then work on the EPM deployment in the months following.
Somewhere along the way two things happened to dramatically alter the schedule. First, the timesheet vendor informed the client that a perceived deficiency in the timesheet could be solved with the functionality of the EPM system. Second, almost simultaneously, management had renewed its requests for resource capacity planning information from Project.
The result was to move the implementation of the EPM system forward and to implement the timesheet system and the EPM system simultaneously. I was not surprised to learn the schedule had not been lengthened to accommodate the changes.
I was asked to determine if the schedule was still viable and to look over the new scope of work to determine if this was the most effective course — an exercise done all too rarely in deployments of EPM systems. We looked at the final vision of the system from a business needs perspective. I asked the deployment team to identify business decisions they intended to make from the system rather than identifying the functions required. By focusing on business use, we were able to quickly list the business benefits. Virtually all of those benefits were focused around the functionality of the timesheet change rather than other EPM-oriented functionality.
This left us with the problematic functionality that had started the scope creep in the first place. The culprit in this case was the chief accountant who wanted to be able to extract resource capacity planning information from Project. When I asked how much effort was required to manually manage this function now, the answer was about five or so minutes a month. Such a small improvement could not justify the cost and effort of the whole EPM deployment.
The lesson? Let the business benefits dictate, and focus on the return on investment for each aspect of EPM deployment.