- Introduction
- Different Types of RFPs
- Why Write an RFP?
- RFP Development and Preparation
- Anatomy of an RFP
- RFP Activities
- The Importance of the RFP from a Contract Perspective
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Importance of the RFP from a Contract Perspective
The primary purpose of an RFP is to transmit your understanding of the requirements for a project to suppliers who you believe can provide solutions. The RFP is a written document that both you and the supplier use to establish your joint understanding of the requirements, which become the project's baseline. This baseline, or the final proposal and RFP as written and agreed to, becomes the statement of work for the contract and is an important historical document if the project begins to experience problems.
Problems can begin at any point in the project and may include any aspect of the project from the schedule to the deliverables. If a problem becomes serious and begins to affect the project itself, the baseline documentation will most likely be used to determine where the problem originated. The origin of the problem must be established before a resolution can be _determined.
If we agree that both the buyer and supplier in most cases operate in good faith, we can further agree that if the original cause of the problem can be pinpointed, the party responsible should accept responsibility for the cure. Having the RFP, proposal, and all associated documentation helps avoid the instinctive "finger pointing" when a problem is discovered and further puts the issue on the table in an objective fashion, allowing both buyer and supplier to determine jointly the cause, the potential effect on the project, and the possible resolution.
It is crucial to maintaining this "audit trail" to insist that every change, no matter how small, be put in writing and formally accepted by both parties. This change documentation should become part of the amended contract and should include any changes to the project schedule and other aspects of the original deliverables. For example, a "small" change or addition may affect the initial deliverable schedule, the internal and external testing schedule, the final documentation deliverable, and the final project deliverable itself. Even small additions must be accounted for in all of the areas that may be affected.
If the problem goes beyond the "good faith" mode of operation and the parties end up litigating the issue, the RFP and proposal will become the primary documents involved in the effort to establish the root cause of the issue. Maintaining current copies and insisting on documenting every change in writing will provide the detail necessary to determine who is at fault.
|
One of the more common problems in projects is when two system engineers, one from the supplier and one from the buyer, decide to make an innocent change based on a conversation that goes something like, Supplier: "Can we move the text query box from the second page to the first so it can be accessed directly?" Buyer: "That's a good idea and I don't see why not. What's involved?" Supplier: "Not much. I'll handle it." This change is then discovered during final testing by the marketing person, who says, "Who changed my design? The query box is not supposed to be on the first page because . . . so change it back." |
Problems can range from schedule issues to feature issues and can be blamed on either party. While schedule issues may be the more common problem, "schedule creep" is typically the result of changing requirements or adding requirements to the project. Capers Jones, in his paper titled "Conflict and Litigation between Software Clients and Developers,"2 states:
Software development has been a difficult technology for many years. Compared to almost any other manufactured object, software development requires more manual labor by skilled craftsmen.
Further, many software applications are designed to automate manual activities that were not often fully understood by clients in sufficient detail. Therefore as software development proceeds, new requirements and new features tend to occur in a continuous stream.
Software contracting practices have often been highly ambiguous in determining the sizes of various deliverables, development schedules, and other quantitative matters. More often than not, the contract would deal only in generalities or discuss only part of the situation such as the number of staff to be applied. Unfortunately, most software development contracts contain insufficient language and clauses for dealing with changes in the requirements during development.
The most common root cause of contract litigation where we have been expert witnesses are [sic] new or changed requirements added by clients after the basic contract has been signed and agreed to. The clients think these new requirements should be included in the original agreement while the contractor thinks they should be funded separately. Unfortunately, the contract itself is usually ambiguous as to how new requirements should be handled, and hence the contract itself adds to the probability of conflict and litigation.
By maintaining good documentation for the project, you will be able to minimize the "fix the blame, not the problem" mode of operation and be able to assess objectively how to handle project changes. Mutual assessment and agreement are preferable to allowing a problem to become an issue that may impact the schedule or the contract itself.
Jones' statement, "Unfortunately, the contract itself is usually ambiguous as to how new requirements should be handled. . . . " draws our attention to a potential area of concern over how changes will be handled and how suppliers accept (or reject) changes, track them, and report on the overall project status. Ensure that this topic is covered in your project management requirements section.