My Jerry Maguire Moment

on
Courtesy Sony Pictures

Show Me the Functional Specifications!

The challenge of creating RFP specifications for computer systems that are clear and useful.

 *******************************************************************
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.
*******************************************************************

For the first twenty years of my career I was a consultant who worked on public sector software projects, and for most of those years one of the tasks I did a lot was respond to checklists of functional requirements from RFPs (Requests for Proposals). I read scores of checklists, answered thousands of individual requirements, and performed hundreds of hours of software demonstrations trying to address them in a real-time environment.

 From this experience, I want to say that the current model for government software procurement is bad for everyone, especially for the governments doing the buying.

 I had a fantasy that the end of my software sales career would include a Jerry Maguire moment: I would publish my insider’s account on the flaws of the public sector IT procurement process, and suggest a radical alternative.

 Well, I missed that window. It’s been 14 months since I left the private sector, and I’m just now starting to write. The good news is that now that I’m a City IT Director, I have experience on the other side of the fence. From this side, I can see that a drastic break from the current RFP process is unlikely. But, even if we can’t redo the whole methodology, at least we can enhance it, right?
 
So here’s part 1 of what might be an ongoing series on improving the software procurement (and implementation) process. This guidance is directed at governments, but it could be useful far beyond that, too. (I did later write a Part 2, on software demonstrations: https://blog.tectonicspeed.com/2015/10/lets-make-software-demos-meaningful.html

Guidelines for writing functional requirements.

My “Jerry Maguire” proposal was going to be to scrap functional requirements altogether. NO ONE can completely identify their system needs as a series of discrete statements. And I guarantee you that no vendor can read that list of statements and know exactly what you need. Worst of all - on almost every software implementation I worked on, the functional requirements were chucked aside on day one and a new requirements analysis began. So the whole exercise is, if not a waste of time, at least a very inefficient way to pick a solution.

 However, I have mellowed a bit… and I grudgingly admit that there is some value in functional requirements. They provide an objective method to score systems, and they set a benchmark that you can use to determine if the software is ready to go live.

 So if we’re going to have them, let’s at least make them good. Here are some guidelines.

 Don’t start with a blank piece of paper; leverage the work of your many peers who have done this already. Recently, I helped our Public Works department write a checklist for a work order system. Since they lack any system now, they didn't know what they wanted, and we couldn't afford consultants (to sell us a pre-written list), so we had to do it quick and dirty. Here was what I did:
  1. Searched the web for other checklists of the same type. There are dozens out there of any common system.
  2. Skimmed a few to find ones I thought were well-written (see the other criteria, below)
  3. Copied and pasted the requirements into a common Word document and (this is important!) assigned functional areas to them.
  4. Sat down with our users and showed them the requirements, grouped by area. We kept (and tweaked) ones we liked, got rid of unneeded ones, and used them as a starting point to add ones that we felt were missing.
  5. Revised, edited, and groomed what was left into our own checklist.
But don’t simply copy someone’s or use a consultant’s checklist “as is.” Note that in the scenario above we used the other lists as a launching point for discussions, not as the final answer. When I responded to checklists, we could tell which RFPs were written by specific consultants because the requirements were exactly the same each time.

 Never depend on someone else to tell you what you want. The worst possible scenario is when the RFP consultant is gone and no one knows what the checklist requirement means! I've seen that happen during the RFP process, at the RFP demo, and (especially) once the implementation begins.

 When writing checklists, don’t try to be exhaustive. In fact, err on the other side and keep them open-ended. I've seen many checklists attempt to list every field that should be on the screen. For example, in Accounts Payable requirements, successive items ask for Vendor’s Name, Vendor’s TIN, Vendor Address (field by field!), etc. This is a waste of effort. You’ll have too many requirements, you’ll probably skip fields you forgot about, and what financial system DOESN'T have Vendor’s Name, TIN, and address?

 So, my suggestion is don’t even try to go to that level of detail. Instead focus on the business needs. For example, instead of listing mailing address and contact address fields, just say, “System captures contact addresses for a vendor separately from the payment address.”

 Or if you do want to ask about fields, focus on what’s important. Ask about only unusual fields, or just say “List the fields you capture on a vendor record.” Or ask proposals to tell you the field lengths for specific codes. (And are they expandable?) Or ask what their method is for adding new fields to a screen – and how you keep them during an upgrade.

 At the extreme side of open questions, don’t hesitate to ask questions that require a full text answer. Instead of asking “Ability to identify minority-owned vendors”, “Ability to identify local vendors”, etc, just skip that and say “We want to be able to identify vendors that are minority-owned, veteran-owned, local, and/or women-owned. The list of demographics could change, also. What method do you have to record the demographics on a vendor, and how can we change it in the future?”

 Another example: data entry is a very important part of systems use. On our Work Order checklist we simply asked “Users must manually create Work Orders. What data entry tools do you have to simplify Work Order creation and maintenance?”

 As an RFP responder, I actually relished a question like that – it was a chance to pitch what differentiated us. And if a proposal response comes in and they say very little, well… doesn't that tell you something about them as a vendor?

Finally, some advice on phrasing requirements.

Sorry to burst your bubble, but the RFP process is something that vendors (and purchasers!) try to game. For example, vendors will go through every twist and turn they can to say “yes” to a requirement. Your best approach is to make them clear and concise, so a “Yes” is unambiguous.
 
Don’t give the vendor any room to weasel out. For example, do NOT use the phrase “Ability to”. (I use this purposefully in my bad requirements throughout this post) As a vendor, I loved this phrasing because as long as I can come up with even a convoluted manual work-around, I could say “YES”. Don’t give vendors that easy escape – use active verbs (#3 below) or open-ended questions instead.
  • Bad: System has the ability to track Tax Increment Financing (TIF) districts.
  • Better: System links the work order to a Tax Increment Financing (TIF) district.
  • Best: How do your clients track Tax Increment Financing (TIF) districts in the software?
Keep in mind Boolean logic; the words “OR” vs. “AND” matter! If you used the word “or” in a list, then (as a responder) I would apply Boolean logic - and if I can meet ANY item in that list I’m answering “Yes”.
  • Bad: Multiple bonds can be applied to a single work order, project, or development.
  • Better: Three separate checklist items… "Multiple bonds can be recorded for a single work order.", "Multiple bonds can be recorded for a single project.", etc.
In general, apply the good writing principle of using active verbs. It clarifies that the system should be doing these things, as opposed to someone manually doing them. For example, a vendor could definitely answer YES to the "Bad" requirement below, even if their solution requires the entry staff to remember to manually route the purchase order. (It says "Ability to...")
  • Bad: "Ability to route a purchase order for approval based on commodity."
  • Better: "System sends purchase orders for approval automatically, from pre-defined rules based on the commodity purchased."
Focus on the business outcomes and not HOW it’s achieved. Every solution is going to be a little different. If you describe the “how”, then you’ll inevitably ask for it in terms of what you know, such as your current system or a specific system you've used before. You might not ask for enough – or you might ask for more specifics than you need. Examples:
  • Bad: “Users must have a screen where they can query Accounting entries by vendor, minor object, dollar amount, and date.”
  • Good: “Users can query accounting entries with any of the field values on the record”
  • Bad: “Work Orders must be numbered as the two digit year + two digit division code + 4 digit sequential number.”
  • Good: “Work Orders can be automatically numbered using prefixes that will be defined during implementation.”
  • Better: “What features do you have to assign numbers to Work Orders?”