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!

Rescuing Troubled Projects 4

Rescuing Troubled Projects 4
This week, we will discuss focusing on the correct activities and testing. If you missed any of the prior installments, then you can read them here.

Never mistake activity for progress!

On killer projects, there is always a lot of activity.  People are scurrying around, and developers are coding up a storm (often while the requirements are being drafted).

You can’t fix everything!  So, it is important that you FOCUS.  I believe in focusing on delivery.  If the client is happy, then ultimately your management will be satisfied (though not always happy).

There is a term from the movie MASH that a fellow PM and I use called, “Meatball Surgery”.  On troubled projects you can’t always execute perfectly.  Therefore, you have to do what it takes to keep things alive and moving.  That is you have to sew them up, and send them out.

There will be times when you can’t afford to follow the process.  The real skill handling troubled projects is to know what part of the process to follow (and when).

You will have to judge when the work you have done is good enough.  You will have to decide what corners you can afford to cut.

I really relate to testers.  They almost always have a tough time on a troubled project.

Test is usually brought in at the last minute.  They don’t know the application.  They don’t have a test environment.  And they don’t have any documentation to write test cases from.

Typically, development will deliver the system late.  Then, everyone will blame the test team, when they don’t have enough time to thoroughly test the application, and bugs are found.

So what can you do?

I suggest that you get a Test Manager involved as soon as you can to help you sort out the mess.  A good Test Manager will let you know where you stand and will tell you what is lacking to test the application.

You can also use some testing shortcuts to save time in the schedule:

  1. Write Test Guidelines rather than individual test cases. Document findings using the guidelines.  This is not as good as test cases, but it does work.
  2. Use test scenarios that test the critical business functionality first and often. If the critical functions are right, the small stuff may be forgiven.
  3. Use a defect tracking tool to capture and manage test results and for tester-developer communication.  Remember, it is not working until the tester says it is.

On one of my projects, I was told that the IT organization did not have a test tracking tool. My attempts to convince them to purchase a tool could not overcome their budget limitations. So, I found a simple tracking tool on the web that cost $40 a month.  The tool was all you can eat in terms of number of developers, and it included email routing.  I wrote a user’s guide, trained my developers and testers and completed the testing successfully in one month.

In our next installment, I will discuss getting sign-off on key documents and scheduling for large troubled projects.

See you then!

Rescuing Troubled Projects 3


This is the third installment of Rescuing Troubled Projects.   This time we will discuss teams and communication.  If you missed any of the prior installments, then you can read them here.

As I said last time, a good, properly motivated team can accomplish amazing things.

However, gaining the respect and trust of a new team (or of an existing team where you are the new leader) takes time.

Nevertheless, there are a few simple things you can do quickly to help rebuild or to improve the morale of your new team:

  1.  If your team is not completely remote, then bring in snack foods and drinks.  I usually set up a table and keep it stocked.  We all know that developers live on Jolt Cola and candy bars.  If any part of your team is remote, then make sure that they get the same kind of consideration as the local team.
  2.  Look for opportunities to genuinely praise good work.  These teams have often not heard a thank you or a kind word in a long time.
  3.  See if it is possible to have a morale event.  I favor bowling, but you should be innovative.  If you can only do a pot-luck, then do one.

In some cases, you will be the working primarily with a customer team.  When this happens, you should make an effort to learn the group dynamics and who the key players are.  This will help you to find ways to relate to the team and to be accepted by them.

At one major food retailer I was introduced to a team of twenty plus recently-minted project managers on a major, but troubled, project.  I attended a team meeting early on, not to just take note of issues and status, but to learn the team’s norms and behaviors.  During the meeting they passed around various snack foods and joked about the use of the term “vanilla” being used to mean standard or straight forward.  At the next meeting I showed up with bags of snacks and a white plastic horse I nicknamed “Vanilla”.  By the end of the meeting I was an accepted member of the team.

I am not a great communicator. Hence, I can say with some experience that it takes effort to communicate effectively.

On every killer project that I arrived at, there was already a serious communication issue.  Often the team and client were not even aware of it!

As you might guess, if you don’t fix this, your efforts may fall very flat.

You must learn the client’s business language and teach the team to speak it.  You should also cultivate allies in cleaning distorted messages.  These are usually client contacts or coaches that understand and agree with your message and will filter out distortion and deliberate interference for other clients.

Remember the communications model, and put in steps to verify that the message that is sent is the message that is received.

Years ago, after completing a very successful project for a client, I was involved with another project for the same client.

This second project was having a lot of trouble getting going … unlike the first project.  I sat down with my contact on the client team and we discussed why we were having a problem.

We finally realized that it was a communications issue.  The terms we were using meant different things to the new group we were working with.  We resolved it by writing a dictionary of terms that both sides used from that point on.

Often teams or clients believe that they have communicated effectively because we told them what we wanted.”  The reality is that little or no coherent information actually was transmitted.  You must verify, usually over and over, that the information you send and receive is correct.  Clients (and project teams) will very often not understand the need for clear communication.

At one account, I asked the client why they had not turned their Acceptance Test cases over to the project development and test team.  I was told, “That would be cheating!”  This is clearly a case of not communicating effectively.

I spent 9 years in voice recognition. So, I know that people act like they are listening, when they are not really listening at all.  We nod, and smile, and we may chuckle at the right moments, but we are not really paying attention at all.  We are thinking about lunch or what we will do tonight.  This is why we document and review what we document.

Next time we will cover the importance of focusing on the correct activities.

See you then!