“The first iteration of a solution is going to be real rough” ITX Delivery Director Christina Halladay told me over coffee one morning. “It takes iteration, and solid communication, to get it just right.”

In technology, we often find a disconnect between what we know it takes to craft an excellent digital product — knowing that it’s difficult to identify and then solve an acute problem — and client expectations. Christina, a leader with years of experience in design, has seen plenty of rough first iterations derailed by unspoken requirements. “You need to have an experimental mindset and approach,” she continued, “which might butt up against expectations of what you thought was required in terms of implementation.”

Curious about this, I asked her what challenges that creates for scoping a software project ahead of time. After all, surely there are hundreds or thousands of unknowns at that point? 

“Sure, the technical path might not be what anyone expected [at the outset],” she answered, “but we stay on the hook until it works.”

ITX sets high expectations on our teams to deliver outstanding software that solves business problems. This in turn makes it difficult to scope projects accurately, a difficulty compounded by non-functional software requirements (or NFRs), aspects of a product that are often only unveiled via the act of building. I talked to Mike Lesher, our VP of Technology, and continued my conversation with Christina, to learn how ITX is leading the way in reducing the potential negative impact that under-scoping non-functional requirements can have on a technology project.

Types of NFRs.

NFRs are those aspects of a product that define how a product executes on its features. Consider a car: it gets you to Wegmans for milk and bread, i.e., its main feature is transportation. The NFRs of your car include its engine power, and how comfortable and safe you are inside. Software NFRs typically include:

• Performance.
  Nine times out of ten, Mike Lesher says, performance is where we have most of our conversations: “I want to do XYZ faster” is a common refrain.
• Security.
  ITX delivers products for organizations that deal with PII, PHI, and PCI (personally identifiable, health, and payment card information). Strong security is a requirement that may not be functional but remains an absolute necessity.
• Accessibility.
  Crafting an accessible product is often talked about in terms of risk mitigation — no company likes to invite lawsuits — but accessibility is, more importantly in Christina’s view, a non-functional requirement that can maximize your user base.
• Usability.
  Products that are difficult to use are slower to establish a core user base, have higher churn rates, and are vulnerable to competitors with more user-friendly interfaces.
• Scalability.
  ITX often works with companies seeking to grow through acquisition: in this context, the scalability of their product suite is a core concern.
• Maintainability.
  Building software is oftentimes a large capital expense; therefore we seek to make our products as affordable to maintain as possible.

When products are scoped according to their features and functionality, these non-functional requirements may not be discussed early enough in a project. What happens in that case?

Staying on the hook.

At ITX, when a non-functional requirement is under-scoped, Mike admits that “frankly, we always make things right. That’s what integrity means to us. So in those situations, we almost always eat the cost or find a way to keep our word.” Deadlines are kept, but pressure on the product team is turned up. Product leaders with tight budgets and timelines, particularly in-house ones, do not often have the luxury of saying “we should have caught that in the pitching process.”

Mike sees this as one of ITX’s competitive advantages, able to drop in additional development resources to help propel under-scoped products across the finish line. “But this isn’t sustainable, right? So, we’ve been talking more and more about how to push these NFRs ‘further left [that is, earlier in the engagement].”

Talking more.

“It’s rarely the features that get us,” Mike offered, “but the unspoken expectations.” So, we speak the unspoken. Starting the conversation around non-functional requirements early, and returning to that topic often, has been effective. At first, Mike says, “we were hesitant to talk about NFRs because we felt that they remained opaque to our clients.” It required a conscious effort to talk more about them. One breakthrough for us was “to consistently discuss the level of effort and impact that not having these conversations brings.”

Considering that Usability is a key NFR, I raised this with Christina. She, along with VP of UX at ITX Nancy Neumann, had years of experience advocating for excellent design as a non-functional requirement. “I’d much rather discuss these non-functional requirements on every meeting,” she agreed, “than have a conversation about scope change later.”

The value of experience and expertise.

When addressed directly, discussing NFRs opens a door to a deeper, and more thorough conversation with our clients that better serves our goal of solving their problems. When companies engage with ITX, they’re engaging with a team of experts expected to be creatively engaged, and not mere order-takers. Mike’s seen positive effects from his strategy of ‘moving NFR discussions left,’ in that “these conversations become a demonstration of maturity and systems thinking. We can really showcase our deeper level of thinking when we take the step to bring up things like accessibility, like security, like performance — and do that early.”

What one of these early conversations sounds like.

Bring these five questions to your next vendor meeting, whether it’s with us or anyone else. The answers to these will help you understand your team’s commitment to your NFRs.

1. How fast should the product be, and for how many people at once?
   Mike hears “I want it to do XYZ faster” more than anything else, and it’s hard to build toward. Putting numbers down early, even if they change, is an invaluable step: how long a page can take to load on a normal day, how many people will be using it on launch day, and how many you hope will be using it in two years.
2. Which accessibility standard does this need to meet?
   Pick one (WCAG 2.1 AA is the usual choice) and ask for details around how it’s tested. Mike has heard clients arrive at this one late with a version of “I don’t want to get sued because I now realize that people with disabilities use my application too.” Christina would add that an accessible product is also not only available to a bigger audience; it’s simply the right thing to do, too.
3. What data will this touch, and who has to sign off on how it’s handled?
   If the answer includes personal, health, or payment card information, get your legal and compliance people in the room early.
4. What does it cost to run once it’s live?
   Hosting, monitoring, and upgrades keep billing after launch, and with AI features the usage itself costs money. On that same project, Christina’s team researched what the app would cost to run across a variety of scenarios, tokens included, and built in notifications for when usage crosses set thresholds.
5. What are you assuming is included that we haven’t talked about?
   Ask it of the vendor, and ask it of yourself. A client once told Mike he was surprised his new application didn’t have analytics, since he’d had analytics back in 2005. “Nothing is free,” Mike says, “despite Google making it feel that way.”

If your answers come back vague, that’s worth knowing before the contract is signed. It’s also what an architecture assessment is for.

Architecture assessments.

Going into an engagement, the scope of the NFRs can be captured ahead of time. If performance of the existing tech stack is poor, for example, we want to know how much work will be required to bring it up a standard that exceeds what’s merely acceptable.

To this end, Mike and his team developed an architecture assessment: an independent second opinion on your technology’s non-functional requirements, delivered to you within 14 days.

Is it always rough?

I asked Mike if he agreed with Christina that “the first iteration of a solution is going to be real rough.”

“That’s the nature of building something new. It’s a difficult process.”