Keeping Your Vendor on Track
It sometimes makes sense to have vendor experts implement a system for your organization, but this doesn’t assure success, it just helps spread the blame if things go poorly. The quality of service received from systems integration firms can vary from firm to firm, but they are all pretty good at avoiding blame, assuring everyone it’s not their fault. Because of vendor firm expertise at blame management, clients need to be vigilant and proactive about managing systems integration efforts.
Things weren’t going well on the project. The one-year project had already slipped six months. Personnel turnover on the vendor side was constant, including three project managers in a year. Two months before the scheduled go-live, the vendor spun off and sold the business unit performing the project, leading to confusion about who was staying with the original firm, who was going to the new firm, and resignations from staff who didn’t like where they ended up.
Still, the vendor was adamant that the new go-live target couldn’t slip without an expensive change order. The client department could stomach a slip if needed, but the vendor threatened that any further delay would cause resource hardships and the next window that the vendor could support was six months away.
The project office director was wary, worried that the system wasn't ready for prime time and that the vendor wasn’t prepared to support the system post go-live.
Together, we developed an approach to minimize thrash and tried to avoid the change order while holding the vendor’s feet to the fire. A month before go-live the PMO director gathered a detailed list of open issues and shared them with the vendor and his steering committee at their monthly meeting. He sought agreements on the issues and their priorities in the meeting, and when they had developed a sorted list, he worked to develop consensus on where to draw a line to define the minimum viable product (MVP), everything above the line needed to be resolved to the steering committee’s satisfaction before the go-live decision would be a “go”.
To some extent, this put the vendor on the spot in a public forum by compelling it to acknowledge:
- The issue(s) existed and were legitimate concerns
- The prioritization was fair
- Where the line was drawn on the prioritized list was reasonable
Once the vendor acknowledged these points, it became harder to blame the customer for delaying go-live. It also had a focusing effect on a vendor team that was struggling and vendor executives who might not have been getting the complete story from their project manager. Because most of the priority issues were on the vendor side and needed to be resolved by the vendor, it wasn’t realistic for the vendor to assert that a change order was warranted, “because the client is delaying the project.”
While we probably agree that developing acceptance criteria for the minimum viable product should happen earlier in the project, regularly revisiting and refreshing that list helped to keep the vendor honest.
