Managing Vendors – Articles by Jim Everett

Tips on managing vendors, skills and competencies required

Practical Terminating Factors

Posted on | October 23, 2009 | CLICK HERE TO COMMENT OR ASK QUESTION

Following the earlier post on Terminating Vendor Relationships, this post touches on operational issues, transitioning, and what makes a program different from a project.


Recent searches on this blog around terminating vendor relationships show this is a hot topic. Answers to questions about this depend on many aspects of the work, including the original agreement, reasons for terminating (project changes, client-side factors, or vendor performance), and the terms of the contract that spell out termination procedures.

Also, whether the engagement is a project or a program will have a large impact on how the vendor relationship, or work on this project/program, will be terminated.

So, we need to look at reasons, strategies, processes, risks and consequences. What has been included in the contract about obligations on both sides in the case of a termination? Are there clauses for a no-fault termination, and are there triggers if there is a performance issue (such as late deliverables, quality, or service levels not being met)?

The most straightforward (and possibly easiest) situation is where the termination has been anticipated (in the correct sense of this word, meaning preparatory plans made or steps taken in advance), and there is no fault on either side. Both client and vendor follow the procedures and steps agreed.

It may be that the work had a limited life and, while the exact timing was not known, both parties knew it was finite. This could be supporting a new product line that did not perform as well in the market as was hoped. Or, it could be that the product or initiative being supported was wildly successful and the scope of work grew beyond the capacity of the vendor to grow with it.

In another set of circumstances, a project may be canceled, or a program phased out. The vendor will no longer be needed on that. So for now, let’s assume that we are not redeploying the vendor on other programs or projects.

This is the time to be clear on the difference between projects and programs. A project typically has a finite timeline. It has specific completions and deliverables due by specified and agreed dates. There are also milestones and stages. Payment is structured against deliverables or completion of milestones. A program is typically ongoing and is measured by metrics and service levels.

In both cases, plans have to be made to either wrap up the work or transition to another vendor (or bring in-house). This means that for a project, progress will be halted, or completed to a point of legal obligation, or where it makes strategic/operational/financial sense. A program may have stakeholders (or recipients) and needs to be phased out so that there is minimal impact.

Alternatively, if a project or program is being assigned to another vendor, then a handoff needs to be planned to ensure an effective and smooth transition. Stakeholders may need to be involved. If the handover is harmonious, the job is a lot easier. The client has the leverage of payments for the project against the completion of milestones to the quality and time agreed, and for the program against the meeting of service levels and other metrics.

Key factors in a transition include the critical path and milestones (for projects), and how service levels are maintained (for programs). It may be possible for the incoming vendor to deploy additional resources to offset the loss of momentum and acquired knowledge. Or (if there is trust and a good relationship) the client may pay the outgoing vendor to train the new vendor.

Each situation is unique, and is handled differently. The primary concern for projects and programs that remain active is continuity, and keeping costs and losses within limits. Another key factor is ensuring the transition of capital assets and infrastructure. A less tangible asset is the knowledge and operational, process and product experience accumulated by the outgoing vendor.

Part of any process should be a detailed review of the terms of the agreement that remain in place after the termination. These will include reinforcing the non-disclosure clauses, use of intellectual property (this goes both ways), confidentiality of client data, non-compete clauses, any other residual obligations, or handling undisclosed or overlooked elements that may come to light at a later date (such as promises made to customers, or guarantees on applications developed but not fully deployed at the time of termination).



Leave a Reply

About Think180

Think180 helps companies get best results with service providers (vendors). Our core product is an in-house customizable workshop for Vendor Managers, or entire teams who outsource. This has been run for many clients, including Palm, Philips, Harrah's, BP USA and Canada, Vantive, Alkermes, Avaya, Government of Canada, Fidelity Investments, Quantlab and others.

We now also can offer live and interactive videoconference services and webinars, Training Modules for team events, planning tools and consulting on Vendor Manager competencies, and 1:1 coaching for individuals with videochat (desktop and mobile) on managing vendors.

Call Jim Everett 310.346.8042 for more information to assess if these service are of value to you.

Subscribe to this blog


Email Author