Compartilhar via

So you want to do project recovery?

  • Artigo

I am seeing a gathering wave of players in the project recovery market.  I have stumbled across a half dozen new companies specializing in it.  I have been told about a few management conferences where recovery is being discussed and have certainly been speaking at increasingly diverse conferences on the topic.  I was even asked about teaching recovery for a large education company recently.  If that's not evidence enough it seems my blog readership numbers are on the increase.

I am not too surprised. While you can argue whether the industry failure rate is down below 60% or up over 70% the statistics clearly support the concept that this is an undeserved market niche.  There are certainly a reasonable number of software practitioners who can consistently deliver but I am concerned that the difference between delivering a project and recovering a project is not clear.

Project Recovery isn't for the meek. While others are fleeing from the fire you have to walk into it.  When everyone else is predicting failure you need to guarantee success.  In the middle of chaos, with random activity all around you must constantly make (what you believe to be) the right decisions.  To recover a project you have to assess quickly, pattern match across an encyclopedic number of past experiences and derive what is more likely than not to be a unique solution for the problem at hand based solely on your experience.  Not exactly CMMi level 5 predictability but that's what you are there to do.

The pain is, by most measures extreme.  You effectively interview and establish yourself as a respected leader constantly.  You are being judged by organizations who, by the very fact that you have been called in, are not functioning well.  You will need to outperform everyone in every role; architect, developer, tester, quality assurance, project and program management, and do some portion of them all at once.  You need to smile reassuringly to the CIO and CFO while effectively driving risk in the form of change into their program.  You will be deprived of sleep spending your days on your feet (I rarely take a cube and generally spend less than an hour a day at a desk) walking around teaching, correcting, and aiding communication and most of the night doing code reviews, statistical analysis to justify funding, and presentations ... lots of presentations to both convince and justify the team your direction isn't just a random thought.

You will be isolated.  Isolated from your team, isolated from your customer, isolated from your users, and in some ways your life.  If you go native, that is to be accepted by the team and the customer as "one of them", your opinion will not carry the additional weight of an outside consultant.  You will need to both protect and fight your users.  If they believe you are one of them, you will not be able to mitigate the unreasonable so you may deliver the possible.  You will need people to do what you say because they buy into the process not because they have become your friend.  Friends may do the right thing when directed but the lessons really only stick when they are internalized.  You will live in a state of nearly constant thread switching.  You must maintain a laser focus on the person, the deliverable, or problem in front of you and only that.  Of course the laser focus can't interfere with being the sole keeper of the big picture.  Really... it's fun.

If you are really good, you will document and communicate all of this, all the time.  You will delegate effectively.  You will identify people to trust and task them.  You will work with your customer leads to improve them so that they can take on the program as you exit.  You will need additional super hero members on your team and you will bring have to fight for the right team sometimes rejecting a paying job because you know that you can't staff it.  Personally I try but I do confess I am not always that good.

When everything goes well your team delivers the solution, the end users are happy, the customer staff takes over your multiple roles, and you fade quietly away.  No reward, no recognition.  When things don't go well, you still deliver the solution, the end users are still happy, the customer staff still takes over your multiple roles, but you get to be the container for the customer’s woes.  Run out of town like a sacrificial lamb only to go to another customer and do it all over again.

I do wish all who enter this new niche market the best.  If you do, and you're good at this, and you still want to do it again.  Drop me a comment.  I would like to hear from you.

Comments