An organization had asked us to undertake a Project Server deployment initiative. The user base was gigantic. The deployment timeframe was tight, and on the agreed-upon budget we could just scrape by.
The initial kick-off meeting took place in an eerie room where there was a creepy pale white elephant — existing data and its quality. Data was everywhere — the data’s quality had to be assessed and some of it had to be created. The number of stakeholders to be engaged was growing in number and requirements were being agreed to, all leading to a gravely expanding scope.
To deploy the enterprise project management (EPM) solution in place, our experts put a lot of hours in — including plenty of blood-curdling non-billable hours to accommodate the work, even as it continued growing in all directions. Everything was done on horrifically tedious Excel sheets and hence the data had to be validated, scrubbed and cleaned up before migrating to the new platform. Custom code had to be written to migrate data, generating rejection errors as the data was in different formats. With every new delay caused by scope creep and inconsistent data, we spawned a new adversary.
Of course, the project ran over budget. We had to manage more non-billable time. The lack of a support contract increased frustration of the developers. However, due to a good working relationship with client, we were able to loss-lead on the service and still maintain a dialogue with them.
3 Creepy Lessons We Had to Learn
Always manage project scope to avoid scope creep. Make sure you have set this up and agreed in stone with the client in the statement of work. A proper change control process should be in place to manage any changes to the SoW. This will become your garlic necklace and holy cross to ward off any evil scope creep.
Service transition is quite important, not just with EPM but with any type of engagement. When handing over the delivered service or solution to the client, ensure there is an agreement in place to provide any support going forward. Having a support contract in place post-engagement will help recognize the support revenue and also formalize turnaround time according to the service level agreement.
Finally, do a formal current state assessment to avoid the “tip of the iceberg” horror. Spend enough time on understanding the current infrastructure, build a foundation for technology-enabled change and address the scalability needs of the client’s programs to avoid scary surprises at later stages of the project.
Photo courtesy of Christy Henderson
