The Yellow Brick Road: Contracting for OSS Success in IP Telephony (cont'd)

This should be a rather long list, with as many hard facts can be mustered. Having this clear definition of success is what provides objective control of a project. The items on the list will not only guide the detailed design, they will form the backbone for Acceptance Testing, day-to-day and milestone-to-milestone management of the project, and for 'go'/'no go' decisions at each step.

Contracting for Success
When negotiating contracts with suppliers, all of the earlier thinking and planning needs to be built into the deal. Service providers are generally good at using the high level requirements and vision for their new services to steer discussions with potential vendors and systems integrators. Often the "critical success factors" and even "key performance measures" are stated in an RFQ, or Statement of Work. But these business objectives are rarely incorporated into the actual terms and conditions of the contract itself. Very often, the fine print in the contract sets out quite clearly that the only real commitments are those in the contract, not in any attachments.

Often, the fine print will say things like "We do not warrant that this work will be fit for any business purpose". By signing such a document, all attempts to define project success, have clear deliverables, enforce performance-based payments, and define go/no-go decision metrics, will be all for nothing. Given this warning, consider the following suggestions:

• Read "boilerplate" language as if the project was already in deep trouble. Your ability to control your project will be affected by the contract language. The contract is negotiated in the "honeymoon phase", when everyone is excited about the opportunity and raring to get going. It is tempting to believe that best intentions will govern the entire project, and that time nit-picking about the words in the contract is just wasted effort. However, when things go off track, every word in the contract takes on enormous significance. Recent disputes over non-performance have shown that many "standard" clauses severely limit one's recourse.
• Insert specific requirements - rigorously. The thinking is done, so write it down. Make sure that the contract documents describe exactly what is to be delivered, and what success criteria the supplier will be held to. Document expected outcomes explicitly. Use all of the Pragmatic ROI thinking and ensure it is captured in the contract in terms that are not over-ridden by boilerplate disclaimers. Describe the post-project environment as accurately as possible, in detail, and clearly specify who is responsible for each item.
• If the contract includes training, make sure that the scope of training is well-defined. Training is a go/no-go milestone. If training is not completed in advance of User Acceptance Testing, the ability to test delivered systems is lost.In some instances a vendor's definition of "train the trainer" means essentially that it will conduct one end-user class on using the new systems attended by staff who will then schedule and run classes for everyone else. This means that the development of training manuals falls to those taking the first course. It is critical to specify how training will relate to what's to be tested during Acceptance Testing.
• Make sure the contract gives you the right to review and reject team members. Experienced, skilled people in small teams can get much more done than large teams of inexperienced people. Insist on the right to interview each member proposed for a team. Reject those that do not have the right experience and qualifications for the project at hand.
• In case there's a big problem. Specify the type of project problems that will cause an Executive Review; an Immediate Suspension of Work, or Project Termination. Specify who will pay for bringing the project back into line, if recovery is possible. Specify what you will pay for, if anything, while the project is under Review or Suspension. Specify who will pay for software bug fixes. Specify who pays for fixing other mistakes made by the supplier.

«Prev    Next »   |   1   |   2   |   3   |   4   |   Subscribe

Send Comment

© 2004, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.