Clear communication is essential to ensure accurate resourcing of appropriate technology to meet user need. Poorly articulated requirements often result in the provisioning inappropriate solutions that can ultimately degrade mission effectiveness and even place users at risk.
Requirement developers are often isolated from the user and therefore need to understand if users are asking for a capability or simply looking for a specific product.
Risk of Poorly Articulated Requirements
Simply put, a poorly written requirement fails to supply what the end user needs. Whether formal or informal, the details that shape requirements can either clarify need, expediting resource provisioning, or result in a cumbersome acquisition process, frequently ending in users receiving something off target. Time, money, and operational effectiveness can be negatively impacted when requirement specifications are unclear or poorly developed.
Knowing the Requirement
Requirements are generally developed from one of two directions— essentially, those where the requirement owner knows exactly what material solution they need and those where they recognize a critical gap in capability. Knowing what is needed (product or capability) will determine how the requirement is written. Both need to establish a clear and comprehensive picture of need to be easily furnished by industry.
- Technical discriminators: Requirement developers who know the specific materiel solution needed must use clear discriminators, directly associated with operational justification, to isolate that desired solution from similar products that cannot execute the intended role. This requirements definition through mission-critical discriminators (as opposed to simply listing technical specifications) is also a useful way for requirement owners to prioritize attributes and determine if the intended solution is even the most appropriate. These technical discriminators help to isolate appropriate resource response from competitive yet inadequate solutions.
- Capability gap response: Requirement development is largely seen as a way for users to tell the acquisition community and industry what they need. However, it should also be leveraged as a means to solve a problem. Recognition of a capability gap doesn’t always present a solution to those immersed in operational context of that gap. General needs and operational context, are useful for industry providers who offer non-standard solutions to resolve gaps in the field. Users lacking the capability to cross rivers may be so focused on writing a requirement for a bridge that they eliminate the solution of a boat. In this instance, it is important for the requirement developers to ask what needs to be done, not simply what they think needs to be done.
- Match existing specifications: The above two approaches to defining requirements seek either a response to a problem or a known product. Unfortunately, degrees of separation can exist between requirement developers and end users (the true requirement owners). Even more degrees of separation stand between end users and industry. Because of this separation, assumptions are often made when defining requirements, which causes confusion and encourages end users to use technical specifications of known products to define their need without ever knowing the feasible alternatives. It often falls on industry leaders to keep end users and requirement developers informed.
- Being too specific: Poorly written requirements can also be too narrow. In an effort to be comprehensive, requirement developers sometimes establish restrictions through arbitrary specifications. More appropriate solutions may be available but disqualified due to an arbitrary constraint. It is important to ask why something is a specification and what operational significance it has. Deliberate application of technical specifications allows industry room for adaptability and versatility in requirement response.
Communication is Key
Communication is key to the accurate fulfillment of requirements, plain and simple. Users must know what they are looking for and inform those documenting their need clearly. Likewise, requirement developers must take context into consideration and justify limiting specification with operational significance to avoid establishing arbitrary parameters that could prevent the most appropriate solution from consideration.
We can offer strategic guidance in the development of your route clearance requirements - get in touch today.