Building better processes, Part II: Quantify requirements to make your processes outcome-focused (5 tips)

This is part II of our brief series on how to construct better processes, ones reflective of the factors that matter most. Part I of this series advocated for making all processes requirements-driven. If the DevOps pipeline and other key agile processes remain focused on requirements, the tools themselves have less influence on key factors like release quality and feature portfolio management.

This second part of the series provides tips and guidance for discovering requirements, prioritizing them, and ultimately determining which should have the greatest influence on final process architecture. By taking the time to make an objective assessment with input from across all stakeholder teams, IT leaders can increase the chances that their processes will be geared towards specific outcomes, not simply what outcomes the tools lend themselves towards.

Going from subjective and unclear requirements to specific, objective ones

When building or revising processes, they should be reflective of your organization’s top requirements and aspirational goals. Working from a list of requirements sounds easy enough. When procuring/building a tool to fit in your DevOps environment or revising your existing processes, most IT leaders will be quick to list a dozen or so generalized requirements. 

But requirements can actually be difficult to put into specific words, such that everyone can understand what the requirement actually means and how it would affect a process’s architecture.

For example, many agile experts recommend that businesses use customer feedback to define their product requirements and, from there, the process needed to build such a product. But, as products engineer Shan Bhattacharya cautions, customers can be an unreliable source of objective data: 

“Ever talk to a customer? Requirements should quantify and communicate the customer’s concept of a product, but often customers don’t know what they need. They have fuzzy ideas of what they want and tend to focus on how a system should be developed instead of what a system’s behavior and constraints should entail. As a result, it’s very easy for requirements to get mired down with poor wording, ambiguities, loopholes, and unnecessary implementation details.”

Internal teams and program leads can be guilty of the same sins! They may be hyper-focused on certain areas of the existing process while overlooking other areas.

These perspectives may also vary greatly from team to team, given each’s specific discipline.

To resolve these myriad perspectives, teams should be encouraged to collaborate on not just eliciting feedback but also reconciling the entirety of the feedback that is sourced. They can then proceed to categorize requirements, all while asking the questions needed to nail down specifics of what requirements are needed and why.

Here are 5 tips to help with this process:

1. Rank and categorize requirements to give context

Top IT leadership can act as product managers to sort through long lists of requirements and apply meta-information, make hidden assumptions visible.

As hardware engineering firm Valispace notes, “requirements are too often times ambiguous, open to interpretation or contradict each other.”

What is needed is a system to ensure the language used is specified and consistently understood between teams. When there seems to be a contradiction, it should prompt a discussion to uncover why two teams have differing perspectives/experiences or seem to have goals at odds with one another. 

To manage requirements discovery, Neuma founder & CEO Joe Farah recommends to:

• Identify the requirements as line items
• Identify the key objectives/deliverables for each of the process activities, and split/merge requirements, if necessary.
• Prioritize each of the requirements (e.g.,  high/medium/low or must/should/could)
• Gather input from across IT and the entire organization to consider all requirements

2. Separate functional and non-functional requirements

In products engineering terms, a functional requirement (FR) is a mandate. FRs represent the bare minimum viable product needed.

FRs are more commonplace in industries with serious compliance requirements, such as finance or aerospace. They may also be more likely to be present in industries with sensitive data architectures, such as research, healthcare, and GDPR-regulated markets.

A non-functional requirement (NFR) is an initiative meant to drive a product in a direction consistent with the developer’s goals. They make up a large part of what drives a company to adapt, innovate, grow, and improve the efficiency of value delivery

Some example NFRs seen in digital industries include (per a paper from IFIP Working Conference on The Practice of Enterprise Modeling):

• Agility and Adaptability: Rapidly adapting to changing circumstances such as evolving customer behavior, regulatory environment, emerging technologies, etc.
• Responsiveness: Quickly responding to user feedback and change requests in the form of new product features and bug fixes.
• Speed and Frequency: Delivering new product features and bug fixes faster as well as having a high deployment frequency.
• Efficiency: Improvement in software process execution by automating key process segments and increasing collaboration between team members for greater information flow.
• Customizability: Being able to customize the behavior of the software development lifecycle based on changing contextual and situational needs.

It’s important for organizations to not leave NFRs by the wayside. A product that meets all FRs can still utterly fail to deliver on the expectations of customers or internal initiatives. 

Yet, separating the two can reveal which requirements are integral, and which solutions are automatically disqualified because they can’t meet basic FRs

3. Work backwards from pain points

Many process characteristics (and tool features) aim to address specific pain points. The ultimate goal is to avoid undesirable scenarios, such as gated manual approvals for all work items that lead to major bottlenecks. An example solution to preceding challenge is an AI-based modeling system that automates certain approvals while scoring others as needing a review.

Past pain points can reveal both FRs and NFRs for a revised process. Quantifying these pain points in terms of volume metrics — like unplanned work, escaped defects, etc. — provides objective data for which pain points deserve the most attention.

4. Couch requirements in specific process qualities/solutions capabilities

Creative marketing on the part of solutions providers — helped along by general industry hype — can make it difficult to not focus on specific tools or specific new features. But the features of the chosen solutions must be able to meet specific requirements.

For example, many industries are being pushed to invest in AI-driven analytics solutions. They should not consider the procurement of such a solution to be an end goal in itself but rather a means of meeting a specific goal or requirement.

As Digital.ai Analytics (formerly Numerify) once observed:

“Ultimately, procurement of the right solution is not about going out and buying something specific like, ‘an analytics AI,’ but more about understanding how something like AI can apply to your specific business needs. You want to be able to ask tough questions, and then you can get specific answers that point you down the path towards business success.”

5. Regularly evaluate the DevOps pipeline as a whole to consider options for improvement

One of the biggest mistakes organizations make is that they commit to a specific process or tool pipeline and then never consider if the end results meet requirements and expectations.

The initial results of the change should always be measured against a past benchmark. Overall performance should continue to be monitored as the new process becomes more mature.

After all, a process revision is based on a hypothesis more so than a known factor. Assumptions made in the process development or tool acquisition phase can turn out to be incorrect. Unexpected complications or discoveries may necessitate revisions for the new process to work as intended. 

Further, processes that work now will not fit requirements forever. Organizations must continually evaluate performance data and subjective feedback from teams in order to determine if a process change is needed. Because of this need, it is important to map the entire pipeline and regularly gather data feedback from across the process. Measure results, compare outcomes to expectations and recommend changes to drive continuous improvement.

Don’t let tool choices limit what your teams are capable of

Making your processes requirements-driven reduces the risk that the quality of releases and the efficiency of your workflows will be compromised. At the same time, embedding requirements into your process architectures ensures that the qualities and capabilities you hold most dear will be reflected in the final products of your labor.

Uncovering requirements isn’t easy, not is keeping them at the forefront of your priorities when selecting tools or revising your processes. But the reward provided is immeasurable: your processes become capable of creating things no one else can, even if they have the exact same tools. That’s because values and goals, not tools, make the difference.

Learn how to evaluate tool options and visualize how your choices affect the end-to-end DevOps pipeline in our recent webinar: “Demystify the DevOps Landscape with the Periodic Table of DevOps Tools & DevOps Diagram Generator“