Statewide Longitudinal Data System RFP Process
29
Office of Superintendent of Public Instruction Olympia, Washington Statewide Longitudinal Data System RFP Process
Transcript of Statewide Longitudinal Data System RFP Process
Office of Superintendent of Public Instruction
Olympia, Washington
Statewide Longitudinal Data System RFP Process
Washington State Profile66,544 sq. miles Land area (2000)
6,287,759 Population (2005)
Under 5 yrs old 6.3%
Under 18 yrs old 23.6%
1,013,189 Students (K12)
58,011 Classroom Teachers (K12)
17.4 Students per Teacher
7 Student Information Systems
40 School Districts w/o a SIS
Brief History
3
2002 – OSPI began creating the Core Student Record System (CSRS)
2003 - created the State Student Identifier (SSID)
CSRS V2 enhanced the SSID system by collecting student data element information
School districts push a monthly data file
Goals of RFPSelect the best partner the state could grow with
Create buy-in from vendors, school districts and ESD’s
Reduce the data collection efforts of the school districts
Collect more dataStudent to teacherStudent to courseTeacher to courseStudent to program
RFP ProcessCreated a data advisory committee
School Districts, Educational Service Districts, and multiple vendorsDiscuss Challenges with current systemData to be collected and why
Communicate statewideLeveraged educational video conference system
RFP ProcessRFP review committee
One SIS Vendor, Two District CIO, One ESD CIO, Agency Developers, agency CIOReport back to advisory committee
Helped develop the RFPReviewed the RFPSelected the final candidate
RFP ProcessScored each RFP based on:
Technical/Design ImplementationCostsProject PlanningExperience of companyExperience of implementation teamFiscal Health
RFP ProcessFace to Face Interviews with Management and Team
Selected final 4 based on scores for interviewsSelected final two for additional interviews
Selection completed Contract Negotiations SOW
RFP Lessons LearnedNeeded more detail about current state systems
Expect to be challenged by vendors once selection process is complete
Thoroughly address security in RFP
Be extremely careful Competition is fierce – RFP and SOW must be strong
Be detailed but be careful - Don’t want to get locked in because of minor changes
Add-on or out of scope will be costlyCOTS solutions – high long term licensing costs
Center for Educational Performance and Information
Margaret Merlyn Ropp, Ph.D.
NCES MIS ConferenceMarch 2007
Responding to Needs – Next Generation Systems• Vision – Collect once, store once, use
many times –– Good stewardship of data and resources
at the state and local levels• Student Data System – why rewrite?
– Funding (FTE) vs. Accountability –where is a student at a point and time and who is responsible?
– Lack of Alignment with federal reporting deadlines and longitudinal
– Current process resulted in “collect many times, store many times and use once!”
Responding to Needs – Next Generation Systems• School Code Master (Educational Entity
Master)• Student data system could not be rewritten without
changing the underlying structure of entity relationships
• “Schools” are more than buildings at which you report a broken window– Consortia– Charter schools– “Virtual schools”– Early Childhood providers outside of the K-12
constellation– Accountability – who is responsible for providing
instruction?
Procuring Two System Rewrites – The Challenges
• Needed new ideas + migration from existing systems– Multiple existing student data systems that need to use one
Unique Identification Code (UIC) – e.g., assessment, special education, career and technical education, adult education
• A vendor generating a statement of work for an RFP or requirements is prohibited from winning another contract for system design and implementation.
• Needed a blend of transactions and snapshots to determine how frequently to update specific subsets of data elements and a create manageable workflow
What we requested…
• RFP included multiple components –vendors could bid on one or more options– Detailed requirements gathering– Student Data System– Education Entity Master– Optional student transcript functionality
What we got...
Vendors developed partnerships to bid on all the components
• Commercial Off-The-Shelf (COTS) solutions• Warehousing solutions based on ETL
processing• Customizing some existing resources• Build-from-scratch 100% customization.
What we learned…
• Managing a fixed-price deliverable bid– Added 2,000 extra hours for unknown
requirements– Vendors asked many questions to clarify
the scope – we had 90% of the high-level requirements completed
Procurement Tips• DO
– Include cross-agency/program stakeholders on the JEC - locals as advisors
– Create a template for cost breakdown –hours by role, estimates for state infrastructure requirements
– Make sure IT is ready to go – vendors may propose cutting-edge when government values stability and older software versions
– Ask trusted colleagues to review the statement of work
Lessons LearnedOhio’s Request for Proposals (RFP):
Education Management Information System Redesign for Longitudinal Data
Beth JuilleratChief Information Officer
Background•1990
The Education Management Information System (EMIS) was developed for ODE to collect aggregate student data from LEAs.
•1998 A change in state law enabled the collection of unidentifiable student level data via the use of a unique data verification code.
•2003 No Child Left Behind introduced new requirements for disaggregation of data and calculating adequate yearly progress.
ODE began collecting student data with a unique identification number.
System Inefficiencies
• Collection and storage of duplicate demographic data across various student data files
• Continued data storage in flat file formats that limit efficientaccess, management and use of the data for longitudinal analysisand linkages between student and staff data
• Continued restrictions of the collection of data to a weekly batch mode rather than utilizing new technologies and standards to support real time data submissions
RFP Objectives
• Improve the Education Management Information System reporting from the 26 regional sites to the Ohio Department of Education using School Interoperability Framework standards and infrastructure.
• Allow school district data to be shared more efficiently and effectively with the Ohio Department of Education using School Interoperability Framework standards and infrastructure.
RFP Objectives
• Design, develop and implement a relational database structure for efficient data validation, maintenance, and retrieval of data.
• Enable the Ohio Department of Education to more efficiently and effectively manage longitudinal student data for operational purposes and decision making.
Lessons Learned
Request for Information (RFI)
• Provides an open forum for feedback and questions from potential vendors.
• Brings to light areas in which there was lack of clarity in the scope or goals of the project.
Lessons Learned
Clear and Concise Business Objectives
• Clearly state the business problem to be solved and the objectives of the project
• Articulate the limitations or inefficiencies of the existing system
Lessons Learned
RFP Writer Qualifications
• Must have a good understanding of the business objectives for the project and the scope of the initiative.
• Must be familiar with the state procurement process and structure.
Lessons Learned
Involvement and Communication
• Initiate and require frequent discussions with procurement administrators
• Solicit assistance and feedback from education and technology stakeholders
•Leverage available expertise such as SIFA
Lessons Learned
TIME……TIME ……TIME ….NEVER ENOUGH!
•It always takes more time than you plan!
•Build in EXTRA, EXTRA time for multiple iterations and reviews, including legal!
