Introduction to IT Project Risk

While working on a variety of IT projects, I’ve seen several project charters and risk registers. Over time, I’ve noticed that not all project managers have a solid grasp of how to identify and mitigate project risk. So, here’s an introduction to the subject.

These aren’t project risks

Perhaps it seems an odd place to start, but the most common problem I see is that many risks identified aren’t really risks.  So, what is not a project risk?

An issue is not a project risk.  An issue is something that is already a problem for the project. E.g. a risk item that states: Vendor is late delivering components. Since the vendor is already late, or you already know the delivery is going to be late, this is an issue, not a risk. A risk is something that could happen, but hasn’t happened yet.

An outcome is not a project risk. E.g. a risk item that states: The project might not go live on time. This statement is an outcome of one or more events that could happen, for which the outcome is that there could be an impact on the project timeline. A risk is the thing that might cause the project to go late or cost more, etc.

Also, a vaguely-defined concern isn’t a risk. Risks aren’t really properly identified if they are not specific. E.g. a risk item that states: Testing is a risk. This statement is too vague, as it doesn’t say what specifically about testing is a risk and why it is being identified.

These aren’t mitigation plans

In addition to incorrectly identified risks, I often see vague mitigation plans. E.g. Manage dependencies and milestones. E.g. Leverage vendor’s experience. These mitigation plans are too vague to be actionable.

What are we worried about? What will we do about it?

Every book on project management has a risk definition along the lines of “Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, and quality.” (PMBOK, Fifth Edition). Following that, there’s a definition of risk mitigation, such as: “Risk mitigation is a risk response strategy whereby the project team acts to reduce the probability of occurrence or impact of a risk.” (PMBOK, Fifth Edition)

Although accurate, these definitions can be simplified to aid understanding. The easiest way to identify risks is to ask yourself and others: What exactly are we worried about and why are we worried about it?

Then, once the worry and rationale are very clearly defined, the mitigation plan is based on:  What very specific actions are we going to take regarding that worry?

An example

Do you have reason to believe the vendor might deliver late – before it happens? For example, maybe the vendor has recently made a lot more sales than usual and you’ve had late deliveries when you’ve bought from other fast-growing vendors. If so, you can record the risk very clearly: Vendor has gained significant market share in the last three months. Based on our experience with other vendors, this market gain can have an impact on manufacturing capacity, which may result in late delivery.

If you want to avoid this event, think about what options you have to avoid your project being derailed by late delivery. For example, if the contract isn’t signed yet, can you build in a penalty clause, or pay a premium for on-time? Can you spend extra effort on vetting your requirements to ensure your own project doesn’t cause any impact on the vendor? Do you have access to other equipment you could use temporarily if the delivery is late? Does that strategy lead you define an additional risk and mitigation plan? Ask others for ideas on how they’ve managed this kind of risk before and how successful the strategy was for them. Be specific in your mitigation plan: go beyond platitudes such as good project management.

Do you have other worries?

Anything that causes you a specific concern is a candidate to be included as a risk.  Risks are as varied as the projects on which they arise. Here are a few examples I’ve seen: (1) Servers are being moved from a company-run to an external data centre during the same time period that our project needs to test connectivity for several interfaces. Testing connections to the old data centre will need to be repeated for the new data centre, with potential for delay to our project’s timeline. (2) Although the on-site project manager assigned by a major vendor has great leadership skills, he’s not particularly rigorous about scheduling and tracking against the schedule. Since he is managing a large team and a tight delivery timeline, we are concerned that we won’t have adequate visibility to progress or lack thereof. (3) Previous upgrades to this application have failed due to lack of understanding of the integration points.

Notice that all of these risks are very specific, and they provide a rationale for why the risk has been identified.

Schedule and follow up

Assign a responsible person and due date for every mitigation action item. If you aren’t able to assign a person and due date, the mitigation step probably isn’t defined clearly enough. Track these mitigation steps to make sure that they actually get accomplished.

Conclusion

Understanding of IT project risks and mitigation plans can be improved by simplifying the definitions to: (a) What you are worried about exactly and why; and (b) what you will do about it.

It is important to be very specific and provide the rationale for the risks. The mitigation plan needs to be detailed enough that each task in it can be assigned to a person and on a specific date. 

Project risk: Vendor management case study

Working with vendors is a fact of life on technology projects. It makes sense to engage vendors to work on your projects. They have product experience with many clients and can bring best practices in addition to technical expertise.

However, vendors are not your employees and it is wise to remember that their goals and your company’s goals are not always completely aligned. As a result, in addition to the benefits, there are risks in bringing on vendors to deliver your projects.

Case study

Here’s an example of a project gone off the rails due to issues with selecting and managing the vendor.

The client had issued a Request for Proposal (RFP) and selected a vendor to implement a new application and its supporting technology platform.

The vendor started missing deadlines early in the project. The client’s requirements for performance were not met. To resolve the performance issues, the vendor proposed hardware changes. The resulting procurement and installation time caused more delay.

Unfortunately, installation of the new hardware did not resolve the performance problems, so the vendor embarked on a series of changes to try and improve performance.  Time after time, the vendor said the performance changes would be done by the following week, but every time they were unable to deliver the improvements.  It was clear that the vendor’s team was working hard, including evenings and weekends, but still the system could not operate within the necessary timeframe.

After months of promises followed by non-delivery, the vendor asked for a three-month period to achieve the necessary performance. The client agreed to the three-month timeline, but once again, the performance metrics were not achieved.

At this point, the vendor asked if the client would make changes to other applications in the same business process. As long as all of the applications fit into the overnight process, the vendor’s own application performance would be of less concern. The client agreed to modify other applications, which caused further delays while requirements, development, and testing took place.

Unfortunately, the changes to the other applications were not sufficient. When done, it was clear that the vendor would still have to significantly improve the performance of its own product.  

The vendor continued to work at application changes and database tuning to try and correct the performance issues. When that failed to achieve the desired results, the client agreed to examine the business process to see if they could change it to accommodate the product’s performance issues. The process re-design did not create enough efficiency to solve the problem.

If you’ve ever been in this position, either as vendor or client, you know it’s a very unpleasant situation. The client and vendor blame each other for the problems. Millions of dollars are spent. The business does not have their new application. The vendor is losing money on the project. Discussions about legal action take place.

Causes

There were several problems with this situation.

In the RFP, the client did not specify performance requirements. This lack of guidance allowed the vendor to avoid considering performance when creating the proposal.

The vendor was a solid, well-established company, with an excellent reputation for delivery and support. However, the product was new, with no installations in the client’s industry or any other industry. When evaluating the vendor proposals, the client did not recognize the importance of the fact that the references provided by the vendor (for other products) were irrelevant to the project they were proposing.

The vendor’s size, stability, and reputation were a good thing, of course, in that the vendor was motivated to deliver to the client’s satisfaction, and had the financial resources to invest in efforts to correct the problems.  A smaller, less reputable vendor may have simply walked away early on.

As delays continued over many months and millions were spent, the client never had any discussion regarding whether the project should be cancelled and alternative products evaluated.  This inability to face the failure of a product and project is common. Many clients, once they’ve invested a lot of money, time, and resources, do not admit defeat and start over.

Conclusion

The interests of the client and vendor were never aligned right from the start. The client was looking for a product to install and add value to their business process right away.

The vendor was looking for a successful installation of its new product, so they could use it as a reference when selling to other clients.

If the client had realized up front the differences in their goals, they may have been able to negotiate an approach that worked for both. Instead, both the client and vendor have failed to achieve their objectives.

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

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 

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 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 

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 

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