How Washington State handled a flood of applications to be its "pot czar"
When Washington state voters passed a marijuana legalization referendum last November, it presented a unique challenge to the Liquor Control Board put in charge of implementing it. They had to find an outside consultant to run the program, and they needed to do it fast.
As it normally does, the state put out a request for proposal for a consultant to run the new legal marijuana program. As word leaked out that there was an RFP open for what essentially was a "pot czar," the floodgates opened. It would be the most popular RFP in the state's history. The Liquor Control Board needed a way to process these requests quickly and cheaply.
There was another wrinkle. Last year, the same voters had voted ended state control over liquor sales. This meant that the Liquor Control Board staff, including the procurement department, had been reduced accordingly. One year, they were out of the liquor business. The next year, they were in the pot business.
In a typical RFP scenario, they would get maybe half a dozen responses. This one got close to 100, of which 52 would make the cut.
The state called in consultant Shadrach White, CEO at cloudPWR and presented him with a challenge.
They needed him to design an RFP management system. They needed it to be cheap, because anything under $10,000 doesn't have to be put out to bid, and it had to provide a simple way for the review committee members to process and grade the proposals.
Oh, and it had to be done in 10 days.
Piece of cake, right?
White attacked the problem. First, he decided paper was out. If the RFP process remained paper-based, all nine bid evaluators would need to get together in a room at the same time and go over the bids. In addition, everyone would need to get copies of the 52 bids in binders and paper forms.
White decided the only way to do this for the price they were wiling to pay was to use cloud services, and the system he came up with was ingenious in its simplicity.
He started with Box to store the proposals in PDF files instead of paper binders. He created an intelligent form in Google Docs for the review form. He used DocuSign so that each reviewer could certify their review form with a signature and he mashed it all together in a WordPress site.
The data from the Google form dumped automatically into a locked Google spreadsheet, which saved time they used to spend keying in the data, and ensured accuracy because it eliminated possible data entry errors. Locking down the spreadsheet ensured the integrity of the process because nobody could manipulate the data.
He chose these particular tools because they all had open APIs, which allowed him to mash them together easily into the solution. They were easy to use, so reviewers could learn the system with little or no training, and they were mobile, so users could access the system from any device. In particular he wanted reviewers to be able to use the system on a tablet.
He ensured the security of the system by giving the users each a unique ID (e.g., Reviewer1, Reviewer2, etc.) and password, which protected the system integrity and maintained the anonymity of each reviewer - crucial factors in what was bound to be a controversial selection process.
White built the prototype in a less than a week, reviewed it with officials, and tweaked it based on their feedback. He didn't quite make the 10-day window, but the system was up in running in less than three weeks -- an astonishing time frame for a state project of this scope.
Google made a big splash almost a year ago with its Google Glass Internet-connected eyewear. Now the search giant is ready to broaden its assault on the wearable computing market by releasing a software development kit for developers to create Android-based software for wearables.