Wednesday, June 10, 2015

I won't trouble the client with it

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

Choosing the product

Acme Corporation, a large Asian retail company, was expanding into the U.S. and engaged Standard Consulting to select, negotiate the software purchase, and implement a financial system to be used for their new U.S. subsidiary.

Acme wanted to move along quickly. Based on an existing professional relationship, Acme trusted Standard’s capabilities and expertise. Because Acme was setting up a new subsidiary, there were very few employees so far. Employees who had been hired had joined Acme recently, so had no experience yet in Acme processes and procedures. As a result of all of these factors, Acme decided to rely heavily on the expertise of Standard’s project manager in assessing the strengths and weaknesses of the various products, and recommending a product for Acme.

The project manager selected a system that was new to the North American market, but was widely used in Asia’s manufacturing industry. The vendor was planning to build additional functionality into the product to accommodate retail businesses.

The project manager was satisfied with the vendor’s plan to accommodate the U.S. market and the retail business requirements. She wanted to help the client feel comfortable with the selected product and vendor, and didn’t want to worry the client. So, she decided to skip the project risk assessment; it was only a list of potential problems that might cause unnecessary concerns for the client.

Problems surface

As the project got under way, the team started finding bugs right away. Many bugs were serious and affected basic financial processes. As the implementation continued, it also became apparent that the vendor’s new functionality for retailers was not going to be delivered, and was not even under development. As time went on, more and more bugs were found and, like the earlier bugs, several were serious, with the potential to prevent operation of the software by Acme.

The project team was heavily reliant on Standard Consulting, as there were very few Acme employees hired yet. Those who were on staff were all new hires and did not know yet what their business required. As a result, the project team had to guess at what some of the system configuration should be.

The project manager was pleased with the vendor’s intention to fix up all the bugs, and decided not to bother the client with any worries about the continuing and increasing incidence of serious bugs. The project team managed to develop a number of complicated workarounds to enable operation of the system, despite the lack of retail functionality, and to eliminate reliance on the worst of the buggy programs. The project manager continued to assure the client that everything would work out well.

More problems after go-live

The system did go live, but was very complicated to use and unstable. The project costs went over budget and because Acme hadn’t been made aware of the extent of the problems created by the vendor, Standard was left to cover most of the shortfall in fees.

Acme had no internal IT support in the U.S. yet, and hired Standard Consulting to provide support services. In the support services contract, Standard did not distance itself from the vendor’s problems, so Standard was often responsible for resolving serious errors caused by the vendor.

When Acme hired a CFO for its U.S. operation, and he discovered the complexity of using and managing the new system, with its instability and complicated workarounds, he complained to Standard Consulting. However, given the buggy software and existing system functionality, not much could be done in the short term to make the software easier to use or more stable. After go-live, the vendor did develop some of the retail functionality and did fix many of the more serious bugs. However, Acme and its CFO were stuck with several clumsy workarounds.


Skipping the risk assessment was an error in judgement by the project manager. She wasn’t lazy, but was overly concerned about keeping the client protected from the reality of the project risks.

The project manager significantly underestimated the risks of implementing software that was being installed for the first time in a new country and a new industry. She also did not warn the client of the risk of buying undeveloped features or modules (also known as vapourware). Because she was too optimistic, the project manager didn’t ensure that the vendor’s promises about the new retail functionality were written into the contract. There was also no provision in the contract for recourse when the serious nature of the numerous bugs was discovered.

Another sizeable risk in this project was the lack of availability of experienced client staff to participate in the product selection and the implementation. An experienced user has the best insight into what the company’s needs are and what configuration and processes are suitable. Acme didn’t have anyone available to fill this role, thus creating significant risk of selecting a product that was a poor fit, or of implementing the product poorly.

Later, when developing the support agreement, the project manager did not separate the responsibilities of Standard Consulting from the responsibilities of the vendor, thereby creating unnecessary risk for Standard. This error also reduced risk for the vendor, and may have decreased the vendor’s incentive to fix problems.

Due to the project manager’s concern about making sure the client always felt comfortable, the client was never fully aware of the level of risk being assumed in the implementation of this product.

Optimism is not necessarily a good quality in a project manager. Setting the expectations of the client is a major responsibility of the project manager and is best achieved with a healthy dose of realism.

Copyright 2015 Debbie Gallagher