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!