While there may be an attractive market, selling to the government is a byzantine, frustrating process that puts startups and small businesses without in-house contracting expertise at a disadvantage.
Before you commit to anything, study the processes that govern this space. There are lots of requirements for getting into the system — my company (not a tech startup, FWIW) needed to register for SAM (“The System for Award Management is the Official U.S. Government system that consolidated the capabilities of CCR/FedReg, ORCA, and EPLS”), Fedbizopps, GSA Vendor Support Center (VSC), ACES (the private company which issues a digital certificate), Duns & Bradstreet, etc. Then I had to bone up on general contracting requirements and pass some tests before I could bid … and then discovered individual solicitations have their own requirements, pricing restrictions, vetting processes, and sometimes huge delays (for one that I was interested in, the solicitation said “it may take up to 12 months or longer before an offer is evaluated.”) (1)
I am assuming that the Govtech fund has in-house expertise that can help smooth the way for new companies, but there will almost certainly be complicated processes, time-consuming bureaucratic requirements, and huge delays that cannot be circumvented. My advice would be to ask hard questions about these issues before going down this path.
It's not that hard once you get used to it, and your industry seems to be an exception to the case as what you experienced is not typical in IT. The upside far outweighs the bureaucracy when you land your first $1M+ contract (or you could just subcontract and avoid the bureaucracy altogether). It is, however, a market that requires a lot more commitment than most startups are accustomed to, which is why they try to enter and then give up shortly thereafter. It requires a lot of relationship-building, learning, and such.
I've noticed, however, that military veterans tend to be very successful in this space because they are accustomed to the jargon, the processes and the requirements. Like I said, it's a learning curve, but one that pays huge dividends if you stick with it.
Plus, your local SBA office has a special government-procurement officer in there who will actually sit with you and go over things one-by-one, so no need to ever go it alone if you get lost. They offer free training courses as well in government procurement. The resources exist, but too few people are using them.
Indeed -- and this will be a topic for some follow up posts (if I can actually get the time to write them :) -- much of the govtech innovation is happening today at the municipal level. I would encourage you to start there as there are tens of thousands of potential customers. None of our companies contract, sub-contract, lobby, etc and sales are done directly to the departmental buyer.
The good news is that we're starting to see many of the same industry trends mentioned (eg. adoption of the cloud, new wave of gov't employees/buyers due to retirement cycle, riding the cost curve, etc.) at the State level but that will, in our estimate, take the next 5 years to mimic what we're seeing at the municipal level.
Re: the Federal level, our expectation is that we will see the changes start to appear 5 years from now. I know that's a little depressing but a $400 Billion global spend does not turn on a dime.
All of this to say: the govtech revolution is very real as we see from the performance of our startups but it's happening bottom-up not top-down AND this will be a multi-decade technology replacement cycle (not to mention the govtech transformation globally where time cycles will vary).
Honestly, not to sound like we're overhyping, but the rewiring of government is inevitable. The major tech trends are just too powerful in both the consumer and enterprise spheres to skip government. And frankly, we deserve better.
It's also why we're pretty sure there will be Govtech Fund II, III, IV... :)
Selling to DoD specifically is even more fun. Well depending on who's buying you might get to play fast and loose for a while but eventually you'll get bogged down in certifications.
Also security clearance helps if you have to send people onsite to debug.
Also if you think <insert log aggregation as a service> is slow try doing that over the phone from a secure facility where you can't get logs sent to you, just have someone read them to you.
Oh and you get to use Python 2.4 and RHEL 5 a lot if you work on Linux.
Yeah startup people would run for the hills.
However once you break through and get your devices listed on approved list of devices, you can fun overpricing the crap out of your services: https://aplits.disa.mil/processAPList.action (kind of like going to medical school -- pay lots of money upfront, then extract later through overpriced products and services).
Even after you get in the process doesn't get any easier. A friend of mine is a CTO of a successful software company in D.C. that specializes in government contracts. However multiple agencies do a separate bidding process for the software development phase and for the UAT/QA phase (waterfall ughh). So often when they land a software project, the QA for that project will typically go to their direct competitor. The QA phase frequently gets billed based on time spent (with allowances for overruns specified), and so it's in the interest of the QA company to spend as much time in the process as possible. As you can imagine, this does not yield a very productive QA process. I.e. JIRA tickets for "The last letter on this form title is too curvy" are not uncommon.
compare that with setting up a stripe account and starting to charge end-users - you can probably go from a standing start to customer-funded cash flow in a day or two, without having to bone up on much of anything.
And this figure only covers government IT procurement...
When you look at how government has traditionally interacted with citizens, it's indistinguishable from a monopoly service market. In the past, this was the only feasible way to deliver many government services. However, the result is the same as any other market monopoly: inefficient production and above welfare maximising pricing (albeit indirectly paid via taxation).
Government Web APIs fundamentally change this, and I'm not just talking about 'open data'. A whole bunch of monopoly markets suddenly become highly competitive markets (especially since digital service production tends to occur at around 0 marginal cost). The value to the economy could be many times the figure discussed in the OPs article. Tim O'Reilly was so far ahead of the times when he published his chapter on 'Government as a Platform' in 2010 (http://chimera.labs.oreilly.com/books/1234000000774/ch02.htm...)
More recently, in Australia they've just set up their own (kinda crappier) version of the UK GDS and published an API design guide. I think the excerpt from this article basically sums it up (http://www.themandarin.com.au/48771-dto-make-creating-apis-m...):
"However despite all these challenges, the cause [government APIs] is a great one and could do more to transform how government IT operates than many more public steps.
If the DTO [Australian GDS] can pull this off, have agencies fall in line and have APIs start rolling off government IT ‘production lines’, it will have single-handedly justified its own existence and transformed how government works, even if it doesn’t achieve anything else in the next few years."
Veterans will dominate in a lot of these contract bids because they have veterans preferences and many get disability points on their contracts, too. The federal employment system heavily favors veterans and oftentimes lowers standards of employment just to bring in more veterans into companies. Then add in that companies can be essentially paid extra for hiring a veteran on certain contracts and you are left with a heavy bias for employees and leadership whose primary experience in organizations is the old school, rigidly hierarchical military.
Trying to work with some of these guys in a start-up setting outside DoD space is no more frustrating than trying to work with a corporate developer that's never had any job besides at IBM their whole lives. It doesn't mean they're bad or unintelligent, but the rigor and emphasis upon certain organizational structures and workflow processes are just plain useless knowledge in a start-up focused upon execution.
There's a lot of cultural horrors that will keep out motivated, smart folks from working with the government. I've spent well over 10 years of my life hoping to be the change that I was recruited for, but it's just not enough to be smart and motivated as much as well connected to incumbents that are fighting very hard against change because their very expensive meals and Mercedes S500s depend upon keeping things as stable as possible. This is the precise opposite mentality of the technology giants in industry.
Firstly, your perception of veterans is woefully wrong and misplaced. Veterans set-asides in contracting actually do very little to help a company as there is still much legwork to be done. Even then, you stereotype veterans as "rigid" which is simply not at all true. I see envy in your post, not facts. Companies are NOT AT ALL "paid more" for having veterans on contracts. Labor rates are the same regardless of the status of the employee. You're facilitating the spread of rumors, stereotypes and hearsay which is why people think badly of this market. Veterans are given preference for hiring, yes, because they have a skillset that too few private sector employers realize unfortunately. There are studies to prove that point.
Secondly, "focusing on execution" and not processes is why so many startups die in a growth stage because it too often means chasing revenue only with few long-term plans. The government is inherently a long-term market. You need to have a long-term view. True, if you're developing a dog-walking app or glorified to-do list, yeah, it's not a market for you. But if you really want to do something game-changing and want to build something of note, I see no better place for it. Look at Palantir for example. There are hundreds of other examples.
Lastly, you can't just sit around waiting for "change", you have to make it happen. I used to be a GS-13 employee, fairly high up at one of these agencies, and I voluntarily left a secure job to make more of a change and I see it happening. It's rewarding, but you have to push for it and take risks or else nothing will ever come of it. I speak from experience actually doing this. How many else here can?
What have you done to try and fix it? Looking in from the outside you can speculate all you want, but maybe do something to work your way inside and see what it is really all about. There you'll see things can change, but you have to be willing to put in the effort, but too few are unfortunately.
About 70% of our revenue comes from the federal government, including cleared work. We specialize in this space and have customers across a half-dozen or more agencies.
The sales cycles can still be pretty long, but mostly for IDIQ's with $30M+ ceilings. We've received small $500k contracts that took over 9 months to award and, on the other hand, $3M+ contracts that took just a month.
A lot depends on the department/agency, and even organizations within the department/agency. It varies so widely but the key is getting to know your customer and anticipating the cycle. Relationships are absolutely crucial to getting government sales - the boilerplate they put out as RFP's hardly ever tell the full story of what the customer needs.
Also, leverage your set-asides and find reputable partners to team with. Can't stress this enough - it's the only way to compete against the behemoths in the market who have far more name recognition amongst contracting officers (who can be extremely risk averse). If the government isn't your target market, you can start winning work as a subcontractor and working your way up the ladder, getting to know your program manager customers who make the purchase decisions.
It's a tough market for a startup. I've worked for state .gov, and probably oversaw about $20M-50M in purchases annually.
Some downsides:
-Our procurement cycles are very long, sometimes as long as a year.
-Procurement contract vehicles are a horror show. The contract terms and conditions are often not negotiable, and may impact your ability to get credit, etc.
-You may find difficult to deal with services terms imposed by some procurement regime.
-If you don't have a field sales force, you'll probably need lobbyists to get meetings.
-You'll need to deal with all manner of crazy compliance regimes. HIPPA, FERPA, IRS 1075, CJIS, etc. Plus local policy.
-If you "partner" with the IBM/Unisys/Dell/EMCs of the world, you may find yourself screwed holding recievables for the big vendor, used as a straw man by the vendor sales team, forced to use high cost/low quality consultants from the big vendor, or otherwise messed with.
On the upside, .gov is usually terrible at negotiations, and they look at spending differently than commercial customers. You can make a fortune selling stuff, but you're not going to do it with traditional SaaS business models. You need to invest substantial time, energy and dollars into the pre-sales process.
There is a reason most banks exclude government receivables from line of credit borrowing bases. It is a legitimate market, but it is hiding in red tape and not plain sight.
That's not true at all and simply more hearsay and rumor. Banks see government receivables as reliably as if you invested in treasury bonds with cash assets. It's the only customer in the world that is 100% guaranteed to pay, on time, as long as you perform to standard. You're speaking to the wrong people if someone told you that. I'm speaking, however, from experience.
I want to build "organizational operating systems" for govts. (incorporating "best practices") using FLOSS ERP software (I've done e-Government research in academia, and I can also code).
People who have experience in this space: is there a market for such a thing or do govts. prefer commercial (i.e. non FLOSS) software systems?
GovWorks was focused on only a small subset of the government market and rode the dot-com boom. I've personally known companies grow from $1M in revenue to over $100M in revenue in a span of only 5 or 6 years in the government space, even in a lousy economy. It's the hype of Silicon Valley that you have to avoid. Government, especially Federal, is a market that is driven by different principles than most others out there, which many startups don't understand before they try to enter it. So they expect immediate returns and just give up. It doesn't work like that.
[+] [-] ilamont|10 years ago|reply
Before you commit to anything, study the processes that govern this space. There are lots of requirements for getting into the system — my company (not a tech startup, FWIW) needed to register for SAM (“The System for Award Management is the Official U.S. Government system that consolidated the capabilities of CCR/FedReg, ORCA, and EPLS”), Fedbizopps, GSA Vendor Support Center (VSC), ACES (the private company which issues a digital certificate), Duns & Bradstreet, etc. Then I had to bone up on general contracting requirements and pass some tests before I could bid … and then discovered individual solicitations have their own requirements, pricing restrictions, vetting processes, and sometimes huge delays (for one that I was interested in, the solicitation said “it may take up to 12 months or longer before an offer is evaluated.”) (1)
I am assuming that the Govtech fund has in-house expertise that can help smooth the way for new companies, but there will almost certainly be complicated processes, time-consuming bureaucratic requirements, and huge delays that cannot be circumvented. My advice would be to ask hard questions about these issues before going down this path.
1. http://in30minutes.com/selling-to-the-federal-governmentgsa-...
[+] [-] USNetizen|10 years ago|reply
I've noticed, however, that military veterans tend to be very successful in this space because they are accustomed to the jargon, the processes and the requirements. Like I said, it's a learning curve, but one that pays huge dividends if you stick with it.
Plus, your local SBA office has a special government-procurement officer in there who will actually sit with you and go over things one-by-one, so no need to ever go it alone if you get lost. They offer free training courses as well in government procurement. The resources exist, but too few people are using them.
[+] [-] RonnieB|10 years ago|reply
The good news is that we're starting to see many of the same industry trends mentioned (eg. adoption of the cloud, new wave of gov't employees/buyers due to retirement cycle, riding the cost curve, etc.) at the State level but that will, in our estimate, take the next 5 years to mimic what we're seeing at the municipal level.
Re: the Federal level, our expectation is that we will see the changes start to appear 5 years from now. I know that's a little depressing but a $400 Billion global spend does not turn on a dime.
All of this to say: the govtech revolution is very real as we see from the performance of our startups but it's happening bottom-up not top-down AND this will be a multi-decade technology replacement cycle (not to mention the govtech transformation globally where time cycles will vary).
Honestly, not to sound like we're overhyping, but the rewiring of government is inevitable. The major tech trends are just too powerful in both the consumer and enterprise spheres to skip government. And frankly, we deserve better.
It's also why we're pretty sure there will be Govtech Fund II, III, IV... :)
[+] [-] rdtsc|10 years ago|reply
Also security clearance helps if you have to send people onsite to debug.
Also if you think <insert log aggregation as a service> is slow try doing that over the phone from a secure facility where you can't get logs sent to you, just have someone read them to you.
Oh and you get to use Python 2.4 and RHEL 5 a lot if you work on Linux.
Yeah startup people would run for the hills.
However once you break through and get your devices listed on approved list of devices, you can fun overpricing the crap out of your services: https://aplits.disa.mil/processAPList.action (kind of like going to medical school -- pay lots of money upfront, then extract later through overpriced products and services).
[+] [-] anthonybsd|10 years ago|reply
[+] [-] logicallee|10 years ago|reply
[+] [-] spangry|10 years ago|reply
When you look at how government has traditionally interacted with citizens, it's indistinguishable from a monopoly service market. In the past, this was the only feasible way to deliver many government services. However, the result is the same as any other market monopoly: inefficient production and above welfare maximising pricing (albeit indirectly paid via taxation).
Government Web APIs fundamentally change this, and I'm not just talking about 'open data'. A whole bunch of monopoly markets suddenly become highly competitive markets (especially since digital service production tends to occur at around 0 marginal cost). The value to the economy could be many times the figure discussed in the OPs article. Tim O'Reilly was so far ahead of the times when he published his chapter on 'Government as a Platform' in 2010 (http://chimera.labs.oreilly.com/books/1234000000774/ch02.htm...)
More recently, in Australia they've just set up their own (kinda crappier) version of the UK GDS and published an API design guide. I think the excerpt from this article basically sums it up (http://www.themandarin.com.au/48771-dto-make-creating-apis-m...):
"However despite all these challenges, the cause [government APIs] is a great one and could do more to transform how government IT operates than many more public steps.
If the DTO [Australian GDS] can pull this off, have agencies fall in line and have APIs start rolling off government IT ‘production lines’, it will have single-handedly justified its own existence and transformed how government works, even if it doesn’t achieve anything else in the next few years."
[+] [-] devonkim|10 years ago|reply
Trying to work with some of these guys in a start-up setting outside DoD space is no more frustrating than trying to work with a corporate developer that's never had any job besides at IBM their whole lives. It doesn't mean they're bad or unintelligent, but the rigor and emphasis upon certain organizational structures and workflow processes are just plain useless knowledge in a start-up focused upon execution.
There's a lot of cultural horrors that will keep out motivated, smart folks from working with the government. I've spent well over 10 years of my life hoping to be the change that I was recruited for, but it's just not enough to be smart and motivated as much as well connected to incumbents that are fighting very hard against change because their very expensive meals and Mercedes S500s depend upon keeping things as stable as possible. This is the precise opposite mentality of the technology giants in industry.
[+] [-] USNetizen|10 years ago|reply
Secondly, "focusing on execution" and not processes is why so many startups die in a growth stage because it too often means chasing revenue only with few long-term plans. The government is inherently a long-term market. You need to have a long-term view. True, if you're developing a dog-walking app or glorified to-do list, yeah, it's not a market for you. But if you really want to do something game-changing and want to build something of note, I see no better place for it. Look at Palantir for example. There are hundreds of other examples.
Lastly, you can't just sit around waiting for "change", you have to make it happen. I used to be a GS-13 employee, fairly high up at one of these agencies, and I voluntarily left a secure job to make more of a change and I see it happening. It's rewarding, but you have to push for it and take risks or else nothing will ever come of it. I speak from experience actually doing this. How many else here can?
[+] [-] wmeredith|10 years ago|reply
[+] [-] USNetizen|10 years ago|reply
[+] [-] joshmn|10 years ago|reply
[+] [-] USNetizen|10 years ago|reply
The sales cycles can still be pretty long, but mostly for IDIQ's with $30M+ ceilings. We've received small $500k contracts that took over 9 months to award and, on the other hand, $3M+ contracts that took just a month.
A lot depends on the department/agency, and even organizations within the department/agency. It varies so widely but the key is getting to know your customer and anticipating the cycle. Relationships are absolutely crucial to getting government sales - the boilerplate they put out as RFP's hardly ever tell the full story of what the customer needs.
Also, leverage your set-asides and find reputable partners to team with. Can't stress this enough - it's the only way to compete against the behemoths in the market who have far more name recognition amongst contracting officers (who can be extremely risk averse). If the government isn't your target market, you can start winning work as a subcontractor and working your way up the ladder, getting to know your program manager customers who make the purchase decisions.
Two books I recommend as well - http://www.apress.com/9781430244974 and http://www.amazon.com/Zero-Billion-Entrepreneurs-Government-...
[+] [-] dkyc|10 years ago|reply
Specifically about B2G sales.
[+] [-] RonnieB|10 years ago|reply
[+] [-] godzillabrennus|10 years ago|reply
[+] [-] Spooky23|10 years ago|reply
Some downsides:
-Our procurement cycles are very long, sometimes as long as a year.
-Procurement contract vehicles are a horror show. The contract terms and conditions are often not negotiable, and may impact your ability to get credit, etc.
-You may find difficult to deal with services terms imposed by some procurement regime.
-If you don't have a field sales force, you'll probably need lobbyists to get meetings.
-You'll need to deal with all manner of crazy compliance regimes. HIPPA, FERPA, IRS 1075, CJIS, etc. Plus local policy.
-If you "partner" with the IBM/Unisys/Dell/EMCs of the world, you may find yourself screwed holding recievables for the big vendor, used as a straw man by the vendor sales team, forced to use high cost/low quality consultants from the big vendor, or otherwise messed with.
On the upside, .gov is usually terrible at negotiations, and they look at spending differently than commercial customers. You can make a fortune selling stuff, but you're not going to do it with traditional SaaS business models. You need to invest substantial time, energy and dollars into the pre-sales process.
[+] [-] niels_olson|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] jaybna|10 years ago|reply
[+] [-] USNetizen|10 years ago|reply
[+] [-] hackaflocka|10 years ago|reply
People who have experience in this space: is there a market for such a thing or do govts. prefer commercial (i.e. non FLOSS) software systems?
[+] [-] tdaltonc|10 years ago|reply
[+] [-] jlas|10 years ago|reply
https://en.wikipedia.org/wiki/GovWorks
[+] [-] USNetizen|10 years ago|reply
[+] [-] godzillabrennus|10 years ago|reply
Also, kudos to Civis Analytics for growing beyond govtech.
[+] [-] selimthegrim|10 years ago|reply
[+] [-] daodedickinson|10 years ago|reply