There's been a lot of talk about fixing IT procurement lately. And while most of it is focused on the federal level, large IT failures happen at the state and local level too. There's not a city or state government that we can yet point to that has a truly modern procurement environment.

Fixing IT procurement is going to take a lot of people and a lot of attention to get right. In that spirit, If you'd like to be involved with fixing procurement here are some questions to ask in your local community in order to understand how procurement is set up:

Who has purchasing authority?

Is purchasing handled by individual agencies, or is it done by some central authority? Does your police department buy its own computers, does it go through a inter-agency procurement department, or does it have the option do do either?

What are the 'Purchasing Thresholds?'

Usually there are certain dollar amount thresholds that govern how complex a procurement needs to be. So for instance, if you buy something for less than $25,000, it needs less of a buying evaluation than for something of above that number. Or if it's below $500, it can just be bought with a credit card. What are those numbers?

Are there small/minority/women/veteran/local business set-aside programs?

All agencies and government officials will say that they want to give contracts to, and work with small local businesses. This doesn't count for anything. The question is: are there actual dollar or deal amount quotas that agencies have to meet that are either government policy, or written down in law? How do they work? Are they preferences or set asides or both?

An example of a preference: when reviewing a contract's price, if the bid comes from a local business, a contracting officer will subtract 10% from the bid price for evaluation purposes, giving the local business an advantage in lowest-bid proposals.

An example of a set-aside: The city says that this contract is only eligible for bid by local business.

How do Information Technology Purchasing Decisions Get Made?

There is usually a CIO for a city or a state. But what kind of authority do they have to make purchasing decisions? Does the CIO of your City or State make the Information Technology purchasing decisions for the Sanitation Department? Or does the Sanitation Department have its own CIO, and do they get to make those decisions? Or are the decisions made primarily by contracting officers seeking lowest-bid proposals?

What are the business registration requirements in your area?

How does one register to bid on government contracts in your city or state? What information must they provide in order to get registered? What does the form look like? Is it paper or digital?

What are the set-aside/preference registration requirements like?

Another thing to ask is what it takes to register as one of the set-aside/preference companies beyond basic bidding registration. In some cities, having a local address isn't good enough to certify that you're a local business. Sometimes you need to get notes from customers that are also inside of the government's boundaries to vouch for you. In other places, you must provide an original copy of your birth certificate.

Where are the RFPs?

What is the process for finding business opportunities to bid on? Is there a website that lists all of the RFPs? Is it agency by agency, does the government share a central place to list all of them, or does it use some other listing process (like does a city use a State government RFP listing website, for instance).

Some key questions to ask here are also: if the RFPs are listed on a website, is this information available to the general public, or is it behind a registration/login/signup form?

What does it usually take in order to bid?

Different RFPs have different requirements and bid processes. But usually things work minimally the same way every time on a department by department basis. So, is there a pre-proposal mandatory meeting that's held on an rfp-by-rfp basis? In order to provide a qualified bid, must you attend this meeting? Are bids collected via mail or is there a digital process? Do they use a sealed-bid process whereby the proposal is in one envelope, and the price is in another?

Do they use "schedules"?

Schedules aren't calendars or time sheets. Sometimes governments make "schedules" or lists of pre-negotiated and approved rates with companies that they can purchase from quickly. Lots of cities and states actually purchase off of the GSA's set of schedules. Does your city do that? How much do they get from those schedules, and what are the requirements to get on those schedules?

Are there any contract vehicles in place?

Despite all this, your local government may have already set up contracting vehicles and outsourced all of their technology contracting to those vendors, and do they make those vendors acquire all their technology through those contracts (either through delivery or subcontracting?)

Do they use any Federal Systems?

Some governments use websites like sam.gov to handle registrations and record management of individual vendors. Or they use them in addition to their own internal systems.

What kind of political attention has been paid to IT?

Do you have a mayor,governor, member of city council or state rep, who was recently an "internet candidate?" Are they interested in fixing the way government buys tech?

Conclusion

Today we're launching Quick Consults Whether you need to bring someone in to take a look at an RFP, figure out what's going on with some Ruby code, or work on that strategic plan, we're here to help. And fast.

http://consults.dobt.co

Here's how it works:

There's flat rate pricing. Most projects will start at and be limited to $150.

You fill out a form, we get back to you, quickly, with an invoice and some suggested times.

We get together via phone, Skype, Google Hangout, or in person and work on your request.

I'm excited about DOBT Consults because a few hundred dollars spent early-on could save the government millions down the road.

Last week, I had an op-ed in the New York Times. The unfortunate headline (one that the Times came up with, but I consented to in a rush to get the op-ed out) was Why The Government Never Gets Tech Right. While I do agree that government rarely gets tech right, never is a dangerous word to use here, first because it's not true, and second because when government gets tech right, it's instructive and it's a bad idea to ignore where the success is for the sake of a clickable headline. Especially for the guy who wrote this book.

Healthcare.gov is instructive in a lot of ways because it highlights the failure of so many of our oversight, risk mitigation, and development systems. It's a project that draws attention to the fact that the systems that we use to buy and build technology are undeniably broken. But they're not universally broken. So I'd like to spend this week talking about where success is, and how those models can be replicated.

When those of us that work closely with government think about IT success, there's no greater technology success story than the Consumer Financial Protection Bureau. It's an agency with an entire budget that's within the same ballpark as the cost of some larger IT projects, and they've built a reputation for being the best team in the league.

Last week they released their eRegulations tool, a way to browse through the CFPB's regulations. And you can see it in CFPB's Github repository. Now granted, this is no Healthcare.gov, but let's compare this to, say, the way that you browse the federal acquisition regulation. Or the whole corpus of US Federal Regulations. What a difference while the language of the CFPB's regulations are somewhat unavoidably bad (because lawyers write them, not people interested in clear and effective communication), certainly CFPB's technology and design initiatives have put an emphasis on making their regulations as accessible as their lawyers' cultural speech impediment will allow.

Just as a broken Healthcare.gov is a symptom of a larger problem, CFPB's well designed regulation browser is indicative of a strong and successful model for developing technology internally. Unlike many other agencies, CFPB brought much of its technology brains inside. Initially under the leadership of now Senator Elizabeth Warren, she brought in Eugene Huang and Merici Vinton[1]. I spoke with Huang and Vinton in the early days of CFPB and it was clear they wanted to build a different kind of agency, one with technical brains and acumen on the inside from the start.

That notion paid off. CFPB made key hires, and built a design and technology leadership organization on the inside. Now, when they want to build simple tools like the regulations browser, they can. And when they need to contract with an external entity to do things larger than their internal team is capable of, they know how to do it, and whom to select.

This isn't something that could really happen out of the blue at an agency like the Department of Health and Human Services, or the Department of Defense though. CFPB started from scratch, as a high-priority effort from the president. They got to invent their own culture and their own status-quo, that's not something that even a new Secretary of Defense gets to do. There were no entrenched vendors, entrenched processes, or entrenched culture inside of CFPB.

But now that CFPB has done it, it can be used as a model of success for other agencies. If there's a lesson to take away from Healthcare.gov, it's that while procurement reform is important, you also need people on the inside who know what they're doing.

Late last night, the White House and the Department of Health and Human Services finally communicated with the public and let us know their plans on fixing Healthcare.gov with a "tech surge". Their plan?

Our team is bringing in some of the best and brightest from both inside and outside government to scrub in with the team and help improve HealthCare.gov.

So, it's a good step -- admitting that something has gone wrong is a big deal, especially for a modern presidential administration in the 24-hour, hyper-partisan news cycle. But the solution of "bring in experts"? Yikes! With the total cost of Healthcare.gov speculated to be anywhere between $100 and $500 million dollars, I'd have hoped that plenty of "experts" have been in there already.

The problem here isn't just the result of bad programming. It's the result of bad systems and bad architecture from the get-go. When you try and build the world's biggest shopping mall and the only place you can buy your support beams from is a balsa-wood mill, your building is going to collapse. The best thing that any outside experts can do in any reasonable amount of time is replace some drywall and paint. Otherwise, your experts are going to have to figure out where the balsa-wood is falling apart, and replace it with iron. That takes time.

That said, the opportunity to use Healthcare.gov's to create a model of success is something I couldn't pass up. The great news is that we've failed! Everybody's pissed! And while that may sound like a crisis, for a guy like me it smells like opportunity: there's nowhere to go but up! That means it's ripe for innovation, and I couldn't be more glad that Todd Park is helping to lead the cleanup crew.

So Todd, and the rest of the experts tasked with fixing this problem: if you're reading this, here's your playbook for how to turn Healthcare.gov into an amazing win. And this win? It's not just for the Affordable Care Act, but also for the system that created the fiasco we're in now.

1. Admit Failure, Make Failure Consequential

The first thing that you've got to do is hold the responsible parties accountable. There's lots of hysteria about firing the Secretary of Health and Human Services for this mess. I think that's a misstep. While her departure might be a political win for right-of-center adversaries, it's not actually going to do anything to solve the real problem of what's happened here.

Every new federal service has to get a Certification and Accreditation and an Authority to Operate. The people who signed those documents saying that this was a product that met and passed all the specified requirements assumed the risk of failure, and ought to be fired -- clearly they're not capable of being in positions where they can assess those requirements and assume that risk. Replace them with people who are qualified to run a technical recovery option.

2. Open Everything. Even if you have to go slow

It was a lack of critical thought about architecture that got you into this problem in the first place. Continuing to not think about architecting a way out of it will make getting out of the mess even worse. So we need to design a system that's going to give you the best chance of success.

First step: bring back the old github repository for the front-end of Healthcare.gov. People were actually participating with you and you shut it down. Turn it back on and let them participate.

Second: you've got to know what some of the problems are inside. The ones that involve custom software code, can you open source them? Do it. As fast as you can. I know you're using a lot of commercial off the shelf software and that it's virtually impossible to open source that. Ask your vendor to do it, and if they don't say yes in 24 hours, tell them that it will be replaced with an open source version Begin to make a real GitHub repository, one that includes all the code required to run Healthcare.gov.

Use the current Presidential Innovation Fellows to be community ambassadors and build managers to this open source community you're about to build. They all know how to work GitHub. Let them figure out how to get the code out, documented, and workable by people on the outside who could help.

3. RFP-EZ 10x.

For those who don't know, when Todd Park says "the best and brightest from inside and outside of government", the folks he's referring to are the Presidential Innovation Fellows. So I suspect that's who will be tasked with this recovery operation. And some PIFs might be able to scrub-in to solve this problem. Are they wonderful and bright? You bet. DOBT was actually founded out of the inaugural round of the program.

But are they the right people to solve the issues at hand? I'm not sure. There are people lining up who want to solve this problem. Lots of them, DOBT included, would love to help. But we're blocked out.

During my round, I led the team that built RFP-EZ. The system makes it easy for government to put out RFPs for less than $150,000, and easy for companies or individuals to bid on fixing the problem.

Use this program to openly solicit new businesses to help. Write a clear, open, short, and honest RFP that allows experts to see where you think the problems are, and submit bids not to exceed $149,999 for how to solve that problem. Put out the RFPs on Monday, select the winners by Thursday, have them on the ground on the following Monday.

I understand you go to war with the army you have, not the army you want. But you have the ability to get the army you want in a matter of days -- all it takes is leadership. The leadership to end the cycle of blunders without accountability, the leadership to be clear, honest, and open about where problems are, and the leadership to allow for a different set of vendors to come in and fix the mess that your old set made for you.

The most important thing? This is the best opportunity people like Todd Park and Jen Pahlka will have, during their entire careers, to show that government can work a different way. By using the playbook described above, they can turn the Healthcare.gov crisis into an opportunity that'll cause rapid change in the way government buys things that'll lead to a more cost-effective government, more jobs for small business creators, and most importantly, better service delivery from government to the people government serves.

Two choices lie ahead: keep it locked down, and you win the battle. Open it up, and you win the war. 

Here at DOBT we talk a lot about How To Fix Procurement, but you don't hear a lot about why things go wrong. The Healthcare.gov Fiasco is instructive in that it highlights every piece of our procurement process that's broken. How, with a half-trillion dollar a year spend, could something like this botch even happen? Here's how:

A High-Friction, High-Overhead contracting process

The contract for Healthcare.gov wasn't a fully competitive process. In fact, there was no competition for it at all. To get the work done, the Department of Health and Human Services used an existing contract it already had with CGI Federal to get the work done. The contract, as they say, was "greased."

So why was it greased? Technically, "greasing" something means reducing its friction. Running a public procurement of this size, and visibility -- it would probably take at least 18 months just to get through the procurement process and start the job. The awarded contract would almost assuredly get protested by those who didn't win, and it would yield to a very public, very political, and probably very bad outcome.

So what they did instead, and very rationally, is they opted to take a contract that they already had -- one with CGI Federal -- and amended that contract to add the Healthcare.gov stuff onto it. CGI had already built some of the systems that Healthcare.gov would depend upon, and already had "boots on the ground" as it were. So giving the contract to this vendor for this kind of work "just made sense" if you wanted to get a website done in time.

Requirements Written By People Who Don't Understand Technology or Procurement

So, well, if it was going to take a long time to do a procurement, and to have an open competition, why didn't they do that? Were they just lazy? Did they just not want to do the actual work of having a full, fair, open competition?

The more likely answer is that the Affordable Care Act set a date in stone, and during the contentious passage of the bill, Congress and the President gave very little consideration to the federal procurement process. They wanted it done, and wanted it done sooner rather than later.

If you want an IT project to fail, allocate a bunch of dollars to it. If you want it to be a total disaster, do that, plus let Congress design the requirements and set the deadlines. The disconnect between Congress' view of software and the developer's view of software has never been more vast. Then you have a force multiplier: Congress' seemingly willful ignorance over how the procurement process actually works.

Building a Battleship like a Website

Healthcare.gov isn't a book by itself. It's a chapter in an epic saga of large IT implementation screw-ups. From SAM.gov to the DoD's electronic healthcare record problem, an IT project's probability of failure is positively correlated with the amount of dollars allocated to it. This experiment has failed. So why does it continue to happen?

Because that's the way the regulation is written. Changing the federal acquisition regulation is a hard task, and it hasn't been modernized in years. Frankly, I often wonder if the regulation could even keep up with the rapid developmental changes of the technology sector. As an example: today, in 2013, the regulation requires that all systems be Y2K Compliant.

The process leans towards a write-down-all-the-requirements-then-build-to-those-requirements type of methodology. That's the kind of methodology you would use to build a space shuttle or a battleship, not the kind of methodology you'd want in building a website -- the tools themselves may change over the course of the time it takes to build the site, and it becomes impossible to course-correct even if you know something's going wrong.

Lack of Pricing and Accountability

In a functional marketplace, companies that do a good job at a low cost grow. Companies that regularly do a bad job at a high cost shrink. In the federal IT marketplace this isn't the case. This is for two reasons: the federal government has no idea how much stuff should cost, and the federal government does not do a good job at sharing performance based information.

The best source of contractor performance information to-date is probably the Project on Government Oversight's contractor misconduct database. But this database only catalogs instances of misconduct, not poor performance. The federal government does keep a database of performance information, called PPIRS (hilariously pronounced "peepers"), but predictably, this database is closed off from the public.

But even as an internal tool, it's inadequate. The GAO estimated that it's actually used less than a third of the time. Why? Because the information in it is unreliable -- and from what I've been able to determine from asking around inside the federal government, it's because people are afraid of being sued by the companies for saying that they do a bad job.

Layered on top of the missing performance information is a complete lack of pricing information. The federal government keeps no central database of pricing information. You read that correctly: there is no database inside of the federal government that says "we paid X for Y." This information is traditionally unshared because contractors view their pricing information as confidential, and while I might be convinced that it shouldn't be shared with the public because of anti-trust/market coercion reasons, certainly we want federal buyers in good negotiation positions. There's no reason this cannot be shared internally. Fortunately work on this has started, but I'm still shocked that it took 237 years to make it happen.

Inappropriate relationships between Congress and Contractors

I'd be remiss if I didn't finally mention that contractors are free to lobby the federal government. CGI Group, Inc, lobbied the federal government on the Affordable Care Act itself. Whilst there's little data on what they lobbied for, or why they lobbied, it seems strange to me that the procurement process and the ethics process of government allows for this. The good point of the procurement process is that it divorces the buying decisions from the political decisions -- meaning you can't become president and then give all your buddies contracts. But this is a back-door way in to ensure it. No contracting officer wants a call from a Member of Congress asking why their backyard IT integrator wasn't selected.

Fixing it

These problems are systemic. I'm sympathetic to all the people involved in building Healthcare.gov -- anybody that's been following IT procurement knew it would be a disaster from the start. But at this point, it's time we started fixing this stuff.

The White House has the power to do so. An executive order could be passed that would require an approval from the Office of Management and Budget for any IT integration over a million dollars. We already do so for every government form that gets created, as well as every high-impact regulation.

It's been a week since Healthcare.gov launched, and for anyone who has tried to register for new health insurance on the website, its online waiting room page is perhaps the most recognizable page on the site:

Not only did the site not scale at launch, it was riddled with errors, and it clearly wasn't ready to go. Just taking a look at the code that runs the site, you can see that it’s riddled with "Lorem Ipsum Dolor" -- the placeholder text that web designers and developers use to demonstrate designs before copy has been written. Reddit's gone wild with speculation about who built it and, of course, legions of IT experts have come out questioning the architecture of the website.

The contractors who made this website were at best sloppy, and at worst unqualified for the job. So, why? How did this happen to arguably the most important and lasting website of this president’s administration? And why did such sloppiness cost the taxpayer, from what I can tell, over 600 Million Dollars?

Some may say that this is complicated stuff. That the systems in place that Healthcare.gov had to integrate into various legacy systems, and that the system could only be tested so much, and that building a highly scalable FISMA certified web service was impossible from the get-go. Others might argue that this is the country that invented the Internet, Google, Amazon, Twitter, Facebook, the iPhone, and Android, it isn't as though we don't have the technical talent to stand up a website that allows people buy health insurance over the Internet.

But the truth is, they're both right. But worrying about fixing healthcare.gov is a bit like giving Walter White cough syrup and expecting it to solve all his problems. You might hope his cough will go away, but it certainly isn't going to end his lung cancer nor convince him to shut down his meth empire.

Healthcare.gov got this way not because of incompetence or sloppiness of an individual vendor, but because of a deeply engrained and malignant cancer that's eating away at the federal government's ability to provide effective online services. It's a cancer that's shut out the best and brightest minds from working on these problems, diminished competition for federal work, and landed us here -- where you have half-billion dollar websites that don't work.

That cancer is called "procurement" and it's primarily a culture driven cancer one that tries to mitigate so much risk that it all but ensures it. It's one that allowed for only a handful of companies like CGI Federal to not only build disasters like this, but to keep building more and more failures without any accountability to the ultimate client: us. Take a look at CGI's website, and the industries they serve: financial services, oil and gas, public utilities, insurance. Have you had a positive user experience in any of those industries?

The cancer starts with fear. Contracting officers -- people inside of the government in charge of selecting who gets to do what work -- are afraid of their buys being contested by people who didn't get selected. They're also afraid of things going wrong down the line inside of a procurement, so they select vendors with a lot of "federal experience" to do the work. Over time, those vendors have been consolidated into pre-approved lists like GSA's Alliant schedule. Then, for risk mitigation's sake, they end up being the only ones allowed to compete for bids.

This results in a culturally accepted idea that cost implies quality. To ensure no disasters happen, throw lots of money at it. And when things go terribly wrong, throw more money at the same people who caused the problem to fix the problem. While this assumption may work well with commodities (want to ensure that you get lots of high-quality gravel? Buy a lot more gravel than you need, then throw out the bad gravel) the evidence points to the contrary with large IT purchases: they usually fail.

On top of this culture of fear? 6,500 pages of regulation, cumbersome business registration processes, and hostile bidding environments ensure that very few new businesses can compete for contracts, and the ones that do end up becoming specialists in those regulatory burdens, not in doing the right thing.

The truth is, the people inside of government would like nothing more than to have the best and brightest minds in the world working on Healthcare.gov. But the best they've got to choose from are 58 different companies. That's *the* problem.

In order to solve the healthcare.gov problem, we've got to stop worrying about the cough, and start worrying about the cancer. We've got to start worrying about the systemic issues that allow for healthcare.gov to happen, not the "Lorem Ipsums" sprinkled in the javascript source code of the website.

It was a full year ago that Adam, Jed, and I started as Presidential Innovation Fellows to make RFP-EZ: The software that ended up saving the government 30% on IT purchases. It was a remarkable journey that not only ended up in a successful shipment of software, but also a lot of lessons learned.

We took some time to reflect on that effort earlier this year. Now we’re happy to release an edited, lessons-learned document that we’ve turned into an e-book called “7 Simple Ways to Modernize Enterprise Procurement.” It’s a white paper on what we learned during RFP-EZ, where I think we succeeded, and where I think we ought to go.

A little over a month ago, we launched Adopta, our version of Code for America's Adopt-a-Hydrant that let anyone set up their own Adopt-a-Anything website. While our original goal was just to see if there would any interest in such an app, we quickly realized that more than just making the app widely available, it was also our duty to see what we could do to improve it.

That's why today we're launching a shiny, new version of Adopta, complete with some changes that we're pretty excited about:

1. Better user engagement

One of the best criticisms of the Adopt-a-* apps was that "there is absolutely no perception of activity, urgency, or community".  So we added an activity stream to see adoptions as they happen, and a leaderboard so that active community members can achieve recognition for their efforts.

2. Mobile-first

Enough has been said about the prevalence of smartphones and mobile internet usage -- so I'll just say that it was mildly embarrassing that Adopta wasn't optimized for mobile use. Not to worry though, we've rebuilt our stylesheets from the ground up with mobile in mind.

3. Your ideas?

Our team here at DOBT is growing, and so is our capacity to continuously improve the apps we build and support. Some features that are already in the works include:

Improved support for migrating an existing non-digital Adopt a Hydrant program

The ability for citizens to provide & update the coordinates of infrastructure they adopt

And on the crazier side of things:

What if each adopter received a custom sticker in the mail, and they were *encouraged* to stick it on the hydrant that they adopted?

Can we let citizens post requests for help? Maybe provide some sort of bounty for the folks that fill the request?

  It's our goal to make a flexible application that works for scenarios we haven't even thought of yet, so if you have feature ideas or suggestions, don't hesistate to get in touch. Launching an Adopta site might not fix all of government's tech woes, but showing citizens that government can be an "us" and not just a "them" is a great first step.

I'm so happy we managed to talk Sid Burgess into joining our team here at the Department. Sid is now the guy that links our great technology to the people who need it.

Sid's been around the space for quite some time (12 years!), and I admire his passion for using the web to improve the lives of everyday people. He's a fire fighter, a former city councilman, a combat medic and the president of a community non-profit. And now he's our new government liaison. I couldn't be more thrilled.

The notion that we can improve government by going upstream and giving people on the inside tools they love, and tools that help make great decisions just got a little more realistic. Welcome aboard, Sid!

Earlier this year, California Governor Jerry Brown appointed DOBT founder and CEO Clay Johnson to the state's Task Force on Reengineering IT Procurement for Success, which was created to "identify how it can (1) hire the right vendors (2) at the best value, and (3) hold them accountable for their performance."

The following report outlines 7 key areas for improvement, and is a must-read for anyone remotely involved in the IT procurement process.

One thing that’s been frustrating about developing apps for the government web is that some of the great front-end frameworks we use don’t take accessibility into account. A week ago I announced our plan to add some modest accessibility improvements to Bootstrap, and asked some friends from Code for America and the White House’s Presidential Innovation Fellows program to help contribute.

I’m proud to announce that as of today, our changes have been merged into the main Bootstrap repo. Our work isn’t completely done, (in round 2, we’ll start testing Bootstrap with an actual screen reader,) but we’ve already achieved significant progress in making Bootstrap more friendly to users of assistive technology.

Recently I’ve been working on making Screendoor “508 compliant”. Section 508 is a federal law stating that all IT systems must be accessible to users with disabilities – kind of like WCAG, except mandated by the federal government. In it’s most simplified form, it’s basically a checklist of accessibility best-practices that all federal websites need to follow.

Unfortunately, everyone’s favorite Twitter Bootstrap is rife with accessibility issues. Things like using the <i> tag for icon classes, using anchor tags to toggle menus… and some trickier ones, like encouraging users to use non-semantic header nesting. (Is the biggest header on your site an <h1>? no? bzzzzzzz)

That’s why this weekend we’re hosting an informal gathering in Oakland (and virtually) to work on making Bootstrap follow accessibility best-practices. Where we need your help is filing issues – before Sunday, we would love to have a fairly comprehensive list of where Bootstrap fails 508 and WCAG guidelines. I’ve started building the list, and would love any and all help filling it out:

https://github.com/dobtco/bootstrap-accessible/issues

A while back, before Clay and I had even conceived of DOBT, I tweeted:

Someone needs to create the 37signals of government software.

If you’re familiar with 37signals, you know that they’re behind Basecamp, Campfire, Highrise, and a bunch of other highly-regarded web applications. None of these apps are particular unique – there’s probably at least 10,000 other project management tools out there – but users love these apps because:

They do one thing and do it well

They start out free, and the price scales with the size of your organization

They’re Software-as-a-Service (SaaS), so there’s nothing to install and they’re never out of date.

Our open government community has made some pretty some pretty big strides in the past decade. A lot of the cutting-edge apps and platforms that governments are using are open-source, so anyone can grab the code and deploy an instance for their city. But what happens when someone wants to use these applications, but doesn’t have the technical know-how to take the code, customize it, and host it themselves?

That’s why today we’re launching Adopta, a SaaS version of Code for America’s most-redeployed application, Adopt-a-Hydrant.

Adopt a Hydrant is one of CfA’s biggest successes. It was originally developed for the City of Boston in 2011, but the community quickly realized that it had applications beyond just adopting fire hydrants. In 2012, Honolulu launched “Adopt a Siren”, an application that allows citizens to take responsibility for tsunami sirens by checking to ensure their functionality and reporting the status to the City.

Today, Adopta empowers anyone, regardless of coding skills and technology know-how, to create their very own Adopt a Hydrant for their community. Every aspect of the site is customizable – so no matter if you want to adopt hydrants, storm drains, or banana stands, you’ll be able to tweak the website copy and images to fit.

Today we’re launching a new feature in Screendoor: custom review fields. We’ve had this one on our minds for a while, and we think that it will make Screendoor an even more effective tool for reviewing large numbers of applicants.

With all of our features we want to make sure that we keep Screendoor as simple as possible, so when adding customization to the application, we never want to create more work for you, our user. Here’s how it works:

When you create a project in screendoor, we create an overall rating field for you:

This should be enough for most use cases, but if you want to rank your responses on say, a combination of “skill”, “experience”, and “creativity”, it’s as easy as creating those three fields here:

This will let your reviews rank each response multiple times, and the system will automatically calculate the average rating across all fields and display it to you.

And that’s just one way to rank responses. You also have the option of reviewing by response field – so you can ask your reviewers to rate a specific section of a response, like so:

Right now, you have the option between Stars, Red/Yellow/Green, a Number Range, and Free Response. Here’s what they look like, all in a row:

One big problem we have in getting government to use new technology is the Terms of Service problem. See, unlike you and me, government employees can’t just “click through” a legally binding contract without reading it. Instead, if you want to buy something, you’ve got to have your counsel read through the Terms, and often, negotiate with the service providing the terms.

That’s why for a lot of small businesses, it’s good to have some kind of standardized terms. Eventually, we want to get to the point where Counsel says “oh, I’ve seen these terms before. It’s fine.”

We love MeasuredVoice – they’re out there selling, working on solving a hard problem (helping government listen better) and, like us, working on stuff that matters. So when we noticed that they had developed their own Terms with GSA, we asked if we could steal them. And they oblidged. They even put it up on github.

So now we’ve got something we can work with – a template, a place to start. Let’s work together to craft a terms document that works for everybody, so we can focus on what we do best – making great software.

Last month, the White House announced that our project, RFP-EZ, helped cut the costs of government IT projects by an average of 30%. Today, I’m excited to announce that we’re making that same technology to every city and state in America, regardless of the size of their budget or their IT department. We’re doing this by launching Screendoor.io, a software-as-a-service application modeled after RFP-EZ. This means:

You pay for a monthly subscription, with no initial upfront cost

You can try it out, without ever spending a dime

It never goes out of date, and new features are always being developed

There’s no server upkeep or other hidden costs

You can cancel your subscription and take your data at any time

By now you’ve probably heard about the fantastic results we saw during our pilot of RFP-EZ inside the federal government. Recently we’ve been talking to cities and encouraging them to try a similar pilot, but we realize that not every city has an RFP-EZ-sized budget available to them for procurement experimentation. By embracing a software-as-a-service platform, we’ve done something incredible: every single city, county, and state government is now able to run this pilot completely free of charge. We expect participating governments to see decreased cost, increased number of competitive bids received, and heightened engagement with small and local businesses. And if we don’t see this success? They won’t have spent a dime.

If a city has an engaged technology community and would rather own the application themselves, Procure.io will live on as a separate open-source project, available for cities and organizations that want to customize every aspect of the software.

Screendoor will be extremely affordable for cities that decide to continue using it – our plans start at just $29/month and scale with the size of your city and the number of procurements you’re running through the system. You can sign up starting today, and if you use the coupon code “SCREENDOORLAUNCH”, and your free trial will be upgraded from one project to ten.

And another note…

We’re happy to announce that we’re one of the 9 organizations that were selected to receive funding from the John S. and James L. Knight Foundation as part of the Open Gov Knight News Challege. It’s going to promote and extend our Procure.io platform, to support and scale Screendoor, and to build out an open library of RFPs and Statements of Work for anyone to use at any level of government.

Imagine you’re an expert carpenter. And, solely out of altruism, you spend six weekends a year volunteering to build houses for Habitat for Humanity. You wake up early on a Saturday morning, walk away from your family, and spend two full days putting up a house for the greater good. Habitat’s not paying you in anything but the lunch and snacks they bring you, but its fulfilling – you’re giving back.

You get so good at leading teams to build houses you get a call from Jimmy Carter. Carter calls you up and invites you to Habitat for Humanity’s headquarters for lunch to thank you for your hard work.

But driving up to Habitat’s headquarters, things seem out of whack. You, as a builder can take one look at it, and understand that the place is about to fall apart. Structural beams are in the wrong place. There are two toilets in every stall in the bathroom. The water in the building is pumped into a large pool at the top of the building, and then trickles down to where it needs to go, and the pool is held up by very narrow wood beams. And the furnace and water heater are insulated with dry pine straw.

You don’t even want to go into the building, but it’s to meet president Carter, so you decide to essentially risk your life and get in the elevator and hit the button to go to the top floor. And of course even though you’re the only passenger on the elevator, the car stops at every floor on its way up to the top.

By the time you get to Carter’s office you’re terrified. Now this is an organization you’ve given a lot to, and that you care a lot about. You certainly don’t want the building to fall apart. You’ve got to say something, or at least figure out how an organization with so much access to excellent carpenters, plumbers, and electricians, could end up with such a terrible, dangerous building.

You sit and say to the former president, “Thanks for having me here for lunch. This building is something else, isn’t it?”

President Carter responds, seemingly well aware that his building is a disaster: ”It’s amazing, isn’t it? Have you ever seen a more poorly designed building?”

“No, no Mr. President, I haven’t. It’s really dangerous – it’s not only aesthetically bad, it’s also structurally unsound.”

“Oh, I know. Our contractors told us it was. They’re fixing it now, thankfully. After they’re done fixing the insides, hopefully we’ll have enough budget to upgrade the aesthetics, too.”

“That’s a relief, Mr. president. Who built this thing? I hope they’re not building any houses.”

“Well, we bid this out and the only people who bid on this was Master Builders, Incorporated or MBI.” He says.

“I had no idea MBI still built buildings. Who is cleaning up their mess?” you ask.

“Well, MBI is on the hook to fix it too. The good news is, they’ve put 50 new people on the project. Including 45 new project managers.”

“Mr. President, I’m sorry, but you really should switch vendors. I wouldn’t trust the people who built this building to clean it up.” you say.

“Well, it was a 500 Million dollar project and there really aren’t that many builders out there that can qualify for a project of this size and scope. So we have to use them. They’re the only ones that have a track record of doing half-billion dollar projects.” he says.

“500 million dollars? For this office? How many people do you have in here, 60?”

“It has room for 60, but 30 of our people work in remote offices – out in the field building houses.”

“Mr. president,” you say, “I don’t know how to tell you this, but it’d probably take the crew I had this weekend to build a habitat house about 500k to build an office building like this. Half a billion dollars more than you need to build a town, not an office building.”

He raises an eyebrow: “I think there’s a lot more that goes into building a building of this size than one of the residential buildings our volunteers build. We have to be compliant with many more building codes.”

“Like what?” you ask.

“For instance, we need to be accessible to people with disabilities. This means we need ramps to our doors, urinals that are installed a bit lower, and braille on our elevator buttons. And we need to control access to the building. Stuff like that” he says.

“Mr. President – that’s generally cosmetic stuff – it shouldn’t increase the cost and scope of your building by 1,000x. And if you build your building with standards, most of that stuff is already done for you. Let me and a team come in here and fix this. We’ll do it for a tenth of the cost, and you can take the money you were planning to spend on your building, and spend it on building more houses and putting more people in them.”

“Really? I have to confess I don’t know much about actually building houses these days. I’m going to look into this. But for now, let’s just enjoy our lunch.”

You find president Carter charming, and he takes a liking to you too. At the end he gives you his card and says, “we really appreciate your help. And if you know how we can do anything better, you call me directly and let’s talk about it.”

You finish up your lunch with president Carter and get out of the building as soon as you can. Then on your way home, you drive past a home that you built for Habitat. It’s empty. By the looks of it, nobody’s been on the lot since the press event that happened right after it was built. You decide to take a look around at the other houses you’ve helped build. They all seem to be in some stage of disrepair and neglect.

By the time you get home, you’re outraged. You decide to sleep it off, but the neglected houses keep you up. By 9am, you find yourself with your phone in your hand dialing president Carter.”

“Hey there! Good to hear from you! I’ve been asking around about our building issue. It seems like MBI is the only builder that’s managed to go through our vendor qualification program, and thus they’re the only ones qualified to do the building. But if you went through the process, you could probably bid on the project and compete against them in the open market for the next round of work.”

“How long does that process take?”

“To register? I don’t know. Shouldn’t take that long, should it?”

“I guess not,” you say, “but Mr. President, I have a more pressing question – why is it that all the houses I helped to build are all vacant and neglected?”

“Ah, yes that’s really unfortunate. But the problem is, we don’t have the budget to hire the people needed to keep the property maintained and to put them in houses.”

“But… you’re spending a half billion dollars on your office building. Do you know how many people you could put in houses with that money?”

Carter chuckles. “Wow, that would be a lot, huh? Hey – I’ve got to run to a fundraiser. But it’s good talking to you. I’ll introduce you to our procurement people about getting registered as a vendor for us.”

You’re frustrated, but think you can solve the problem. You’ll just form a company with your friends from Habitat to get that building’s cost down so that money can get freed up, and then people can get in those houses. A few days later, you get a terse email from Habitat for Humanity’s procurement division:

“Dear Ms. or Mr. Smith,

Please see the attached documentation for signing up to be a supplier for Habitat for Humanity. Please note that your business must meet the minimum requirements in order to bid on our projects.”

Out of the 14 attachments on the email, you manage to find the document (titled 2012_AU776-REQS.PDF) describing the requirements. It says:

All Vendors must be at least 2 years old. Vendors for projects that cost more than 150,000 must have a one billion dollar liability insurance policy.

Well, so much for that. You won’t even be eligible to bid on the project for another two years. And there’s no way you’ll get an insurance policy like that. Only huge mega corporations have insurance policies like that. You call president Carter.

“Hey, it’s good to hear from you. You get connected with our procurement people?”

“Yeah, I did. It’s unfortunate though, because they say that I have to be two years old and have a huge insurance policy in order to even get a seat at the table to help you out. So, I guess that’s that.”

“Well, why don’t you partner up with an existing company and just subcontract through them. I think our procurement people have encouraged a mentoring program for this.”

You have to admit, you hadn’t thought of that. So you call up the procurement people at Habitat. They’re very accommodating and they give you a list of companies who say they’ll partner up with smaller contractors to “learn the trade.”

You set up meetings with MBI’s biggest competitors: Dynamic General Builders, Whiskey Elon Jackson, and Whiterock. And when you meet with them it’s clear that they don’t know anything about building houses. Not a single one of them uses termite treated wood, for instance. They all connect copper pipes to iron ones, not understanding that over time, that will cause corrosion and the pipes will have to be replaced. And when you mention these issues, they’re condescending about it: “Listen,” they say, “you may know a lot about building homes – but you have no idea how to build enterprise-grade buildings. You have to do things this way. Work with us and you’ll learn this in time.”

You just can’t bring yourself to do it. 99% of all new houses today use PVC piping and termite treated wood for damn good reasons, and you’re not going to go back and use tools and techniques from 50 years ago.

Then you realize it: this is, of course, the problem. This is the reason why the building costs a half-billion dollars in the first place. Habitat is trying to build a modern building using the tools from 50 years ago. It’d be like trying to buy a car with 300 horsepower by buying 300 actual horses and trying to get them to all go at the same time. Horses cost $5,000 each.

Defeated, you head home. The phone rings, and it’s president Carter.

“Hey there – I was calling to see if you’d lead a build-a-thon this weekend to put up a house in your neighborhood. Homelessness is way up because of the economy, but if we work together, we can give people a helping hand up.”

You get sick to your stomach. “Mr. president, I’d be happy to help, but I can’t very well build houses for you for free while you’re paying people a half billion dollars to build yourself an office. And I know you don’t have the budget to actually maintain and get people in the house.”

“Oh, I’m sorry to hear that. Is there anything I can do to change your mind?”

“Yes. You can make it so that your own volunteers who’ve built these houses can come in and fix yours. And that starts with changing who can compete for your contracts,” you say.

“Gosh, I’d really love to do that, but to be honest with you I really don’t want to pick a political battle with our procurement people. It’s an issue that doesn’t win me a lot of support with my board. They’re much more concerned with getting new homes up or meeting fundraising numbers,” he says.

“So you don’t think that spending a half billion dollars on your office building is a high priority problem?” You say, steaming.

“Well, I do. But I don’t think my board is going to let me do anything about it.”

“I think they’d be really concerned about it. Who is on your board?

“Well, we have a ‘representational board’” he says, proudly. “80% of the board votes belong to our members – people who donate under $250, and people who volunteer. Then we have 20% of the board represented by our large corporate sponsors: people who have given more than $50,000.”

“Really? Do those people usually vote on stuff?” You ask

“No, most are just happy donating. It’s the corporate sponsors who normally care about our operations.” he says.

“And who are they?” you ask.

”MBI, Whiskey, Dynamic General, Whiterock, you know them.” He says.

You want to give up. But you think about it, and for some reason, you just can’t.

“Mr. President,” you say, “we’ve got to fix this procurement problem. And if it’s not an issue for you now, I’ve got to make it an issue. But for now, no. I can’t lead the build-a-thon this weekend. I’ve got a bigger problem to solve than building houses on the cheap.”

“Okay!” he says. “Well, hope to hear from you soon then!”