This is page 2 of:
The Three Stooges Vendor Accountability Program
It is easy to fall into this trap. Once you do, it is hard to get out. From my experience, here are a few tips for keeping people honest and pulling their fair share of the project’s weight.
- Remove “soft” words from the vendor’s vocabulary. Replace them with “hard” words. Shame them publically in meetings if they don’t take subtle hints. For example:
- “We should…” becomes “We will…”
- “We might…” becomes “We are…”
- “We think…” becomes “We know…”
- “We are waiting on them…” becomes “The latest update from them is…”
- “We hope…” becomes “Get the *%#*$%& out of my office!”
- Don’t let the details slide. I have fallen victim to being lulled into a sense of security by things looking OK on the surface when they in fact have problems lurking underneath.
- Keep an eye out for the “Game of Chicken.” If several vendors are behind and they all know it, each may hope that the other cries “Uncle” first, leaving them off the hook. Sniff out the slackers by making sure you have status updates from each organization in addition to an overall update.
- For support issues, implement an umbrella organization to manage the back-and-forth between vendors. Although this type of organization often demands an additional cost, the time and hassle you’ll save are significant.
I don’t think there is any way to completely remove this issue from a multi-vendor environment. It comes with the territory. But managing all the individual pieces at a much tighter level can make a big difference in the performance of the project or the effectiveness of the support team.
Another good tool is to execute “Lesson’s Learned” after the project’s completion. Specifically, draw out examples of these types of problems. Discuss with the team how you can better work through such issues in the future. Make sure all your vendors understand your expectations about improvements.
Another idea is to have a section of your Operations Performance Reviews (assuming you do them) focus on “Finger Pointing” incidents. Do a mock-up walkthrough of the problem that happened and determine what could have been done differently to avoid a similar run-around in the future.
What do you think? Love it or hate it, I’d love to gain some additional perspectives. Leave a comment, or E-mail me at Todd.Michaud@FranchiseIT.org.
-Marc
April 15th, 2010 at 7:34 am
This is not a new problem and it is not limited to franchising organizations. It appears to have at least 5 parts: 1) A lack of specific performance requirements from IT that have been agreed on with the company end-users, 2) Failure to put these specific requirements into the contracts with the vendors, 3) Lack of precise metrics to measure contractor performance and a clear statement of what constitutes a failure (serious or minor), 4) Omitting a description of the measurement process (who will do, how often, how results get communicated), and 5) Agreeing on dollar ‘penalties’ for failures. Adding to this real world problem is the fact that it is difficult to find someone to manage this problem. It takes a rare combination of technical IT understanding, contract know-how, business and management experience and communications skills plus continuing effort to quickly recognize and solve these problems.