This is a true story. The company name has been changed.
The Acme Corporation was custom-developing a new web application to manage the shipping and distribution of parts from the originating plants to Acme’s manufacturing facilities all over the world. More than three-quarters of the originating plants were owned by suppliers, who also had their own systems. All functions were to be available to Acme staff over the web, and many functions were to be available to suppliers over the web, all with appropriate security.
The development was broken down into nine modules, scheduled to be delivered starting at month twelve and continuing to be delivered up to month eighteen.
The project plans were formally documented, and included appropriate documents and signoffs from the business for all development work and all new organizational designs and processes.
Development and go-live
The development and testing of the application proceeded according to schedule, with no more than the usual number and type of issues to resolve.
The first few modules were delivered for conference room pilot, which was followed by go-live. During go-live of the first modules, the European Region VP was worried that the new systems were not being implemented very well and that the supporting process and organization changes were not occurring as planned.
The VP discussed his concerns with the project manager, who was very confident about the project’s progress. She reminded the VP that all specifications were very thorough and detailed and had been signed off by all of the user departments.
In addition, she pointed out to the VP that the new organizational design and processes were clearly defined from the outset and it was the responsibility of the VP’s staff to ensure they were implemented properly.
Again the following month, the VP brought up his concerns, and was reassured by the project manager, who said, “Don’t worry; everything is going exactly according to plan”.
The VP continued to voice his concerns. The project manager reviewed the plan with the VP in detail, and the VP conceded that each deliverable had been developed according to the specifications, and had been delivered on time. The VP agreed that the organizational and implementation issues were the responsibility of his staff to complete and had been clearly defined.
Every one of the nine modules was developed and delivered on schedule and according to the specifications. The user acceptance testing was signed off, as all modules functioned as designed. However, the project was seen as a failure throughout the company, and many users avoided using the new systems where possible. It could not be considered a success.
The project manager was devastated. Everything had gone according to plan. How could the project be a failure? She decided to investigate and determine what had gone wrong.
The problem on this project was that the modules developed were quite large. There were two significant challenges that arose as a result of the large modules. First, they required a lot of pilot and implementation effort, including a great deal of organizational and process change at one time. Second, because it was twelve months from start of development to go-live of the first module, the project was well under way before the issues in implementation and organizational change began to surface.
The project manager planned her next large project differently. She defined the next eighteen-month project as two dozen very small modules.
With smaller modules, there was less development, pilot and implementation time needed for each module. A few modules were developed and implemented first. Then a post-implementation review and impact assessment was conducted for the first few modules. Then the plan was re-worked to breakdown the modules differently based on the feedback from that review.
Although the implementation and organization issues were the VPs responsibility, they were valid concerns. If she had investigated those concerns, instead of trying to re-assure the VP that her team was producing as planned, the project manager would have discovered that the large modules were contributing to the VP’s problems.
Even at the twelve-month mark, it would have been advisable to stop and review the issues and re-work the plan into smaller units for delivery of the remaining functionality. Probably, late product delivery would have been preferable to on-time delivery into an organization that could not absorb the changes in responsibility and process.
The project manager should have checked out the VP’s concerns to either prove him wrong, or to solve the problem that he was worried about. Her “don’t worry” response to his concerns amounted to “I’m not listening”. Because she didn’t listen, she did not find out until after the project was over that the product, once implemented, was not meeting the needs of the business.
Copyright 2015 Debbie Gallagher