• Increase font size
  • Default font size
  • Decrease font size
E-mail Print PDF

Blame The Customer

I am always amazed 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
Delicious Delicious
Add to Technorati Favorites

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.



Previous Blog Next Blog


0 # Guest 2009-12-07 14:03
Blame the customer....I understand that this is actually supposed to pull the team together because we all have a common villian we can focus on. I think the problem is really that we do not manage our customer's expectations well, or the customer could have waited until the QA testing was completed. Typically I see that when a manager gets backed into a corner and blame is being focused on the manager the only thing an inexperienced manager knows how to do is refocus the blame.
Rarely is the customer to blame (track those change orders), it is expectation management from the team.
+1 # Todd C. Williams 2009-12-07 17:06

You are right, managing expectation is a big issue and really should be driven by the PM. If the customer is real difficult then executive management should help. In spending time with the customer at the beginning, I was setting new expectations. I was glad they thought I would fail in the recovery since they were already setting low expectations. After a few weeks the customer and the project team were back in line with one another. Expectations were properly set (they could see I was not going to fail). The lack of issues kept IT Management out of the project.

In this case, the real source of the problem was IT Management, they did not set expectations and were abusive to the staff. They considered the problem in testing to be QA and not rooted in the upgrade requests for the faulty test environments. Nor did they see an issue in denying testing from outside the firewall (through a series of corporate policies).

I find that the lack of management support is a major root cause for project failure.

Thanks you very much for your comment.

Todd Williams

Currently comment rights have been restricted to registered users only. Please try registering and logging on.

Who's Listening To Us...

Fortune/CNN Money logo
Forefront's logo
Logo Oregonian/OregonLive
Enterprising CIO's logo
Slashdot's logo
The CEO Magazine's logo

Read and Hear More...

Visualize Your Future

Change how you do business.

Project Failure Insight:

The following blogs regularly have articles on project failure, recovery and good management practices.
Chris Curran
CIO Dashboard
Michiko Diby
Preventing Project Failure
John Estrella
Dr. John A. Estrella's Blog
Mike Krigsman
IT Project Failures on ZDNet
John F. Moore
Random Thoughts of a Boston-based CTO
Roger Sessions
Simple Architectures for Complex Enterprises

Looking to buy the internationally acclaimed Rescue the Problem Project?

Image of RPP

For a signed and personalized copy in the US visit the book's website.

Not in the US? Try one of these book stores worldwide

Amazon logo
Book or Kindle
Flag of the United States
United States

Flag of Canada

Flag of the United Kingdom Flag of Ireland
United Kingdom

Flag of Germany

Flag of France

Flag of Italy

Flag of the PRC
Flag of Japan
Barnes and Noble Logo
Book or Nook
Sony Reader Store logo
Sony Reader
Worldwide: Many other
book sellers worldwide.

Recent and Upcoming Events

Suggested Books

Many of these books have reviews in the "Books to Read" section of this site.

Agile Project Management: Creating Innovative Products
by Jim Highsmith

Related Items