This is a true story. The company names have been changed.
Acme was starting a project to implement a new logistics application, and engaged Standard Consulting as their implementation partner. When the logistics project started, a new manufacturing system was already in progress, and was also expected to complete before the logistics project.
There were a lot of custom reports required for both manufacturing and logistics. Acme had identified a few hundred necessary reports, including fifty reports for logistics that were critical to go-live. The report development for the manufacturing module had not gone well: many reports were incomplete and some reports that were done were buggy. Acme decided to take more control of the reports development process by assigning an Acme employee as the reporting team lead.
The schedule for reporting
The Standard Consulting project manager asked the new reporting team lead for his schedule, but the reporting team lead had no intention of developing one, as it seemed a waste of time. The project manager asked, “How do you know you’ll be done the critical reports in time for go-live?” The report team lead replied, “We’ll cross our fingers and hope for the best. After all, we always come through in the end.”
The project manager continued to insist on a schedule. Finally, the project manager prevailed. She had the two most experienced report developers stop work on reports. These two developers were assigned to define the development tool to use for each report, as well as the estimated effort for coding, testing, and promotion to production environment. The project manager used this information to build a schedule.
The reporting lead started to realize there was a lot more to report development than just the coding. In addition, the schedule made it clear that the fifty critical reports for go-live could not possibly be completed in time.
However, the reporting lead was worried about looking bad, and didn’t want anyone to know about the possibility that the reports might not get finished. He asked the project manager to avoid discussing the report schedule issue at the status meeting. Despite the schedule, he hoped the reports would get done on time.
The project manager insisted that since the problem had been identified, it had to be raised as a project issue. The reporting lead finally agreed.
Getting some help
The project manager and the reporting lead met with the logistics team and explained the problem. The logistics team was upset about the reports at first, but then agreed to help solve the problem.
The logistics team agreed to prioritize their reports and, with discussion, it became clear that only two reports actually had to be run on the day of go-live. Several others were not needed until the end of the first week, others at the two-week mark, and most at month end. There were even some reports that were not needed until year-end, which was six months after go-live.
When the reports issue was raised at the project status meeting, the manufacturing team offered to prioritize their remaining reports to free up resources to work on the distribution reports. In addition, the Acme project director offered to provide some extra report writing staff.
The manufacturing and distribution modules both were live on time. In addition, the critical reports for both modules were available by the newly prioritized dates.
The reporting lead’s approach of crossing his fingers and hoping for the best was not realistic. Once he understood and made the other team members aware of the reporting delivery problems, everyone pitched in to help solve the problem. The logistics team prioritized their reports realistically, the manufacturing team delayed some of their reports to free up resources, and the project director provided additional help. None of this could have happened if the team lead kept his problem secret.
Even though the client was responsible for its own report development, the consulting firm project manager was right to insist on a proper schedule for the reports. The reports were needed for the implementation, for which the project manager was responsible. Without the schedule, no one had any idea of the extent of work involved, and it was impossible to predict success or failure.