Determine Requirements

Identifying and responding to organizational drivers is a fundamental aspect of everyone’s working day in an organization. Intentionally and explicitly clarifying the general direction and scope of the response to a driver before deciding on what specific steps to take, helps identify more specific and suitable solutions, especially in complex situations.

A requirement is a need or desire considered necessary to fulfill to respond to an organizational driver, adequately or as a suitable incremental next step.

Examples

1. Driver: Information is unstructured, kept in silos and sometimes unrecorded, leading to people working with missing or outdated information, which results in ineffectiveness and our clients’ needs being unmet.

   Requirement: We need to store and share relevant information effectively, to improve everyone’s ability to provide valuable solutions for our customers.

2. Driver: We spend 25% of our work hours on admin work and this is leading to slow response time for customer requests and a growing number of complaints. We’re starting to develop a bad reputation and run the risk of losing customers and compromising future sales.

   Requirement: We need to free up time for handling customer requirements in a timely manner, so that we improve customer satisfaction and eliminate this type of complaint.

3. Driver: We’re preparing to recruit five new members into the development teams, and a lack of relevant training could lead to inefficiencies and errors, and an overall decrease in team productivity and quality of work.

   Requirement: We need to ensure that all prospective candidates have the relevant training and experience, so they can effectively contribute to the teams they’ll be part of.

4. Driver: The teams often work on items that have not been prioritized in accordance with the product roadmap. This slows down the delivery of features that have been assigned a high priority by the customer and is leading to complaints about the effectiveness of our work.

   Requirement: We need to improve alignment of the team planning to the product roadmap so that the most important features are shipped first.

5. Driver: Although the financial records of the organization are available to anyone who asks, most people in the organization lack adequate financial understanding to make sense of them in the current format. This leads to frustration, uncertainty and questions that are hard to answer about why certain decisions are being made.

   Requirement: We need to present the information in ways that are understandable, so that people can inform themselves when insight into the financial situation of the organization is required.

Why determine requirements?

In some cases, a requirement is already clear because there is an existing agreement that governs how to deal with a particular driver, or because the situation is simple to deal with and the requirement is obvious.

If there is no agreement in place you need to agree (or decide) what the requirement is. Then you can then act on what has been agreed, review outcomes and, if necessary or helpful, adapt and improve things based on what you learn.

Our opinion about what’s required to deal with a specific situation will inevitably be influenced by our past experience. When facing complex situations however, our initial opinion about what’s required is more likely to be unsuitable or difficult to determine: Several potential requirements may be indicated or what’s required may simply be unclear.

This is why it’s valuable to approach deciding what you believe is required to respond effectively, in a conscious and intentional way, even if the requirement appears obvious.

Determining a requirement, before deciding on what specific steps to be taken, helps define a general direction while still allowing for a range of options on how to fulfill the requirement to respond to the driver in an effective way.

When two or more people share responsibility for deciding how to respond to an organizational driver, differing opinions about specific solutions can lead to contention. People’s ideas can be contradictory or objectionable to others, and they can get into either/or conversations about what would be best. To avoid such confrontation, it’s helpful to resist debating specific solutions until you’ve agreed on the requirement first.

Even in the case that you are the sole person responsible for responding to an organizational driver, it’s useful to clarify for yourself the requirement, before deciding how to proceed. Deciding on a course of action is often more straightforward when the general direction and scope for such action is determined first.

Keeping a record of the requirement (as well as any relevant information about why it was chosen) will help with communicating the requirement to others - especially to those who will be affected by whatever’s decided and by those who will help respond to the organizational driver. It will also help later when reviewing and potentially improving whatever decision has been made.

Once a requirement is determined, the next steps for responding to the organizational driver involve agreeing on how to fulfill the requirement, acting on this agreement, reviewing outcomes, and, if needed, adapting your decision to improve it, based on what you learn (see Respond to Organizational Drivers for more details).

In complex situations where multiple and sometimes even contradictory options exist, an iterative approach for determining a requirement may be necessary because:

• In some cases the suitability of a particular requirement can only be validated through experimentation (i.e. practical application and subsequent evaluation)
• fulfilling what was initially determined as required may take you some way toward responding to a driver, but a further requirement—or even several further requirements—may need to be determined and fulfilled sequentially, to respond to the driver in an adequate way.

How to determine the requirement

An organizational driver is a situation that the organization would benefit from responding to. A requirement however, is a decision that defines direction and scope for a suitable response. When determining what requirement would be suitable, it’s helpful to consider:

• The requirement: what you believe is needed or desirable to respond to this driver appropriately
• The anticipated impact: how you think fulfilling the requirement will help with the driver.

Requirement

When determining a requirement, deciding how specific or broad to be is crucial. Each requirement inherently suggests a direction; a more specific one narrows the range of options for how to fulfill it, while a less specific requirement broadens the possibilities. The desirability of a wider or narrower scope of options varies depending on the situation.

When addressing a complex driver, or when deciding how to respond to an organizational driver collaboratively, it’s often beneficial to aim for a requirement that allows for a broader scope of potential solutions.

If people bring contradictory suggestions about what’s required, this is sometimes an indicator that they’re too much in the solution space. In this case it can be helpful to zoom out and try to identify a requirement that some or all of these solutions might help to fulfill.

• Be specific on whose requirement it is (e.g. “we need”, “they need”, “I need”)
• Avoid describing specific solutions disguised as requirements (see “Requirement vs. Solution” below)

Sometimes further investigation of the driver or experimentation to test assumptions may be the first requirement, leading to the identification of a more specific and suitable requirement in time.

Anticipated Impact

When describing the anticipated impact, explain what you anticipate the consequence of fulfilling the requirement will lead to, and how this is relevant in relation to the driver.

• Explain potential benefits, opportunities, or even the intended outcome of responding to the requirement in relation to the driver.
• Making the impact explicit constraints the scope of the response and helps evaluating the effectiveness of the response in relation the driver

Requirement vs. Solution

The requirement provides a general direction and clarifies the scope for possible solutions. A solution on the other hand is a specific course of action that fulfills a requirement.

Example:

• Requirement: We need to store and share relevant information effectively, to improve everyone’s ability to provide valuable solutions for our customers.
• Solution: A simple and comprehensive information architecture for Confluence, and a coordinated effort to migrate all existing information into that structure.

The requirement above explains what is missing (absent or deficit in some way), but it doesn’t specify how the information will be stored and shared, what steps to take, and who will do what, etc. Having agreed on this requirement, specific decisions. e.g. about how and where to store and share relevant information effectively can be made.

When to determine a requirement?

Determine the requirement before deciding how to specifically respond to an organizational driver, but after establishing that this is in fact an organizational driver, that it’s yours or your team’s responsibility to deal with it, and that responding is a priority. Determining a requirement for drivers that are not a priority might be wasteful, because the situation or its relevance to the organization might change.