Update: A Procurement Coup

on
Photo Credit - https://commons.wikimedia.org/wiki/File:Old_telephones_in_HDR_(7613799796).jpg - Jimmy McIntyre

Mostly my posts focus on problems. This one is a success story!

*********************************************************************

Disclaimer: 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.

*********************************************************************

I’ve written at length about the challenges of buying Government IT solutions (Tectonic Speed: Part 1) and about the difficulty of writing IT specifications (My Jerry Maguire Moment). The fundamental issue is that IT purchases are ensnared by processes written for copier paper and printer maintenance. The convoluted process is described in Note #1 - notes are below.

But there is an alternative. Our City is a member of several Purchasing Cooperatives. With that membership, I can simply contact a vendor who has an award from the Cooperative, get a price, and buy something – without conducting a procurement. No fuss, no muss, and minimal paperwork! Here is one Cooperative’s “How it Works” page: https://www.sourcewell-mn.gov/Cooperative-Purchasing/how-it-works.

As I wrote previously (see Suggestion #1 here), this feels like cheating - and it does lead to some negative outcomes.   

  • Without writing specifications, how do you know what you need? Poorly scoped purchases can overlook necessary features, causing issues later. At best, you will find those issues in the middle of the project, risking delays and cost increases. At worst, you’ll find those problems after go-live, and be stuck with an unsatisfactory result. 
  • How do we know that the vendor chosen by the Cooperative is really a good solution? When I dug into the details on a few of them, I didn’t see a good set of Specifications – only vague statements. (Note #2)  
  • Over the long run, if a limited number of vendors are available through the Cooperative, then they consolidate their dominance and prevent new entrants to the field. (Note #3) 
  • Cooperatives enable a backwards Procurement process, where people first decide what solution they want – and then go through a perfunctory process to buy it.  As I described in my post about sales communication, sales processes create a push to spend money on solutions that might not be needed. Spending should occur based on needs, not a good demo.

So, neither solution is ideal: full procurements are hard and time-consuming, but Cooperatives risk buying a solution that won’t meet your needs.

COVID-19 Makes a Call

When the pandemic hit, our aging telephone system went from being an annoyance to a liability. The best we could offer our employees working from home was to forward all calls to an outside phone number. However, forwarded calls had no caller ID; all you saw was that it was forwarded from your desk phone. Worse, some work-from-home employees had to use personal phones to initiate phone calls on behalf of the City, raising issues of privacy and propriety. (Some employees had City-issued mobile phones, but many did not.)  

We needed a new phone system, but that’s a purchase of more than $100,00 when you consider that we’re buying 150 handsets and monthly service for a five-year contract. That's 10 times as much as the dollar limit requiring an RFP by our policies. (Yes, our threshold to require an RFP is $10,000... many of my peers can spend several times that before they are required to do the same!) 

Previously, I’d attempted - and shelved - writing an RFP for a phone system. Not being an expert in telephones, I had to synthesize information from others – so my Specifications went on for dozens of pages (Note #4). It was a mess, even though I’d spent many weeks of personal effort on the document. I had bogged down in the Messy Middle (Note #5) of writing the RFP and so I had to put it aside when other efforts demanded my time.

But the pandemic changed priorities. A phone system was urgent, and an RFP would take months.  At that point, I remembered our Cooperatives. A little research uncovered that yes, we could buy a phone system from a Purchasing Cooperative! In fact, more than one of the Cooperatives we belong to have options – we could CHOOSE from different systems!!!    

Here is the key point: because I could buy one of several systems without an RFP, I was free to investigate the options without the formality of an official procurement process. (Note #6)  And so...

The Hybrid Procurement Process

I decided to use the best feature of the RFP (scope analysis) and combine it with the simplified Cooperative purchasing process  

To start, I took my last version of the specifications I’d written and started cutting. First, I cut specifications for basic functionality that we could simply assume existed in a phone solution. (This isn’t related to Cooperative purchasing, it’s just something I’ve started doing when I write specifications, to keep them short and focused on the idiosyncratic needs.) Then I asked questions requiring long-form answers on the 20% of our needs that would require 80% of the effort, like the public-use phone in our lobby that shouldn't be able to make long-distance calls and our phones that connect to the 911 Center without dialing. 

Then I sent my streamlined set of specifications to three vendors with telephone system awards from Cooperatives we've joined. I asked the vendors to send me pricing and specification responses and I encouraged short documents, without boilerplate bloat. I gave them a few weeks to respond, emphasizing the shortened process. 

Simplifying the specifications was refreshing, but even better was the next phase. Once I received “pricing documents” from each vendor, I sent individualized responses to each one asking for clarifications and digging into their pricing. In some cases, we had Zoom calls to discuss the specifications and responses. 

This interactive procurement process was the best outcome, because the second round of pricing was extremely focused and accurate.   Doing something similar in an RFP would have required me to send the same list of questions to all vendors and transact a second round of pricing refinement by group email.  So the procurement was faster, and more effective, with less time invested. I had only three proposals to review, all of which were focused and appropriate – a normal RFP could have received several times that many proposals. 

After two rounds of pricing, we created a scoring matrix of the solutions and I felt reasonably confident that we addressed most our needs. (There will still be issues – see Note #5 – but that’s just part of the process.)

Final Thoughts  

The process wasn’t all sunshine and lollipops. The contracting and rollout phases of the project dragged on, mostly due to competing priorities. For example: I purposefully delayed signing a contract until we were ready for infrastructure upgrades, because once we signed we began paying monthly fees. (The biggest rollout issue we faced was the need to upgrade network switches and run network cables to many locations that didn’t have them before. That’s been harder to organize and perform during a pandemic.) 

Ultimately, the hybrid procurement process was a major success: 

  1. A “skinny” version of our specifications was sufficient.    That saved valuable time.
  2. Actually talking to the vendors during the process was very useful to better understand their proposal and for them to understand our idiosyncrasies, which were more idiosyncratic then they realized at first.
  3. I saved effort when I bypassed some of the more time-consuming and outdated aspects of the RFP process, like reading lengthy proposals full of boilerplate text. (Not that some of the vendors didn’t send me lots of boilerplate to read anyway…) 
  4. Ultimately, the pricing I received was quite good. The Cooperatives’ RFP processes creates a “ceiling” for pricing, but the awards from Cooperatives often allow for additional discounting. Two iterations of pricing led to a satisfactory outcome for our City taxpayers. 

Notes

Note #1: Let’s say we want to license software to host an open data portal. Pretend the software is $8,000 per year, and we want to sign a contract of at least three years because it’s a pain to switch after you set up the site and configure the data loading. Our procurement rules consider that a $24,000 purchase – so I need to do all of the following steps to conduct a Request for Proposals (RFP): 

  1. Write specifications and merge those into the RFP boilerplate 
  2. Post the template on our website. 
  3. Run an ad in the local newspaper (seriously… don’t even get me started on this step) 
  4. Answer questions and publish addenda 
  5. Read the responses, which are written with as much boilerplate as our RFP was 
  6. Conduct demonstrations 
  7. Call references 
  8. Notify with an intent to award and begin contract negotiations.

Note #2: Using the type of software I know best (Administration systems) here’s the RFP they issued. https://www.sourcewell-mn.gov/sites/default/files/2020-10-28/RFP%20and%20Addendums-090320-Public%20Admin.%20Software.pdf  It was originally 12 pages (this version has the Q&A for 14 more pages…) and the very first vendor question in the Q&A speaks volumes about the lack of detail: “What type of software solutions is Sourcewell looking for as part of this RFP?” You can find the specifications on pages 3-5.   

Note #3: As customers, we appreciate new entrants to challenge dominant players. New entrants can be cheaper (they’re seeking clients), we (as early customers) can have more influence their product, and new solutions can leapfrog technology advances while older solutions lumber along slowed down by the need to support legacy functionality. For example: I’m writing this on Microsoft’s OneDrive right now, which wouldn’t exist without Google Drive doing it first.   

Note #4: Phones are more complicated than you realize! First, there are all kinds of ways to deliver a phone signal to the phone: PBX, VoIP, POTS - with the last of these being a wonderful acronym for “Plain Old Telephone Service.” Then there is an array of devices you can use for a call, including apps you run on a mobile phone or software for a computer that doesn’t require a physical phone at all. Then there is setup: there are many behaviors you can program to handle call routing (ring groups, call queues, phone trees, etc.) Finally, and most financially relevant, do you want to buy and maintain an on-premise phone system or rent and outsource maintenance for a hosted system?  

Note #5: The “Messy Middle” is what I call the phase of a project when what looked simple at the start gets more complex as you uncover new issues that you didn’t know at the beginning. During the Messy Middle, uncovering issues makes the project lose momentum; you feel like you’re bogging down or even going backwards. However, this is a necessary stage – and a sign of progress! We all underestimate projects at the start, due to ignorance, over-confidence, or both. The Messy Middle is a required step – every project has complexities that you must work through, so the sooner you uncover them the better. At some point, the middle gets less messy and things start to coalesce towards a solution.   I spoke about this in my talk on “Getting to No” – start the speech here for more on just this topic: https://youtu.be/PVzJArhf1go?t=510  

Note #6: The barriers to communication with vendors is the most frustrating part of the formal process. It has its basis in a good idea: you don’t want to favor any vendor over another, so all communication should be equal. This leads to the Q&A process mentioned in Note #2 – vendors submit written questions and we respond to them to all vendors. But it’s not good for communication in the reverse direction, when we have questions to ask of the vendors.