Some common reasons why requirements can cause risk to a project are:

• To be determined (TBD)
• Late requirements definition
• Unclear requirement definition
• Changing requirements
• Late requirement flow down to subcontractors
• Incorrect or poorly defined interface documents

This paper explains how poorly defined requirements can impact the project.

Requirement Sources

There are two sources of project requirements:

• Customer specified requirements
• Derived requirements

Customer specified requirements typically are stated in a specification within the Request for Proposal (RFP). The requirements are system level, completely defined, clear and usually not a source of risk to the project.

Typically, the contractor’s system engineering team defines the derived requirements. Based on analysis, simulations, calculations, and other methods they allocate the customers system level requirements to the lower-level product level.

Derived requirements are the source of risk to the project for reasons noted above.  System engineering is under pressure by management to define the derived requirements because they want the project to start on time. It takes time to define all of the derived requirements and as a result, the derived requirements are released prematurely.  This means the design starts based on incomplete requirements.  When the requirements are finally well defined, the design team has to go back and redo some or all of the design. This results in cost and schedule impact to the project.

Usually, the plan is based on awarding the subcontractor within four to six weeks after contract award. Again, management puts pressure on the analysts to release the subcontractor requirements prematurely to get them started. When the requirements are completely defined, they are sent to the subcontractor for review. This revised requirements usually results in a higher cost and longer schedule for the subcontractor. As a result, there is a cost and schedule impact to the project.

To Be Determined (TBD)

If a requirement is unknown, a TBD is inserted as a placeholder and to notify the reader that the requirement has to be defined. Once defined, the TBD is replaced with the defined requirement.

Late Requirement Definition

There are a number of reasons why a requirement can be defined late as discussed above.  It most likely will have a negative impact on the project unless the requirement is not too late.

Unclear Requirement Definition

A requirement may be clear to you but not to someone else. For example, the subcontractor may read the same words but understands the requirement and intent differently than you. In this case, sit with the subcontractor and review every “shall” (a requirement) to ensure you both have the same understanding of it. If there is a “will” in the specification under review, then it is only a goal. A “shall” is a requirement.

Changing Requirements

System engineering has a tendency sometimes to change a derived requirement based on my experience. Changing requirements almost always impacts project cost and schedule.  Try and avoid this situation if possible.

Late Flow Down of Requirement

Late flow down of requirements to the subcontractor causes potential project cost and schedule impact.  The reason being, any work the subcontractor has done that has to be redone impacts their cost and schedule which is passed on to the project.

Incorrect or Poorly Defined Interface Documents

Interface documents are required to ensure two or more products that mate up with each other will in fact do that without incident. I have seen many examples where poorly or incorrectly done interface documents have caused serious cost and schedule impact to the project because the mating of the products usually comes near the end of the project and there is no time to recover.

Summary

Requirements are the basis of design and services. If they are poorly defined or the definition is late, then most likely the project will be adversely impacted.

Customer requirements that are stated in the RFP are usually defined and clear.  The derived requirements generated typically by the system engineering team is the cause of project cost and schedule impact if not done properly in a timely fashion.

To mitigate the derived requirements risk, working in advance of the RFP with your customer and the system engineering team is strongly recommended.

To mitigate the subcontractor requirements risk, working with candidate subcontractors well in advance of the RFP (maybe one year) is vital to success.

To mitigate schedule pressure from management, it is essential the proposed schedule is realistic.

Bio:

Currently John Ayers is an author, writer, and consultant. He authored a book entitled Project Risk Management. It went on sale on Amazon in August 2019. He authored a second book entitled How to Get a Project Management Job: Future of Work.  It is on sale on Amazon. The first is a text book that includes all of the technical information you will need to become a Project Manager (PM). The second book shows you how to get a PM job. Between the two, you have the secret sauce to succeed. There are links to both books on his website. https://projectriskmanagement.info/He has presented numerous Webinars on project risk management to PMI. He writes columns on project risk management for CERM (certified enterprise risk management). John also writes blogs for Association for Project Management (APM) in the UK. He has conducted a podcast on project risk management.  John has published numerous papers on project risk management and project management on LinkedIn.

John earned a BS in Mechanical Engineering and MS in Engineering Management from Northeastern University. He has extensive experience with commercial and U.S. DOD companies. He is a member of the Project Management Institute (PMI. John has managed numerous large high technical development programs worth in excessive of $100M. He has extensive subcontract management experience domestically and foreign.  John has held a number of positions over his career including: Director of Programs; Director of Operations; Program Manager; Project Engineer; Engineering Manager; and Design Engineer.  He has experience with: design; manufacturing; test; integration; subcontract management; contracts; project management; risk management; and quality control.  John is a certified six sigma specialist, and certified to level 2 Earned Value Management (EVM). Go to his website above to find links to his books on Amazon and numerous papers.