Debbie Karcher is an accomplished and creative IT executive who served as Chief Information Officer from Miami-Dade County Public Schools (M-DCPS), the fourth-largest school district in the US. During her 15-year tenure with M-DCPS, Debbie managed information technology operations and network infrastructure for more than 37,000 employees and 340,000 students and led the District’s IT strategic vision and long-range planning. Currently, as a K12 Education Technology Advisor, Debbie utilizes her diverse experience and understanding of current and future IT trends, as well as her proven ability to revitalize district operations through the implementation of enterprise systems, to direct information technology strategy for leading K12 edtech companies.
Whether a large or small district, there are some things that can be done to increase operational efficiency. These do not always have to be elaborate systems or processes. Most can be discovered by taking a fresh look at your operations as if this was your first day on the job. Some of these are simple changes but are sometimes difficult to implement because they go against the culture. But they can be implemented successfully by providing reasons and benefits of the change and making sure that everyone wins. One of the most time-consuming and difficult operational activities is the Request for Proposal (RFP) process. This article deals with (RFP) process specifically with new system implementations from the vantage point of a large district.
Over the past two years, many RFPs have been issued because of the funding made available through AARP and ESSA funding. Past experiences and policies have resulted in pages and pages of requirements often driven by the RFP process itself, hoping to prevent project failure and litigation. Usually, to protect the stakeholders, every functionality ever seen, thought of, or heard of is included. In a recent RFP for an LMS, it listed 78 major requirements, with several sub-requirements. Every response must be reviewed, and the results documented by all the RFP voting members.
This requires a great deal of time and effort by the district’s procurement office, the vendors responding, and the selection team. All parties must make sure that every i is dotted and t crossed. If a vendor fails to respond to any part of the RFP, they can be eliminated. The more requirements, the more chance of oversight by all parties. It has also been my experience that a yes to check off a box may be true, but the expectation is barely met. The remainder of this article will discuss a very targeted approach to identifying core requirements, objectives that summarize functional requirements, pricing considerations that result in apple-to-apple comparisons a pre-work stage that will identify gaps in the project scope, and the benefits of this approach.
By the time a district reaches the RFP stage of an initiative, the stakeholders have probably been visited by multiple vendors, seen several product demonstrations, and have a good understanding of product functionality. During this period the stakeholders should be documenting the functionality that is common in all the products. Whether it is Human Capital, Finance, Student Information Systems, (SIS), or Learning Management Systems (LMS) all similar modules will offer similar functionality. The differences such as the platforms, scalability, system architecture, reconfigurability, and the number of modules offered should also be noted. After meeting and learning about these systems, stakeholders should have a list of unique and required functionality exclusive to their districts.
Because of this research, the stakeholders can move from an RFP to an Intent to Negotiate (ITN). While both are used in a competitive bidding process, an ITN allows an organization to enter negotiations with one or more vendors and lists only the general requirements without a specific outcome in mind. While an RFP has very specific requirements and vendors are awarded based on meeting criteria. The ITN should be limited to key operational goals and ultimately pricing. Once a provider is chosen through the ITN process the project will move into a pre-work stage.
The pre-work stage involves the district stakeholders and providers and will identify missing requirements, gaps in the project scope, and financial impact. At this time the district and provider can renegotiate the contract terms or if the financial and/or resource requirement is too large the contract can be terminated. This protects the district from cost overruns and scope creep.
The pre-work stage should include the following:
- Base system is configured to determine how well the system will work with the district data and infrastructure.
- Identifying integration points and understanding new processes
- Identifying testing and professional development requirements
- Stakeholders can test drive the system giving them a chance to see the solution in action.
All parties win by changing the RFP to an ITN. There is some risk because the number one choice may be rejected after the pre-work stage. But it is better to know the shortcomings prior to implementation than having a failed implementation or unhappy users. Both can create local headlines.