A common facet of contracts is a true-up clause that pushes a disagreement on price or capacity into the future, with actual usage or consumption to be calculated at a future date or time. Think of the classic French Bistro (in the outback of France, no in a London or New York suburb), and the bottle of house red that is automatically delivered to your table. Or the bottle of whiskey in the officers mess in the Indian Raj, with the line drawn on the bottle. When the meal is finished, or the drinking is done, a new line is drawn, and you are charged for the difference - the amount consumed.
There is no contract that requires you to consume the entire bottle(s), or a guarantee that you will only drink three-quarters. The contract is settled at a later time. The core of this contract is that all can clearly see what was consumed, and there can be little dispute as the actual quantities and therefore the final bill.
I have seen computer systems contracts with just that type of resolution built into the contract.
Many years ago, I was asked to look at a contract that had such a true-up clause in it. The computer vendor had estimated that a certain level of computing power (mainframes) would be required, while the client estimated a lower amount would be required. In the days before on-demand cloud infrastructure, computing power came in "boxes" of defined "MIPS"(Millions of Instructions per Second - a quaint concept to us today). You got the whole box, or no box. The vendor believed that a certain number of "boxes" would be needed, while the client thought otherwise.
The system was of too much importance however, to allow for the implementation of inadequate computing power, and so both partied agreed to install enough to ensure smooth functioning. The vendor was adamant that their estimates were right, so insisted that the total amount of processing power be installed.
Through the negotiations, a final difference of $18 million was arrived at, out of a total contract value of approximately $80 million. The parties agreed then, as is not uncommon, to split the difference three ways.
Makes perfect sense, if the actual usage can be measured and recorded, and if monitoring and system optimisation are in place on the client side. Like the line on the bottle, the utilisation level could be measured and a line drawn across the capacity of the systems.
Unfortunately, the client failed to put in place the monitoring. As a former mainframe systems capacity planner, I knew what monitoring would be required, and I knew exactly how the vendor would demonstrate that the application actually did require the full amount of computing capacity that was originally estimated. I had, in fact, worked for that vendor.
As the IT Auditor, I recommended that the monitoring should be put in place, and provided guidance on what and how to perform that monitoring. I also recommended that such monitoring should be performed on an ongoing basis, so that management could track how much of the $6 million they would "owe" at any given month-end, so that system optimisation could be performed.
Nothing happened.
Again, in three months, I recommended that the monitoring be put in place. Again nothing was done. All the while the clock was ticking down to the performance date, and it was looking like the $6 million would be owed to the vendor.
Having received no response from the CIO, and in fact, having been told by the CIO that Internal Audit really didn't know what it was talking about, that Internal Audit knew nothing about IT, and that IT auditors were a particularly incompetent bunch, we felt there was no option but to escalate. A one-page memo was prepared and sent to the CEO (the same CEO who sent a two-page memo to all managers telling them that all correspondence to him should be in one-page memo form) outlining quickly the situation, and the (lack of) response from the CIO.
The result: After an independent review of IS's work lasting all of one day, the CIO was fired, and new negotiations were opened with the vendor, and a pre-emptive agreement was reached that saw the client pay the vendor $3 million. The vendor forgave the other $3 million.
Ultimately all agreed that they would not be able to draw a line on the bottle that each party would agree to, so it would have been almost impossible to agree exactly how much had been consumed.
But failure to implement basic monitoring and management cost the company $3 million that they should not have needed to pay.
There is no contract that requires you to consume the entire bottle(s), or a guarantee that you will only drink three-quarters. The contract is settled at a later time. The core of this contract is that all can clearly see what was consumed, and there can be little dispute as the actual quantities and therefore the final bill.
I have seen computer systems contracts with just that type of resolution built into the contract.
Many years ago, I was asked to look at a contract that had such a true-up clause in it. The computer vendor had estimated that a certain level of computing power (mainframes) would be required, while the client estimated a lower amount would be required. In the days before on-demand cloud infrastructure, computing power came in "boxes" of defined "MIPS"(Millions of Instructions per Second - a quaint concept to us today). You got the whole box, or no box. The vendor believed that a certain number of "boxes" would be needed, while the client thought otherwise.
The system was of too much importance however, to allow for the implementation of inadequate computing power, and so both partied agreed to install enough to ensure smooth functioning. The vendor was adamant that their estimates were right, so insisted that the total amount of processing power be installed.
Through the negotiations, a final difference of $18 million was arrived at, out of a total contract value of approximately $80 million. The parties agreed then, as is not uncommon, to split the difference three ways.
- The client agreed to pay $6 million.
- The vendor agreed to discount $6 million.
- The parties agreed to review system usage at the end a year, and split the remaining $6 million based on the actual usage.
Makes perfect sense, if the actual usage can be measured and recorded, and if monitoring and system optimisation are in place on the client side. Like the line on the bottle, the utilisation level could be measured and a line drawn across the capacity of the systems.
Unfortunately, the client failed to put in place the monitoring. As a former mainframe systems capacity planner, I knew what monitoring would be required, and I knew exactly how the vendor would demonstrate that the application actually did require the full amount of computing capacity that was originally estimated. I had, in fact, worked for that vendor.
As the IT Auditor, I recommended that the monitoring should be put in place, and provided guidance on what and how to perform that monitoring. I also recommended that such monitoring should be performed on an ongoing basis, so that management could track how much of the $6 million they would "owe" at any given month-end, so that system optimisation could be performed.
Nothing happened.
Again, in three months, I recommended that the monitoring be put in place. Again nothing was done. All the while the clock was ticking down to the performance date, and it was looking like the $6 million would be owed to the vendor.
Having received no response from the CIO, and in fact, having been told by the CIO that Internal Audit really didn't know what it was talking about, that Internal Audit knew nothing about IT, and that IT auditors were a particularly incompetent bunch, we felt there was no option but to escalate. A one-page memo was prepared and sent to the CEO (the same CEO who sent a two-page memo to all managers telling them that all correspondence to him should be in one-page memo form) outlining quickly the situation, and the (lack of) response from the CIO.
The result: After an independent review of IS's work lasting all of one day, the CIO was fired, and new negotiations were opened with the vendor, and a pre-emptive agreement was reached that saw the client pay the vendor $3 million. The vendor forgave the other $3 million.
Ultimately all agreed that they would not be able to draw a line on the bottle that each party would agree to, so it would have been almost impossible to agree exactly how much had been consumed.
But failure to implement basic monitoring and management cost the company $3 million that they should not have needed to pay.
No comments:
Post a Comment