In my previous post, I made the outlandish statement that not all vendors are well-versed in the skills needed to properly handle large, fixed-price, contracts for one-off products. Now, I want to discuss some ways to effectively work with such contractees.
Risk: Many vendors feel they are simply not prepared to assume the risk that’s involved in a fixed-price contract. When you press them, of course, you find that risk assumption is not the real problem. If you ask questions like, Could you do the project for $10 million? Could you do the project for $100 million. What if we offered you $1 billion? These questions are obviously silly, but they illustrate the point that there usually is a price point where the risk can be assumed. So, what they usually mean by we can’t do a fixed price contract is that they don’t understand the risk well enough to be able to price it into their bid. With this insight realized, there are a number of approaches you can take:
1) accept certain risks for the vendor
2) initiate some pilot studies to assess and/or eliminate key areas of risk
3) allow some flexibility in the bid price, with certain elements being priced only after enough effort has been made to understand and costs the risky bits
4) simply encourage them to price the uncertainty into their bid and submit a higher priced bid
Working Relationship: Most academic teams don’t really like the customer/vendor relationship model. Many of them are in academia, and not industry, for exactly reasons like this. They usually prefer a more interactive partnership where science objectives, technical requirements, and management decisions are made more jointly with less clear lines of authority from contractor to contractee. The goals of the academic world include building and sharing new knowledge and closer interaction with the project partners helps fulfil these objectives. The contractor, therefore, has to be willing and able to devote more resources to the project and have more interactions with the contractee than they might otherwise have, sometimes partnering in parts of the work and mangement efforts. Lines of ultimate authority and responsibility can get a bit blurred in these situations, though, so it is important to make it clear who has the final say when necessary (although only when necessary) and what decisions and discussions have contractual implications vs. those that are simply exploratory debates and discussions.
Understanding the Contract: Many of our vendors (academic or not) do not seem to fully read or understand our contracts. They often do not know exactly what they are expected to do, nor what their rights and responsibilities are with respect to the contract. Sometimes this lack of understanding actually helps the contractor when, for example, a contractee does not realize that a change initiated by the contractor does not have to be accepted without additional compensation. But even in these cases, ultimate harm is done to both the contractor and contractee if the contract terms are not openly discussed and enforced by both parties. No one who loses money in a contract due to changes by the customer will want to contract with them again, for example. So, it is vital for the contractor to really explain the contract to the contractee and to constantly refer to it and abide by it when new situations arise. This behavior gets everyone’s rights and responsibilities out in the open, eliminates a lot of arguments about what the correct course of action is, and build good relationships for this and future work together.
Contingency Management: I referred to this issue in my last post, but it’s of such vital importance to the success of a project that I want to bring it up again here. First of all, it is important to realize there are three types of contingency: cost, schedule, and functional. The temptation, typically, is to use them in that order, but that is exactly the wrong thing to do. Towards the end stages of a project, often when the most problems occur as the pieces come together for full assembly and integration, there is very little functional contingency left. The only thing that will get you our of a jam at this point, is usually money. The only time functional contingency has any availability is early on in the project, before the design has been set and components purchased. Unfortunately, early on in the project, there should also be lots of cost and schedule contingency, so the temptation is to keep the product fully functional and start dipping into the cost and schedule buckets. The problem then comes, of course, at the end stage, when the functional contingency has expired and the cost and schedule contingencies have already been spent. You don’t want to hoard your cost and schedule contingencies past the end of the project, but you do want to make sure they are available in the latter stages of the project when you are most likely to need them.
The scientists and technologists involved in a project will not want to give up functions early in the project when, from their point of view, there is a pile of available time and money just waiting to be spent. Worse still, they may want to start adding features as new ideas and products are discovered that will enhance the end product. Ask any experienced project manager and they will tell you that succumbing to these two temptations is to go down a very precarious path towards successful project completion. So, one technique to employ is to leave hooks in the project for the cut or new functionality and set a date by which time it can be included if other risks have not been realized. Doing so establishes the mindset that these three areas of cost, schedule, and function have to be continually balanced within each of their finite limits and may even inspire people to work harder in other aspects of the project so that their favorite functionality can be restored/added later.