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