Requirements gathering is one of the most important disciplines in government technology procurement.
Before selecting a new enterprise system, organizations invest considerable time documenting workflows, consulting stakeholders, identifying integrations, defining security and technical standards, and establishing the functionality a new solution must provide. These requirements become the foundation for everything from budgeting and procurement to vendor evaluation and implementation.
There is, however, one category of requirement that no project team can document completely:
That isn’t a deficiency in planning. It’s an unavoidable consequence of purchasing technology expected to remain useful long after the environment in which it was selected has changed.
A system implemented today may still be supporting critical government operations a decade or more from now. During that time, legislation will change. New technologies will emerge. Security expectations will evolve. New services and integrations will be required. Citizens will expect different ways of interacting with government. Entirely new regulated activities may appear.
The challenge isn’t predicting all of those changes.
It’s making a technology decision today that preserves the organization’s ability to respond to them tomorrow.
Government organizations have always operated in changing environments. What’s becoming more difficult is the number of different sources of change that technology leaders must accommodate simultaneously.
Artificial intelligence is creating new opportunities—and new governance questions. Cybersecurity requirements continue to evolve. Governments are placing greater expectations on data accessibility and analytics. Budget pressures are intensifying the need for operational efficiency. New digital services require integrations that may not have existed when legacy systems were implemented.
Individual regulatory environments add another layer of change.
Gaming regulators, for example, are confronting emerging gaming models, evolving responsible-gambling expectations, increasingly sophisticated data requirements, new compliance considerations and rapidly developing technologies.
Alcohol and cannabis regulators must respond to legislative changes, emerging product categories, changing licensing structures and evolving approaches to compliance and oversight.
Community development organizations face changing building codes, housing policy, permitting requirements, digital plan-review expectations and increasing pressure for faster, more accessible citizen services.
The details are different. The underlying technology problem is remarkably similar.
Government organizations need systems capable of supporting well-understood processes today without assuming those processes will remain unchanged indefinitely.
That makes adaptability more than a desirable technology feature. It makes it a procurement imperative.
Most technology requirements understandably answer a straightforward question:
What must the system do?
These questions are essential, and a well-structured procurement should define them carefully. CX’s own guidance on defining COTS project requirements and developing a government software procurement document emphasizes the importance of documenting business, technical, interface and functional requirements clearly.
But long-lived government technology investments increasingly warrant a second question:
What characteristics must the system possess so the organization can change what it does later?
That question shifts the evaluation beyond functional fit.
A system can satisfy every major requirement in an RFP on the day it is selected and still prove increasingly restrictive as the organization, technology and regulatory environment evolve around it.
The challenge is not to somehow write tomorrow’s requirements into today’s RFP. It’s to evaluate the capacity for change itself.
Adaptability shouldn’t be reduced to a checkbox marked configurable.
Nor should buyers assume that a system described as flexible will necessarily accommodate every future requirement easily, affordably or without vendor involvement.
Instead, organizations evaluating a configurable government technology platform can investigate how that adaptability actually works.
Consider asking:
These questions don’t attempt to predict the future.
They help determine how prepared the technology architecture is to accommodate it.
There is an important counterpoint.
Maximum flexibility isn’t necessarily the objective.
Highly customized systems can create their own problems: technical debt, upgrade complexity, inconsistent processes, increased maintenance requirements and dependence on specialized knowledge.
The better objective is balance.
Structure without rigidity. Flexibility without chaos.
A mature commercial solution can provide proven functionality for established government processes while the underlying architecture provides controlled mechanisms for accommodating requirements that differ between organizations—or emerge over time.
This distinction matters.
Adaptability shouldn’t require reinventing a mature application every time it’s implemented. Nor should adopting proven functionality mean accepting that an organization’s processes must remain permanently confined to what the software supported when it was purchased.
That middle ground is one of the ideas behind the POSSE enterprise platform: combining established government solution capabilities with an underlying platform and workflow engine designed to support configurable processes.
Configurability is easy to claim. Demonstrated adaptability is harder.
One useful consideration when evaluating a platform is therefore surprisingly simple:
Has the underlying technology successfully supported materially different processes, programs and regulatory environments?
This is an area where CX’s experience is somewhat unusual.
The vendor landscapes surrounding community development, alcohol and cannabis regulation, gaming control and enterprise licensing are often quite distinct. Yet POSSE technology has been applied across these different government environments—and beyond them.
That breadth matters because it provides another way to evaluate adaptability: not merely by examining what an architecture is theoretically capable of supporting, but by considering what it has already demonstrated an ability to become.
The same principle can be applied during any government software procurement.
Government technology relationships can last a very long time. CX’s existing guidance on evaluating and selecting a software vendor recommends looking beyond proposals and demonstrations to examine implementation history, references, organizational stability and the prospects for a successful long-term relationship.
Adaptability deserves similar scrutiny.
Feature matrices will—and should—remain an important part of government technology procurement.
But imagine two systems that both satisfy the functional requirements identified today.
Their functional scores might look remarkably similar at procurement. Their long-term value may not.
That’s why adaptability can be considered throughout the evaluation process rather than treated as a vague architectural benefit.
The objective isn’t to diminish the importance of today’s functional fit.
It’s to recognize that current fit and future adaptive capacity are different dimensions of the same technology decision.
At CX, this isn’t an abstract technology principle.
More than four decades of working with government organizations across different regulatory environments has demonstrated something relatively predictable about government requirements: They change.
Sometimes the change is incremental. Sometimes new legislation or policy substantially alters a process. Sometimes an emerging technology creates possibilities that didn’t previously exist. Sometimes a new program needs to be accommodated quickly. And sometimes the organization simply discovers a better way of working after its new system is already in production.
That reality is reflected in the architecture of the adaptable POSSE government workflow platform. POSSE combines established solution capabilities with a configurable enterprise platform and workflow engine designed to automate and support government business processes.
Its application across materially different government environments provides practical evidence of the philosophy underneath that architecture.
The more realistic objective is to preserve options.
Government CIOs cannot know precisely what their regulatory organizations will be asked to do five or ten years from now. Procurement teams cannot write requirements for legislation that hasn’t been enacted, technologies that haven’t matured or public expectations that haven’t yet emerged.
They can, however, ask whether the technology they’re selecting today gives their organization reasonable capacity to respond when those changes arrive.
Uncertainty is unavoidable. Rigidity isn’t.
The most important requirement in a long-term government technology decision may therefore be less about predicting what comes next—and more about preserving your organization’s ability to respond when it does.
CX has spent more than four decades helping government organizations implement technology in environments where regulations, processes and priorities continue to evolve.
Explore the POSSE Enterprise Platform to learn how a configurable technology foundation can support established requirements today while providing capacity to accommodate change over time.
