This isn’t a knock on anyone. Writing a good RFP is hard. It takes deep operational knowledge, coordination across different teams and thoughtful deliberation. But as we try to improve procurement statewide, it may be worth pausing to ask: Are we spending enough time on what has the biggest impact?
IT STARTS WITH SCOPE
In my experience, many challenges we see in IT projects trace back to a scope of work that’s either unclear, overly detailed in the wrong places or missing the voice of the end user.
We often move quickly to meet procurement deadlines or get a project moving. But sometimes, a little more time up front to ask, “what do we really need this system to do?” can make all the difference. The adage “measure twice, cut once” applies here.
DIFFERENT TYPES OF SPECIFICATIONS
When developing a solicitation, I’ve found it helpful to distinguish between different types of requirements — functional, performance and technical. Here’s a quick way to think about it:
- Functional requirements describe what a system needs to do. Example: “Allow employees to submit leave requests online.”
- Performance requirements describe how well it needs to do it. Example: “System must be available 99.9 percent of the time.”
- Technical requirements describe how it must be built. Example: “System must use Java and run on Oracle DB.”
There are good reasons to include all three in an RFP. But in many cases, we lean too heavily on technical requirements. That can inadvertently limit the types of solutions we receive, particularly from vendors offering commercial off-the-shelf (COTS) platforms or newer, cloud-native tools. In some recent RFPs, I’ve seen pages of requirements specifying software the bidder must use. But this comes at the expense of providing more functional requirements that allow the bidder to propose their own solution or setting performance requirements that focus on end-user experience.
We might consider whether we’re giving vendors enough room to propose better, faster or cheaper ways to meet our needs. Focusing more on what we need and less on how to build it can open the door to creative, viable solutions we hadn’t considered.
THE CASE FOR COTS
Departments don’t always need a fully customized system. COTS solutions, especially those that are configurable, can meet core needs at lower cost and with less risk. But our RFPs sometimes discourage this path by treating preferences as hard requirements or building evaluation criteria around niche use cases.
Rather than eliminate optional features, we might consider distinguishing them more clearly by having subject matter experts (SMEs) and front-line users identify which functions are truly critical for Day 1, and which are “nice to have” or could come later.
This doesn’t mean lowering standards; it means prioritizing effectively. I’ve seen strong COTS-based projects succeed when the team was thoughtful about what mattered most, and open to adjusting fewer essential features over time.
BALANCING TRADE-OFFS: FUNCTIONALITY, SPEED, COST
Every project balances scope, timeline and budget. But RFPs don’t always reflect how departments weigh those trade-offs. For example, we may say we want the best functionality, implemented quickly, at the lowest possible cost — but then evaluate bids with no clear signal of which factor truly matters most.
Vendors can better respond when we’re transparent about priorities. If speed is critical, we might weigh implementation approach and past performance more heavily. If cost is fixed, maybe we set a price ceiling and focus the scoring on business fit. If functionality is paramount, we could design the evaluation to reward depth and usability over price.
This isn’t a new idea. When I was at the Department of General Services, we saw good results in our building projects when we moved away from the old “design-bid-build” model. Instead of specifying every material and method, we shifted to performance-based criteria: square footage, energy efficiency and total cost of ownership. That opened the door for more creative and cost-effective responses while still ensuring we got what we needed.
I don’t want to oversell that comparison. Buildings are different from IT systems. But the principle is similar. Clear, outcome-focused guidance paired with some flexibility in how to achieve it can produce stronger results.
WHAT MIGHT HELP GOING FORWARD
Here are a few ideas that might help improve how we write scopes of work:
- Develop clearer templates for RFP writers that emphasize functional and performance specifications, with examples to illustrate the difference. For technical specifications, keep asking why they are necessary before including them.
- Create lightweight review processes to vet RFP scopes before release — perhaps with operational SMEs, user reps, procurement staff and even prospective vendors at the table.
- Encourage internal conversations early in the process around trade-offs. What matters most to your department for this project: speed, cost or completeness of scope?
- Use scoring criteria that reflect those priorities clearly, so vendors can tailor their proposals accordingly.
- Leverage pre-solicitation research or vendor engagement sessions to understand what’s feasible in the current market, especially for COTS.
ENCOURAGING SIGNS
The good news is that we’re seeing positive signs. I’ve noticed that departments are asking sharper questions, engaging users earlier and working to clarify what’s required versus what’s preferred. Those efforts should be celebrated and, ideally, supported with tools and guidance to make this kind of disciplined thinking the norm, not the exception.
No RFP will ever be perfect. But if we spend a little more time getting the scope right — framing outcomes clearly, prioritizing what matters most and inviting innovation — we may find that the rest of the procurement process moves faster and delivers better results.
We all want to see IT projects succeed. Rethinking how we write RFPs might be one of the most practical places to start.
