A group who shares ideas and experiences employing innovative acquisition practices, collaborative methods and use of Web2.0 technologies to transform federal acquisition.
Collaborative Software Selection Methodology
July 16, 2009 at 7:43 pm #75905
My name is Jay Nath and I’m the Manager of Innovation in the City & County of San Francisco. In my brief time here, I’ve noticed how software (or any capital expense) is often procured without rigor or standardization. My last experience left me wondering how can we do this better. So we experimented with a collaborative approach using Web 2.0 tools to assist in the process. The other aspect that I wanted to improve was giving open source software equal footing with close source. You can see that in the process below as well.
Our reasoning for making software selection transparent and collaborative was based on the premise that more heads are better than one/few. We think it helps minimize the impact of a person with crazy requirements or someone who rates every requirement as a must have.
Here is a summary of the process but I have a wiki posting on GovLoop for the detailed process.
1. Gather requirements (through interviews documented in a wiki)
2. Select software candidates (criteria based and conference call)
3. Establish weighting (through a survey)
4. Score/evaluate candidates (web conference)
5. Determine Total Cost of Ownership (TCO) (standardized and completed by vendor)
6. Publish recommendation report (email and conference call)
This process worked well for us and we’re going to run it through a few more before we consider moving forward.
With that said, what can we do better? Or why won’t this work in your organization?
July 17, 2009 at 1:24 pm #75907
Thanks for publishing this! As a former software vendor and now as a confirmed — and realistic — user of web 2.0 approaches, I do have some comments.
I like the idea of a process as long as it is flexible. The process you lay out in the wiki makes sense. I would hope that the way you manage it takes into account the fact that these steps can overlap. People may want to go back and modify what they said — or even decided — previously (up to a point, of course). As people work through the process they learn and, hopefully as they exchange ideas and comments with others, their understanding of the requirements will grow. Whether or not you can collect all this back and forth in a wiki is a question I can’t answer.
Talking with all the stakeholders is good. This is an important step in defining requirements. I would want to make sure that the business or organizational goals that the software has to support are openly discussed or understood. “Goal clarification” may or may not need to be a separate part of requirements definition as that drives what you want the software to do.
As a former software vendor I have had to work through many “requirements checklists” that gave no indication of weighting or relative importance. (I can even recall evaluators coming in to my office to measure the mechanical performance of a mass storage device down to the millisecond even though actual hardware performance contributed only minimally to the overall system performance. But it was on the requirements checklist and it was something that could be unambiguously measured.)
There’s no question in my mind that improved collaboration among stakeholders on the government side in defining requirements is good, assuming you can overcome organizational siloes. The technology you use to accomplish this (wiki, blog, discussion forum, etc) may be secondary to the willingness of people from traditionally separate organizations to communicate. Having a clear goal — such as a specific procurement effort — to drive this cross-departmental collaboration is a big help.
One of the trickiest issues is how and where you engage with the vendor community. Making vendor discussions “transparent,” even in early requirements discussions, can raise significant competitive and confidentiality issues. But I really think it’s important not to limit vendor engagement to trade shows, canned demos, and collecting fact sheets. Many software vendors in recent years have become more open and transparent in how they operate their user and support groups; this would be one way to openly engage with vendors and their customers.
If you’re interested on reading more along these lines, here are some items from my blog:
“How Will U.S. Government Procurement Processes Handle the Stimulus Spending Surge?”
“Can Government Procurement Be Streamlined By Using Collaboration Technologies and Social Media?”
“Using Collaboration Technologies to Accelerate Innovation in Federally Funded R&D Programs”
You must be logged in to reply to this topic.