Home | Login | Recent Changes | Search | All Pages | Help

RescuingProjects

see also: BadSmellsInProjects
Ever had a thought but you couldn't get it started? This thought is about what things do you look for when you walk in on a project that's in trouble.

What things do you look for when you walk in on a project that's in trouble? DonGray 2/21/2002


I look for people who know it's in trouble and are willing to talk about it. - JerryWeinberg 2/21/02
I look for closure materials: requirements, what do they need to succeed? What do I need to succeed? I look at the PM's and/or lead's actions - I'm looking for placating or blaming. Is the team doing best practices? Is upper management part of the problem or part of the solution when push comes to shove? Are junior members too busy creating problems that lock the strong players into find & fix? What strong players can help get it back on track? What best patterns and what anti-patterns do I see that can be either reenforced or reduced to help? What is happening to the relationship with the customer? BobLee 2/21/02
Like Jerry, I look for people who recognize that the project is in trouble... I also start looking for ways to bring the state of the project into the awareness of the people who can make decisions to get it out of trouble. Sometimes it seems like no one wants to know. EstherDerby 2/25/02
Clarification: "when you walk in on a project that's in trouble?" -- what role am I walking in as? My answer was framed as "new contributor" I think Jerry & Esther are thinking "consultant" -- are we "doing" or "advising"? [As a "doer" on a project in trouble, I don't expect to find people willing to hear my advice until I do something that they can trust me from.] I think both points of view make interesting discussion. BobLee 2/25/02
Clarification: I said anything about giving advice. I'm listening to people and what they want to tell me. I don't expect people to ever hear my advice. I do expect them to offer ideas which I then support or ignore. JerryWeinberg 2/26/02
What I'm reading (for consultant or doer) is that people and information matter. I have found (as consultant) that when I share initial observations about people with my contacts, they concur with my obeservations. I think of this as a verification that we all see the same thing - outside or inside. The next layer of observation may dig into those areas which are hard for insiders to talk about and easier for outsiders to "lay on the table".

Sometimes the "doers" have no control over the factors that affect "rescue". Whether a rescue is possible or not depends on the situation. Do people want a project to be rescued? Sometimes a failure is really what a company wants!

Do I/we have the current capability to perform a reliable rescue? If someone wants to be rescued, I may not be qualified for that situation. So, the best I might be able to do is find others who can help.

In cases where I have rescued a project, it has always been based on information from the people involved. Some people offer words, others documents, stories, and or leads to another person.

- BeckyWinant 2/27/02


Good point, Becky. I've seen situations where somebody was brought in to shoulder the blame. I like to try to understand the motivations of the stakeholders and contrast that to the motivations of the development group [management plus project team]. That helps me guess what the closure conditions need to be: rescue or failure. BobLee 02/27/02
Bob, interesting observation. I think you've got it right: some times an outsider is brought in so the insiders can say "See, we tried, and if this outside expert couldn't fix it, how could you expect us to? At least we tried, by bringin in an expert..." Or they can say "Things were going ok until that expert consultant came in ... now look at this mess."

And sometimes its just easier to have an outsider bear the message. The outsider takes the heat and those inside aren't left with the wrath or the stigma.

EstherDerby 02/28/02


I moved the diagnosing of projects in trouble into BadSmellsInProjects in the same way that Kent Beck and Martin Fowler describe bad smells in code.

Perhaps we can discuss favorite remedies here.

Many of the Bad Smells come from poor team communication. I like to get peer reviews started ASAP to break down the little walls and get everybody pulling the same direction.

BobLee 03/10/02


What are the clues that someone at a medium or high level wants failure? I've never heard someone say "See, we tried, and if this outside expert couldn't fix it, how could you expect us to? At least we tried, by bringin in an expert..." because the people in trouble act like there is no problem.

(It doesn't have to be these exact words... I usually get the sense this is happening from actions rather than words. ED 031702)

One of the hardest things for me is watching a project that needs help, but your offer to help will not be accepted, because no one is asking for help. In fact, I usually can't resist offering helpful information (which is easily rejected.)

One of the points of the book Software For Your Head is that (1) you don't offer help unless someone asks for it (2) learn to ask for help (3) helping someone without their request is a rescue (4) "indirectly asking for help" is actually asking for rescue (4) rescue is counterproductive because it puts responsibility on the wrong person (the rescuer).

KeithRay 03/17/02

Did I come here and go negative all over everybody? Maybe the more "cynical" parts of Software For Your Head are resonating for me this weekend. The books also says (on a more positive note) "An expert at help acquisition will ask for help when things are going well. [...] Acquiring help, especially when things don't seem so terrible, is really the first step to greatness. Acquiring help is not a surrender, but an advance."

So, if people don't really accept help unless they ask for it, how do we encourage them to become experts at acquiring help (and thus rescue their own project)?

KeithRay 03/17/02 (later that day)


Some situations that someone out there wants failure:
  • Feuds in middle management - trying a Tonya Harding on the competitor
  • Management culture directs competition inward rather than outward - projects are win/lose or lose/lose.
  • "Users" would be losers - project would enable laying off staff.
  • Managers would be losers - project would reduce the size of their empire.
  • Project sponsor left, replacement manager doesn't want the project.

Most of these are strongly signalled by incongruent behaviors. Watch for body language clues in meetings.
BobLee 03/17/02


Updated: Sunday, March 17, 2002