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.

No comments: