What Best Practices in Software Procurement Do You See?
There's been plenty said and written about what's wrong with government acquisition and procurement in the IT space. Yet people still seek positive alternatives as if they do not exist. Is the "app store" model the way to go? What about things that aren't apps, like enterprise software? Should we treat them separately and differently in the procurement process? What about contracted professional services? How should we handle situations where agencies have a technical requirement to build a thing and a contractual requirement to have all things built in an approved way by approved companies via an approved contract vehicle? We know about the problems. Stop complaining about them. How do we fix them?
Let's talk about best practices for buying software and professional services. Share yours here.
Tags: acquisition, best practices, fix it, tech
Replies to This Discussion
-
Permalink Reply by Angel Delgado on -
My #1 rule!!! Consolidation of procurement actions will lead to better pricing.... Most manufacturers will negotiate their agreements to meet your needs.
-
Permalink Reply by Kevin Curry on -
Angel. I'm intrigued. Will you please elaborate on what you mean by consolidation of procurement actions? I have a sense, but it could be wrong.
-
Permalink Reply by Angel Delgado on
-
For example...Oracle may have different softwares running under a specific agency "application / systems". Consolidating procurement packages for uprades, maintenance agreements, of sort for different products...e.g.(eBusiness suites, Agile lifecycle mgmt, Crystal Ball, Primavera Fusion, Database, etc.) may bring cost savings to the customer and assurance of continued business to the manufacturer.
-
Permalink Reply by Kevin Curry on
-
Aaahhh, yes. Now I understand. At one point Joint Forces Command had several thousand separate licenses for the same product, all with separate maintenance contracts.
-
Permalink Reply by GovLoop on -
To me there's a couple key areas for good software procurement:
-Know your requirements (at the right level of detail) - I often saw software procurements that were either too in the weeds with requirements (needs this one tab in top left that is yellow)...or too vague - we need ERP. I think you need to know what you need requirements wise and then be flexible about what you really need and what can be worked around
-Market research - Spend some time figuring out the landscape of options. For any problem, there are a range of software options and some are better suited than others. Also there are high/low cost options with various pros/cons. Make sure you understand the market and ensure that vendors have awareness when you have a RFP-
-
Permalink Reply by Kevin Curry on
-
Steve, I agree 100% with market research. The first instinct anyone should have to look for what has worked where. Too often government thinks it is looking for something new, when it isn't, or has a new problem, when it doesn't. I think we can do a lot to help with market research, too, as a community of practice. Better "apps" stores will help. Better product wikis, tools like Civic Commons Marketplace (disclosure: a Code for America project), along with means for government to express challenges to which the community can respond, ex., SIMPL. A recommender system would help "govvies who looked at/bought this prodcut also looked at X, Y, Z..."
I'm not sure I agree that "we need an ERP is too vague." It's only too vague if there isn't a competitive market for the product or if ERP is actually the wrong solution to the perceived problem. I think a competitive market now requires open source vendors, too, because no off-the-shelf solution is ever perfect for your needs. If you have the need ability to hack the product then you should be able to. What gov should not have to do is start from square one with a new RFP to reinvent an entire wheel just because the valve cap is the wrong color. That's what they do now.
-
Permalink Reply by GovLoop on
-
Valid point. Maybe ERP wasn't the best example but I think there are some times when the requirements are so vague the question becomes do you want a bike, car, or monster truck. And it's important to put some clarification on it.
I agree with Angel's part as well. Often in large organizations we have enterprise licenses for large packages like Microsoft or Oracle and what we want is actually already purchased under another agreement (we just aren't coordinated internally)
-
Permalink Reply by Jaime Gracia on -
One initiative that @Angel is referring to is strategic sourcing, since the government can leverage its buying power through consolidation of requirements to get volume discounts.
Effective market research is one of the fundamental tools in regards to software. Certainly purchases are commoditized, so there are plenty of contract vehicle options to purchase. Creating yet another BPA/IDIQ, etc. is really inexcusable at this point, as the proliferation of unaccounted for MACs dilute the ability to get better pricing through consolidation (e.g. strategic sourcing).
Software development should also be done in a FFP environment, using Agile methodologies to implement capability more quickly to the end user. This goes to the OMB 25-Point IT Reform Plan. Let's use commercially proven methodologies to acquire and implement technologies faster, cheaper, and of better quality and capability.
-
Permalink Reply by Kevin Curry on
-
+1 OMB 25 Point IT Reform Plan. It's flawed but net gain.
-
Permalink Reply by Kevin Curry on
-
Actually, +1 to all of this.
-
Permalink Reply by Julie Chase on -
Kevin, the reality, is, it is not going to change until someone forces the change. How can you be positive about innovation and positive alternatives, when the DoD is hiding behind a tree? We "had" thumbdrives. They were great! Stored alot of data that our contractor NMCI does not provide. Well, turns out the thumbdrives were, are loaded with malware made in a country we are not friendly with........bye bye thumbdrives. Our legacy shared drive would get so full that our IT folks would send out an email telling everyone to clean it up or it will crash. Yes, the entire base SHARES a legacy drive, which can crash at any minute.The "solution" was for EACH organization procure an "approved" external hard drive with proper justificaiton. I have purchased 6 at about $200.00 each....and let me tell you the "process" is unreal. The hoops you have to jump through and it has to come out of the individuals organization budget. If we don't have the money, you don't get one.Then it has to be sent to the IT folks to put some type of "security" on it. So now throughout DoD and military installations there are little black TB external hard drives clogging desk space. Wow...one step back for the home team.
Kevin, I just don't see it happening anytime soon. I can't give you a best practice, because there isn't one. I follow whatever comes down from on high no matter how conveluted, complicated, time consuming, waste of time and money it is. We will just keep buying external hard drives and buying software one piece at a time as budget allows, and hope we can afford the "updates" for the software in the coming year. Keep in mind other installations "mirror" what we do and they are hitting the "exact" same brick walls. And they are buying exactly the same individual software packages and individual external hard drives.
-
Permalink Reply by Logan Kleier on -
Based on my experiences at the City of Portland, it seems there are a couple of things that should be best practices:
1) Mandatory Cooperative Purchasing Agreement Clauses- All contracts that governments sign should have clauses that allow any other government agency to buy off that same contract. It's amazing how many government entities don't do this.
Of course, awareness is another issue. Government entities have to have a centralized and well publicized place that they can find out who is buying what. The City didn't even put cooperative purchasing language in our standard contracts until 3 years ago. Ultimately this could mean that governments should stop buying technology on a organization by organization basis and start buying through a consortium. I know that many government entities want to believe that they have unique requirements for every other government entity, but that's usually not true.
2) "Flexible Goods" RFPs- We should have a way to buy any general type of software/hardware etc. as long as it meets certain functional requirements. This should also have some kind of rolling admission where if fail to apply during the initial RFP phase, that you're not locked out for a multi-year period. Companies should be able to get into the qualified vendor pool mid stream.
Tools & Resources
© 2012 Created by GovLoop.
