Back From Red Blog Banner
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.


More in this category:
Next Post Previous post
Read 4394 times
Login to post comments

Related items

  • The Mythical Man-Month: Essays on Software Engineering
    The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition

    Add To Cart

    Author:Frederick P. Brooks Jr.
    Publisher: Addison-Wesley Professional
    Released: August 1995
    Type: Softcover
    Pages: 336

    Not too long ago I had coffee with fellow tweep, Peter Kretzman, at the Zeitgeist Coffee in Seattle. We had a wonderful conversation and shared stories, philosophies, and impressions. In the process we stumbled upon a common literary love—The Mythical Man-Month by Frederick Brooks. I read it for the first time last summer and Peter reads every few years. We both extolled the virtues of the book and lamented at the fact that so many of the items Brooks brings up continue to plague us today.

  • Retrospective Workshop

    Flier PhotoTired of doing the same thing and expecting the different results? The goal of a properly run retrospective is to do more of the good things and fewer of the bad. Even well run projects have lessons that we can learn. Preforming a retrospective on a project allows you to capture the highs and lows of a project and integrate that information into a library for others to use.

  • Project Rescue Services

    You have been there, unfortuantely projects, programs, and sometimes entire initiatives fail. As opposed to the normal first reaction of finding someone to blame, what is needed is immediate action. Troubles in delivery are only symptoms and not the source of issue. Projects put organizations under stress. eCameron uses a fail-safe recovery plan for helping you turn around your failing projects. We carry out a fact-finding audit and root-cause analysis to create an achievable corrective action plan that helps you get your project on a new track and meet the value requirements of your stakeholders.

    For any strategic initiative, it is critical that everyone associated with the project be focused on the the projects minimal viable goals. This requires strong team interactions and open and realistic communications from the leadership to the individual contributors. We ensure that the project is completed; however, to avoid further failures the organization often needs repair, too.  We have a track record of successfully completing the most complex of projects while making improvements to the organization to prevent failures from reoccurring.

  • Governance & Definition Services

    Packaged Services

    A project's destiny is set very early, often at the inception phase long before the project even starts. The definition and setup of project governance to ensure your projects are properly defined and monitored throughout the project lifecycle is critical.

    Having the appropriate level of governance and oversight is always a challenge. Unfortunately previous project performance has a huge influence on level and degree of governance. The more failures the more governance; the more governance the more bureaucracy and the lower the agility. eCameron has extensive experience with all levels of projects, sizes of company, scope of project, and culture of the company. We can help you balance the governance with your company's culture and its people.

  • Project Health Check & Audit Services

    Packaged Services

    Projects never go bad overnight. It takes time. They slowly drift away from the baseline. Maybe it is a change request that goes undocumented, or a series of tasks that run a little late, or an over-optimistic employee not realizing they are in trouble, or misinterpreted communication. They all add up over time and are very difficult to detect while in the heat of the delivery.

    It often takes an experienced outsider who is removed from the history and politics to see the issues and make the recommendations that will keep a project on track. The Project Health Check provides the data and accountability you need to maintain your project on a proper course.

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
Flag of the United States Buy it in Canada Flag of the United Kingdom
Flag of Ireland Flag of Germany Flag of France
Flag of Italy Flag of the PRC
Flag of Japan
Book sellers worldwide.

Upcoming Events