There are typically four steps in the procurement process for getting a request for proposal (RFP). This process typically applies to procurement at the federal, state, and local levels, although the types of vendors that compete for these projects are quite a bit different.
First, conduct any necessary research to identify the type of project (waterfall or agile), the scope of the project (i.e., price), and the project manager.
Second, write the RFP. This will include identifying the price structure and where the money is going to come from, creating a timeline of the project, and figuring out the technical requirements of the project. State and local governments usually have more leeway in this process, and sometimes use that discretion to write RFPs that target specific vendors. This is typically done in three ways.
- Making specific requirements in the RFP that only apply to certain vendors.
- Add so many requirements that only a few vendors qualify to submit a bid.
- Create significant barriers that discourage vendors from bidding.
For example, according to Sam Hammar the Director of Digital Engagement for the Massachusetts Office of the Treasurer, Massachusetts requires that if a vendor fails to deliver on their contract, they must pay 2.5x the amount they were awarded from the contract back to the state. Following the rhetoric that “nobody gets fired for choosing IBM,” Hammar says this requirement was strategically designed to scare away smaller vendors from bidding on RFPs, which she believes especially hinders innovative solutions for tech RFPs.
Third, publish and advertise the RFP. The requirements for this process varies depending on the scope of the project and the specific laws governing that jurisdiction (i.e., states likely have different advertising requirements than other states or the federal government). For example, Massachusetts has various requirements on advertising based on multiple factors like the type of project—such as if the project includes building construction labor—or the scope of the project (different rules for under $10k, between $10k and $50k, etc.). However, larger contracts typically require more exposure than smaller ones. Although, specific vendors are sometimes contacted directly and “encouraged” to bid on an RFP.
Fourth, evaluating and selecting a vendor, and working out the final details of the contract.
implementation and accountability
With an IT project, there should be three guiding questions. First, should I take a waterfall or agile approach to this project? If unsure, ask the sub-question, if I incorporate user design into the project, is there some variance as to what the final product will look like depending on what comes up? If the answer is “it depends” (i.e., you are not sure what the final product will look like), then an agile method is probably the best approach. In fact, an agile approach is almost always the more efficient method when it comes to IT projects. This is largely because IT is always changing and its use in government projects is more widespread than ever before. This means that the project is undertaking a new path unfamiliar IT path to fix government problems. However, not only is IT continually changing, but it’s also fundamentally flawed (i.e., no software is perfect). Thus, we need to use a more adaptable process that can evolve into a product that works for citizens and fits their needs.
The second question is, has something like this been done somewhere else before? As we discussed in class, as well as what I have seen while working on my PAE, governments are really good at doing things over and over again. It shouldn’t be surprising to see that projects are much more likely to succeed if they have already been done before. Benchmarking other governments that created a similar project can cut costs and time while improving effectiveness.
The third question is, how can we incorporate expertise in creating this RFP? One of the biggest problems that I’ve seen throughout the semester is that RFPs are not sufficiently built for the project. In other words, RFPs need to be developed with IT experts, not for IT experts.
I have come up with three different complexities that exist as barriers for government IT projects and make recommendations based on these issues. If governments can overcome these problems, then it should increase the success rate for IT initiatives.
Risk and moving away from legacy technology
Governments are risk-averse by extension by extension of the politicians, bureaucrats, and public workers that are risk-averse. This is largely because there is little to no incentive for public servants to take risks. But, there is a considerable downside for risk-taking individuals. In a democracy, if things go wrong, it is easy to shift blame on the risk taker. Reasonably, constituents do not want to see tax dollars wasted. Furthermore, it’s politically convenient for the opposing side to attack the political leaders in charge during the failure. As a result, political leaders will blame the agency or people involved with creating or implementing the project, even if they were just following orders from above. This risk-averse culture in government is even more prevalent when it comes to IT projects. These projects have a lower success rate because they are new, untested, and unfamiliar. So why would anyone want to stand out and stick their neck out for a new approach or an unconventional vendor when they will likely shoulder the blame if things go bad?
Moreover, it’s difficult to incorporate a change when things have been done a certain way for so long. Because past IT projects have been developed with a waterfall method that favored large vendors that created proprietary software, it is difficult to incorporate new technology that works with old technology without going back to the same large vendor. In fact, it seems like the only way to do this successfully is to replace the old technology altogether. Going back to public servants being risk-averse–avoiding the potential disaster far outweighs the potential upside of going to a new system. For example, the failure that came from the Phoenix Payroll System has cost Canadian taxpayers billions of dollars with only problems to show for it. While the political fallout of this disaster has not been determined, I think we can agree that it is something everyone wants to avoid and future policymakers will think twice before looking into another IT project of this magnitude.
However, some actions can be taken to overcome these complexities. The first is creating a safe place to fail. In Boston, the Office of New Urban Mechanics is known as the failure agency. This is where many of the city’s IT project ideas go to be developed and tested. Projects can fail as long as progress is made. If cities cannot afford to have these type of made-to-fail agencies, they can partner with an academic institution or a non-profit to test IT projects, such as the Office of New Urban Mechanics at Utah Valley University. This should help shift the risk away from the government since failed projects would be under the watch of these partner organizations.
Lack of User Design
Governments have been successful in past projects with extensive planning and instruction following. If the government wanted a bridge, a company would assess the area, create a blueprint and follow the specific set of instructions. You don’t need people on the bridge to test it during different phases to know what constituents want. In fact, this approach might do more harm than good. However, there are a lot more unknown variables when it comes to IT projects. When creating a blueprint for an IT project, it is impossible to see and predict all of the problems in design, security, capacity, etc. While extensive planning and instructions can help some of the problems, the most efficient way to catch the major issues is to create prototypes, have users test the IT, and then have developers make adjustments based on the user feedback.
Unfortunately, this approach does not fit nicely with the way governments have traditionally created products. As we become more dependent on technology, policies will also need to adjust to this technology to deliver on the needs of the constituents. Governments need to recognize and change the way they approach IT projects. For state and local governments, following the way other governments have approached successful IT projects is a good start. For the federal government, seeking input from experts (i.e., 18F) can help ensure the best approach is used.
A common problem that appears throughout the cases we discussed in class is the gap in communication between and within governments, vendors, and constituents. However, I don’t want to regurgitate the obvious communication problems and solutions we discussed in class—like the communication process failure between government agencies with healthcare.gov. Instead, I want to focus on the lack of recognizing and communicating failures.
With the California Procurement case study, leaders knew there was a problem and advocates for the agile method were able to communicate how the waterfall approach failed. Unfortunately, this seems to be the exception rather than the rule. Governments and vendors need to be more open about their IT failures because it could help others avoid these failures. A simple way to do this is to create a blog post, op-ed, or even a press release that discusses why these projects failed. Of course, this is a lot easier said than done since it would require public servants admitting failure. But, I think we can make more progress if we can somehow open this dialogue.
There are two big takeaways that I took from this course. First, always evaluate the process and system (i.e., waterfall vs. agile). Second, is that things need to be created with the user, not just for them.
In the future, I see myself working with a mission focused organization as an advisor or consultant. For example, I am interested in an advisory role for a private company that helps public school teachers stay in their home.
Evaluate the process and system
Just because some method worked in the past, doesn’t mean that it is always the best approach. In my ethics class, we learned about Kant’s theory of ethics where the rightness or wrongness of an action is not based on the consequences of the action, but whether the action fulfills our moral duty. This duty is universal and must pass the Categorical Imperative test.
In this case, I believe that simply doing things one way because they deliver the necessary results is not sufficient to fulfill this moral standard. This standard can only be fulfilled if it is the best action we are capable of taking. For my future advisory role, I believe my duty is to make recommendations that I believe is the most efficient use of the money. For me, this passes Kant’s Categorical Imperative test, where I would expect everyone to act in the same way. In this case, efficiency does not mean more teachers. Instead, I believe efficiency would be making recommendations based on the most effective and the most deserving teachers. If I’m not constantly evaluating the approach that maximizes this efficiency, then I cannot fulfill this duty.
In addition to helping teachers in a more meaningful way, this constant evaluation will help me fulfill my ethical duty while enabling me to be more effective in my role as an advisor. Fortunately, following my moral duty results in a positive consequence for me.
Create with, not for
When creating something, it should be developed with the person that will be using the product or service, not just for them. There is a difference. When a product or service is created for someone, it may or may not be successful. I believe that successfully developing for someone is a function of luck. Without understanding the needs of the person, you are relying on many assumptions. Possibly the biggest assumption is that you have correctly identified the problem and have a usable solution. This assumption can be wiped away with adequate interaction with those that will be using the solution. For example, Harlan Weber from Code for Boston told me in an interview (at least seven times) that their biggest problem is that they don’t have enough money for pizza and servers. If I took just this information, I might reasonably suggest that organizations open up more grant money for IT projects like Code for Boston. However, this “solution” wouldn’t solve Harlan’s problem. When exploring solutions with Harlan, he mentioned that there is plenty of grant money, but they just don’t know how to write grants.
While it may seem simple, people often ignore this part of the design. Instead, they invest a significant amount of time and money developing a product or service that is based on their idea of the solution. In his persuasion class, Professor Orren preaches that the top two principles of persuasion are: knowing your audience and salience. That means if you want to persuade someone to use your product or service, the two most powerful tactics you can deploy are: understanding your audience (the more you know about them, the more persuasive you can be) and offering something that is salient for your audience (this is most effective when something is salient to both parties).
When working in my future job, I need to make sure I am doing everything I can to understand the needs of the teachers I am offering to help. By working with them, not only can I help show them that this is salient to both parties, I can use their feedback to identify problems and help further develop the company’s service. If they want to keep living and working in the district, our company offers a creative equity sharing solution that can help get them into a home without the burden of interest or making payments. I anticipate a big part of my future will rely on my ability to work and create things with others.