Summary: This article covers what architects should know about contracts and why. Its objective is to enable an architect to identify the clauses in a contract that could affect the design and implementation of a system, and, conversely, how system design might best assure compliance with the contract. (6 printed pages)
The objective of this article is to enable an architect to identify the clauses in a contract that could affect the design and implementation of a system, and, conversely, how system design might best assure compliance with the contract.
Several years ago, while working for a turnkey system vendor, I was asked to replace the chief architect on a project that was circling the drain. The client and my employer had entered into a contract about a year earlier, things had not gone well, and both parties agreed there was more than enough blame to go around. Both were interested in salvaging the situation (and saving face), but a new start was needed.
The client was tough, but reasonable. My company was small and could not afford what could be a very expensive outcome if we did not come up with something both of us could live with. We were in the business of selling and implementing a customer-information system. Price for the product ranged from a couple of hundred-thousand dollars to six million dollars, depending on the number of client users and optional features of the software. Implementation services, which could be on a fixed-price basis or a time-and-expense basis, ranged from about a quarter of a million dollars to about 10 million. Services were a combination of product customization—such as configuration and parameterization of the product—and custom code development when configuration was not sufficient to meet a client's requirements. In this case, the client was a giant industrial company that had more lawyers than we had employees.
My job was to revise the system design, so the client would accept it, while avoiding the consequences of the more onerous clauses in the contract. The contract consisted of:
- A main section that outlined the legal and financial aspects of the job.
- A functional-requirements section.
- A statement of work (SOW) that defined the roles and responsibilities (that is, activities and deliverables) for each party.
The first thing that I looked at was the scope defined in both the system requirements and the SOW. Because the requirements were, for the most part, functional in nature, we took two approaches. First, we got the client to agree to eliminate some of the "bells and whistles"—the nice-to-haves. Next, with the client, we reworked the SOW to identify each party's activities and deliverables very specifically and in detail, as well as the activities and deliverables for which each party was not responsible, but was supporting the responsible party.
The original SOW was not very specific, so there was confusion and there were disagreements that resulted in wasted time, while we and the client figured out who did what. For example: Who is responsible for developing scenarios and data for the acceptance test? Who is responsible for data conversion/migration from legacy systems to the new system? Who does what, relative to the interfaces between the new system and other client systems? You can see that a very detailed SOW can be both a money saver and risk reducer.
We then took a design approach that in some cases catered for the specific requirements in the contract, instead of a more general approach that is usually advisable. (I wouldn't say that we hard-coded what should be generalized, but we limited in some instances the amount of generalization that we otherwise would have built in.)
After scope, we looked at pricing. This was a fixed-price contract with progress payments. We structured the pricing and the schedule, so there were many milestones and, therefore, more but smaller payments. I designed the system so that we could deliver logical component portions of it early, so as to enhance the project's cash flow. The terms of the contract were adjusted to accommodate the revised schedule, plus as much contingency for slippage as we could negotiate.
The schedule was important because, among other reasons, we wanted to have in it milestones that the client had to meet for items on which we were dependent, and because the contract had a liquidated-damages clause (or penalty clause, as we often—but incorrectly—call it, legally speaking). In designing the system, we looked for trade-offs between our costs for off-the-shelf products that we could embed versus the costs for differing approaches to staffing to do all the development in-house. The former would save time, but would be more expensive than developing all the required software. It would, however, shorten the schedule and reduce the risk of incurring liquidated damages. In some cases, if these damages are small, it might pay to develop in-house and run the risk of having to pay them.
During contract negotiations, we succeeded in getting a grace period—that is, a time between the project-completion date and when assessment of liquidated damages could start. Note that I said "could" start, not "would" start. "Could" leaves the decision up to the client—usually, their project manager or an executive with whom we have a relationship—as opposed to having the liquidated damages start automatically. We have learned that clients often want things that are out of scope that are not too expensive to implement. "Could" enables the client project manager or executive to make a trade (for example, postponement of start of damages for the desired function) without having to get their lawyers involved in drafting and negotiating a contract change.
With a tight schedule and the fact that people really need some vacation time, we latched on to the fact that a transit strike was a relatively sure thing, and we'd be able to count on the force majeure provision in the contract to provide a schedule extension. We arranged with most of the staff to take vacations during the time in which the strike was anticipated to take place.
I already mentioned the term of the contract as being tied to the completion of the project, but there were some items that we and the client wanted to remain in effect past that date. To do this, we had to identify these items explicitly and specify when they would no longer be in effect. One of the key items has to do with intellectual property (IP). Because there were off-the-shelf products in addition to the software we provided, we had to make sure that the product vendors' IP was protected, as well as ours. Similarly, there was a need to protect confidential information past the contract-termination date.
The main body of the contract contained (as do most) general terms and conditions—legal and administrative items—what we sometimes call "boilerplate." It did not contain technical information or things having to do with the specific work to be done for the project to succeed. These latter things appeared in the SOW. The SOW contained:
- Roles and responsibilities of the parties—a three-column matrix in which the first column listed each significant activity and deliverable, the second identified the party responsible for the activity or deliverable, and the third identified the party that participated with and/or supported the responsible party for the activity or deliverable.
- Price for the work to be done, and whether and to what extent we would be reimbursed for travel, living, and other out-of-pocket expenses.
- Acceptance criteria for system functionality and performance, in addition to the process to be used for acceptance testing.
- Assumptions on which our price and schedule were based. These included:
- Supporting facilities and infrastructure that each party was to provide: desks, phones, data-communication hookup, conference rooms, and so on.
- Turnaround time each party was allotted for things it had to approve, information it had to provide, and decisions it had to make. This was a tricky item, because the client wanted a relatively long time to meet its commitments, but we wanted a shorter time. If approvals were not provided within the response period, we wanted the approval to be deemed to have been granted. If information or decisions were not provided in time, or turned out to be incomplete or incorrect, we wanted to be able to obtain an equitable adjustment—such as an increase in price and schedule—and possibly changes in other contract terms and conditions that would be affected. An example of one of these things could be acceptance criteria.
- The training courses we would give, the number of sessions for each course, and the number of client personnel that could attend sessions. Our experience had taught us that classes featuring hands-on system training become less effective if more than about 12 people attend. We also learned that hands-on classes are best conducted by having two trainers in the room throughout, so attendees can get quick personal attention when they run into trouble.
- The conditions under which acceptance tests were to be conducted. For example, it specified that, when performance-testing our system, no other application could be running.
I drafted the SOW. Architects normally do this in our company, because we know what is required in terms of activities and deliverables for any specific project, and we know the technology and its issues. The project director added into the SOW managerial controls and reporting and administrative things that were to be required. The SOW was reviewed by the project director, our attorneys, and me. This enabled us to consider the project management and administration, the technical aspects, and the legal considerations in an integrated manner, and it resulted in some changes to some of the contract documents. We paid specific attention to precedence of the contract documents.
Precedence is more important than it might appear. For example, if for a specific project we were required to attach the client's Request for Proposal (RFP) and our response, in addition to the SOW, ambiguities and/or contradictions between documents could lead to very costly consequences. I will not soon forget one case in which the customer's RFP called for the vendor to provide a "complete disaster-recovery plan." The vendor's proposal price included a plan. The client interpreted "complete disaster-recovery plan" to mean a plan, plus all the hardware and software required to recover from a disaster. That situation really would have been a disaster for the vendor if the proposal did not take precedence over the RFP.
After the contract was renegotiated and the project started anew, there were differences of opinion between my company and the client—some rising to the level of a dispute. That is only to be expected for large, complex systems and projects. We were fortunate, however, that the revised contract was well-written, so it served as a solid guide in most cases as to what had been agreed to, which enabled differences of opinion and disputes to be resolved by the two project directors in almost all cases. When that was not the case, they were resolved by one executive from each of the parties.
In summary, I learned that the purpose of a contract is to:
- Define the parties' expectations before a project starts.
- Guide parties' actions during the project.
- Protect parties' rights.
- Facilitate parties' ability to resolve issues quickly and inexpensively.
- Enable a third party (judge, jury, arbitrator, or company executives) to adjudicate fairly, in the event of a dispute that cannot be resolved internally.
Two things follow from that:
- Prior to the start of a project, architects can play a determining role in drafting parts of a contract. They can also assist in contract negotiations by bringing to the table their knowledge of what system and operational concessions make good sense for us.
- After a project has started, an architect's knowledge of the contract might enable them to shape the solution or design, so as to improve the chances of fully meeting requirements, meeting the schedule, controlling costs, and generally reducing risks.
If at all possible, get involved in the project planning, the contract drafting, and the contract negotiation if you will be a senior architect on a project. As the project progresses, read the contract from time to time to stay abreast of how its contents can affect the design and other decisions that you will make.
The old saying "Knowledge is power" will be amply demonstrated.
- Clapp, James E. Random House Webster's Dictionary of the Law. New York, NY: Random House, 2000.
- Garner, Bryan A. (Editor). Black's Law Dictionary (Standard Edition). Eighth Edition. St. Paul, MN: Thomson West, 2004.
Scope—The scope of a project or a party's portion of a project is of all the activities and deliverables for which the party is responsible, and the requirements that those activities and deliverables are expected to meet.
Liquidated damages (LDs)—Damages for noncompliance with contract terms, in an amount that is agreed upon by the parties when the contract is drafted and negotiated, before the project starts. LDs are agreed upon when the amount of loss due to a particular type of contract breach cannot be predetermined. An interesting aspect of LDs is that, in the event of a breach that is addressed by LDs, the LDs are the only amount that a company can claim if it sustains a loss or damages for the other party's breach. LDs are often expressed as an amount of money to be paid by the breaching party for each unit of time that noncompliance is in effect. Two examples are so many dollars a day for each day of schedule slippage and so many dollars for each day that system-response time fails to meet predefined requirements. This latter type of LD is of particular importance to architects.
Force majeure—Circumstances beyond the control of a party that prevent the party from fulfilling its contract obligations. A force majeure clause relieves the party from the duty to perform the obligations affected by the circumstance.
About the author
Mike Marcus has more than 40 years of experience in the software-services and products industry and in system integration. He has also been an arbitrator for the American Arbitration Association for computer-system–related disputes, and has taught seminars in Project Management for Computer Systems Development for the University of Chicago School for Continuing Education.
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.