So many bugs!

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

Background

The replacement of Acme Corporation’s equipment maintenance system would directly affect the work of about one-third of Acme’s work force, and provide data for the daily work of nearly everyone else in the company.   

After the new software was selected, the implementation project was expected to take nine months.

The situation

Early in the project, the project team found bugs in the software, but not a lot of them at first. They reported these bugs to the vendor and obtained incident numbers.

The vendor had a consultant on site setting up a prototype. Even before timelines started to slip, the project manager noticed that the consultant appeared to be spending more time on troubleshooting bugs than on creating the prototype.

In addition, the project manager recognized that the amount of attention paid to bugs indicated a risk: that the software may not work as expected and might not be implemented on schedule.

Action taken

The project manager contacted the vendor and asked for a report on all outstanding bugs, along with a status update on each one. However, the vendor was unable to come up with such a list. To the project manager, the inability to produce a status for bugs indicated that the vendor did not have a good tracking mechanism, and the risk became an issue that needed to be managed.

The project manager immediately assigned an analyst on the project team to track all bugs, and arranged a weekly status call with the vendor. In the status call, the bug list was reviewed, and priorities were also established, in order to ensure that the highest priority bugs were fixed first.The tracking of bugs and testing and installation of fixes became high priority work on the project.

Although bugs were being fixed, more were found and the overall number of bugs continued to climb. Many of the defects were also critical – Acme could not possibly implement the system with these types of problems.

The next one’s better…

The vendor explained that many bugs reported were already fixed in the next release of the product, and that it would be faster to install the next release than to continue to fix bugs in the current release. The timeline was in danger of slipping, so Acme agreed to have the vendor install the next release.

The vendor installed the next release of the software, but the bugs were even worse than before. The go-live date had to be delayed because the software was too defective to implement. Acme was committed to the software product selected. They decided to have the project team continue to manage the tracking of bugs and testing and installation of the fixes.

Outcome

The go-live date was delayed again.  The new system was finally implemented after thirteen months, four months after originally scheduled. The cost of implementation was higher than expected due to the number of delays and amount of re-testing required.

Conclusion

The software selected was well established in the marketplace, with over forty successful large implementations of its product. I wonder if Acme relied on reputation and could have done a more thorough job of checking references. Acme was committed to the product and probably would have selected it even if it was buggy. However, more information about the problems would have allowed them to plan extra time and money for the implementation.

Although the project was completed late and over budget, the project manager was recognized as having done an exceptional job of managing the implementation.

For the Acme Corporation, on-time and on-budget were not the only items to consider in evaluating the success of the implementation. The early recognition of the bugs as a problem, the immediate action on tracking and managing bugs, and the establishing of control over the priorities of the vendor were key to getting the product to run reliably, which was the most important outcome for Acme.

Copyright 2015 Debbie Gallagher

Oh no, an expert!

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

Background

In order to implement their new ERP system, Acme Corporation hired a well-known consulting firm, Standard Inc., to assist with the implementation.

Standard Inc.’s management determined that there was a gap in their expertise for one of the modules, and engaged a sub-contractor with expertise to work as part of their team.

The project manager observed that the sub-contractor was a domineering personality and realized it could cause difficulties for the project, but decided to hire him anyway in order to have the expertise on the team.

The situation

On the Acme project, the Standard Inc. expert sub-contractor was at the centre of nearly every problem that occurred. The Standard team and the sub-contractor had different standards for determining completion of each type of work, including even documentation. The sub-contractor also pushed aggressively for things to be done his way, due to his prior product knowledge.

The client team was very small and had to be scheduled carefully in order to ensure their ability to contribute to all parts of the implementation. However, the sub-contractor would announce schedule changes to the client that had the team spend more time on the expert’s module and less time on other work. These changes had not been approved by the project manager.

The Standard Inc. team found out that the sub-contractor was telling the client that any problems were the fault of the Standard Inc. consultants. The consultants felt the sub-contractor was trying to make himself look good to the client at their expense, in order to obtain more work for himself in the future.

In addition, Standard Inc. was doing the implementation work for a fixed fee, while the sub-contractor was being paid for his work by the hour. So, the sub-contractor was agreeing directly with the client to do extras, since he was getting paid for them. He was not discussing them with the project manager, prior to doing this extra work and billing for it. These extras were causing problems in managing the schedule and budget.

Action and outcome

The project manager discussed the problems with the sub-contractor, who agreed to stop attacking the Standard Inc. consultants and to stop changing the project schedule and adding extras without approval.

The project manager also worked hard at encouraging the client to stick with the project as scheduled, and not follow the sub-contractor’s last minute schedule changes unless approved by the project manager.

The sub-contractor ignored the project manager, continued to re-schedule as he wished, and also continued to attack the other consultants. The conflicts on the project worsened.

The implementation project did go live as planned. By this time, the sub-contractor and the Standard Inc. consultants were barely on speaking terms. Everyone was relieved to see the project end.

Some observations

It’s difficult to know whether it was a mistake to hire an expert who was such a poor team member. There are many who say that collaboration is just as important as expertise, and just as many who believe that the product expertise trumps all other considerations.

However, once the decision was made to hire the expert sub-contractor, there are a few things that could have been done differently in this situation:

·         Specify limits to authority in the expert’s contract, to make it clear to him the necessity of obtaining the project manager’s approval for changes.

·         Fix the scope and price of the expert’s work.

·         Clearly define the change process and expected behavior with the expert sub-contractor before the work starts, in an effort to reduce or eliminate problems before they start.

Copyright 2015 Debbie Gallagher 

The boonies

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

Background

Acme Corporation’s offices and operations weres located in a small village pretty much in the middle of nowhere, accessible only by charter aircraft.

During the planning stage for their new system, Acme’s location had been discussed at length. Acme’s sponsor was concerned that technical support for the new software and hardware would be slow and delay the implementation if any problems occurred during the project.

As a result of these concerns, it was decided that the project should be run in a nearby city. The Acme employees on the project team would leave their regular jobs and re-locate to the city for the duration of the project. Technical support was readily available in the city, eliminating the lag time of chartering aircraft for technical support.

An added benefit was expected, that Acme employees would be physically removed from their usual work and able to focus on their project work. This should lead to less time required by the consultants, trainers and data conversion specialists, and therefore lower costs.

The situation

Early on in the project, timelines started slipping. The Acme team members were coming to the city unprepared for the next stage of the implementation.

The project manager probed to find out why these problems were occurring. Acme’s remote location turned out to be the problem. It had not been possible to fill the Acme team members’ regular jobs at the office, as it was an extremely small town with no other qualified individuals that could be hired. As a result, when the Acme team members went back to the office to gather information for the next step in the project, they had to do their regular jobs instead.

Options

The project manager worked with the project team to evaluate the available alternatives.

The options considered were:

(a)   Change scope;

(b)   Move the deadline;

(c)   Add resources.

The team felt it was unhelpful to change the scope of the project. Implementing only some of the modules instead of all of them would require either a lot of manual processes or custom-designed interfaces. This interface design work would need to be done by the same Acme team members who were overworked already. So, reducing the scope of the project would actually eliminate very little or no work.

It was clear that the deadline would be missed by at least a month, because timelines had already slipped a month and the project schedule had been tight to start with. The team considered whether moving the deadline any further would really be helpful. They felt that unless it moved a long way, they still would not have time to devote to the project - the business still had to function. However, the team felt it was very important to avoid missing the go-live date by any more than the one month.

Adding resources looked like the only option. However, Acme had no resources. They didn’t have any other internal staff to do the work, and had been unable to hire anyone else due to the remote location. The only way to add staff was to add external resources, by increasing the hours of the consultants.

The team also believed that it would be better for the project work to take place at the Acme office. This would allow the consultants to obtain information directly from other Acme staff members, instead of waiting while the overloaded Acme project team members coordinated the information gathering.

Adding the extra consulting time would require an increase to the budget to cover increased consulting fees, and for travel for the technical person when support was required.

The project manager reworked the project plan and the budget. She presented them to the project sponsor, and the changes were approved.

Epilogue

The new approach worked; the consultants were able to obtain information directly once they were relocated to the Acme offices. Fortunately, there were very few technical issues after the team moved to Acme’s office.

The project did finish one month late. However, no further time delays occurred. The project team had not been able to save money by implementing in the city. However, the new project budget, based on the remote town implementation, was met.

The project sponsor was pleased with the outcome. Although cost-conscious, he had been more concerned about the slipping deadlines and possibility of further lengthy delays.

Conclusion

The lack of resources in the remote location should have been considered during the planning process. Some creative approaches to recruiting may have enticed resources to move to fill the temporary roles.

However, once the project was underway and deadlines were being missed, the project manager needed to focus on evaluation of alternatives and getting the project back on track.

Copyright 2015 Debbie Gallagher

The right stuff

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

Background

Acme Corporation hired a project manager to plan and manage the implementation of an ERP software package, a well-known product by a leading vendor.

The project sponsor wanted the project staffed with internal resources, having consultants only in an advisory role. After assessing the work, the project manager recommended that eight company staff be assigned to the project full-time.

The project manager also gave the project sponsor guidance on selecting the eight resources and how to ensure they would be available to work on the project.

The right stuff

The project manager gave the sponsor a description of the type of individual that should be chosen for the implementation team.

Each team member should be highly motivated, with strong knowledge of her subject area and the company business processes.

Team members must be capable of thinking in abstract terms, willing and able to visualize new business processes, and resourceful.

In addition, the individuals must be team players, and the project work should fit with the team members’ career goals.

Back-filling jobs

The regular jobs done by these employees should be filled by internal transfers or temporary staff for the duration of the project. This back-filling would ensure that the employees assigned to the project team could focus on it full-time.

The Situation

It was obvious almost immediately that project work was not being completed on time and some tasks were not being done particularly well.

Timelines would soon start slipping and the project could be in danger of missing the first major milestone.

No back-fills

The project manager discovered that seven of the eight of the team members had been assigned to the project on an 80% basis, instead of full-time. In addition, their regular jobs in the company had not been back-filled. As a result, the team members were trying to do their project work and their regular work, with little success in each.

They were not able to commit even 80% to the project team. The most any of them was actually available was 60% and some were as low as 40% available.

The wrong stuff

In addition, it was evident that two inappropriate choices had been made in selecting members of the implementation team.

They were not the right type of person for the implementation team. They were good at their own jobs, but unable to think in abstract terms and visualize the required new business processes.

In addition, one of the two was a poor team player. She didn’t share information. She also frequently told other employees outside of the project that the company had made a big mistake and this project was never going to work out. However, she voiced no concerns to the project team, project manager, or sponsor.

Recommendation and response

What did the project manager do? The project manager knew that part-time resources are a common and very difficult problem to resolve. Part-time resources are always pulled back to their regular jobs for urgent work, unless someone else is filling that position.

The project manager met with the sponsor to review the problems with project staffing, and requested that the sponsor replace the two unsuitable team members. In addition, he asked that the regular jobs of all team members be back-filled, so they could concentrate on the project work.

The sponsor was not receptive to these suggestions, and decided not to change any team members or to back-fill their jobs.

The saga continued

The problem with lack of availability and lack of fit continued. The sponsor continued to make vague reassuring noises about the team members’ ability and commitment, but did not back-fill regular jobs and did not recognize the weaknesses in the team members that had been inappropriately assigned.

The outcome

Timelines slipped, and then project milestones were missed. Deadlines had to be moved out several times. After some of the milestones were missed, the sponsor still did not back-fill jobs or re-assign weak team members. Instead, consultants were brought in after all, to complete much of the work on the project.

The team members were exhausted long before the project was finished, due to their efforts to do two jobs at once. They also felt they were doing both jobs badly instead of doing one job well, which contributed to morale problems on the team.

The project finished in fourteen months instead of the planned ten months. Costs were higher than intended, due to the extended timeline and additional consulting fees.

The team did make good decisions regarding implementation of the software and the new business processes. The company realized the expected benefits from the software purchase.

However, the perception throughout the company was that the project was a failure before it was even half completed. A large internal marketing effort was needed to overcome the corporate lack of enthusiasm for the new system and processes.

Conclusion

It is critical to the success of the project that each team member is the right person for the job.

In addition, those team members must be available to fulfill their time commitment to the project. Back-filling their regular jobs for the duration of the project allows the team members to concentrate on the project work.

Copyright 2015 Debbie Gallagher 

Project euthanasia

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

Background

Acme Corporation selected a new integrated general ledger and accounts payable package. Then they assigned a project manager to plan and manage the implementation.  

The project manager worked with the vendor and the Acme employees to plan the work. Once the sponsor approved the plan, the implementation began.

The situation

One of the responsibilities of the project manager is identifying, documenting, prioritizing, and tracking issues. In addition, the project manager has to find out what needs to be done to resolve each issue and ensure that it is cleared up within an appropriate period of time.

At Acme, there were a large number of issues to deal with during the first few months of the general ledger implementation.

Many issues were typical of any system implementation. In these cases, the project manager worked with the vendor and the users to tweak business processes that would facilitate use of the system.

However, several other issues were directly related to the capabilities of the product. The vendor’s consultant was thorough about investigating workarounds that would deal with the functionality issues.  However, several issues could not be resolved to the satisfaction of the client. The general ledger system that Acme had purchased could not support Acme’s business needs.

In addition, the team had discovered that the accounts payable and general ledger were not really an integrated package. Instead they had been designed and written by two different companies, then marketed by the general ledger software vendor under a single brand name with a standard import/export interface. This lack of integration was a big concern for the users.

Analysis and recommendation

What did the project manager do? She reviewed the outstanding functionality issues and assessed them in terms of the short term and long term impact on the company. The project manager recognized that some of the issues were so severe that they would restrict the growth plans of the company. For example, the company had already used up all of the profit and cost centre codes allowed in the general ledger.

The project manager met with the project implementation team and recommended cancellation of the project. As expected, this was a very difficult decision for the team, as they had already invested considerable effort and money in the project so far. They did not want it to appear that their project had failed.

Cancellation

The project team did conclude that cancellation was the appropriate action, and the recommendation was taken to the project sponsor, who agreed.

The project was cancelled. The Acme legal department, the vendor, and all affected users were notified of the cancellation.

 

Epilogue

Many projects that fail manage to stumble along to the end before being judged a failure. As this tale illustrated, the evidence of impending failure is usually available earlier in the project, and the decision can be made at lower cost.

This is an extremely tough decision to make because the vendor is determined to find a workaround to solve the problems, and the momentum of the project tends to make the project team want to continue along the planned path.

The product was so unsuitable to the company’s needs that the project would have been widely judged a failure anyway. So, the decision took place sooner rather than later.

Of course, doing a proper definition of needs and a software selection in the first place could have prevented the whole debacle.

When the project sponsor initiated a new project to replace the general ledger and accounts payable systems, the new project started with a detailed analysis of the company’s business requirements.

Copyright 2015 Debbie Gallagher

Please change everything

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

Background

Acme Corporation was doing a large system replacement project with a very tight timeline. The project manager was experienced and understood the importance of clarity in the scope definition. The project scope statement included details of not just in-scope, but also out-of-scope items.

The situation

The decision to implement the new system was made by the company that owned Acme. The Acme employees wanted a system more tailored to their current processes, and didn’t see any benefit to being integrated with their owner’s system.

During the project, the Acme staff repeatedly claimed that the software didn’t fit their processes and would have to be customized to suit them.

The project manager recognized that the project was in danger of falling prey to significant scope expansion.

Analysis and recommendation

The project manager reviewed the requests that the employees made and compared them to the approved scope statement.

Since the project manager had been diligent in determining and documenting what was in and out of scope at the beginning of the project, it wasn’t hard to compare to the employees’ requests. The project charter had been created with and approved by the project sponsor, so the sponsor’s approval of the scope was clear.

The project manager did accommodate small requests that did not affect the time line of the project. However, all other requests were documented for consideration after the go-live date.

Any appeals were referred to the project change control process outlined in the project charter.

Epilogue

Acme’s system replacement finished on time, despite the tight timeline. The project manager achieved this outcome by ensuring a clear understanding of the project scope at the outset, and by managing scope carefully during the project.

This specific case of attempted scope expansion occurred when the company employees were not in favour of the product they were implementing. 

However, scope definition and scope management is needed on all projects, and the analysis of the situation is appropriate for all scope change requests.

Introducing change management might also have been helpful in reducing the number of changes requested by the employees.

Copyright 2015 Debbie Gallagher

We’re busy selling the company

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

The situation

Acme Corporation was well under way in implementing their new ERP package. The project was on schedule and running smoothly.

Then, the Acme Corporation’s owners announced that they were putting the company up for sale. The core project team was suddenly unavailable for three or four weeks. They were busy working on reports, answering questions for the potential buyers, and supporting the due diligence efforts.  As project team members, they were supposed to be finalizing design, completing procedures, and preparing training materials.

The accounting staff in the branch offices was also doing work related to the sale. They were kept busy answering questions from potential buyers, touring them through the facilities, and answering questions from customers. As extended project team members, they were supposed to be gathering, verifying and mapping data for entry into the new system.

At the branches, they also speculated…was the project cancelled, should they stop gathering data for the new system?

The project manager and project sponsor had not imagined that there was any possibility of a sale of the company, so there was no provision in the project plan for such an event.

When the extent of the project delay was assessed, the project was about three to four weeks behind schedule.

Analysis and recommendation

What did the project manager do? She worked with the core implementation team to evaluate the available alternatives.

The options considered were:

(a)   Add resources;

(b)   Move the deadline;

(c)   Change scope.

Adding resources would not help at this stage of the project. Anyone qualified to help the core team would have reduced the accounting staff in one of the branch offices, which would also delay the project. So, with that option eliminated, they looked at changing the scope and/or deadline.

The team felt strongly about keeping the deadline as planned. The deadline had been carefully chosen, with thought given to budget time, vacation schedules, year-end accounting and reporting needs, and impact on amount of data to be entered in the new system.

The project manager and core team’s decision was to reduce the scope of the project. There were several items in the scope of the project that, although important to the company, could be removed without impacting daily processing on the “go-live” date. These items were identified for deferral to a follow-up phase.

Approval and communication

The project manager and core implementation team presented their plan for changes to the project sponsor.

The sponsor approved moving scope from the current phase to a newly defined follow-on phase. The sponsor made arrangements for the core team to continue with the follow on phase after the current “go-live” date.

The project sponsor announced to the accounting staff in the branches that the project was continuing, and advising them of the changes made to the plan.

Epilogue

The project (now phase 1) did “go-live” on the planned date. The work deferred did get completed in the new second phase.

This project management tale took place due to a sale of the company.

However, the analysis of the solution is appropriate for any situation where the project has been delayed and a decision has to be made regarding how to get back on track.

Copyright 2015 Debbie Gallagher