On every Recovery Project Someone Must Die

OK, First ... ITS A METAPHOR ... so no flames about me really taking a life ... That said;

If you have me knocking at your projects door something has gone terribly terribly wrong.  Things are so bad that the only thing worse than seeing me is total failure.  Usually I have been called after the budget has been set and largely expended and well into the allotted time if not nearing the end.  The chart below paints the basic picture.  Above the line development moves forward.  The further above the line you get the more effective the development effort is;

The GRAY line is a basically healthy project.  The team forms and overtime delivers the product.

The RED line is the typical arc of my customers.  The team forms and things go very well, for a while.  Then, as they find unexpected technical and political difficulties delivery slows, consultants leave, and the teams effectiveness turns negative. 

The GREEN line begins when recovery begins.  In truth it begins when the project leadership believes recovery is possible.  Next is the slow climb back to zero.  Along the way the team readdressed the basics; Clean environments for build and test, establishing scope, selecting measures, etc ...  It's during this phase and before deliver gets underway in earnest that the staff get reviewed.

Everyone involved prior to my arrival is required to interview with me.  At first I'm not really looking to for blood.  I am trying to decide what if any staff augmentation is required to get the product delivered.   I am also on the lookout for those who are responsible for the mess I am inheriting.  Someone is, it didn't happen by itself, and when I find them there are only two questions left to be answered.  Will they do it again?  and Can I prevent it?

If I find someone who is both culpable and failing to adapt to the "new" way of things I will try to counsel them.  I will provide them potential alternative areas to help the program.  Maybe shifting them to a supporting role.  But history dictates that at least one person will be disgruntled enough to try and actively subvert the recovery effort. 

Now there are several schools of thought when it comes to removing someone from a project;

• You can pull the person aside and quietly tell them they need to seek other opportunities.  Its kind, and provides them a chance to have some control over their destiny.  Of course it hasn't really gone that well for me.  Instead I find the person I am trying to be sensitive to uses the time seed hate and discontent. 
• You can catch them at the end of the day, preferably a Friday according to the Bobs in the movie 'Office Space", with a security guard and a copy paper box.  Overseeing their cubicle de-personalization activities and escorting them quietly out the back door.  This approach prevent the seeding discontent problem and works well enough, but I have a better way.
• You can wait quietly for the right moment to bait them into an opinion driven, potentially divisive debate in front of as many team members as possible.  Public humiliation, a decisive command to be gone, and the public walk of shame with the bankers box sends just the right message to the remaining team.

Of course that's all in my head.  In the real world I do my best to comply with all HR policies related to the release of an employee from their contract frequently leaving the actual dismissal to the appropriate authority based on the persons particular affiliation.

 

Technorati Tags: Agile, Project Recovery, Team Dynamics