Practical Terminating Factors
Posted on | October 23, 2009 | CLICK HERE TO COMMENT OR ASK QUESTION
_____________
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).
Tags: business relationships > client-vendor > contracts > corrections > critical path > deliverables > handoff > handover > intellectual property > managing > milestones > penalties > program > project > Service Levels > SLAs > terminate > terminating > transition
Comments
Leave a Reply