Transferring Risk via Contract Terms and Conditions

These simplified methods of procurement save time and overhead for routine project items. However, for more complex requirements, project leadership needs to pursue a formal contract method such as:

• Competitive bidding – sealed bid submissions to obtain lowest price from a qualified contractor resulting in a fixed price contract arrangement
• Reverse Auctions – iterative on-line bidding to obtain lowest price; similar to a Dutch flower auction where initial bids are high and progress to lower prices from contractors who are more aggressive in obtaining the work
• Competitive proposals – Request for Proposal (RFP) seeking best business value (technical merits) rather than the lowest price; particularly used for complex requirements with a select group of contractors

These procurement methods allow organizations to focus on its core business skills and still address the total needs of the project through outsourcing. Possible considerations for outsourcing via a formal contract are:

• Core capabilities, Strategic Direction, Expertise
• Cost, Initial Capital Investment, On-going Project Expense
• Schedule, Processes, Agility
• Quality, Compatibility, Reliability
• Resources (skills, experience, certifications, licenses)
• Risk (management capability, technical ability, price, schedule, etc.)

What is a Contract?
A contract is an agreement between two or more organizations that form an obligation to do something or not do something. There are several legal elements for forming a legal contract:

• There must be a legal agreement (offer and acceptance) of mutual consideration that is enforceable by law.
• The organizations must be
• competent (legal capacity),
• separate and legal entities,
• represented by an authorized agent.

Note that a contract cannot exist in an in-house project since there are no separate and legal entities. The parties all belong to the same organization. I highlight this due to a past experience. I was a business analyst (employee) that just implemented a new system for my organization’s Human Resources department. I had asked the HR manager to sign-off on a Service Level Agreement (SLA) to ensure that HR had correct expectations on the new system. The HR manager refused to sign. He was very risk averse and was concerned that he would be held legally accountable if any problems occurred. He viewed the SLA as a contract. The fact that we were not separate and legal entities, there was no contract. In addition, neither of us were authorized agents of the organization (perhaps questionable competence :-)). The SLA was never signed and had no business impact. Soon after this encounter, this same HR manager called me on a weekend upset that the new system was not available. I reminded him that the new system was not available on the weekend per the SLA. To his chagrin, he admitted he never read the SLA (bless his heart). I then advised him he could request an expansion of the service hours via a change request per the SLA.

Note even though an SLA may involve only one organization and therefore not an enforceable contract, it still manages risk by ensuring a common set of stakeholder expectations.

Project Risk

All projects have risk: project risk and requirement risk. We, as project managers and/or business analysts, must identify, evaluate, and respond to these risk items; see Table 1.

Table 1. Risk Register (+risk window - period where risk is a concern)

Besides the cited risk responses in Table 1, note the entry for projects utilizing contracts – transfer (i.e., moving risk to another organization via an agreement in the form of a contract).

But just transferring risk by outsourcing is just the beginning of managing risk. We need to follow-up the make/buy decision by reviewing the assumptions, dependencies, constraints and possible resistance (sources of risk) associated with the transfer. Table 2 shows examples of follow-up transfer threats (opportunities could be added) associated with contracts and possible responses in the form of contract terms (promises) and conditions (drives a promise to be honored or not). The project manager and/or business analyst incorporates these responses into the risk register (Table 1) and assigns someone the responsibility to monitor the threat during its window and report its status to project leadership.

Table 2. Follow-up Transfer Risk Items

Note that you can transfer risk, but you can never transfer accountability.

---

Author: Mark Monteleone, PMP, CBAP, CSM, CSPO

Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) International and the International Association of Facilitators (IAF).