Art of Delegation

Friday, July 15th, 2005 is etched in my memory as I can vividly remember the system test plan document of my project flying into the dustbin. 

I led the policy administration reengineering project for a large insurance company in the US. The client director JC had called for a meeting to review the system test plan. I was interacting with the offshore team over the last few weeks, having delegated the documentation of the system test plan. As per the planned submission date, I had received the final version of the system test plan from the offshore team.

At 09 am sharp, seven of us assembled in the large conference room on the ground floor, including the five from the client team and my account manager. I started to explain the system test plan. About 15 minutes into the meeting, JC picked up his print copy of the system test plan and threw it into the dustbin, a good 2 feet behind him. In hindsight, I had wondered if he had practiced throwing it in the dustbin on any previous occasion. The stapled system test plan flew right into the dustbin. He stood up to exclaim that he didn't expect it from our team and walked away before we could gather our wits. All of us present in the room were left stunned. With no option to recover from the meeting, all of us slowly made our way out of the conference room.

Along with my account manager, I came back to our office. We relooked at the system test plan and decided to rewrite it. We had not accounted for several business scenarios and missed out on detailing how we will put together the test data. The flow of the document was also not up to the mark. Thus began our efforts stretching into the weekend and over the following week, supported by a couple of other team members. We burnt the midnight oil for a few days to significantly improve the quality. We ultimately took a printout and read it multiple times to be sure we have covered everything.

(Disclaimer: I do not advocate taking a printout, given that I am a Go Green enthusiast. But when you are up against the wall, I had no choice. I have always found more mistakes in a work product when reading from a physical copy than a digital copy)

We requested a second meeting with JC and presented the system test plan a week later. Thankfully, the next attempt ended positively with a few minor comments from various participants. At the end of the meeting, JC sat up from his chair and mentioned that he didn't expect to see an average work product coming from our team the first time around. He appreciated that we turned around the new version so quickly. We were all very relieved.

My learning from this experience is

Retain accountability when delegating

You may trust somebody based on which you may delegate, but ultimately you are accountable. I learned the difference between delegation and throwing it over the wall. I also learned the importance of explaining the expectations with better clarity to the delegated person/team.

If you are the person to whom a work deliverable has been delegated, you must make all possible attempts to understand the expectations. You should also ask what a successful work deliverable would look like.

Do you have a learning experience similar or contrary to this?

Disclaimer: I am not suggesting that the onshore team should be viewed as a team that throws work over the wall to the offshore team. I am also not suggesting that the offshore team is less important than the onshore team or vice-versa. I am making a case for ensuring accountability rests with you when you delegate whichever team you belong to.