Getting it in the cross-hairs

I had the opportunity this week to lead a couple of dozen managers through a target-setting exercise to define their expectations for a large, diverse outsourced offshore team.

I designed the exercise with particular attention around the offshore part of this particular engagement, but as I have said many times, managing offshore outsourced teams requires basic management skills, and the exercise took a back to the basics approach.

In my exercise, we called the overall process goals and objectives or GAOs. The name doesn't really matter, and I have heard and/or done this exercise as key performance indicators (KPIs), management by objective (MBOs), key growth areas, or simply deliverables.

The name does not matter, what matters is the communication. What matters is that management clearly articulates expectations, and treats this process with urgency.

Here is the summary of the voice-over from my exercise:

The exercise is about establishing and communicating goals and objectives for your offshore staff. 

Remember, these folks are your staff. You are responsible for their work, and they are responsible for helping make you successful. So some of these GAOs will cascade directly from your GAOs as managers and business leaders.

However, because of some of the unique aspects of offshore contract teams, some of the GAOs will be specific behavioral expectations, and some will attempt to fix bugs in the partnership.
The important thing here is to document your expectations, then to communicate those expectations to all stake holders (your offshore staff, as well as your retained team).

This has the short term benefit of letting people know what they're accountable for, and giving them a chance to be successful.  There is a long term benefit of preparing yourself and your organization to measure cost effectiveness of your service delivery, and to begin managing to a service level.  

How do you start?  I've watched dozens of managers try to work through establishing and documenting GAOs, and it’s always hard.  I've developed a few simple catalyzing questions that seem to get people thinking...

  • What do you need your (offshore) staff to do over the next 90 days, in order to meet your business objectives? (This becomes the basis for operational GAOs and targets.)
  • What metrics do you already use to measure performance of your offshore staff? If you don’t have anything in place, what could you easily implement via pick-and-axe work? (This will define how to measure performance against these GAOs.)
  • What if any issues or disappointments have you had over the last couple of quarters? (These are the bugs you need to patch through behavioral GAOs.)
After getting managers to think about this, I remind them what a bad GAO looks like. 

Simply put, bad GAOs are non-measurable, subjective, vague or implicit, or unachievable.
Examples of bad GAOs, with some reasoning about what makes it bad, follow:

  • Add value to the team. This is bad because you cannot directly measure value, and someone may think they are adding value when in fact they are negative value-add.
  • Deliver Widget X with high quality. "High quality" is very subjective.  
  • Deliver Widget X with zero defects. "Zero Defects" is impossible to achieve, and this GAO will set the team up for failure.
  • Deliver Function Y on time. "On time" may be clear to the author of this GAO, but it does not communicate to the staff what exactly is expected.
Following that, I presented some good GAOs. All of these are objective, clear, concise, self-contained, and explicit.  Where possible or practical, they should be jointly developed.  And most importantly, they should be clearly communicated to the staff responsible for execution. It’s really as simple as this…  

Some good GAOs might look more like this:
  • Obtain proficiency in development processes through completion of on boarding training, followed by proficiency quiz.
  • Deliver Widget X in the November release, with no more than 2 S1 defects and 4 S2 defects "leaked" to the field within the first 90 days of production use.
  • Deliver all specified behavior in Function Y, by 11/31/2008.  Pass full code inspection and acceptance testing with less than 5% rework.
The difference in each of these good GAOs is that they are precise, they define the target, they define the time line where applicable, and they define the means by which success will be measured. 

The last bit of my talk was about behavioral GAOs. This is a method I've used successfully to get around sensitive cultural or enterprise-to-enterprise relationship issues. A couple of examples follow:

Scenario 1:  An architect-level resource from a service provider was involved at a very deep 
level in a client project. When the architect perceived a problem with the project (that ultimately resulted in a schedule slip), they escalated first to their own (service provider) chain of command. The service delivery director received the escalation, discussed it with the staff involved, and then escalated to the client-side senior leadership.  
Problem: This escalation chain was troublesome to the client, because it created a secondary, unintentional chain of command within the project. They wanted the senior service provider resource to work directly with the product team, rather4 than through a “shadow” management team.
GAO we used to fix it: We wrote a GAO something to the effect of:  Senior architect resources should act and behave as if they were “badged employees” with respect 

Scenario 2:  In a large ITO portfolio with multiple client-side managers, there was some confusion and surprise around staffing coverage in the Indian delivery center, on an Indian national holiday. A reminder that staff would be unavailable went out the day before the holiday.
Problem: This caught many of the client-side managers by surprise, and they had to do significant schedule-shuffling to ensure coverage while the India-based staff was on holiday.
GAO we used to fix it: The service provider management team was asked to send reminders for national holidays and planned personal vacation to all affected client-side manager 2 weeks, 1 week, 2 days and 1 day in advance of the event, to ensure that client-side managers have more than ample advance notice.

These last two scenarios illustrate the organizational or behavioral GAO I mentioned at the start of the post. This method can be used to fix real or perceived bugs in how outsourcing partners relate to one another.

Over the next few weeks, I’ll be getting draft GAOs from about two dozen client-side managers, so I should have some interesting source material about how managers across a wide spectrum of experience approach the problem.


Finally, someone as panoid and cynical about security as I am...

I just stumbled on this excellent list of "security maxims" from the Nuke E. division of the Argonne National Laboratory.  They describe it as "cynical and tongue in cheek."  In my opinion, this just makes it good reading, not less valuable or true.  Read and enjoy.  Here are some excerpts:

Ignorance is Bliss Maxim: The confidence that people have in security is inversely proportional to how much they know about it.

Huh Maxim: When a (non-security) senior manager, bureaucrat, or government official talks publicly about security, he or she will usually say something stupid, unrealistic, inaccurate, and/or na├»ve.

Really, just great, well written, kind of funny truths.  Check it out.


We’re all experts…

I had to take a commercial flight yesterday morning. As is usually the case, I was amused by the latest changes in the TSA’s security theater.

For those readers who have not traveled in the US recently, I will remind you that prior to entering the terminal travelers have to go through security screening. To be allowed into the terminal, you have to:

  • present photo ID and boarding pass
  • resent your carry-on luggage to be x-rayed
  •  remove your shoes and any coat you may be wearing
  • place them on a flat bin to be x-rayed
  • take your computer out so it can be x-rayed by itself
  • remove any liquids such as shampoo or toothpaste from your luggage
  •  ensure said liquids are in containers no larger than 3 ounces by volume
  •  ensure that the containers of liquid are in a one quart clear plastic zip-lock bag
  • walk through the metal detector while carrying your boarding pass

As Security Theater goes, it’s actually not that bad. I've had more intrusive security checks in Asia, and I've had more thorough scanning for possible weapons or explosives in both Brussels and Paris. But it is a lot to ask people to get right.

That list of procedures places a lot of expectation on the traveler. And people mostly get it wrong and gum up the works.  If you remember any of my recent posts about checklists, this is a set of complex high-expectation tasks.

The TSA clearly had the bright idea of segregating frequent travelers from neophytes, so the “frequent traveler” line would work like the express lane in grocery stores… you know, 14 items or fewer, cash only. 

But, the way it was implemented was laughable and made matters worse. And it played into a facet of human nature that frequently hurts those of us involved in managing offshore partnerships or teams. The implementation was this:

At one end of the terminal, there was a sign stating that there were three lines prior to the screening. One was for novice travelers.  One was for experienced travelers. One was for expert travelers.  You had to work your way through a maze of rope barriers for each line, so you couldn't really tell which line was shorter. So everyone picked according to how well they thought they knew the TSA regulations.

Once I got deep into the maze, I could tell that I picked badly.

There were about 150 people in the “expert” line. There were about 50 people in the line for “experienced” travelers. There were two families, seven people total, skipping to the front of the “novice” line and going through their own private. If you were smart, you would have selected that line. But no one did.

Almost everyone asserted that they were experts.  And as a result, all the self-proclaimed experts had to stand in line for 45 minutes waiting to get to the screening tables.

This efficiency effort failed because of a fascinating facet of human nature that inflates our assessment of our own skills. 

I have run “self-assessment” programs with engineering teams and people usually treat it as an affirmation of their aspirations rather than a true and honest assessment of their capabilities. And people will very rarely publicly admit that they are novices at anything.

So, the TSA should clearly try to find a better way to select for their express lane. Maybe they could select by number of bags and get the desired effect of sorting out people who are likely to forget some of the requirements I noted above.

But more interestingly, the object lesson in this is that you should find a better method than self-assessment when analyzing your team’s expertise. Because clearly, we’re all experts.


An interesting idea...

So, I just today learned about this company - 6th Sense Analytics - out of RTP.  They're building what seems to be low-footprint inter-IDE metrics gathering widgets that they deliver as a software enabled service to their clients.  It's one of those ideas that is immediately obvious when you hear about it.  Enough so to make me smack my forehead and say "why didn't I think of that..."

I am trying to find out more about them, and will post more when I do, but their web site might be a few minutes of browsing for anyone interested in metrics and performance analytics in software development, whether it's done onshore or offshore.