Transferring Risk via Contract Terms and Conditions

Featured
Mar 13, 2017
3976 Views
0 Comments
2 Likes
Through the use of contract terms and conditions, this article provides insight on managing risk on outsourced projects beyond just transferring work to a contractor. Training courses on risk management typically cover transferring risk at a high level (see Table 1), but that is just a start. Read this article for the follow-ups on managing risk via contract terms and conditions (see Table 2).

Background on Project Needs
With today’s virtual organizations, even projects that appear solely in-house (no outsourcing) use some simple method of procurement such as:

  • General Purchases Agreements (covers goods and services as well as human resources)
  • Credit Cards
  • Petty Cash

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.

Source of Contract Risk

(assumptions, dependencies, constraints, and resistance)

Contract Risk

Event Description

Response

(terms and conditions,

contract clauses)

 

 

 

Assumption – the contractor will deliver requirements

Contractor does not deliver requirements due to vague terms and conditions

 

Contractor defaults on contract

  • Ensure the Statement of Work (SOW) follow SMART* guidelines

  • Ensure remedies for damages due to breach

Assumption – the contractor will deliver requirements per the project schedule

Contractor delivers late per the schedule

  • State specific schedule with audit reviews
  • Include penalties for late delivery
  • Include bonus for early delivery

Dependency – contractor will deliver product that is compatible with current organization’s systems

Contractor delivers incompatible product

  • Ensure terms and conditions include testing and acceptance criteria

Constraint – the contractor will be at or under budget

Contractor charges more than budget amount

  • Process not contract clause - Select a fixed price contract

Constraint – the contractor will deliver requirements as specified

Contractor changes requirements without notice

  • Establish a change control process in the terms and conditions

Constraint – the contractor will keep secret proprietary information

Contractor shares proprietary information with other firms

  • All contractor personnel must sign a nondisclosure agreement

Resistance – all employees will agree with the contractor selection

Employees are resistant to working with the contractor

  • Process not contract clause - project leadership asks critical employees to be involved in the contractor selection

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).
Mark is the President of Monteleone Consulting, LLC and author of the book, The 20 Minute Business Analyst: a collection of short articles, humorous stories, and quick reference cards for the busy analyst.

He can be contacted via – www.baquickref.com.


References

Bockrath, Joseph T. Contracts, Specifications, and Law for Engineers. 4th ed. New York: McGraw-Hill Inc., 1986.

*O'Neil, Jan; Conzemius, Anne (2006). The Power of SMART Goals : Using Goals to Improve Student Learning. Solution Tree Press.

PMI® Project Management Institute. A Guide to the Project Management Body of Knowledge. 5th ed. Project Management Institute.





Latest Articles

Agile User Interface Design
Sep 24, 2017
0 Comments
The role of design still puzzles many agile teams I work with. When should the design activities take place? Who should carry them out? How are design...

Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC