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!