What Best Practices in Software Procurement Do You See?

Home Forums Acquisitions What Best Practices in Software Procurement Do You See?

This topic contains 15 replies, has 7 voices, and was last updated by  Angel Delgado 8 years, 2 months ago.

  • Author
    Posts
  • #150446

    Kevin Curry
    Participant

    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.

  • #150476

    Angel Delgado
    Participant

    My #1 rule!!! Consolidation of procurement actions will lead to better pricing…. Most manufacturers will negotiate their agreements to meet your needs.

  • #150474

    Steve Ressler
    Keymaster

    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

  • #150472

    Kevin Curry
    Participant

    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.

  • #150470

    Angel Delgado
    Participant

    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.

  • #150468

    Kevin Curry
    Participant

    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.

  • #150466

    Kevin Curry
    Participant

    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.

  • #150464

    Steve Ressler
    Keymaster

    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)

  • #150462

    Jaime Gracia
    Participant

    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.

  • #150460

    Julie Chase
    Participant

    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.

  • #150458

    Kevin Curry
    Participant

    +1 OMB 25 Point IT Reform Plan. It’s flawed but net gain.

  • #150456

    Logan Kleier
    Participant

    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.

  • #150454

    Ron Falcone
    Participant

    Does anyone know the effectiveness of the GSA SmartBuy program — they tout the ability to obtain lower prices via pre-negotiated contracts with more favorable T&C’s. GSA also touts that its program promotes standardization and best practices for software purchases especially involving cyber security. Anyone have any insight into this?

  • #150452

    Kevin Curry
    Participant

    Great question Ron. I’d like to see some responses here.

  • #150450

    Kevin Curry
    Participant

    Logan, these are helpful answers. The basis behind a mandatory cooperative purchasing agreement seems full of common sense. It’s a “write once, use many” constructive outcome. As you hint, though, it’s not just awareness, but willingness. Purchasers find reasons not to use contract vehicles that are available to them. It might be some other rule in the contract vehicle. It may often be a perceived or actual requirement. On the software side, I wonder if we don’t make further progress when we choose or require open source software. This leaves the door open to customization of an off-the-shelf product when it is needed and takes away a reason not to go with a best practices for purchasing. As for RFPs, I hesitate to even get started on the topic of “indefinite deliver, indefinite quantity” (IDIQ) contracts. In the fed space, companies are able to get in midstream, but only at the subcontractor level. These so-called “license to hunt” contracts are supposed to qualify a short list of tier one, prime contractors. I cynically suspect the purpose of this is to set up an industry bureaucracy that is capable of handling the government bureaucracy. It’s less about the companies and the tech and more about the plumbing between the gov & industry for multi-year engagements. New companies get to the IDIQ midstream by partnering with a prime contractor. This may be different at the local, state, and federal levels. You also seem to be speaking of software and hardware while I am thinking of services. But I don’t think the principles are terribly different. To sum up, 1) we can make governments, contracts officers, and purchaser more aware of mandatory cooperative purchasing agreement clauses. 2) We might be able to lessen resistance to using blanket purchasing agreements for off-the-shelf if we use open source. 3) For multi-year agreements we should allow for new providers to be included after the first year.

  • #150448

    Kevin Curry
    Participant

    Actually, +1 to all of this.

You must be logged in to reply to this topic.