The Difference Between a Requirement, a Preference, and a Workaround

By: Stacey Segal

In nonprofit technology projects, not every request means the same thing.

A stakeholder may say, “We need the system to do this.” Another may say, “This is how we’ve always handled it.” Someone else may ask for a field, report, alert, workflow, or customization that feels urgent.

But before the team turns that request into a system decision, it helps to pause and ask a simple question: Is this a requirement, a preference, or a workaround?

The difference matters. When those three things get treated the same way, projects become harder to manage. Systems become more complicated. Requirements become bloated. And teams risk building around old habits instead of solving the real problem.

What Is a Requirement?

A requirement describes something the system or process must support for the organization to operate successfully.

A true requirement is tied to a business need, a compliance need, a reporting need, a user role, an integration, or an operational outcome.

For example, gift processors must be able to identify restricted gifts. Fundraisers must be able to see assigned prospects and upcoming steps. Leadership must be able to report on campaign performance. An integration must send valid constituent and gift data to the CRM. Users must follow communication preferences before outreach.

Requirements should be clear, testable, and connected to an outcome. If no one can explain why the organization needs it, it may not be a requirement yet.

What Is a Preference?

A preference is how someone would like the system or process to work. Preferences matter because user experience matters. If a system is frustrating, confusing, or inefficient, adoption suffers. But preferences are not automatically requirements.

A user may prefer a field in a certain place. A team may prefer a specific report layout. A department may prefer a familiar workflow because it matches their old system.

Those preferences are worth hearing. They may lead to good design decisions. But they should be weighed against the needs of the whole organization, the cost of customization, long-term maintenance, and whether standard functionality already supports the process well enough.

A preference may become a requirement, but only after the business reason is clear.

What Is a Workaround?

A workaround is what people do when the current system or process does not fully support the work.

Workarounds are valuable clues. They often reveal a broken process, missing data, unclear ownership, poor training, or a gap in the system. But they are not always a model for the future.

For example, a team may use a spreadsheet because the CRM report is unreliable. That does not mean the new system needs to recreate the spreadsheet exactly. It may mean the reporting definitions need to be fixed.

A user may manually track exceptions because the import process lacks visibility. That does not mean the manual process should continue. It may mean exception handling needs to be designed better.

Workarounds should be investigated rather than automatically rebuilt.

Sort the Request

Good implementation teams, business analysts, or admins do not just collect requests. They translate them. When a stakeholder asks for something, the team's role is to understand what is underneath it.

Ask: What problem are we solving? What happens if we do nothing? Who uses this information? What decision or action depends on it? Is this needed for all users or one team? Is this based on the current strategy or the old process? Is this a must-have, a nice-to-have, or a workaround for something else?

These questions help the team avoid turning every request into scope.

Bringing It Together

Requirements, preferences, and workarounds all matter. But they are not the same.

Requirements define what the organization must be able to do. Preferences shape how users would like to do it. Workarounds reveal where the current process is not working.

When project teams can tell the difference, they make better decisions. They reduce unnecessary customization. They protect the scope. And they build systems that support the future rather than preserving every habit of the past.