Troubled Project or Disaster? Understand What You Can Manage
Significantly upgrading a client’s data systems proved to be a large project—more than forty million dollars. Integrating the operational and financial systems would streamline operations and be easier to operate and maintain.
The project began with enthusiasm, but it bogged down in details of data conversion and organizational change, exacerbated by the systems integrator’s inadequate project management skills. The plan had significant omissions of tasks. Dependencies were not clear. Some resources were severely overcommitted.
Weeks before the initially scheduled go-live date, it was no longer possible to ignore the painful truth that the system wasn’t ready, and the proposed implementation date slipped several months.
The IT executive running the project left, prompting the CIO to get involved. He met with the vendor team and requested additional project management support. These efforts were somewhat successful, but it would take time to recover from prior mistakes and get the project back on track. The second schedule slip came shortly after a serious heart-to-heart between the vendor and the CIO, acknowledging that the recently published schedule was still impractical.
Key stakeholders understandably began to worry that the project was out of control. A competitor had gone live with the same product and met with disaster, unable to bill customers for nine months after implementation.
The CIO now had a problem. Stakeholder and customer confidence was plummeting at the same time he was coordinating efforts to get the project back on track and encourage his vendor to step up with more effective project management efforts. If stakeholders pulled back from the effort as it neared implementation, the organizational change efforts would falter, likely dooming the entire project.
The CIO met with the key stakeholders and had a candid conversation about project history, the errors and omissions by both the vendor and the project team, and recent efforts to address them. The principal stakeholder voiced his skepticism: “This project is looking like a disaster.”
The CIO’s reply seemed share-worthy:
“This project is troubled, but it isn’t a disaster. The project is not going to meet its initial schedule goals and is going to cost more than originally planned, but we are going to be very rigorous about testing and training to assure that when we go live, we deliver a quality product that meets your needs to a user base that is ready for the new system. A disaster is if we go live before we are ready and disrupt your business. I want to share our approach to the remaining work with you to assure that doesn’t happen.”
The distinction between a troubled project and a disaster is important. Troubled projects might be canceled and result in significant costs and consequences to an organization, but that should always be compared to the potential disaster of going live prematurely with a bad system or in an unprepared business unit simply because the initial schedule says it’s time and you don’t want to offend the stakeholders.
