Rescuing Troubled Projects 7

Rescuing Troubled Projects 7
This is the seventh and last installment of Rescuing Troubled Projects.   This time we will examine some of the techniques you should probably avoid for large troubled projects.  If you missed any of the prior installments, then you can read them here.

Now let’s examine some of the techniques you should probably avoid.

I have been told on more than one account that I should confront clients and in effect show them who is in charge.  Hey, we’re the experts after all!  We will tell you what you should know and do!

In my opinion, this is a failed strategy.  When you are at the bottom of the hill with a cap gun, and the client is at the top with an army and heavy artillery, you are not in a position to challenge for “king of the hill”.  You are simply over matched.


If you do your due diligence with the account management team, you will develop or become part of a strategy to work with, not confront, the client.

We should be straight forward and honest with clients, and we should do what we say.  However, within reason, we should work at partnering with clients, not battling them.  When we work to a common vision we enhance our chances for success.

At one automotive account, I was assigned to a killer project with some extremely difficult clients.  The approach in the past had always been combative, and my direct client contact constantly sent out harsh emails that copied all of her top management.  So, I set up a face to face meeting with my client contact.  And I discussed how we could work together rather than fighting over everything.  I also asked what information would help the client with her management.  This approach resulted in a much more workable relationship that significantly reduced the nasty emails on both sides.

Usually on a killer project, I am asked to try and make the deadline (no matter how impossible) by overloading and/or adding resources.

If you succumb to this pressure, before you know what is really needed to correct the situation, then you are only making a deeper hole.  Believe me, adding a lot of resources will really speed up digging.  Now, you may determine that additional resources or specific resources are what you need, but be certain first.

Extended overtime leads to burnout and poor quality.  You will frequently have to work some overtime, but don’t plan to work it.  Build your plan based upon a sane workload.  If you build in the overtime and then run short, what will you do?

By the way, a good leader leads by example.  Don’t ask your team to work late while you go home early.  Most of the time, the people that you get at the start will be the people that get you to the finish.  If you care about your team, then usually they will care about you.

Now we come to one of my project pet peeves.

At some point in a project, I will be told by one or more testers, that they can’t write test cases or guidelines until they can work with the application.  This is usually because there is little or no documentation on killer projects.

When the application is ready (or at least usable), the testers write their test cases according to the results of the application.

The developers will always assure the testers that, “that is the way the client wants it”.

This is of course nonsense.  When you test this way, the application always works the way it was developed.  Unfortunately, that may not be the way the client required it.

You must use the requirements to specify the test cases or guidelines.  If they don’t exist, then why are you coding, let alone testing?

This problem is often present at killer projects.  You will know you have been bitten, when User Acceptance blows up because the new “system” doesn’t match the client’s perceived requirements.  This is a BAD TIME to realize that some requirements were left out!

Now don’t laugh!  I had this happen to me once, back when I was in voice recognition applications.  I gave a voice command, and the system burst into flames!  But, that is a story for another time…

How do you know that you are not going to pull this one out of the fire (pun intended)?

There are several indicators you can use, but three are pretty certain to spell doom for the project:

  1.  If you are already past any hope of revenue, and you have substantial costs yet to incur, then you probably won’t succeed.  Although you may, for contractual reasons be asked to complete this work, know that you will be continuously squeezed to cut the losses.  Sometimes you may be asked to be a good soldier for contractual reasons, but be aware that it won’t be fun.
  2.  If you simply have no resources that can do the work, or you have been given resources to use that can’t do the work, then you are probably facing failure of delivery. This includes hardware and software resources.
  3.  If your best scheduling wizardry shows that you are substantially past the required deadline, then expect delivery failure.

On one account that I was sent to, I told the manager that they would not make their deadline the second day that I was there.  How did I know?

They were deep into coding while they were in the midst of requirements gathering.  Although I received some heat for my assessment, it turned out they missed the deadline by a wide margin.

Even though you can’t meet the original plan, don’t give up hope.  Remember innovation!

Negotiate a piece that you can deliver.  Create a contingent agreement that will let you move to the next piece of work after delivering the first one.  Most clients don’t want an embarrassing failure either.  Work with them to define a deliverable, and then see that it gets delivered!

It may turn out that the innovative thing to do is walk away, but don’t suggest it until you have explored other ideas.

I hope you have found this series useful.  Please comment or ask questions, and I will be happy to respond.

Until next time!