Getting Requirements Right

A problem-centric approach reduces risk and results in an accurate contract.

By John Petkosek

A critical activity in contracting is getting the requirements right. Yet contracting managers often struggle with defining requirements because they do not fully understand the problem(s) that a particular contract is designed to solve. 

By approaching contracting from a problem-centric, instead of a solution-focused, perspective, contracting managers can dramatically improve their effectiveness. Tying contracts to problems reduces the risk that a contract will be unable to fulfill the requirement. Or, as is more often the case, provides a solution to the wrong problem. To increase accuracy and reduce risk, contracting managers need a way to structure problems to clearly communicate their essential elements.

Before conducting a deep dive into what makes a good problem, it’s important to establish an overarching framework for how innovative organizations approach problem solving. BMNT, a Silicon Valley-based innovation consultancy, developed and promulgates the H4X® Innovation Pipeline® as a useful framework for problem-solving. This disciplined, evidence-based, data-driven process connects innovation activities into an accountable system that rapidly delivers solutions to hard problems. Think of the Innovation Pipeline (see Figure 1) as the operating system for organizational problem-solving.

A Framework for Innovating

The Innovation Pipeline comprises five steps: sourcing problems, curating and prioritizing problems, discovering solutions to problems, incubating solutions to problems, and transitioning solutions to organizations.

Contract managers play a critical role throughout the Innovation Pipeline. To start, it is important for them to be a part of the process from the beginning when problems are sourced. There are several common ways that organizations source problems but all are based on either grassroots sourcing by end users or leadership providing problems identified through knowledge of their organization. Both approaches are valuable and can even be complementary.

Two principles contribute to successful problem sourcing: sourcing at scale and identifying the problem owner. Not every problem is worth solving, but it’s important to source a representative set. By identifying as many problems as possible during sourcing, organizations have the opportunity to discard weak or unimportant problems. And with a comprehensive problem set, it’s much easier to focus on solving the best ones, which are more likely to transition to a solution. 

The second principle is that every problem has a problem owner who has a pain point and an interest in solving the problem. Think of this as the person who would give you a big hug if you solved a particular problem. This person may or may not be the one who generates the requirements. They will be a key person for contract managers to have in their coalitions as they seek to fully understand the problem.

Contract managers can have their greatest impact on the second step in the Innovation Pipeline – problem curation. This is where problems are assessed and prioritized based on evidence collected by engaging with those who experience the problem. 

As Steve Blank, creator of the Lean Startup movement, often says, “get out of the building” and talk to the people experiencing the problem. In many organizations, contract managers are so removed from the end users, they are disconnected from the problem owner they are trying to support. But by investing time upfront to talk with the owner to define the problem a contract will be designed to solve, contract managers construct a contract significantly more likely to succeed.

Good Problem, Bad Problem – How to Know the Difference

It’s helpful to have a structure in mind when focusing on the specifics of a problem. The problem curation process focuses on the three essential elements: the beneficiary, the pain point or basic needs, and the desired outcome. 

The beneficiary is the person who feels the most acute pain from the problem and is invested in solving it. The more specifically you can define this entity, the better. For example, a high-tension lineman needs to be able to reconnect power quickly and safely after a storm. The lineman is the beneficiary. You should be able to write a job title or specific role for this person so you can locate an actual person to speak with later in the discovery process. 

The pain point is the action that is currently not being done, i.e., what the beneficiary needs to accomplish. Sometimes solutions disguise themselves as pain points, so be careful not to fall into that trap. A person needing to get from point A to point B has a pain point. A person needing a car is a solution disguised as a pain point.

Finally, there is the desired outcome. In other words, the result if the pain point is resolved.

Once you have identified the three components of the problem, it’s time to construct the problem statement. Using the following template is one of the most succinct ways to do it: (Beneficiary) needs (pain point) in order to (desired outcome).

For example, electrical linemen need a way to reach high-tension electrical wires in order to restore electric service after a storm. 

The beneficiary group is electrical linemen. The description is discrete enough to narrow the focus to a single group but broad enough to include a number of sources to consult to learn more about the problem. 

The pain point or basic need is not a specific thing or tool like a truck with a bucket lift. It is a description of the task the linemen are trying to do: reach high-tension wires. There likely are many ways to reach the wires: a ladder, a helicopter, a bucket lift, a firetruck. Don’t limit the realm of possible solutions by allowing a specific solution to pose as a pain point. 

Finally, this desired outcome is specific. The pain point is not located in everyday maintenance. It appears during a particular set of circumstances after a storm that are different from normal operations.

Prioritization is the final step in curation. Not every problem is worth solving and it’s often difficult to determine which problems warrant the energy and effort to pursue a solution via contract. An effective way to evaluate problems is by considering them against three criteria: desirability, viability, and feasibility. 

Desirability tests whether the organization is solving the right problem. Simply put, do users want this problem solved? Evaluate whether key stakeholders will adopt it. If the end user and other key players aren’t invested in solving a problem, it is does not merit further consideration.

Viability is a test to determine the long-term sustainability of a solution to a problem within an organization. Is there a pathway through the bureaucracy to tackle this problem and is it supported politically within the organization? If there is no way the organization could or would adopt a potential solution, or if it is not sustainable by the organization, then it is not a viable problem.

Finally, there is the feasibility test. Is the problem technically possible to solve? This may also be a place to consider possible cost. Could a solution be delivered affordably? If potential solutions to a problem are not technically possible or affordable, then the problem fails the feasibility test.

For a problem to be worth tackling it should pass all three of these tests. If a problem is desirable and feasible but not viable, it is just a good idea that has no organizational traction. If a problem is desirable and viable but not feasible, it is an impossible project. There is no technical way to solve it. And, if a problem is feasible and viable but not desirable, it is a bad project. Nobody wants it to be solved. 

Learning at Speed

Only after clearly defining the problem with specifically identified end users and outcomes should you start to consider possible solutions. The first phase in starting to consider possible solutions is discovery. It is not called solution-building or prototyping precisely because there is still a lot to learn before you invest resources in developing a solution pathway. 

Discovery is all about developing, testing, and validating or invalidating critical hypotheses around a specific proposed solution pathway. For a solution to solve a problem, certain things must be true. These are the critical hypotheses. If any of the critical hypotheses are proved false, then the proposed solution will not work.

The goal is to, as rapidly and cheaply as possible, test the critical hypotheses with end users. We do this using a minimum viable product or MVP. The purpose of an MVP is to learn as much as possible about the problem and potential solutions. MVPs can take many forms; a drawing, a slide deck, a physical thing that users can touch and hold. The most important thing is that MVPs can be employed quickly and cheaply to test a critical hypothesis. 

In the linemen example above, a critical hypothesis might be that linemen need to be able to put their hands on the wires to make repairs. An MVP could be a simple A/B test. Linemen could be shown two sketches; one with the lineman on the ground with a mechanical arm working on a power line and one with the lineman elevated to the level of the powerline to work on the wire. To test the critical hypotheses, the tester can ask potential users which is preferred and why. If the preponderance of users indicate they need to put hands on the wires, the critical hypothesis is true. Any solution must be able to elevate the lineman to the height of the wires.

Getting Your Solution Into the Right Hands

The incubation phase expands the coalition building that takes place in problem curation and the tests conducted during discovery. This is where we build and test early versions of the solution. The evidence-based justification developed in previous phases helps the organization’s leaders support and resource incubation. It may require building a team around the possible solution to build, test, learn, and refine before it is ready to transition to implementation. 

In the case of the linemen, through multiple tests we might discover they need to be elevated to work on the wires by hand. During discovery, we may learn that a bucket lift is the best solution pathway. But, since it will be used after a disaster, it needs certain features such as the ability to operate off road and have puncture-resistant tires.

During the incubation phase, the polarity of the innovation pipeline changes. On the left side of the pipeline, the problem owner pushes the problem through the pipeline during sourcing, curation, and discovery. If we get the problem right up front, then during incubation we should see potential partners start to pull the problem through the pipeline looking to transition a solution into use.

The ultimate goal is to be able to transition solutions into existing organizational frameworks and structures and sustain them. By including end users and stakeholders in the process from the beginning, you have laid the groundwork for successful solution adoption. The early focus on the problem, speaking with those who experience it, developing and testing critical hypotheses for possible solutions, and iteratively testing potential solutions all come together during transition. 

The person or organization to which the solution is transitioning is not always the problem owner. In the case of the linemen, the transition partner probably would be the utility company that will decide what tools to buy and sustain to support the linemen.

As the key interlocutor between requirements and the delivery of solutions, contract managers play a critical role in the disciplined allocation of resources. By starting with a problem-centric approach, contract managers can reduce organizational risk and increase the likelihood of a contract action solving the right problem. 

Instead of looking at requirements as an exhaustive list of features needed in a solution, zoom out and consider what problem the contract is intended to solve. Ask yourself: Who is the beneficiary? What is the pain point? And what is the desired outcome? These three questions will allow you to develop a clear and concise problem statement. 

Ultimately, having a clear understanding of the problem you are trying to solve provides a guidepost as you turn requirements into executable contracts that solve real problems. CM

John Petkosek is a Senior Program Manager at BMNT Inc, an internationally recognized innovation consultancy and early-stage enterprise accelerator that is changing the future of public service innovation.