| page 2
These are only some of the many ways a project can fail. Dyer noted that there were a few things that show up on poorly performing projects time after time. One of the things that absolutely does not work is a temporary solution.
Suppose, for example, that a client needs to have something completed by July, but it’s January and the vendor knows it would take a year’s worth of work. But the vendor wants to be accommodating and offers to put in a temporary solution by July, promising to fix it later.
“This is one of my hot buttons,” Dyer said. “Getting anything up and running requires extraordinary effort. Vendors and clients should always negotiate something that has a degree of permanence and has the proper time frames for development.”
If it’s not permanent, it’s not a solution. Something that has to be done quickly isn’t likely to be done well, and fixes after the fact usually aren’t enough to compensate for poorly planned work.
It’s also important for the client to understand the problem. If that seems like a given, consider the cautionary tale told by one of the participants of an IT outsourcing contract that was killed just as it was about to be signed. The vendor had worked closely with the board of the client company for months and had negotiated a contract that both sides felt was a good fit. But the board had not consulted an advisory committee that had to approve the contract, and it did not approve. The committee, as it turned out, did not want to try outsourcing for another couple of years.
The lesson for vendors is that they not only need to understand the client’s problem but also understand how that problem is seen by the people who actually make the decisions on the client side.
Know what you signed up to do
Once decision makers from the client and vendor have come to an understanding, they are supposed to document the agreement in the Master Services Agreement and the Statement of Work. These two contract vehicles define the scope of the contract.
Yet vendors still do work that isn’t in the contract. Roger Crabb, vice president of CSC’s Global Transformation Solutions Group EMEA Solution Delivery, described three ways this can happen.
The first is starting work on a project before the main contract has been agreed to. Vendors may do this because the project is on a tight deadline while the main deal takes a long time to negotiate and close. The problem is that it’s very difficult for that vendor to negotiate the scope of a project after the work has already begun. “If you really have to do it,” Crabb said, “and sometimes you do, then make a milestone contract agreement with the client, say within a month. And be prepared to stop work if agreement isn’t reached by that time.”
Even when the scope of work has been written down in MSAs, vendors can be unclear about what is expected of them. On long-running contracts, MSAs can run to several volumes, are several years old, and have been heavily covered over with changes, many of them hand-written. Reading these documents can be a task in itself, one that a project manager simply does not have time to take on.
Clients can also not know what they signed up for. On package implementations, for example, most clients say they want the right-out-of-the-box, plain vanilla variety. All too often, though, that is not what the client’s business users want. “Nine times out of ten,” Crabb said, “the people who signed the contract can’t control the business users, and client and vendor end up making expensive customizations.”
A good way to deal with these situations is to do the customization through a change control process.
< previous page | 1 | 2 | 3 | next page > |
