“I’m sorry I don’t have a requirement”
That’s a phrase you may have heard if you’ve had some experience in the defense market. Other federal agencies may refer to their budget priorities.
It can be infuriating, as a solutions provider, when you’ve come across a government agency or team that has a clear need and interest in your offering, and yet appears hand tied by an arbitrary notion of prioritized spending that was made before they knew about you. While it feels inflexible, and there are criticisms that can be made here, managing a finite resource such as funding, over a massive set of interconnected organizations within a complex political structure is nontrivial. I invite a lively debate over means of improving this, but for the sake of practicality, I’d like to shed some light on current reality for those striving to navigate it.
The fourth and final stakeholder in your customer breakout is who I referred to as your “requirer”. I used an informal term deliberately, as you may or may not fall under a formal requirements owner. This person, whether in a formal position or not, is pivotal to your success. They are the one with the authority to decide if your offering is prioritized for spending.
“R” vs “r”
You’ll often hear people reference a “Big R requirement” vs a “Little r requirement”. It’s pretty universal that “Big R” refers to a formal requirement listed in the Program Objective Memorandum, or POM. “Little r” typically refers to derived requirements - either technical requirements that lead to a capability requirement, a discretionary budget priority at a lower level, or the mandatory specifications associated with one specific contract agreement.
How to determine your “Requirer”
If you are providing a major capability, you know there is dedicated funding against it, and you’ve seen the line item in the president’s budget, then you likely fall under a formal requirement. These requirements are generally sponsored by an operational organization considered the requirements owner. For technology development and system procurement, they are usually executed on by an acquisition organization.
When you’re told “I don't have a requirement” for that by an execution agency, know that they don’t get to decide their requirements. They can influence and inform them, and often do, but the operational organization is the one that has final say in the prioritization and funds allocation. That’s why it’s critical to know your buyer AND your requirer and to be engaged with both. Either one can make or break your success in the system!
If you are providing a technical component or sub element, that derived and unsolved technical requirement is often referred to as a “little r” and the authority is delegated to the program office or research organization. If you fall in this group, you’ll want to pay close attention to the relationship between the owner of the formal requirement your work is derivative under and the buyer or integration organization you’re working with. It may be that the buyer has full authority. It may also be that you need to ensure the value proposition of what you're integrating is adequately communicated to the formal requirer.
If you’re providing something that doesn’t seem to fit in any of the formal requirements buckets you likely in one of three boats:
- You’re providing something transformative and extraordinarily novel. (I AM your fan. I’m also your coach, and here to tell you this is uncommon.)
- You fall into a discretionary budget. (This could be as simple as a unit commander and convincing the local spending authority that holds the credit card! This is the easiest case to work with so long as the funding exists!)
- You’re in a convoluted funding chain and need to have some conversations.
Option (3) can be hard, and this is where deep customer discovery is critical. Your user may have no clue who pays for whatever you’re replacing. Perhaps it’s an issued item or something that is enterprise funded. In these unique cases, there’s often more than one answer and it can take some time to make your way to the answer, but there is one. While the system is complex, defense spending is heavily scrutinized and well documented, and all prioritized spending has a champion or it wouldn’t have made the cut.
An important note on Big “R”
Formal requirements prioritization is approved by congress. That means it’s not an instantaneous process to prioritize or modify these items. It also means they likely have some inertia within senior leadership and across congressional committees. That doesn’t mean they cannot be changed, but they cannot be changed rapidly. (Tune in April when I dive into the defense budgeting process!).
For acquisition programs, the establishment of that requirement and program also drives the resourcing tied to it. So if a program office doesn’t see the connection between your product and their requirements, even if they could use discretionary or inserted funding, they don’t have the human resources to manage the program. This is important to keep in mind when asking for support for programs like the Small Business Innovation Research and Small Business Technology Transfer (SBIR/STTR) Programs. Asking someone to sign as a technical point of contact (TPOC), even though you’re not asking for their funding, is still using up their most valuable resource - their time.
How to make the system work for you:
Requirements exist. They drive spending. And they’re not often rapidly changeable, even if you have something cool enough to change them. So how do you work with that?
Read everything you can get your hands on that references the most relevant requirement to you, and let that drive the direction of your strategic communication. If you can be mapped to an existing requirement you can be funded. It’s, of course, more complex than that, but rather than arguing for why the requirement should be reworded because of your invention, see if you can communicate the value of your technology in words that resonate with the requirement. You’ll spend less time trying to swim upstream and more time making progress if you step back from specific semantics, at least in the near term.
Have questions or thoughts about this post? Please share in the comments section below or tag Auxo and share your thoughts on Linkedin!
Your Fan,
