Recovering from a Project Gone Horribly Wrong ......

From overcomingpoopyelearning.com

Projects by their very nature will go wrong.  Project teams will also recover from bad projects. 

I do not think that there is a formula for recovery like a 9-step program. What I can share with you are our “Learnings” in our journey of recovering from “delivering crap.” (ref my earlier blog)

When Paul told me that we delivered crap, I promised to fix it.  I took responsibility to fix it, even tho’ the entire project team did not report to me. I promised to fix it at our expense, even tho’ I did not know how much it cost. Paul calmed down immediately.

Learning 1: Accept openly that there is an issue, and than, deal with it!

There is no use trying to defend a project that is failing in a customer’s eyes.  If it is failing, it is failing.  Accept it and move on to fixing it.  Best to keep this period as short as possible.

In this project there was an onsite team that did not report to me.  They did the analysis, design and scripting, we did the media, programming, integration and testing. So here I was, committed to fix something that I did not have control over.  

Off I went to meet the onsite project leader, OPM, to seek his buy-in.  All I got was his driving me to meet Paul.  How?  Well, I told him what Paul had said (OPM already knew, as office gossip travels at the speed of light!).  I told OPM how I was embarrassed, and how I needed him to help me interpret what Paul wanted.

Learning 2: Let all stakeholders hear problems. They then become party to the need to solve them.

OPM and I met with Paul.  As OPM thought this was a problem with the development team, he kept quiet. So did I, after asking Paul to freely tell me all the issues.  Paul spoke non-stop for 45 mins.  I wrote down each complaint, categorizing as I went.  Separating data from feelings.  When he stopped, I said, “To ensure I have understood the issues, let me recap these.  Do feel free to correct me if I am wrong.” And I went thru the categorized list with him, starting first with the feeling and then the data.  It went something like this:

“Paul you are irritated that your reading flow is interrupted when you see English grammar and edit errors.  There has not been a single topic that has not had errors.”

Paul said, “Yes”.

I went thru the full list, getting acceptance after each one, and many times, clarifications on feelings and data.

Learning 3: Data is important.  But feelings are more important, especially when a project fails

At the end of a marathon 3-hour meeting we had a long list of issues.  And of course feelings.

I also asked Paul, to help me identify the critical issues, as tackling all of them at one go, would be like boiling the ocean. So he listed what he wanted fixed immediately, and what he could live with. 

Then I told him, “The urgent and critical issues, we will fix.  If you see even one of these in the next deliverable, throw it across the seven seas, and we will get it back to you fixed.  I don’t want to waste your time on these issues.”  In the process we bought a little time.

Learning 4: When a customer prioritizes actions, they are invested in the solution.

So back I came to India, with a long list of issues.  I got the managers into a room.  Asked that they hear what Paul had to say.  Without any reactions. They heard the data on the issues faced.

Then I asked them, how they would feel if they were Paul.  And they repeated all the “feelings” that Paul had shared.  They were spot on.

We then went back to the data.  We agreed that tho' data may be different, it did not matter. For example, whether the average edit errors was 1 in every 5000 words or 1 in every 7500 words did not matter.  What mattered was that there were edit errors.

I asked that they meet with their teams and run the same session. The teams all felt the same as Paul!

Learning 5: Project teams can really put themselves in a customer’s shoes and feel the pinch.

We then wrote down what we thought would make Paul happy. And that became our team goal sheet.

Then we started solutioning, with a large part of the team in one room. We just listed all their ideas on how to solve the issues. 

Then we categorized them into short / long term solutions, on an easy to hard scale. Teams implemented the short term (immediate) easy fixes.  The managers brain stormed the long term hard fixes.  We then went out and requisitioned, commandeered, & acquired the resources we needed. We pulled in OPM for those that concerned him; after all he heard the issues from "the horse's mouth".

Learning 6: Its worth every minute spent with the team finding solutions.  They are in the thick of things and often know better than managers how to get something done.

Then we went out and implemented the solutions. 

When the next deliverable had to go to Paul, I insisted that I review it.  But before I reviewed it, I asked the team if they were submitting something that they were proud to sign their name on.  Some were ready and some wanted to do one last review.

Interestingly, when the people who wanted more time, came back with their work product, I asked if they had found errors. Most said no.  My response, “Have more faith in yourself and your team!  Also, remember, I am a part of the project team even when I am pretending to be the customer.” Most of the “want one more review” brigade never asked for more time again after that.

Learning 7: An unsuccessful project can wither away confidence, our job is to bring it back.  Self- confident people deliver better.

The next deliverable went to Paul with no critical errors.  As did the next and the next.  Also, we chipped away at the prioritized list till we had them all fixed.  What helped was the QA Independence program run by the QA team.  The recognition program was built such that anyone / any team, who delivered a zero error product to QA a certain number of times were certified to deliver to the customer without a QA round. The entire organization wanted this recognition.  The recognition that they had done it right the first time!

Learning 8: Pride in work, big or small, delivers quality.

One person does not make or break a project

One person does not create success or failure

But, one team can sure change anything!