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 

Musical chairs

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

The project

Acme Corporation, a software vendor, was implementing their Sales Order and Payment Processing application at Standard Limited. The product was very flexible, but was also being customized to Standard’s needs.

The contract between Acme and Standard was structured so that there were no progress payments. Payment from Standard could only be requested after a successful User Acceptance Testing (UAT) phase.

The Standard project was estimated to take six months to complete, but at the five-month mark, development was still under way and the testing phase had not started yet.

A few resource changes

Acme had several staff on site doing the implementation and custom development work at Standard. During the fifth month, the project manager and architect were removed from Standard’s project to work for another Acme client. A new project manager was assigned to the Standard project, but the architect was not replaced.

Acme started to worry about Standard’s ability to pay them, as Standard’s business was struggling in the marketplace. Acme wanted to deliver the software and get paid before Standard ran out of money. In addition, Acme was concerned that Standard might sue Acme for non-delivery of the software if they didn’t finish soon. The new project manager was charged with ensuring the project was completed as soon as possible, in order to avoid the potential lawsuit, and to reduce the risk of non-payment.

The project manager assessed her team and discovered they were poorly trained and had learned very little on the project so far. The architect had been providing specific answers to questions from the developers, without explaining the business and software design background that would help them understand the product and their own work better.

The project manager also learned that the development team was sometimes building additional functionality than what had been agreed in the contract.

Getting the work moving

The new project manager immediately re-focussed the development team on the contract as the definitive guide to what was to be built, and directed that no additional work was to be done.

In addition, the project manager realized that a new architect, although not available to the project, was critical to getting the job done. She evaluated the developers on the team and found that one was a resourceful, determined person with good analytical capabilities. This developer was re-assigned to the architect role.

The new architect did whatever analysis was needed to resolve issues and was also able to teach what he learned to the other developers. Progress was being made.

More resource changes

As the developers became more competent, Acme management caused more staffing issues by reassigning them to other Acme projects where there was a greater likelihood of being paid for the work. The project manager had trouble maintaining any stability in the development staff on the project.

During the sixth month, Acme announced job cuts and laid off three of the project’s seven developers, without any notice to the project manager.

At about the same time as Acme’s job cuts, Standard announced that they were dissatisfied with the early results of UAT and would do no further testing until the existing defects were fixed.

Although the client was not contractually entitled to stop the testing phase, the project manager agreed because she didn’t have enough developers to complete the fixes. Having the testing stop allowed the corrections to be completed without new bugs being added to the work list.

The project manager needed to get the bugs fixed but was critically short of resources. Because the project was at the bug-fix stage, the project manager decided that short-term resources were adequate for completing the work. She approached other project managers at Acme and asked to borrow resources for short periods of time. For example, if a developer was not assigned for a few weeks prior to taking vacation in one or two weeks, the project manager used that developer on the Standard project.

When the existing defects were fixed, UAT resumed. The project manager continued to borrow developers for very short periods to correct deficiencies.

Time to pay

When the UAT was completed, Acme requested payment from Standard, but. Standard said there was no money to pay Acme for the software implementation and development fees.

Acme issued a legal notice to Standard that due to non-payment, Standard was not entitled to use the software.

Conclusions

The developer assigned to be the new architect had been reluctant to take on the role, as he felt under qualified. However, he was a good choice because he had the skills to figure out the solution to issues, and as he learned, he shared his knowledge with the developers.

Developers who temporarily could not be used on longer-term projects were a good solution to the problem of staffing the Standard job. These resources were not earning fees on other projects; so there was no additional cost to having them work on the Standard project.

The project manager had no support from her own organization to provide adequate resources to the project. However, her novel staffing approaches allowed her to complete the work so that a non-delivery lawsuit was averted.

The project manager was wise to ensure that the team delivered only what had been specifically contracted. Additional scope takes time, and time was critical to avoiding a lawsuit.

It was common for Acme’s projects to require significant customization and then run late and over budget. Acme management frequently made things worse by removing resources before the work could be completed.

Copyright 2015 Debbie Gallagher

Lessons for the project sponsor

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

CRM project

Acme Corporation, a company specializing in implementation of business applications for small businesses, decided to expand into implementing Customer Relationship Management (CRM) systems.  

Acme executives decided to implement the CRM package for their own use before selling it to their clients. The implementation of CRM at Acme would be followed by the development of a marketing strategy for the CRM product.

The Acme employee setting up their new CRM system took the vendor training, then spent three days getting the system set up for Acme. The implementation included installation of the software, migration of data from the old contact management system, and four hours of training on system navigation to the first four users.

Review of the CRM system

Acme’s president engaged a marketing consultant to develop Acme’s marketing strategy for the CRM product.

The consultant began by reviewing what Acme had done on its own implementation of CRM. Her assessment was that the technical implementation of the system was very good, including software installation, database optimization and system performance. These had been achieved despite some technical difficulties with the hardware.

However, the consultant also pointed out that there had been no changes in business process to ensure the successful use of the new system. In addition, the implementation had been done with no clear understanding of the goals of the new system, the benefits that were expected or any vision of what could be achieved by implementing CRM at Acme.

Acme’s president was very interested in the consultant’s comments. He recognized immediately that she was right – Acme had not thought about what they hoped to achieve by implementing the CRM system, and had not considered business processes in their implementation.

In addition, the consultant talked to the president about his role should have been as the project sponsor, and pointed out how critical the sponsor was to the success of the project.                                                                

Implementing CRM again

Acme’s president asked the marketing consultant to re-implement the CRM product at Acme before developing the marketing strategy.

The president rolled back the CRM implementation, and Acme resumed use of the old contact management system for several more weeks. The president enlisted the support of another key executive in pushing forward with the re-implementation rather than using the system the way it had been implemented already.

The re-implementation started with a series of design workshops. The president attended every workshop, in order to highlight to Acme staff the importance of this project. By the time the fourth design workshop was over, the other staff members understood and agreed with the need for re-implementation of the CRM system.

The re-implementation took five weeks, considerably longer than the original three-day implementation. This time, the work included definition of the expected benefits of the system, as well as the new business processes needed to provide good quality data, and to ensure usage of the system to benefit Acme.

The consultant stayed an additional two weeks to complete the marketing strategy.

The sponsor’s lessons

The president of Acme, as the project sponsor, learned a number of lessons from this project. The first lesson was the importance of defining the system’s goals and benefits to the organization. Without these, the system has no purpose.

The sponsor also learned about the critical importance of business process change when implementing a system. Without processes to ensure the success of the system, it will never deliver the expected benefits. For example, in the new CRM implementation, processes were developed for gathering, validating, and using the data in the new system.

The consultant also taught the president about the very important role of the project sponsor. The sponsor’s support of the project in the organization was critical to its success. When the president attended design sessions, enlisted the support of another executive and, after go-live, used the reports produced by the system, he showed how important he believed the system was to the company. These actions carried more weight than his verbal statements to the staff.

The final lesson for the sponsor was the value of having the right person for the job. The employee hired to do the first implementation was a skilled technician, but with skills different from those required to implement this particular system at this particular company. The president recognized the importance of the marketing consultant’s ability to guide the setting of system goals and benefits and lead the development of new business processes.

Copyright 2015 Debbie Gallagher

That user is a loser!

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

Setting up telecommuting

The manager of the research department at Acme Corporation approached management with a request to provide telecommuting capability for research employees. The research staff would need remote access to email, external journal articles, and internal document systems.

Acme executives thought the telecommuting capability would allow improved staff retention and flexibility, while also reducing office rent costs. A pilot project was approved, and an employee chosen to be involved in the pilot.

Set up and immediate failure

Acme set up a home office with company equipment for the employee. Because the employee lived in a rural area where there was no high-speed Internet access, a dial-up service was arranged.

Right away, the employee complained of intermittent service problems; email was failing, and the screen was freezing while he was trying to use internal documents or external journal articles.

The IT help desk suggested that the employee call the Internet service provider about the service problem. The Internet service provider said they had not been experiencing problems in the employee’s area and that the problem must be with the employee’s system or phone line.

The employee continued to call the help desk whenever the problem occurred, which became more frequent, usually more than once a day. Over the next three months, the problem continued and the IT department tried several different ways to identify the problem.

·         A technician was sent to the employee’s home to replace the modem and verify the configuration settings on the employee’s system. The problem was not resolved.

·         The Acme email and document systems were monitored for problems, but none were found that would cause the employee’s problems.

·         The telephone company tested the employee’s phone line, and verified that the line was fine.

·         A technician was sent to the employee’s home to replace the computer.

Escalation

The research manager complained to management that this pilot was a disaster and that IT wasn’t able to figure out the problem. Several VPs noted that it seemed impossible for the project to have gone so badly.

The IT manager was instructed to make the remote employee’s problem a priority and get it resolved. After reviewing the support desk records, the manager met with one of the support technicians. It was a mystery. The technician was instructed to report to the employee’s home to observe, and to spend every hour of every workday at the employee’s home until the trouble was definitively identified.

Duh user

The technician returned to the office after only a few hours, and could hardly wait to share her findings with the IT manager. The technician and IT manager laughed all the way to the management meeting to explain the problem – the employee had been using the telephone to place outgoing phone calls while the phone line was already engaged for Internet service. Because his phone was often in use for Internet service, his friends, family, and co-workers found the employee hard to reach. As a result, the employee started to make more frequent outgoing calls. He had not realized that the reason he had to click the phone button to get a dial tone was because his computer had the phone line in use for Internet access to email or the remote database.

A second phone line was quickly installed for the employee, the problem did not recur, and the rollout of telecommuting was expanded successfully to other employees.

Conclusion

The IT manager and technician thought the user was extremely stupid and found the whole situation hysterically funny. Unfortunately, the IT manager did not realize he had a serious customer service problem.

Some things were missed in setting up the pilot project for the telecommuting employee. First, although the IT department asked the office services department to make arrangements for the employee to have a second phone line, they didn’t follow up to make sure the line had been installed. This was a critical component of the plan.

Second, when setting up the employee’s home office, assumptions were made about the employee’s technical savvy. No assessment was made of the employee’s capabilities, and no training was provided.

When the employee’s problems started to occur, it took much too long for the IT department to really get serious about solving the employee’s problem. He had service problems more frequently than daily, and yet it took three months and the attention of several VPs to motivate the IT department to go on site and determine the employee’s problem first hand.

An observation – sometimes the only way to assess a problem is to be on site and watch. The issue can occasionally be beyond imagination.

Copyright 2015 Debbie Gallagher

We're not concerned about the budget

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

Estimates are wrong

Acme Corporation’s salesman assured Standard Inc. that the billing and accounts receivable software, hardware, and customizations could be bought and implemented for $500 thousand dollars.

After Standard signed the contract, Acme’s project manager and team were assigned. They met with Standard to work out more details of their requirements and quickly realized that the salesman had under-estimated the costs. In order to support their business, Acme would need additional modules for inventory management, work order management, and additional details to support regulatory reporting. The price should have been $8 million!

Acme management was horrified and decided they would not show this new estimate to Standard. They decided to cut the figure to $6 million. The Marketing VP was interested in these new modules and agreed to pay thirty-five percent, bringing the number down to $4 million. When Acme presented this new budget, Standard thought the estimate was completely unreasonable, but could not agree to eliminate any customizations.

Standard and Acme worked together to create break down the work into two phases. Phase one would have half the work and a budget of $2 million, the remaining work and budget would be phase two. The contract was revised for the new scope of work and price, with additional provisions for a fixed price and for phase one to be completed within twelve months.  

Behind schedule, over budget

Phase one wasn’t even half over when it became very obvious that the project was running behind schedule and over budget. The project manager alerted the Standard sponsor and Acme’s management. The Standard sponsor told the project manager not to worry about the budget for now, but just to keep developing the customizations to make sure the project delivered on time.

For the next four months, the project manager continued to warn Acme management and the Standard sponsor that that project was continuing to run over budget and could not be completed for the expected amount. Both Acme management and the Standard sponsor assured the project manager that she should continue to do the work and bill Standard.

Standard continued to pay the monthly invoices until the end of the ninth month, which brought the billings up to the budgeted $2 million for phase one. More than three months remained in the schedule, and more than three months work remained to be done.

The invoice for the tenth month was being processed at Standard just as Standard was taken over by a new owner. The new owner refused to authorize payment for the tenth month.

Payments stop

The Standard sponsor asked Acme to continue the work, and the sponsor would convince the new owner of the value of the project and obtain approval for payment.

At Acme, it became known that Standard was not paying, and other projects began using resources from Standard’s project to do paid work. The project manager alerted Acme management and Standard that the project would run later as resources were dwindling. They encouraged the project manager to continue the project at whatever pace she could. By the end of the twelfth month, the original deadline, the estimate to complete was another five months.

Work and billings continued to the end of the fourteenth month, when the project fizzled out. Acme never got paid after month nine. Standard never installed the new product. The work completed was rolled into the existing product and sold to other customers.

Acme fired the project manager for allowing the project to run late and over budget.

Conclusion

Management at Acme did not accept responsibility for the problems that they created on this job. The project manager had made it clear to them that the project was behind schedule and over budget. They also knew they weren’t being paid. However, when the project ended disastrously, the project manager was fired.

The early estimates by the project manager and team came to $8 million, twenty-five per cent more than the figure used as the project budget. It was trimmed because Acme management thought the figure was too high to present to the customer. Unfortunately, unless the work is eliminated, reducing estimates of effort don’t make the effort go away. This cut in the estimates was not based on reduced work, and could not be achieved. The project running over budget was predictable.

It’s curious that Acme management did not arrange to meet with the new owner. A meeting with the person refusing to authorize payment would have allowed Acme to discuss the benefits of the project with the new owner. Alternatively, the meeting may have made it clear earlier on that there was no hope of the project being completed and paid. Instead, Acme accepted assurances from the Standard sponsor, who no longer had authority to pay.

Copyright 2015 Debbie Gallagher

Friendly fire

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

Background

Acme Services was selling version four of its sales and distribution system to Standard Inc., a new customer.  Version four had many features that Standard wanted, including pre-built integration with several other industry-standard systems used by Standard.

Timing would be critical, as Standard’s existing system could not support upcoming regulatory requirements, and price discounting calculations that the marketing department believed were holding them back from significant sales.

What version to implement?

In May, Standard’s VP IT told the Acme sales rep that the regulatory changes were going to be government-approved sooner than anticipated. The system implementation would have to be completed by mid-July.

This date was not possible, as version four would be released in September, and then would need to be configured and tested before go-live.

Standard and Acme discussed other options. For example, could version three be implemented immediately, followed by an upgrade to version four later? That approach wasn’t feasible, as version three didn’t meet Standard’s integration and reporting requirements. Just as important, version three took several weeks to implement, so could not be completed by mid-July.

The Acme sales rep suggested to the Acme project manager that he should push the version four delivery date earlier and give Standard a September go-live date. The Acme project manager refused to guarantee an earlier completion and delivery date because he knew that version four couldn’t possibly be ready and implemented by then. The Standard VP IT was irritated that the mid-July date was not being taken seriously.

Back to requirements

The project manager asked Standard detailed questions about immediate requirements. Although Standard wanted everything that version four had to offer, what elements could wait and what elements really had to be in place in July?

Standard’s VP said they could live without the flexible configuration, management reporting, and integration for a short time, but absolutely had to be able to meet regulatory requirements for distribution of their new product by July 15. Some of the discounting features were also crucial to their marketing strategy.

The project manager suggested that what Standard needed by July 15 was version one, with some customizations. Doing the custom programming for version one would delay the release of version four, as the same programmers would be used. When version four became available, then Standard could implement it and get all of the features they wanted.

Standard’s VP thought version one was an acceptable interim solution. However, the Acme sales rep said there were some technical issues that would be problematic. She and the project manager retreated to another room to make phone calls to the Acme technical staff.

Friendly fire

As soon as they closed the door to the other room, the Acme sales rep let the project manager know that she was very angry. This was a terrible solution, as the sale for version four would not fall in the current year’s revenue, nor would her commission. There was no license fee for version one, so the only revenue would be for the custom programming and implementation fees. The phone calls made were not to technical staff but to the Sales VP and Executive VP at Acme.

The project manager was on the receiving end of a tirade from the sales rep, the Sales VP, and the Executive VP. They really wanted the version four revenue booked this year. They felt that if they pushed hard enough, they could convince Standard to accept the September delivery date for version four, allowing the version four sale to occur in the current year. Then, when the software was not ready, Standard would have no choice but to accept the delays.

Implementation

Acme did customize version one and install it at Standard by July 15. Although version one did not have much functionality and was inflexible, it was able to do the basics that Standard needed.

Standard was very pleased with Acme for coming up with a solution to the timing problem. They operated version one until March, when Acme implemented version four of the software at Standard.

Conclusion

Sometimes the project manager has to stand up to members of his own team to deliver what the customer really needs. The project manager’s recommendation was based on the customer’s best interests, but his own organization was displeased about the delayed revenue.

The version one approach allowed Standard to meet its regulatory obligations and use the price discounting features to expand the market for its product, so the effort was appreciated. Standard became a high-profile, very satisfied customer reference for Acme.

In order to figure out how to solve the customer’s timing problem, the project manager had to re-visit the customer’s requirements. This additional analysis was the key to determining how to solve the customer’s problem.

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