Documenting Requirements for Outsourced Projects

Featured
Jun 11, 2017
4485 Views
0 Comments
9 Likes
The purpose of this brief article is to explain the connection between documenting requirements and contract type. Recently I consulted with a firm eliciting requirements for a new product. In this case, an internal business analyst team was documenting the product requirements by consulting with appropriate stakeholders. The follow-on project intent was to outsource the work to develop the product in the form of a contract.

The project sponsor asked me for advice and guidance on documenting the product requirements. 

In response, I asked the project sponsor, “What type of contract is the project pursuing?” 

  • fixed price – single fixed price for all the work
  • cost reimbursement – variable cost for work items
  • time and materials – labor rate plus cost of materials

The project sponsor replied, “Why does that matter?”


Contract Type Does Matter

As stated above, there are, in general, three types of contracts. The most popular is fixed-price. Its popularity is due to the buyer transferring all the cost risk to the contractor. Essentially, the contractor agrees to provide the product to the buyer at an agreed to cost; hence the name fixed-price. This type of contract protects the buyer from the risk of cost overrun in developing the product requirements as defined in the contract.

However, if the buyer really wants to control cost via a fixed-price contract, the product requirements must be precise. The buyer should be aware that the contractor may be relying on the lack of product requirement accuracy as a basis for additional profit. For instance, the contractor may agree or propose a low fixed-price (competitive bidding) to win the contract while expecting high profits for changes, rather than from efficiencies in developing items known stated and in the contract. Note, the buyer will most likely pursue the changes with the same contractor for continuity.

Requirement Thoroughness is a
Prerequisite to a Fixed-Price Contract

In cases where requirements are inaccurately described or worst yet, missing, the cost of covering these changes/add-ons are not covered in the fixed-price contract. To address these modifications, the buyer/contractor typically augments their business relationship with a cost reimbursement or time and material contract(s).

  • fixed-price – best used when requirements are well defined (explained below) and associated costs are known or easily estimated
  • cost reimbursement – best used when requirements are mostly defined, but associated costs are unknown or vary
  • time-and-materials (labor plus material cost) – best used when requirements are on-going or unclear and costs are unknown or vary

Note there are variations of these types of contracts such as Cost-Plus-Award-Fee, Cost-Plus-Incentive, Time-and-Fixed-Fee, and Cost-Plus-Percentage-of-Cost.[1]


What is Well Defined?

In general, the project team should always strive to document complete and comprehensive product requirements (i.e., SMART).
  • Specific – enough details including dependencies to ensure that separate parties have a common understanding
  • Measurable – a qualitative or quantitative metric (testable) used to compare to a known standard or expectation
  • Agreed-Upon – a consensus supported (validated) by stakeholders
  • Realistic – achievable given known constraints such as resources, skills, and money
  • Time-Bound – achievable within the needed time frame including prioritization

Note that depending on the source the SMART acronym words may vary; see one reference below.[2] For example: Accurate instead of Agreed-Upon, Traceable instead of Time-Bound, and Relevant instead of Realistic.

Trust but Verify Deliverables

Besides the validation (agreed-upon) of requirements, also include in the contract acceptable criteria (measurable) of the product deliverable and the test data to be used by the contractor.

Summary

If the end goal is to outsource the development work via a fixed-priced contract, the product requirements need to be precise, including acceptance criteria, for the buyer to enjoy the benefit of fixed-price. Otherwise the potential cost benefit may not be realized due to additional cost associated with incomplete or missing requirements.

References

  1. PMI® Project Management Institute. A Guide to the Project Management Body of Knowledge. 5th ed. Project Management Institute.
  2. O'Neil, Jan; Conzemius, Anne (2006). The Power of SMART Goals : Using Goals to Improve Student Learning. Solution Tree Press.  

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

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. 

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).





Latest Articles

The Goal Is to Solve the Problem
Oct 15, 2017
0 Comments
A requirement is “a condition or capability needed by a user to solve a problem or to achieve an objective” (AKA a goal). Thinking in term...

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