It's just an upgrade

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

The project manager was developing a project charter for his new project. He and his supervisor expected this project to be low risk and quite straightforward, as it was just an upgrade to an application that had already been running for many years in the organization. The application was used daily by approximately ninety percent of employees across the country.

The first risk assessment

The project manager met with his assigned mentor to discuss the project. At this company, it was a requirement that the project charter include a risk assessment section. The project manager included as risks some items that had been problems on previous projects, such as business resources and IT code promotion resources not being available. When questioned, the project manager said there was no particular reason to believe these would be problems on the new project, but he wasn’t sure what else was relevant to include as risks.

The real story

In discussion with the project manager, the mentor learned more about the project, which was in the planning stage prior to charter approval and project launch.

The application vendor had been slow to respond to requests for help with planning the upgrade.  The vendor was apologetic about the lack of assistance provided and explained that they had recently sold a very large engagement and were very busy as a result.

The existing application had numerous customizations and interfaces, almost none of which were documented. Upgrades of this application had been attempted before, but the projects were never completed due to the difficulty in replacing the undocumented customizations and interfaces.

The project sponsor had just gone on medical leave for several months and appointed a junior manager to act as sponsor in her place.

The mentor helped the project manager to identify three significant risks: (a) unavailable vendor resources; (b) undocumented customizations and interfaces; and (c) inappropriate sponsorship.

Actions taken

The mentor suggested several follow up actions to the project manager to try and manage the risks before launching the project.

The project manager approached the application vendor about alternatives for resourcing the project, but the answers were discouraging. The vendor had no business partners trained to perform implementations and also could not recommend any other companies or individuals who might to able to guide the company through the application upgrade process.

A business analyst was assigned to start documenting the customizations and interfaces, but the work was progressing very slowly as he was also assigned to a high-priority project.

Although the original project sponsor was available for a brief phone call, she was unable to suggest a more appropriate replacement sponsor for her expected several-month absence.

Unfortunately, none of the actions resulted in lower risks.

Updated risk assessment

After these follow up actions and further discussion with the mentor, the project manager had a much more realistic view of the project risk.

The vendor’s lack of availability during planning raised significant concerns about its ability to provide appropriate resources for the project itself. Noticeable lack of availability during the sales cycle made it clear that the vendor was overwhelmed by the large contract they had just signed and would not be focused on this company’s upgrade. Even if they managed to provide a few resources, the vendor would not be able to support them to the extent needed.

Undocumented customizations and interfaces had already caused previous upgrades of this application to fail. Proceeding with the project without developing a good understanding of the customizations and interfaces would certainly cause the project to fail once again.

The lack of an appropriate project sponsor is a risk that sounds alarm bells for any experienced project manager.  The appointment of a low-level resource shows a lack of understanding of the role of the sponsor. Someone too junior to determine business priorities and commit resources is not an appropriate choice.

Any one of the three risks described would put the project at significant risk of failure. Given all three risks, it would be nearly impossible for the project to succeed. 

Recommendations

The project manager discussed the revised risk assessment with his supervisor. The supervisor was reluctant to delay the project but did finally agree that it was too risky to proceed at that time.  However, the discussion of the risk with the sponsor would be a delicate matter, especially given the concern about the inappropriateness of the sponsor.

The supervisor arranged for the IT vice-president to have a discussion with the business vice-president (to whom the original project sponsor reported).

Epilogue

The two vice-presidents agreed that a different project was needed first, one with the purpose of documenting the existing customizations and interfaces. The IT vice-president agreed to commit resources to this predecessor project.

They expected that by the time that project was completed, the original project sponsor would be back from medical leave and the vendor would have had time to train new resources.

Conclusion

Given the risks identified for the project, the vice-presidents made the right decision. Delaying the project and starting with documenting the customizations and interfaces was the best option to set it up for success.

Evaluating project risk is frequently a challenge for junior project managers. It is typical for new project managers to focus on schedules and budgets, and develop their understanding of risks and issues at a later stage of their project management career. Providing a mentor for the project manager was a wise course of action for the company. The mentor was able to guide the project manager through the risk assessment process, leading to a more realistic evaluation of the project’s chance of success.

Copyright 2015 Debbie Gallagher

Put money aside for more lumber!

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

Starting with lessons learned

The City of Yorktown was starting a project to replace its financial and human resources systems. The city had a history of technology projects that were completed late and over budget, and the sponsor for this project was determined that this project would be different. He and the project manager decided to start with lessons learned.

The project manager spent time researching what other cities had done and what had worked well. As a result of this research, there were some things she decided were important to Yorktown’s project: (a) all departments would be involved in and committed to the preparation of the business case; (b) the structure of the contracts with the various vendors involved would ensure one vendor was responsible for managing all of the vendors; (c) the vendors would be treated as business partners; and (d) the budget would have plenty of contingencies.

Implementing the lessons

Before choosing a software package and vendors, the business case and requirements were prepared. In every department at Yorktown, the department heads signed off on the cost savings and other benefits expected from the new system, including agreement that specific budget cuts would be made to the department once the system was implemented. The cost savings and budget cuts would be made over a five-year period as staff retired, since there were to be no layoffs.

The Request for Proposal (RFP) was issued with a requirement that the vendors bid together as a team, and that the system integrator take responsibility for managing the other vendors. The proposal was to include software and hardware recommendations.

After the applications and vendors were selected, the business benefits were re-worked, taking into account the specific package that had been chosen and its particular capabilities. Again, each Yorktown department head signed off on the business benefits, including the planned budget reductions. At the same time, the costs were refined, based on current information about the package, the infrastructure and the implementation fees.

The contracts with the vendors were negotiated and included some important elements: (a) the system integrator was to have responsibility for managing the software and hardware vendors; and (b) the vendors were asked to put up some extra contingency dollars. The additional dollars were not laid out in the contract itself but were negotiated at the same time and were to be managed outside of the contract.

The project manager knew that each vendor would already have included some unallocated budget in their own bids, in order to ensure they were not going to lose money on this fixed-fee price. She too had a miscellaneous category in her own project budget. However, she also wanted all parties to provide additional assurance by sharing costs for situations on the project where the responsibility for picking up the extra costs could not be clearly defined. She felt this would prevent cost overruns and also lead to the city and vendors acting as partners instead of each protecting their own budget.

The shared contingency dollars were to be spent on a case-by-case basis when agreed by all parties during the project. The total of the shared miscellaneous budget was approximately one percent of the project budget

Using the shared contingency dollars

The implementation was to take seven months. Almost immediately, Yorktown and the vendors used nearly a quarter of the shared reserve of funds, as additional hardware needs were identified during the set up of the infrastructure.

During the rest of the project, several smaller items were agreed to be paid out of the shared reserve fund. Most of the remainder of the reserve was used for additional processors, storage, and database licensing.

In each case, when an issue arose that would cost more money, Yorktown and the vendors would, as expected, try to negotiate so that another party would pay for the new item. However, when it became apparent that some items could not be agreed upon, the parties agreed to pay out of the shared reserve.

The outcome

The project completed on time and on budget, and is expected to deliver the planned business benefits. Yorktown and the vendors did maintain a collegial relationship during the entire implementation.

Conclusions

The time the project manager spent on planning and research was time well spent. The project manager learned a lot from her discussions with other cities. She focused on making sure the key success factors were in place and that potential points of failure were mitigated.

She ensured commitment from the business users by involving them in defining the system requirements and having them take responsibility for budget reductions related to implementation of the new systems.

The contracts were structured so that one vendor could manage the others, reducing the conflict that can arise when no one vendor is responsible for the outcome.

The shared reserve was an innovative concept that allowed the project manager to honour her commitment to the sponsor and city council to complete the project without going over budget. Just as important, because the reserve was shared by Yorktown and the vendors, there was more of an implied partnership between the parties. They had a means to resolve budget issues that might otherwise cause each to dig in their heels to protect their own budget.

According to the project manager, who built in an extra contingency, when each party already had a contingency, the old expression should be “Measure Twice, Cut Once – And Have Money Handy For More Lumber!”

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

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

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