Sunday, 06 December 2009 00:00

Blame The Customer

Rate this item
(0 votes)

It is amazing how people on failing projects neglect to look at their own issues prior to blaming someone else. Yes, blame is easy and on red projects since no wants to be the source of the issues. The truth is, everyone is at blame, so before bringing in an auditor or recovery manager, tidy up your house first.

One very memorable project illustrates this point. A company was building a thick client sales application using internal IT resources. They had a pipeline of projects to enhance the application, each taking between twelve to fourteen months.

A representative from the PMO called me telling a tale of woe about the latest delivery. It was a miserable failure. The product had been released with a huge number of bugs. The product was deployed over the internet and by default automatically updated sales personnel's computers. With the failure, almost all sales staff's tools were disabled. To make matters worse, the primary failure was caused by the remote update program. It broke itself during the installation making it very difficult to download a fix. The result was a large portion of the sales force was unable to configure products and create bids. No one in the company was happy.

Day One

On the first day at the facility, there were a number of IT managers that set me straight on just where the issues were. It was clearly the customer being too pushy and a project team that could not handle their requests. There was plenty of work to do on the project since a follow-on "fix project" had been initiated to fix the failed deployment. This was affecting the next in the series of projects so it, too, was red. IT's management was emphatic the problem was the business unit being out of control making unreasonable demands. The project team, though, had a different opinion and, along with being demoralized from the failed delivery, was frustrated with their management. The contradiction necessitated an early visit to the accused unreasonable customer. The rest of the day was spent five miles down the road, in the manufacturing facility, talking to them.

The Rules When Auditing Projects
  • Remain objective
  • Interview the people and listen to what they say, but do not take it as fact
  • Listen to your team, they have the answers
  • Get lots of data, it will be your friend
  • Although this case study shows a one sided failure, the customer is not always right

The customer voiced a significant set of issues, including their opinion that I would be unable to help the situation. It was quite clear that the customer was very displeased with the project and did not trust IT's management. The finger pointing between IT and the business unit shutdown communication—it was all just accusations and yelling.

The Plan

That evening I mapped out a schedule to talk to key people. Because of the pressure coming from the customer to fix the failed delivery, I determined it would be best to start there. Calm the customer down and it would buy time to get other issues fixed.

This met with immediate and stern objection from the IT management. They felt the focus should be on the project team; whip them into shape so they would respond to the customer's demands better.

I assured management that attention would turn to the team; however, before addressing any issues on the project, the customer would need to provide a grace period for the audit and analysis. To do that, they needed confidence the problems would be addressed and fixed. First order of business was securing a grace period.

The business's issues were that IT management was unresponsive, had released the product prior to completing proper testing and failed to treat them as a customer. Confirmation of the latter two points was easy. IT management appeared proud of both. Their contention was that the business unit was in the same company, customers bought the company's products. The business unit should focus on selling product, letting IT build the needed applications.

In the next breath, they defended their decision for releasing a buggy product—the product testing was taking too long, it only made sense to release the product. QA was continually sliding their schedule. Had management not told them to do the release "QA would have tested forever." This resulted in the failed delivery. Management refused to acknowledge any culpability in the current mess; it was all QA's fault.

Although the customer claimed they had made numerous complaints about the project, there was no documentation of it. The previous project management had not kept any action items list. It turns out that the prior project management consulting team running the failed project had a separate agenda—to show the business unit that IT was unable to support the product and that it should be outsourced to their company.

I assured the customer that issues would be resolved, even though many of the issues appeared to be with IT management. Customer would need to have patience. Honesty in identifying sources of issues and constant communication convinced them to grant the time.

The Findings

Two weeks later, audit findings were presented to the steering committee. They stated the core issues were:

  1. Animosity between IT management and the business unit was unbearable. This would need to be the primary focus.
  2. The IT test environments were inadequate. They were neither capable of properly reflecting the end users' environment nor executing acceptance test scripts in a timely manner.
  3. Certain people on the IT project team were hostile and uncooperative. They were admittedly unwilling to assist in the project recovery. They would be replaced.
  4. IT management did not understand the need for a product maintenance phase, instead using yearly project releases to address bugs in the product. Bug fix releases would be required.

Nothing in these findings pointed to an unreasonable customer. Even when resolving the communications issue, it was IT that had to change the way they were addressing the business unit—the customer. Later in the project there were places where the customer had to accept blame, these initial big issues, though, all lay in IT's court. As said at the onset "before bringing in an auditor or recovery manager, tidy up your house first"

Remember Jerry?

Remember back a few weeks ago, the article on projects needing value? Well, the Cowboys' owner Jerry Jones exhibited these same traits. As opposed to the height of the world-record video screen, it was the punter who was the problem:

If you look at how you punt the football, unless you're trying to hit the scoreboard, you punt the ball to get downfield. You certainly want to get some hangtime, but you punt the ball to get downfield, and you sure don't punt the ball down the middle. You punt it off to the side.1

Somewhere in the back office, though, there was someone that was a little more reasonable who moved the manufacturer's advertisement from below the screen to above it in order to give punters more room.


Read 4646 times

Related items

  • Comparing Organizational Change Management Models

    A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

  • Disband Your PMO

    After nearly 30 years of project work, I struggle to understand the role of a project management office (PMO). Even though, I have written of the pros and cons, and read a plethora of articles, opinions, and how-to guides little has been done to convince me that the PMO is reducing project failure. It seems to be nothing more than a tool to fill a void in leadership? Even the acronym, which is so widely thrown around, has little meaning as the "P" has no less than four meanings. It is an executive's crutch for their lack of understanding in how projects work. These, like other, unattended holes in the corporate accountability create opportunities for new and greater bureaucracies and empires that further obfuscate accountability.

  • IT: We Don't Need No Stinking Leadership

    I have never posted email marketing results, because... well, let's face it... it is kind of tacky. Now and then, however, there is a story to be told. In my opinion, this set of statistics is a little over-the-top in what it shows. I can only see one way to interpret it other than Information Technology "leaders" simply do not care about leadership.

    To understand how I can make such a brash statement, you need a little background...

  • Alignment: Using the Balanced Scorecard to Create Corporate Synergies
    Alignment: Using the Balanced Scorecard to Create Corporate Synergies

    Add To Cart

    Author:Robert S. Kaplan, David P. Norton
    Publisher: Harvard Business Review Press
    Released: April 2006
    Type: Hardcover
    Pages: 320

    Projects build capabilities to met corporate goals. If you are a CEO, you need to make sure your employees and vendors know what those goals are and how they fit in to the plan. If you are a project manager, you need to know the bounds of you project. If you are anywhere in-between, you need to understand how all the pieces fit together and keep it all aligned.

    Most organizations consist of multiple business and support units, each populated by highly trained, experienced executives. But often the efforts of individual units are not coordinated, resulting in conflicts, lost opportunities, and diminished performance.

  • ADKAR: A Model for Change in Business, Government and our Community
    ADKAR: A Model for Change in Business, Government and our Community

    Add To Cart

    Author: Jeffrey M. Hiatt
    Publisher: Prosci Learning Center Publications
    Released: August 2006
    Type: Softcover
    Pages: 146

    This book is currently under review, more details will be added when available

    Tired of hearing about change and how your project is implementing it, but have no idea how to make it happen? ADKAR is the gold standard process to follow to help make that happen. This, and a little leadership, will get you ahead of the pack.

    Why do some changes fail while others succeed?

    How can you make sense of the many tools and approaches for managing change?

    How can you lead change successfully, both in your personal life and professional career?

Leave a comment

More Info on Project Recovery


Please send me more information on fixing a failing project.

Made with BreezingForms for Joomla!® by Crosstec

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References