Print this page
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 9476 times

Related items