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
kumbesh E
Out of Curiosity wanted to know whether any “pilot” exercise was carried out? Irrespective of whatever the project managers think because of competion from multiple vendors everything goes for a toss which includes estimates
Sharath Kumar
Thank you for your question and comments. Yes, there was a pilot built in order to demonstrate and seek agreement on the way forward. However in hindsight, even the pilot exercise needed to be properly scoped to get a good control of your engagement. Regular reviews of pilots need to be held with the users to ensure the solution is headed in the right direction, and also so that the users are on board with what is coming. Your point about dependencies on multiple vendors is very much valid. We need to be aware of the risks or potential delays caused by dependencies, and build into our schedule estimates.