Contracted IT Projects: A Primer for Client Project Managers
Most project managers learn the basics through a combination of training and experience. Each new project has different “learning opportunities”—some more painful and expensive than others. If you’ve never managed an IT project for your organization that had significant work outsourced to a vendor, what’s learned on the job can be VERY painful and VERY expensive. There are some things to watch out for.
Have experienced lawyers build the contract. Professional services contracts for information technology projects are a very specialized realm of law. Your organization may have a solid legal department, but if they don’t have specific expertise there is a danger that your vendor’s legal team will roll them. Remember that your vendor’s lawyers do this for a living. Best Practices for Contracting with Software and System Vendors is a great resource for you and your lawyers.
You need to be intimately familiar with the contract. You must understand the obligations of your organization and the vendor under the contract, the consequences of not meeting those obligations, and the process and remedies that are spelled out.
You may need to educate client executives. On internal projects, sometimes people can’t meet their commitments, and we work around that. “Gee, our subject matter expert has a conflict and can’t make the requirements meeting? We’ll have to reschedule to next week.” This might affect the schedule, but we absorb it as part of the cost of business and the impact can be mostly invisible—after all, we are on the same team. Client execs must understand that there can be hard dollar costs to not fulfilling contractual obligations. The vendor flew a team out for the requirements session, incurring staff costs and travel expenses. The vendor will likely (and appropriately) file a change order to recover their costs for the last-minute change.
You need to keep more rigorous records. Remember when you took that project management class and they talked about decision logs and risk logs and issue logs and communication plans? It all sounded a little overboard. These serve a purpose and are good things to have on internal projects, but they are essential for keeping things straight with a contracted vendor.
Be aware; you and the vendor have goals that are mostly aligned, but they are different. The vendor PM is not your friend. A good working relationship is desirable, but you serve different masters. The vendor PM wants the engagement to be successful AND profitable. You want the project to be successful and cost-effective. There is an obvious tension between those desires.
Don’t assume the vendor is trying to take advantage of you. As my grandmother always said, “Trust everyone, but cut the cards when you play for money.” Some vendors will try to take advantage of you, but most are in the business of making you successful while turning a profit. Keep vendors at arm’s length. Establish good formal and informal communication paths to your counterpart project manager. Take responsibility (and expect to compensate vendors in some way) for errors and failures on your side. Expect and demand that vendors take responsibility if they fail to deliver as promised—not just at the end but all along the way.
Bringing in vendors with specialized expertise or sufficient capacity to do an IT project for your organization can be a very smart move, but your organization should always have a project manager to manage your organization’s responsibilities and interactions with the vendor. This role can be an order of magnitude more complex than managing internal projects. Don’t be afraid, but do take the job seriously.
