Saturday, June 6, 2015

To plan or not to plan

This is a true story. The name of the company has been changed.

Two projects, one plan

Acme Corporation, a U.S.-based retailer, created two projects, one to replace their financial system and the other to replace their credit card processing system.

Both projects were to go live on the same date. The credit card system was to take eight months, so it started first. When it was at the two-month mark, the six-month financial system project started.

The credit card system project was to include development of an interface between the new credit card system and the new financial system.

The credit card project was kicked off with the project manager’s declaration that “It’ll be tough, but we’ll make it”. There was no project plan, and therefore no scope definition, resourcing, or timelines.

Prior to starting the financial project, a comprehensive plan was developed. It included detailed definitions of items in and out of scope, team member roles and responsibilities, timelines, and a communications plan.

Progress on the projects
The financial system project had a steering committee, which met monthly. Due to the dependency on the credit card project, that project manager was required to attend and provide updates.

At the first steering committee meeting, both the financial system and credit card system project managers reported that their projects were on schedule.

At the second meeting, the credit card project manager stated that work was falling a bit behind, but they would be caught up soon and would be back on schedule.

Unfortunately, at the third meeting, the credit card project manager confessed that the project had continued to slip, and they could not catch up because the team was busy with extra work. They had decided to expand the credit card capabilities to allow an additional brand, which required dealing with a new financial institution and file format.

There’s no plan

The financial systems project manager asked for details of the credit card project, but the credit card project manager had no plan and no other documents to support resourcing, scope, and timelines.

The steering committee insisted that the credit card project manager prepare the information requested and present it as soon as possible. Preparation of project plans for the credit card project took nearly three weeks. The credit card project manager concluded that his project could not be completed on time.

The steering committee did not accept the credit card project manager’s recommendation to defer his project’s go-live. The go-live date of the two systems had been carefully chosen, the company staff had been informed, the financial data conversion would require re-work if the go-live date moved, and the new process designs were dependent on the two systems both being live at the same time.

The financial system project manager realized the critical importance of the credit card project to her own project’s success and offered to help the credit card project manager develop a catch-up plan.

The catch-up plan

The new plan defined the scope of work that would be done by the go-live date and the work that would wait until after go-live. Resources and timelines were identified in detail. The team on the credit card project would have to work 50-hour workweeks, reports would be delayed, additional specialists were hired on contract to assist, and some testing was eliminated, necessitating risk mitigation strategies for go-live.

The financial systems achieved the expected go-live date within budget, and the stripped-down credit card system also was live. However, the interface between the two systems did not work properly.

Acme management decided to live without the interface for over a month, which required a huge effort in creating manual entries to replace the data that was to be supplied by the interface.

Conclusions

The financial systems project manager did a good job of developing the plan and managing her own project. However, despite knowing about her project’s dependency on the credit card project, she took a hands-off approach to it until it was in trouble.

It was a good idea to include the project manager from the credit card project in the steering committee meetings.  However, the financial systems project plan should have included key elements of the plan for the credit card project, including critical milestones, scope, and resourcing.

This story illustrates how critical the project plan is. It allows the company to define expectations, measure progress, assess priorities, assign the right resources at the right time, and communicate as needed with the company.

Prior to starting the financial system project, the project manager and five others spent a full month developing the detailed plan. It seems like a big investment, but as a result of the detailed planning, her six-month project with thirty resources finished on time and on budget.

A project plan should include a detailed list of what is and is not in scope for the project. This definition would have prevented the credit card team from going off on a tangent, developing capability for a new credit card brand, when they should have been focused on the development of the credit card functionality and interface that were required by the go-live date.  At a minimum, clearly defined scope would have allowed Steering Committee to discuss the branding need, the impact of that effort and the implications for the other project.


Copyright 2015 Debbie Gallagher