Contracting Technology in Education

I am glad that Philissa Cramer is reporting on some of the deeper details of the Special Education Student Information System ¹ implementation at the New York City Department of Education here. Many people don’t really understand the ins and outs of government contracting. Folks really think NASA designs and builds the lunar module, for example, instead of realizing that they issued an RFP and contracting with Northrop Grumman to do that work for them. Similarly, in education, especially around complex technology projects, most districts and states purchase products or services through a bid product rather than develop solutions in house.

However, I am a bit disappointed in the angle that City Limits, (Ms. Cramer’s source) took in their reporting. There are real problems with government contracting, but they really mischaracterize the story around SESIS in an attempt to simplify the issue for casual readers. City Limits acts as though it is surprising, or even deplorable, that an RFP was awarded to a company with a largely existing product.

They point to the fact that Maximus, the vendor for the SESIS contract, was modifying an existing product to meet the requirements outlined in NYC DOE’s RFP as though this was clearly bad. City Limits uses words like “revealed” and “simply” to describe what Maximus was offering. This just ignores the reality of government contracting and shows disregard for risk mitigation. Almost all government agencies handsomely reward companies that can point to successes in developing and implementing solutions that can meet many of the requirements outlined in the issued RFP. The government wants to hire people it believes can do the job and do it well and often one of the best ways to make that determination is to see that someone has done it before. In almost all cases, this means selecting a vendor who has an existing product or process for meeting many of the requirements in the RFP that will be expanded upon or modified. But government purchasers don’t just want experienced partners, they also want to leverage efficiencies by not paying for duplication. One of the major reasons for purchasing an existing product or contracting with a vendor is that school systems actually aren’t that different from one another and the basic functionality and organizational structures required in an IT solution are shared across schools, districts, and states. Why pay substantially to build the same basic software infrastructure that already exists elsewhere? It’s a waste of money most of the time.

City Limits then goes on to criticize the massive increases that can occur due to change orders. This is a serious problem with government contracting, but they fail to really explore why. A change order occurs when the client wants new or additional functionality that was not included in the initial contract. Their frequency and expense are not an example of why government agencies should not contract with outside vendors, rather, they demonstrate just how poorly bureaucracies are at managing large-scale complex projects. Change orders happen due to several failures, and almost all are the government agencies’ fault. In no particular order, the government agency:

• failed to do proper discovery before issuing the RFP and, therefore, missed major functional requirements that are not identified until more intensive discovery occurs during development or initial implementation;
• agreed to a contract that was far too specific and did not allow for the reality that requirements do evolve over time (though often not in ways which substantially change the nature or quantity of work);
• agreed to a contract that was far too vague such that the vendor can claim to have delivered a product or service when they did not meet already identified functional requirements for the system;
• did not take into account the preparation and costs required to sustain the product beyond the life of the initial engagement with the vendor.

These are the main things that lead to change orders. If the government agency is doing a top-notch job, they can all be avoided and the only occasion for a change order should be large external shocks that dramatically alter the functional requirements, intentional decisions to move away from the initial functional requirements that weighed the costs of altering the vendor contract, and a desire to extend and expand a relationship because of the success of the initial implementation resulting in a substantially more advanced or mature product.

It is really hard to manage vendor contracts right. It requires actually knowing what you want to buy before an RFP is issued (or recognizing what is and is not known and correctly assessing the scope of the impact future decisions on unknowns will have on the work). It requires a really good team of lawyers to fight outside forces that literally make their profits on carefully abdicating as much responsibility as possible at the contracting phase. It requires selecting good partners that are adequately willing and prepared to evolve and work with the agency as their needs and knowledge grow and mature. It requires an honest assessment of future resources that will be available to assure sustainability of large investments. And perhaps most difficult of all, it requires strong project management infrastructure throughout the entire agency to ensure alignment and consistency across multiple products produced internally and by multiple external partners.

The benefits of outsourcing products can be huge and are worth leveraging. Vendor contracts are difficult to manage, and bureaucracies are not always well-suited to managing these projects, but all government agencies struggle with getting this right.

One last parting thought…

In my view, the most challenging aspect of getting vendor contracting right for government agencies is spending ample upfront time, even before issuing an RFP, articulating the functional needs that a solution must meet in detail. I feel that often public sector employees are so intimidated by the arduous process around issuing and awarding an RFP that they rush to get an RFP out there and worry about the details during contracting and product initiation. Whenever possible, resist this temptation at all costs. Whether custom designed internally or provided by an external vendor, satisfaction is dependent upon clarity of the desired outcomes. This is particularly true with technology projects. Vendors will always produce something, but whether the solution is any good is almost entirely up to good requirements gathering.