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.

Share

Related posts:

  1. Week in Review: Scheduling, Forecasting, Requirements, and Inventory
  2. Outsourcing Governance and “Who Owns Supplier Performance Management?”
  3. Calibrating Quality Expectations With Your Outsourcing Vendor

Comments

2 Responses to “Defects in Requirements, Change Control, and Performance Management”
  1. Sanjay Roy says:

    I fully agree with the above statement that requirement gathering and validation has formorst priority in the entire contract-to-delivery cycle. A well documented requirement is definitely reduces chances of defect. But as a vendor manager i would suggest that the Vendor team should engage the business analyst or a team of senior resources who will ensure that they have a good talkback session with the client team or the user community (select a project champion from client who has expertise of the business requirement of the process) to validate and verify that the requirement is well understood by both. In this kind of discussion itself, one will find that newer requirements get included as well thus early catching of missed requirement in the inital phase of requirement gathering…Well !! i have used such model while i was working for a IT service company and it worked very well for us…

Trackbacks

Check out what others are saying about this post...
  1. [...] Requirements Defects - How do effective outsourcing executives manage requirements accuracy and completeness? [...]



Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!