Skip to main content

My Jerry Maguire Moment

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?”
Thoughts? Additions? How do YOU think we can improve this process?

Popular posts from this blog

The Tectonic Speed of Government, Part 1: Procurement

This post is my reaction to conversations about how hard it is to create change in government, and how government projects (and IT projects in particular) take so long from genesis to completion. This is part 1, about procurement; part 2 will address project implementations. PS - there was a surprise Part 3 of this series later!

Warning: what follows is an “inside baseball” discussion of government IT procurement. I’m not trying to dissuade you from reading it, but if you’re not enmeshed in this world you might want to consider reading my articles on lighter topics like organizing your electronic life, the greatness of Abbey Road, or the story behind The Room.

If you ARE enmeshed in this topic, then please don’t overlook my call to action at the end! Changing the process will take a group effort, and I’m hoping to get feedback on my scheme to create a library of reusable software specifications.

By the way, this post’s first title was “The Glacial Speed of Government” but that title i…

How To Videos: Lucity Queries with Microsoft SQL Server and Excel

What follows is not a blog, but some suggestions on using Microsoft SQL Server "Views" to query your Lucity data using Excel.   This information is intended to assist Lucity software users, and not for any nefarious purposes.

I recommend watching the videos in Full Screen view and with HD resolution.  They're not as blurry as they look on this page!!  Each of these about two minutes long, but the original actions only took 50 seconds each.  (After recording them, I decided to slow them down to make them more watchable.)
1. How to create a SQL Server "View".  The video shows how to create a new View from the core Work Order table.  (WKORDER - see the data dictionary here.)  The video first shows the simple method of creating a view with all fields, then shows the more effective method of including only needed fields, and re-labeling them with their on-screen names.

Music: "A View to a Kill" - Duran Duran


2. How to Connect to the View with ExcelWith a view …

Why the Tectonic Speed of Government?

The original name was "The Glacial Speed of Government” but that title is both cliché and inaccurate, as today it implies a faster pace than it used to. I decided that “Tectonic Speed” is more accurate because you can push very hard, but change in government shows tremendous resistance.  However, when change happens it can occur in significant outbursts - and in those moments, there is great opportunity!

Part 1Part 2  |  Part 3  | Part 4 | Wait there's a Video?!

The Tectonic Speed of Government, Part 3: It’s Never Over

Recently, I wrote two posts discussing why IT Projects take a long time: one on the Procurement Process and one about Project Implementations.  They were written during a time of three simultaneous projects, and they were therapy for me to exorcise some complaints... and make suggestions for others. From the start, I planned those as two topics – and I thought they'd finish the series.

But this third part was a surprise, and the greatest lesson I learned from those projects.
*********************************************************************************************
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.
*********************************************************************************************
“It ain’t over till it’s over” - Yogi Berra on baseball, not IT projects.Trick Question: When is a software project over?

Answer: Never. 

By “over” I mean the soft…

Tectonic Speed of Government, Part 2: Why do Government IT Projects Take So Long?

This is part two of my series on why government IT projects take so long. Part one complained that the Purchasing process is tough to navigate because methodically describing what you want to buy - and documenting your decision making - takes effort. That blog helped me vent some frustrations about parts of my job, although I admit that it was a little dry. (But please, this is Government Procurement.)

With part two I’m on my home turf: the process that starts with the purchase of an IT tool and ends with its everyday use by people. If the process was successful, users are doing their jobs better than they did before. (A less successful outcome that also occurs: it’s harder to do their jobs, but at least their managers have better data.) This process, which I’ll refer to as the “Implementation” or “Project,” can take months or years for any organization - let alone a government.My first section explains why government IT projects take a long time, while the other three suggest str…