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 

Something keeps coming up

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

The vision

Acme Corporation is a successful business selling medium and large-scale business applications. Some executives had an idea for a new application. After further development of the idea, and approval of the business case, a project was started to create the new product.

The steering committee comprised three executives, all of whom had been involved in developing the business case. Senior management was very excited about the prospects for the new product.

Before starting the definition of functional requirements, the project manager interviewed the three executives on the steering committee individually, to determine what their vision was for the new software. Two of the executives agreed on a vision, but the VP Product Development had different thoughts. The project manager met with all three as a group, to try and achieve consensus. There were still significant differences.

In order to try and achieve consensus, the project manager and steering committee agreed it would help to meet with industry experts who could provide additional insight on high-level requirements.

Meeting the experts

Just as the first industry-expert meeting was about to begin, the VP Product Development apologized and explained that an emergency had just come up on another project and he would be unable to attend the session. The other two executives and the project manager continued the meeting with the industry expert.

The next industry-expert meeting was scheduled at a time convenient to the VP Product Development, to ensure he would be able to attend. Unfortunately, a last-minute urgent matter again prevented the VP Product Development from attending. He urged the others to go ahead without him.

At a follow-up meeting to discuss high-level requirements based on the feedback from the industry experts, the VP Product Development didn’t like the proposed product, and thought it wouldn’t sell. He was unable to stay at the meeting long enough or to attend follow-up sessions where further requirements and direction were developed. However, he didn’t want to hold back the team, and suggested they should forge ahead without him. He would review the more detailed requirements and early product prototypes.

Product development

The high-level requirements were not defined, development had not begun, yet the project was behind schedule already. All three members of the steering committee urged the project manager to get the project back on schedule. She should go ahead and develop more detailed specifications, based on the high-level requirements already developed.

In addition, the steering committee was worried about the lack of progress reported on product development, and urged the project manager to get the work started, using the high-level design. As the more detailed requirements were established, the development team would re-work their design as needed.

Project resources were gradually shifting. The database designer was moved to another project and replaced. The technical architect transferred to another division and was not replaced. Her work was assigned to another member of the project team. Some development staff were given additional high-priority work for another project by the VP Product Development.

A key component that was to be purchased and integrated into the new product was not approved for purchase. Instead, the development team built similar functions into the product.

On the market

As a result of the shifting requirements, related re-work, changing and lost resources, the development of the product was behind schedule. Since competitors were moving forward with their own products, the scope of the development plan was revised, eliminating some features in order to have a product ready for sale earlier. They could incorporate the removed features in a future release.

The first product was launched. No one bought it, as competing products were already established and were much more robust. The product was later dropped.

Conclusion

The failure of the product can easily be traced to its root cause. The product didn’t sell because it launched late with insufficient features. This lacklustre product was due to delays in development, as a result of resource gaps and re-assignments. These resource issues were due to the lack of commitment of the VP Product Development.

The signs of lack of commitment were evident starting from the two industry-expert meetings, where “something just came up” and prevented the executive’s attendance.

The project manager got caught up in a get-it-done mentality, focused on the hard deliverables needed to keep the project on schedule. As a result, she did not recognize the signals that her project was doomed to fail, no matter what she did.

Copyright 2015 Debbie Gallagher 

It's going to cost how much?

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

Background

The Acme Corporation is a large North American retail company, with thousands of stores across the continent. The procurement function was centralized, with purchases made and paid at the head office.

The process for stores to make a requisition was extremely outdated, relying on phone calls, emails, and faxes to make requests and with no insight into the process once it was initiated. Acme decide to replace their procurement system with a web-based system that allowed on-line requisitioning, and the ability for store staff to see at any time the status of their requisitions.

How much money?

During the planning stage, the project manager had the project technical lead do an assessment of what infrastructure was needed to support the new system. When the technical lead assessed the network between the stores and head office, she determined that the new application would run too slowly.

The project manager talked to the Network Services department and discovered that the group had no budget to upgrade the network. They told the project manager that if his project needed the upgrade, it would have to come out of the procurement project budget, at a cost of over $100 million.

The estimated cost of the procurement project was $2 million, so this additional cost would be the end of the project. It wouldn’t be possible to make a business case for the procurement project if the cost was increased fifty fold.

Action taken

The project manager asked the technical lead to do some further analysis, which determined that with the current network, the response time for users would be more than two minutes, which was definitely unacceptable. Without the network upgrade, the project was not viable.

In addition, the project manager asked the Network Services group for a review of the cost estimate, and the Network Services group responded that the cost estimate was accurate.

The project manager was not satisfied, and asked Network Services for another re-work of the cost estimate, with more details, so that it could be included in a report to the project steering committee. This time, the Network Services group found a large calculation error, and revised the cost estimate to $8 million. Although a dramatic reduction, this could still not be accommodated in the budget for the project.

The project manager advised the steering committee that the project was not viable without the network upgrade, but that the cost of the upgrade could not be accommodated in the project budget.

The steering committee realized there was never going to be a single project that could absorb the network upgrade cost and still produce a return on the investment. In addition, the steering committee also felt that the speed of the network would be a recurring theme, as demand for faster processes and instant access to information increased.

The steering committee recommended to Acme management that the network upgrade be approved as a separate project, and Acme management agreed.

Epilogue

The store managers were pleased with the new procurement functions and the timeliness of the information available to them. In addition, store managers who ran multiple stores could see the additional stores more easily than before.

Conclusions

Discovery of the slow network demonstrates the project manager’s thoroughness in the planning stage, taking into account factors other than the application functions themselves. His disciplined approach was also in evidence when he requested additional backup, ensuring his estimates were correct, before reporting to the steering committee.

The steering committee comprised several Acme executives, which was valuable in getting the attention of Acme management when they needed to remove the financial obstacle to upgrading the network.

Copyright 2015 Debbie Gallagher

Management's indecision

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

Background

Until now, the Acme Corporation had published product and customer-support information on its web site. The new project would expand the web site’s capabilities by allowing customers to purchase from the web site.

The schedule was the driving force in planning the project, as Acme wanted to capitalize on the crucial Christmas shopping period. The project manager identified finalization of the technical decisions as a critical milestone in the project. The IT Director would need to evaluate and determine the technical direction timely. The project manager made sure the project steering committee was aware of this significant dependency.

The situation

At the project steering committee meeting where the technical direction was supposed to be presented by the IT Director, he instead covered several discussion items. He reviewed his key considerations such as fit with strategic direction, impact on the existing web site environment, stability, and pricing. However, he had not made a decision.

The project manager made her concerns clear; the lack of decision would have an impact on the project schedule.

The IT Director was dismissive of the project manager’s concerns; surely it was better to wait a bit to get a better decision. The steering committee did not pressure the IT Director to finalize the decision.  

Delay continues

The IT Director continued to delay. The project manager followed up regularly with the IT Director, and moved as much work as possible forward. However, with no environment in which to begin programming, there really was very little that could be done.

The decision is made

Once the IT Director finally made the technical decisions, the project manager could see that the work was already a month behind schedule.

The project manager discussed her concerns about the timeline with the project steering committee. It was clear that the deadline could not be moved, as the retail web site was intended to attract customers during the Christmas shopping season.

The only options were to reduce the scope of the project, or to add resources. The project steering committee members were adamant that that neither was possible. The budget did not permit additional resources, and the entire scope of the project was thought to be completely necessary to its success. The team would just have to manage to get the job done.

Epilogue

The project manager and the team did make a valiant effort to get the job done. The programming and testing team members worked very long hours. However, time did run short, and some scope did have to get cut in order to finish on time.

Although the web site was up and running in time for the Christmas shopping season, it did not perform well under some conditions. The project team was completely exhausted.

Conclusion

The IT Director’s and the project steering committee’s lack of concern for the timeliness of the technical decisions was unreasonable. When the technical decisions were finally made, the project steering committee’s refusal to make a decision regarding resources or scope was also unreasonable.

Both the IT Director and the project steering committee did not recognize that the damage to the project was their own responsibility.  Instead, they claimed credit for the project completing on time and on budget.

Copyright 2015 Debbie Gallagher