360° Vendor Management

Defects in Requirements, Change Control, and Performance Management

Following years of “outsourcing done badly”, transitions of new programs to vendors had come under intensive scrutiny coupled with incredibly detailed requirements gathering processes.  While this slowed implementations and limited near term ROI, parties understood that this level of detail was necessary to successfully transition operations to vendors.

Over the last couple of years, we have witnessed a terrible phenomenon.  Companies are not taking the time properly define requirements.  The consequences are dire - incomplete and/or inaccurate requirements result in a poorly performing program.  In response, the client requests changes.  Excited to avoid being scapegoated, the vendors make the necessary changes, but then climb learning and productivity curves caused by the changes.  In the past two years, we have seen two different programs buckle under clients requesting over 100 changes to each program…in the first three months!  The vendors struggled for over 10 months to recover from the changes.  Meanwhile, the client couldn’t understand why the vendor was failing to meet quality and turnaround time expectations, so the client changed many of their internal vendor managers and vendor account management key resources.  Each new resource requested more changes.  New management teams even renegotiated increased penalties for vendor non-performance, further deepening the pain the vendors experienced.  Meanwhile, the vendors’ teams numbering over 3000 employees were whipped back and forth with all the changes…they never caught up.  The vendors charged over $300k in change control fees.

And then they were terminated for non-performance and the clients each spent over $1M to transition the services to new vendors.  Vendor-to-vendor transitions are never easy, and numerous quality and productivity metrics were missed during the implementation.  The clients’ customers satisfaction levels dropped, followed by their revenues…

One of the most important items implementation leaders need to track are reason codes for change requests.  The reason codes need to include “Missing Initial/Change Control Requirement” and “Requirement Clarification”.  These reason codes allow executives to understand how defective the initial program requirements were and to provide trending analyses that, hopefully, forecast when zero defects are left in the initial requirements documents.

Effective vendor managers know the importance of accuracy and completeness when it comes to requirements definitions.   Defects in requirements cause quality issues - and vendor quality audit teams are often the first to detect defects in requirements.  Pay careful attention to quality audit results, in addition to change control requests.  Expect there to be requirements defects early in a program, as nothing is perfect, but keep a careful eye if the quantity of defects doesn’t quickly reduce to zero in the first 2-3 months.

If detect that the quantity of defects isn’t decreasing, then it’s time to take quick action…bring in a “Tiger Team” or similar highly skilled, very focused group of resources to review all the requirements and make a single, large “change request”.  In addition, executives should not let former business owners off the hook.  Failure to accurately and completely define requirements should be reflected in their performance evaluations, even if they no longer manage the business function. Most importantly, vendor management executives should stress the importance of defect-free requirements definitions (and change control requests!).

There will be many forces conspiring to cause defects in your requirements, including angry soon-to-be-ex-employees, inexperienced vendor managers, “know it all” consultants who don’t know your business, and revenue-starved vendors who suggest that you get started immediately with a quick pilot.

An effective vendor manager doesn’t cut corners when it comes to requirements definition.

This entry was posted on Tuesday, November 20th, 2007 at 2:07 am and is filed under Outsourcing, Requirements Definition, Vendor Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.