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 

Project going well? How to break it

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

Background

Acme Corporation had a six-month project under way to implement a new Logistics system. In order to streamline and to take advantage of the new system’s features, the business processes were being reviewed and modified as part of the implementation.

On the project team, the business was represented by the Logistics Manager and two supervisors from her department. These team members were very good choices. The manager, who was acting as an adviser with a significant time commitment, was experienced and knew the organization and its needs well. Both supervisors were power users, with good problem solving skills, as well as in-depth knowledge of the current system and department practices. They were the hands-on active participants on the team.

The first three months of the implementation of Logistics went very well, with no unusual problems.

The takeover

Then, Acme started planning the takeover of a competitor. The project sponsor needed the Logistics manager to assist in evaluation of the target company’s operations, so she removed the Logistics Manager from the project. The sponsor also announced that she really wouldn't have time to continue her project sponsor role.

The project manager urged the sponsor to provide a new adviser and new sponsor to the project. When that was denied, he asked for the project to be delayed or paused during the takeover.

However, the sponsor had been impressed with the progress to date on the Logistics project. The team seemed to be doing very well, and replacing the manager was not a priority. The sponsor also felt that the essential team members were the two supervisors, as they were the doers on the team.

The takeover would require many company resources, and the sponsor couldn't see the point in keeping unnecessary resources on a project that was doing just fine.

The manager and the project sponsor were unavailable to the team for the remaining three months of the project, in order to work on the takeover planning, and the resulting acquisition.

The outcome

The implementation team managed to finish the project on time and on budget without the manager, and without any further input from the project sponsor.

When the new system went live, the users in Logistics were very pleased with the results. The new business processes were easily put into practice, and the new system provided much needed functionality for the department.

The project manager heard from the project sponsor after go-live on the new Logistics system. The sponsor was very upset, as she had been receiving calls from irate plant managers. Several of the reports used in the plants no longer provided the level of detail they used to.

Investigation determined that the design and configuration of the Logistics module had eliminated the detail that the plant managers had relied on in their reports. Several of the reports were essential to plant operations.

Re-work of some business processes and system design decisions began immediately and took two and a half months to complete.

Some of the updated business processes were awkward, due to the difficulty of retrofitting an already-configured system. As a result, the anticipated benefit from re-designed business processes was not fully realized.

Conclusion

The loss of the Logistics Manager had been significant, as she had been knowledgeable about the needs of the organization outside of the Logistics department. Without her, the plant managers’ reporting requirements had been neglected. In addition, the lack of project sponsorship during the same time meant that there was no high level review of the decisions being made by the team.

Management commitment is critical to a successful project. The sponsor’s first mistaken assumption was that the project would continue to succeed without her commitment and without her supporting the manager’s time spent on the project.

The sponsor’s second incorrect assumption was that the doers were the only important team members, and that the team could do without the adviser and the involvement of the sponsor.

Unfortunately, the sponsor made a third mistake. She assumed that since the project was already going well, that it would continue to do well without key resources. These were incorrect assumptions.

Copyright 2015 Debbie Gallagher 

Third-party filter

This is a true story. The company names have been changed.

The project

Acme Corporation is an application development company. They were sub-contracting to Standard Inc., whose Portuguese client wanted several million dollars worth of modifications to their existing Human Resources system.

Before each development occurred, the client would write requirements in Portuguese, and then Standard would translate those requirements to English, which Acme would use to prepare effort and cost estimates. All communication between Acme and the client went through Standard, so Acme and the client never talked directly.

A typical outcome

Acme received a set of translated specifications from Standard, and based on the stated requirements, estimated that the modification would take three months and cost about three hundred thousand dollars. Standard provided the estimate to the client. The client was appalled. Surely this particular modification was not that big a deal. The client asked Standard to have Acme break down the price into components to justify the effort and fees.

Once the client saw the detailed components and fees, it was obvious that Acme had not understood the requirements.

The client re-wrote, and Standard re-translated, the specifications and Acme produced a new estimate of three weeks and thirty thousand dollars. The client accepted the estimate, and the work was completed and delivered.

There were many similar situations with other modifications on the project. Sometimes, the modification would be installed at the client before anyone discovered that the modification did not really deliver what the client had asked for.

The project manager repeatedly tried to convince Standard to allow direct communication between Acme and the client for clarifying requirements. However, Standard insisted on being the go-between.

Epilogue

The problems continued to occur. The client felt that Acme was not serving their needs very well. Acme felt that Standard was the problem, with their sloppy translation of requirements.

The project manager did manage to continue to deliver modifications, but the client was never totally satisfied with Acme, and Acme was continually frustrated with Standard. The Acme project manager left the company after the first year.

Conclusions

Standard had no programmers, analysts, or technicians assigned to the project. Their main function on the project was to translate documents from Portuguese to English and back. This was not a necessary service for Acme, who had already done similar projects for clients in Spanish, German, Arabic and Japanese-speaking countries.

The problem was not the language difference. It was the process that was put in place to solve the supposed language issue. Standard filtered every communication between Acme and the client, and that filtering caused numerous errors and assumptions.

The Acme project manager failed to find a way to solve the problem because she was reluctant to discuss the issue with her own management. She also didn’t figure out the root cause for Standard’s insistence on continuing the unproductive process.

Standard provided little more than translation services, but was able to make its money by marking up Acme’s fees when billing the client. Standard was careful to keep itself between Acme and the client, in order to prevent the client from eliminating Standard from the process and the next contract.

The Acme project manager should have discussed the issue with Acme management. The Acme VP could have encouraged Standard to provide some of technical or analytical resources for the modification work. This approach would allow Standard to be involved in a way that provided value to the client, thereby reducing the chance that they might be eliminated.

Then Standard likely would be more inclined to allow the Acme team to speak directly with the client to obtain and clarify requirements. Speaking directly with the client would certainly shed light on the requests, and allow the client to receive what had been asked for. The client, in turn, would be more satisfied than with the current arrangement, and more likely to renew the contract with Standard and Acme.

Multiple parties to a project are a complicating factor in project management. In this case, the process of filtering communications through a third party caused a lot of confusion.

Copyright 2015 Debbie Gallagher

Of course I did my homework, but the dog ate it

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

Background

The Acme Corporation had a well-established application that was used by large and medium-sized companies. After the most recent release of the product, several of the largest customers complained about poor response time. Company management decided that correcting the performance problem was a priority. It would be corrected and released to customers before any new features were developed for the product.

The analyst from Technical Services reviewed the problem reports, diagnosed the problem, and proposed a solution. The Vice President assigned a project manager to develop a plan for correction of the problem.

Based on the diagnosis and the proposed solution, the project manager developed a high-level project scope and plan. The project to correct the response time problem would take approximately a year to complete. It would require ten developers, plus testers, documentation, and preparation of a new release. The cost would be well over a million dollars.

The Vice President approved the project immediately. The project manager proceeded with the detailed planning of the project. A senior developer was assigned to determine the specific development requirements.

Where’s the report?

The developer began to review the relevant programs to determine the specific work needed. As she reviewed the programs, she began to wonder if the problem to be solved had been correctly determined. Based on how the software was designed, the diagnosis seemed rather odd.

The developer asked the Technical Services analyst for a copy of the report outlining the problem assessment. The analyst was vague, and said he was unsure where the document might have been filed. Follow-ups led the developer to believe that the technical analyst was trying to avoid having to produce the report.

The developer then asked the project manager to intervene and obtain a copy of the technical services report. The project manager made a request, but the report was not provided.

The determined lack of response led the developer to become suspicious that the technical analyst had taken a short cut and not done any proper analysis of the problem after all. The project manager was reluctant to press further, as he thought the developer was concerned about technical details outside her area of expertise.

Analysis of the problem

The developer was determined to figure out whether the diagnosis was correct or not. However, there was no time to do the technical analysis, as she was assigned full-time to do the detailed analysis based on the problem definition and the solution provided.

The developer decided to figure it out over the weekend. She worked both days, using a test environment to test her own theory on what needed to be fixed in the software. At the end of the two days, she had proved that her hypothesis of the problem was correct, and had two potential solutions.  In addition, she had proven that the solution proposed by the technical analyst would not solve the problem, and would very likely make the performance even slower.

The developer met with the project manager, who was skeptical. How could this be? The project had already been approved, and now the developer was telling him it was unnecessary? However, as he reviewed the analysis the developer had done, he realized the technical analyst may not have not done a proper diagnosis.

The project manager insisted on seeing the report from the technical analyst, who finally admitted that no real analysis had been done. The technical analyst had guessed at the problem and solution based on the customer reports alone.

Saving time, resources, money

One of the developer’s solutions was chosen to solve the response time problem. It required very little effort in addition to the work the developer had already done.

More than a million dollars and a dozen individuals were freed up to work on new features for the next software release. The customers would have their application fixed within a few weeks, instead of waiting for a year.

Conclusion

The technical analyst had not done any analysis, but didn’t want to admit it – the systems equivalent of “The dog ate my homework”.

The project manager should have insisted that the technical analyst produce a copy of the report when the developer asked for assistance. 

The project manager would not have to be qualified to understand the technical details in the report, but certainly would be able to recognize if the report was done or not.

Copyright 2015 Debbie Gallagher

What's happening in Yorktown?

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

Background

Acme Corporation determined that updating their existing system to accommodate upcoming tax changes would be nearly as much work as implementing a new system. Because the new system also provided many other advantages, Acme decided to proceed with the new one.

The project was run in two locations: Since most of the sales functions were done in Yorktown, that location was to implement the Sales, Distribution, and Accounts Receivable modules.  The Smithville location, where procurement, manufacturing, and accounting were located, would implement the rest of the system. 

A project director, in charge of the entire project, was located in Smithville. In addition to her overall project responsibilities, she would run the Smithville part of the project.  A project manager was hired to run the Yorktown portion of the project.

The project needed to be done in six months to ensure adherence to the new tax rules.

Yorktown off the rails

In Smithville, the usual number and types of issues surfaced, but in general the work went well and the project was on track.

Each week, the project director had a phone call with the Yorktown project manager to review progress on that part of the project. The Yorktown project manager always sounded confident, and reported that everything was going well in Yorktown, with no significant issues impeding progress.

The project director was very surprised to receive a phone call from the Sales VP in Yorktown after about two months. The VP was very agitated, as she had expected to be attending design meetings to review preliminary set up by this time. However, the VP had not been able to obtain any information from the Yorktown project manager about when the work might be ready for her review.

Rescuing Yorktown

The project director went immediately to Yorktown to investigate. He discovered that there wasn't nearly as work much done as expected.

The project director had a serious problem; the system now had to be ready within four months instead of the planned six months, and there was almost no salvageable work completed.

He fired the Yorktown project manager, and replaced several of the contractors. Then he met with the VP and other key users. He outlined a plan to go-live by the time the tax changes had to be implemented. The key was to determine what functions were critical for the first day of operation of the new system. The users indicated that sales order entry, the logistics methods for their three largest customers, two major billing functions, and cash entry were critical and had to be done for go-live. The rest of the functions were ranked according to when they had to be used for the first time.

Go-live

On the date the new tax law was in effect, the new system was live. Everything in Smithville was running. In Yorktown, the key go-live must-have items worked. There were no management reports, and no other non-key functions.

The remaining items were delivered over the next several weeks according to the ranking done by the users.

The users were relieved. They had been so worried that they would have no system available to run their business and fulfill the requirements of the new tax law.

Conclusion

Once the project director discovered the project was behind schedule, he quickly analyzed the problem and took steps to make sure the main elements of the project finished on time. The deadline could not be moved, due to the impending tax changes. Adding more resources would have been extremely difficult; he already had to get new consultants up to speed. So, the clear choice was to reduce the scope of the project to meet the deadline.

Unfortunately, it took too long for the project manager to find out that the Yorktown project was behind schedule and staffed with poor quality consultants.

The second location for implementation development should have been identified as a risk to the project. Then, the first step in risk mitigation should have been careful selection of the Yorktown project manager and the consultants. It would have been wise of the project director to spend more time on selection and maybe more money on more experienced resources.

The next risk mitigation strategy ought to have involved the development of the approach for Yorktown. It should have included small early deliverables, with appropriate business review and approval. This approach would have allowed the project director to assess the timeliness and quality of the work very early.

During the project, more rigorous reporting practices would have provided the project director a good view of progress. For example, the project director could have insisted that the assistant update the project schedule each week, showing progress on each task, and explaining any discrepancies.

The project director did solve the problem and the must-have components of the project were completed on time. However, earlier recognition of the risk and implementation of mitigation strategies may have allowed the entire project to be delivered on time, with less worry for the users in Yorktown.  

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

It went according to plan, how can it be a failure?

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

Background

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.

After go-live

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.

Conclusion

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 

Drowning in email

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

Background

The Acme Corporation and its two subsidiaries were outsourcing their order taking and fulfillment functions to Standard Inc.  Every month, Standard would send a file of orders taken and shipped so that Acme and its subsidiaries could record entries in their financial systems.

Standard would create one file each month and split it into three, so the file design and content had to be capable of loading into the three different financial systems used by Acme and its subsidiaries.

The three companies would need to define common requirements for the incoming file. A facilitator worked with financial, sales, fulfillment, tax, and systems representatives from Acme and its subsidiaries to define the common requirements.

The situation

With so many participants involved and multiple organizations and systems to serve, progress on the common design was very slow.

In addition, many issues surfaced during the design discussions. They were documented in minutes of the meeting and assigned to individuals for follow up. However, some issues were very time-consuming to resolve and held up progress on the design.

When the deadline was reached and the requirements were not completed, the Standard Inc. systems analyst started to attend the requirements sessions to learn what she could about the requirements.

Between requirements meetings, several participants were sending email and phone messages to the analyst at Standard, letting her know about the various issues and proposed resolutions.

The Standard systems analyst began to receive twenty, then thirty, and then forty messages per day about design concerns.

Then, as the technical specifications were being developed at Acme and the two subsidiaries, there were additional questions. At fifty messages per day, the systems analyst at Standard began to feel like she was drowning in email.

The blame game

The staff at Acme and its subsidiaries complained that the Standard analyst was unresponsive and not able to answer questions or address issues. They were beginning to question the ability of Standard to complete the necessary files. Standard, however, felt that Acme was not being fair, as the design was late being completed, and issues were continuing to be raised long after Standard had expected them to be settled.

The project manager reviewed several of the emails with the facilitator who had been working with the participants to create the functional design.

The content of each message required assessment of the impact on other aspects of the design. In addition, there were frequently other parties to consult before a resolution could be reached. For instance, if Acme head office wanted sales orders to be summarized differently, the two subsidiaries would have to be consulted to see if the change would be acceptable. On top of these considerations, the volume of messages to be dealt with was very high.

They concluded that Standard’s analyst could not possibly have time to answer the volume of issues and questions in addition to the work she already had to do. Unfortunately, Standard’s analyst did not have help, and getting someone at Standard assigned and then up-to-date on the project and issues would take a long time.

However, the facilitator had been involved in the requirements sessions already with all parties, so was knowledgeable about the project details.

The project manager assigned the facilitator to coordinate all issues and questions. Everyone wanting to question or raise an issue with Standard’s analyst had to send it to the facilitator. The facilitator would coordinate all the requests, prioritize, and summarize them for a once-daily phone meeting with the analyst at Standard. In addition, the facilitator would do all the coordination between Acme and its subsidiaries for requests for changes.

Epilogue

It took a few weeks for the backlog of issues and questions to be cleared up. However, the assignment of the facilitator to work as an assistant to Standard’s analyst worked well, and the backlog lessened. In addition, when the analyst had a question or issue for Acme, she could have the facilitator coordinate with Acme and the subsidiaries, and determine a common answer. With so many parties to consider, this coordination saved a lot of time for the analyst.

Conclusion

The project manager had heard complaints from both sides. Acme complained about how unhelpful and unresponsive Standard was, while Standard blamed Acme for causing the project to be so late.

However, the project manager realized that pointing fingers was not getting the job done. So, he focused on assessing and solving the problem.

The problem was that the analyst at Standard had too much work. The project manager’s solution was to assign an extra resource, a knowledgeable one, to help out the analyst.

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 

It's bigger than you think

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

Background

A government agency decided to implement a new set of systems that would provide services to all communities in the state. The project required significant participation from staff of the state government, a telephone company, several systems vendors, and a systems integration vendor.

The government engaged Acme Consulting to manage this large complex project.

Acme’s project manager met with the project sponsor from the government agency several times and established the project scope, responsibilities, schedule, and resources needed.

Acme’s project manager brought on a junior project manager and a coordinator to work with him.  These three were to spend eighteen months implementing the new systems and processes, then at go-live, two Acme consultants were to take over and support the new systems for ten years.

The situation

Within two weeks, the junior project manager began to realize that the scope of the project was too vague. There were several sizeable elements of the project where the government agency and Acme Consulting each thought the other was responsible for the task.

The junior project manager discussed this issue with the project manager, who replied that it was too late to be wondering who should be doing what, and told the junior project manager to focus on getting the work done, instead of questioning the work.

With every week that went by, the junior project manager became more worried about the vagueness and confusion related to who was responsible for what. It was clear that Acme Consulting did not have enough staff assigned to the job to do everything the government was expecting. Further comments to the project manager were futile.

About eight weeks into the project, the junior project manager attended a conference to learn how others had implemented similar services. He realized that the gaps in project scope and responsibility were much worse than he had feared. Many of the vaguely described project elements were significant jobs, requiring weeks or months of effort.

Escalation

The junior project manager documented his concerns in writing to the project manager. When the project manager continued to ignore this information and push the junior project manager to ‘just do it’, the junior project manager talked to an Acme VP about his concerns.

By now, the project was nearly three months along. The VP was very worried when she heard about the junior project manager’s concerns, and began to investigate. At the same time, the project manager finally began to realize that the project had been poorly defined and understaffed.

Recommendation to client

The project manager began to speak more openly to the government sponsor about the problems of project scope and responsibility. The sponsor was quick to grasp the problems and to realize that he too had misunderstood the effort involved in developing and implementing the new services.

With the consent of the sponsor, Acme Consulting began to re-define the project scope and work plan in more detail. This process took the entire fourth month of the project.

At the end of the month of scoping and planning, it was clear that more detailed planning would be required to ensure completeness and clarity. However, there was enough information to determine that the project would take at least three years to complete, and would require eight more staff.

Epilogue

The government wanted Acme Consulting to provide the eight additional staff, but did not have a way to adjust the total project budget. It was decided to reduce the amount of support time for the ten post-implementation years, and apply that money to the implementation phase instead.

The government sponsor and the Acme Consulting VP were unhappy with the project manager who had originally made the deal, and who was slow to recognize the shortcomings in the scoping and responsibility assignments for the project. The project manager was replaced.

Conclusion

There are two things the project manager should have done differently on this project.

First, on a project this large and complex, the amount of effort put into planning and scoping was completely inadequate. Instead of several meetings to determine the project scope and resources, the project manager should have recommended to the government that the planning and scoping be a separate, predecessor project. Resource planning and therefore pricing could not reasonably be done without two or three months of effort.

Second, when the project started, and the extent of the gaps between the government’s and Acme’s understanding started to show, the project manager should have discussed the problem with the VP and the client immediately. Since the project manager had made the agreement that was so inadequate, he was probably reluctant to own up to the error.

The junior project manager, although less experienced, was quick to realize that the project was bigger than they thought. The advice given to him, to ‘just do it’, was not the right advice. The junior project manager was correct to escalate his concerns to the VP.

Copyright 2015 Debbie Gallagher 

The accountants are in charge

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

Background

Acme Corporation hired a project manager and an experienced consultant to implement their new ERP system, which included modules for project management, procurement, accounts payable, and general ledger. The project was to be completed within four months.

Acme set up a project steering committee to oversee the project. The members of the committee were the VP Finance, the Controller and the IT Manager.

The project team included full-time representatives from accounts payable, corporate accounting, and the IT department. Each individual on the project team was selected because he had experience in his particular area of work, and a good work history with the Acme Corporation.

The situation

Early on, it became apparent that tasks were not being completed timely. The consultant revealed to the project manager that the users assigned to the project team did not have the necessary level of expertise in accounting. Although they knew very well the specific steps to take on their existing system, they didn’t understand the underlying accounting principles. This lack of knowledge made it very difficult to make informed decisions about how they wanted their new system to work.

As a result, the consultant was spending a lot of time teaching fundamentals of accounting, before presenting the options available for configuring the general ledger module.

Action taken

The project manager was concerned about the timeline, as there had already been a noticeable delay, and there were many decisions yet to be made. The project manager encouraged the consultant to be more directive in the design and pilot, and spend less time on the accounting basics.

This decision speeded up the pilot considerably, and the project team was able to catch up and get back on schedule.

Go/no-go decision

When the pilot was finished, the project team was concerned that the system had not been adequately tested, and recommended delaying the go-live date.

The project manager disagreed with the rest of the project team and recommended to the steering committee that the system should go live as scheduled. She had met with the consultant and established that all appropriate decisions had been made, and that the project team’s discomfort was due to their lack of knowledge of basic accounting principles.

When the project manager met with the steering committee, the Systems Manager was away, and the VP Finance had recently resigned and left the company, so the recommendation was really made to just the Controller. The Controller was satisfied with the design decisions that had been made by the project team and approved the go-live as scheduled.

Post-go-live review

The system did go live on the scheduled date. However, a few months afterward, when the project manager did a post-project review, she discovered that Acme Corporation was unhappy with the new system. They said, “It doesn’t work the way we thought it would”.

The project manager pursued this comment and discovered that the procurement and project management staff at Acme actively disliked the system and the newly designed processes.

In addition, the accounting users were very uncomfortable with the new system and didn’t understand fully how it worked.

Conclusions

There were multiple causes for the dislike of the new financial system at Acme.

First, the project steering committee had no representation from the procurement and project management areas of the company. This omission led to an accounting-based project team, and accounting-driven processes, with little or no understanding of the impact on procurement and project management staff at the company.

The project manager should certainly have questioned this gap in the steering committee and project team representation right at the beginning of the project. Neither the steering committee nor the project team membership were set up for the project to be successful.

Second, the accounting users didn’t like the new system because they didn’t understand it as well as they should. Because the consultant was so directive in the decision-making process, and because the project team didn’t understand the underlying principles of their design, they didn’t have the confidence to take ownership of the design of the new system and processes.

When the lack of basic accounting knowledge was discovered, the project manager should have resisted the temptation to focus so much on keeping to the schedule. It would have been prudent to either question whether the right project team members had been selected, or perhaps to request a delay so that training of accounting fundamentals could have been delivered.

If the project is done on time and on budget, but it doesn’t support the needs of the business, can it be considered a success?

Copyright 2015 Debbie Gallagher

They're never quite ready

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

Background

The project to implement Acme Corporation’s new warehouse management system was scheduled to take four months.  

At the outset, the project manager heard that the Acme Corporation had a history of trying to implement systems, getting them substantially completed, but then not going live on the new system.  Most recently, a sales order project had run for several months, achieved 99 percent completion, and four years later was still not live due to some small outstanding technical items.

The Situation

For the current warehouse management project, Acme’s IT department was to do the technical set up of the new server, and upgrade of mobile devices. The IT team was enthusiastic about what they had learned at the vendor’s training sessions, but when they returned to Acme their progress on the technical set up was noticeably slow.

The project manager also observed that the other employees on the project had little confidence in the IT team. Technical support, including help desk, was available until only mid-afternoon daily, and was slow to respond to problems. As a result, most employees felt that company systems were unstable and interfered with getting their work done.

Follow up with the IT team

The project manager met with the IT team, who assured him that they were going to get their work done. However, the work continued to slip, and the project manager escalated to the project sponsor.

The sponsor assured the project manager that the IT team would prioritize the warehouse management project work, and get caught up. However, due dates for technical set up of the new system continued to be missed, then the due date for go-live was missed.

The project manager suggested that an outside consultant be brought in to complete the technical work.  The sponsor agreed the consultant could be hired, but wanted Acme’s IT team to use this outside expertise as a training opportunity, and do as much of the work as possible themselves, under the supervision of the  consultant. Unfortunately,  Acme’s IT team was not comfortable doing this work, and participated very little, leaving the consultant to perform most of the set up. When the consultant left, there were only a few technical items to be completed.

Acme’s IT team did not have the last part of the work ready on time for the next month, and the go-live date slipped another month.

Again, the project steering committee assured the project manager that the IT team would get the job done. Again, progress was made, but as the next month approached, there were still some technical items that had not been completed.

Let’s go live

The project manager reviewed the outstanding items with the project team and determined that it was possible to go live without the remaining technical items. The outstanding items would cause some inconvenience, but the problems should be workable.

The project steering committee accepted the project manager’s recommendation that the system should go-live, two months late and 99 percent complete.

Conclusion

The Acme Corporation was satisfied with the implementation of the warehouse management system. It came in under budget because the costs had been over estimated. In addition, since Acme had so many failed implementations in its past, two months late on a four month project was an improvement over what they were used to.

Although Acme was satisfied, there is a lesson for the project manager. He did not recognize a significant project risk when he heard Acme’s history of inability to implement systems even when they were substantially, even as much as 99 percent, complete. If the project manager had probed further, he may have discovered right from the beginning that Acme’s IT department was weak and unlikely to complete their tasks.

Realizing the IT weakness in the company would have allowed the project manager to plan and make recommendations to the sponsor to prevent the problems instead of solving them later in the project.

In order to raise the IT team’s comfort with the technical work to be done and make the technical training environment more realistic, perhaps the vendor’s technical training could have been done at Acme instead of at the vendor. Another possibility may have been to have the training customized to provide more hands-on rather than classroom training. Alternatively, Acme could have planned for the technical consultant to do the technical work on the project, without trying to have the Acme IT department involved in the set up of the new system.

Unfortunately, when the project manager heard the previous disaster stories, he did not recognize the risk they implied for the current project.

Copyright 2015 Debbie Gallagher