 |
| Courtesy of Bing Image Creator with prompt: "purchasing with two tools, pointilism" (See Note #5) |
A Hybrid RFI / Cooperative Purchase: The Best of Both Worlds
******************************************************************************
All of the ideas expressed in this article are my personal statements and opinions, and do not reflect the opinions/statements of the City of Urbana.
******************************************************************************
Previously on “Tectonic Speed”...
In another post in this Tectonic Speed series ("A Procurement Coup"), I described our use of cooperative agreements (hereafter: “Co-Ops”) for flexibility in a purchasing process. That time, we wanted to buy a VoIP telephone system: a project that is complex not because of the technology - one VoIP telephone handset is pretty much the same as another - but because of the project to convert numbers, connect to legacy hardware, and deal with downtime.
We needed a consultative purchasing process so we could discuss our most wacky needs and scope the project appropriately. In that case, we simply reached out and engaged with three vendors who had awards from purchasing Co-Ops where we were members. Because we could buy from any of the three through the Co-Ops, we could start purchasing discussions immediately - without any formal procurement process at all.
At that time, the flexibility to directly communicate with vendors was the key benefit. In a traditional RFP process, we couldn’t have that kind of dialogue. In a relatively short time, we were into negotiations and made a purchase.
A Different Problem
Recently we had a different procurement challenge while buying a Network Detection & Response (NDR) solution. NDRs are a combination of software and (sometimes) hardware that monitor activity on the network, detect threats, alert us, and neutralize the threat... depending on your rules. (We already had a network alert system, but the key difference is the “Response” part. It’s like an anti-virus for network events.)
NDRs cost more than our dollar limit that requires an RFP… unless we bought through a Co-Op agreement. But here the model from our telephone purchase breaks down. VoIP telephones are commodities, so the solutions are mostly the same (to emphasize: with phones, it’s the implementation). This time was different because the NDR solution itself is technically complex; the quality of the system and the vendor make a big difference. (Note #1)
The method of just picking three vendors and starting discussions might not get a good solution. Worse, it would consume lots of time as we explained our network’s details to each one. Also, with the opaque nature of resellers (Note #2) there is no easy way to know what solutions are available through Co-Ops.
The RFI to the Rescue
In the past, I ignored the RFI because it lacked one key feature: unlike an RFP, you can’t buy from it. Uh, excuse me – I just went through a whole procurement process to… learn some stuff?
This time, we embraced the RFI as an efficient way to conduct the first round of a hybrid procurement process. Our RFI was short: 30 questions. The most important question (something we pointed out up front – see page 3, process step #2) was Question 29: “What Procurement Cooperatives are available for this purchase?” (https://www.urbanaillinois.us/sites/default/files/attachments/City%20of%20Urbana%20-%20RFI%202223-23%20Network%20Detection%20and%20Response.pdf)
It’s not that we didn’t consider entrants who had no Co-Op vehicles. We read them but didn’t meet with them. We only met for discussions with the ones who sounded good and were available through a cooperative, which were 5 out of 10 of the responses. If we hadn’t found a partner with one of them, our RFI informed vendors that our Plan B was to use the RFI findings to conduct an RFP. (That was process step 5, as noted on page 2. Remember: ALWAYS Have a Plan B.)
When we met with the vendors, we gave each of them the same questions and agenda for an online meeting – just as we would do for an RFP. We wanted a demonstration of the product and answers to our questions. In addition, we told them to ask for any information they’d need for final pricing; details we omitted from the RFI because it’s bad practice to clearly describe your network in a public document. (Note #3)
Coming out of that process, we had two finalists. One of the two we’d heard of before the process began and one we had not. The well-known one is widely used and has an impressive support operation. The unknown vendor is much smaller (the CTO did the demonstration personally) and has less of a track record, but they were 34% cheaper (over a 3 year time frame) and offered a free proof-of-concept trial. So we decided to try the proof-of-concept. We ran it for 30 days, liked the results, and decided to buy. (Note #4)
The final step was to complete the purchase through the Co-Op. This was slightly trickier than expected because a reseller was involved. So… we had to stop and get more paperwork about the reseller, but after a slight delay it all worked out.
Final Thoughts
Our use of a reseller’s Co-Op agreement leads me back to the central fault of Co-Ops: they can be an easy way to buy goods and services that bypasses the vetting of solutions you get from a solicitation process. The use of reseller agreements makes this even worse - see Note #2. Let’s be honest: there will be lots of people who use Co-Ops as an easy way to bypass a procurement solicitation and buy what they want. With government technology purchases, that means wasted money, poorly-scoped projects, or people buying a tool for the wrong reasons – like seeing a whiz-bang demo at a conference. Although there is some good news if you worry about vendors over-pricing solutions: the Co-Ops generally set minimum discounts. Buyers might be oversold on a solution (buying more than they need) but not on a cost-per-item level.
More importantly, our positive experience from combining the RFI and Co-Ops shows a nice hybrid approach that combines efficiency and diligence - and I wrote this post to share that idea. Using the RFI as a quick way to gather options led us to a Co-Op purchase based on an objective review of the market.
I hope this is useful for anyone in government who buys things (and non-things!) - not just IT people. Cooperatives have all kinds of items and services. It’s a wonderful tool, but like any tool (“A.I. - I'm looking in your direction...” – Note #5) the key is in how you wield it.
Notes
Note #1: A few reasons to justify my statement that the vendor matters for an NDR. First, the detection part of the process “learns” what normal is by watching your network. You want good logic that minimizes false positives, but alerts you to important problems. Human support is important, too: alerts are raised to a service desk for analysis, so the quality of the experts is part of the solution. Finally, there’s a hands-on component where we can access and query the information logged, so the quality of the user experience for these views is important.
Note #2: This is a depressingly predictable outcome of the Co-Ops. Resellers now have awards from the Co-Ops that allow them to offer many third-party solutions, which can now be nominally bought through a Co-Op. With so many solutions available through Co-Ops now, we’ve created a complete work-around to normal procurement. I’m certain that this is the beginning of the end and it will only be a matter of time until 1) everything is available for purchase this way and 2) someone realizes what’s going on and closes the loophole.
Note #3: Asking for two rounds of pricing is something I learned from the telephone system procurement. Iterative pricing helps in two ways. Most importantly, vendors tend to make assumptions in initial pricing that keep prices low… but those assumptions might under-scope the actual solution. Clarifying needs and buying the right amount of services for them avoids nasty issues later in the project when the contract’s money runs out but scope isn’t fully addressed. Another benefit of iterative pricing: vendors might further discount their pricing once they know they’re in a competitive final process. The goal is to wind up with the most accurate (but discounted) price possible.
Note #4: Proof-of-concepts are a nice idea, but they don’t work for most business systems because the challenge with software is the implementation: there’s a learning curve, setup takes time, configuration decisions are needed, etc. The NDR was different: a piece of network hardware that came pre-configured and was mostly plug & play. Returning it only required unplugging and re-packing it in the box, which I kept in my office as a daily reminder to see how we liked it. The proof-of-concept also included only six installs of the endpoint software, which would be easy to remove. As usual, I made myself one of the initial test cases by putting one of the six agents on my machine. I’ve learned that my super-power is to break technology. If I don’t have problems with new tech then I feel good that we can roll it out to our users. (And I didn’t have issues!)
Note #5: Here are my thoughts about A.I. It is a tool and an exciting one - for example, I used A.I. to generate the picture at the top of this post. That’s a revolutionary capability and I consider it indistinguishable from magic (Clarke’s third law).
I do have concerns though – with how people will use A.I.
People are often the problem with technology – it’s how they use it. For example: software code is a tool… and some people use it to write malware. A.I. will have unimaginable opportunities for people to abuse it. I don't fear the tool; I fear what people will use it for.
Two more points:
Please do NOT apply my A.I. commentary to the idea that “Guns don’t kill people; people kill people”. I disagree with that statement; guns are a tool to kill things – that’s their purpose. A.I. is not like that; the tool can be used for both good purposes and bad.
As to the “I’m looking in your direction…” phrasing – it's one of my favorite Simpson’s references. I've used and commented on this before - see the note here that starts “7:20” This...I like!