ED STEPS

Document Information

Title

ED STEPS (System of Tiered E-Plans and Supports) Vision Document

File Name:

ED STEPS Executive Working Document v1.2 03 27 18

Status:

Executive draft working document with ongoing modifications and enhancements

Version Number:

V1.2

Version Date:

03/27/2018

Working Group:

ED STEPS Group

Template Version:

1

Project Manager:

Troy Berry

Project sponsor:

Jeremy Marks

Technical Lead (1):

Technical Lead (2):

Chris Helten

Richard Skinner

Technical Writer:

Priyanka Pavthawala

Version History

Number Date

Description of Change

1.0 02-16-2018

Original

1.1 03-15-2018

Committee updates

1.2 03-27-2018

Committee updates

Purpose of the Document:

Capture the ED STEPS vision and workflow required for implementation, including detail required to transition from design to development. This is an Executive Draft document undergoing numerous revisions throughout all phases of the project as sub-committees gather additional requirements and develop the system.

Table of Contents1. Introduction71.1 Executive Summary71.2 ED STEPS Timeline Overview91.3 Purpose of the Document111.4 Scope of the project121.5 Goals and Guidelines121.6 Assumptions and Constraints132. System Functionality Overview152.1 Executive Summary152.2 Workflow152.3 Impact on exiting systems162.3.1 Comprehensive Continuous Improvement Plan (CCIP)162.3.2 Compliance173. Development Method and Techniques203.1 Executive Summary203.2 The Agile Approach203.3 Architectural Strategies214. ED STEPS Process224.1 Overview of ED STEPS process224.2 Overall Process Workflow and Business Rules225.Component 1: District Dashboard Summary (DDS)255.1 Overview of DDS255.2 The Dashboard practice:255.2.1 Navigation275.2.2 Alerts and Queueing:285.2.3 District/Building Overview (Demographics)295.2.4 Document Library / Reporting:306.Component 2: Decision Framework (DF)326.1 Overview of DF326.1.1 Business Rules326.1.2 The Requirements326.1.3 Roles Allowed326.2 The Decision Framework Practice336.2.1 Access336.2.2 The Landing Page336.2.3 Triggers346.2.4 Categories and Sub-Categories346.2.5 Questions and Answers366.3 The Review Process376.4 Root Cause Analysis377.Component 3: One-Plan397.1 Overview397.2 Business Rules397.3 Plan Submission397.4 Roles Allowed397.5 The One-Plan Practice407.5.1 Access407.5.2 Plan Participants417.5.3 Goal Creation417.5.4 Strategy Creation437.6 Student Indicators/Measures447.7 Implementations and Resources477.7.1 Implementation Response477.8 Financial Linkage487.9 Process Iteration487.10 Audit Process487.11 Building Process498. Component 4: Consolidated Competitive Application (CCA)518.1 Overview518.2 Grant Review518.2.1 Competitive Grants528.2.2 Discretionary Grants528.2.3 Entitlement (Formula) Grants528.3 The Consolidated Competitive Application Practice528.4 List of Components539. Business Process Strategy6310. Project Estimates6510.1 Development Estimate6510.2 Development Timeline6511. Appendix Section67Appendix A: CCA All Grants Spreadsheet67Appendix B: The current list of triggers: B=Building; D=District (as of 1-8-18)68Appendix C: Participant Role for Planning71Appendix D: Grant Table73Federal Grants73Competitive Consolidated Grant74State Grants75Appendix E: List of Grant and Component applicant Will Utilize76Appendix F: List of Business Requirement (Rules)79Appendix G: Workflow process charts84Exhibit 1.1: Dashboard Sample84Exhibit 1.2: Dashboard Framework84Exhibit 1.3: Decision Framework85Exhibit 1.4: Decision Framework High Level User Flow85Exhibit 1.5: Decision Framework Process Flow86Exhibit 1.6: Decision Framework User Flow87Exhibit 1.7: One-Plan Framework88Exhibit 1.8: One-Plan goal User Flow89Exhibit 1.9: One-Plan Strategy User Flow89Exhibit 1.10: Consolidated Competitive Application Framework90Appendix I: CCIP System Overview91Appendix J: Terms and Definitions92Appendix K: Cost Estimate95Appendix L: Timeline estimate95

1. Introduction

The Ohio Department of Education (ODE) is the State Education Agency (SEA) responsible for public primary and secondary education. One of the core functions of the ODE is to ensure the state and its local educational agencies (LEAs or districts) adhere to federal requirements, including the planning for and use of federal resources. Since the early 2000s, the ODE has used a web-based tool known as the Comprehensive Continuous Improvement Plan (CCIP) for federal planning and resource allocation. The CCIP includes information on key federal education laws including the Elementary and Secondary Education Act (ESEA), Individuals with Disabilities Education Act (IDEA) and the Carl D. Perkins Act.

The ODE was a pioneer in the development of the CCIP and the software was a model used across the nation. Over the course of more than a decade, CCIP has taken on more functions and features than were considered in its original design. The CCIP functionality, interfaces and usability became outdated and compliance oriented. The ODE has several needs assessment tools, including one used only for certain entities in the CCIP. Educational entities are required by state and federal laws to submit many types of plans. The CCIP’s planning component is limited, narrative-based and unreportable. The CCIP planning component has a “one-size-fits-all” feel and is not comprehensive. Typically, a district’s “real plan” is not the “compliance” plan in the CCIP.

1.1 Executive Summary

In 2014, due in part to user-feedback, the ODE began exploring improvements to the system. In the summer of 2015, the ODE started an analysis of the CCIP, particularly around the planning component. The analysis lasted two years learning what customers liked and didn’t like about the system and their ideas for improvements. During the analysis, Congress enacted a reauthorized ESEA known as Every Student Succeeds Act (ESSA). The ESSA generally moved away from federal prescription to state determinations for complying with the federal requirements. More responsibilities were placed on states to develop their own “play book”. The timing of the re-authorization reinforced the efforts to redesign and align the various e-planning systems, improve cross-agency collaboration, breakdown programmatic siloes and focus on supports and quality of plans.

In 2017, the ODE began designing the ED ODE System of Tiered E-Plans and Supports (ED STEPS). ED STEPS involve more than just improvements to system and applications; it is a process for continuous improvement involving both human capital and the technological tools. ED STEPS include cross-office collaboration within the ODE to address questions, provide services and improvements, and align technological tools that internal and external customers use.

ED STEPS web-based systems will be built for and designed substantially by the customers. The ODE’s goal is for its customers to want to use ED STEPS systems, not because they are required to do so. Advantageously, ED STEPS systems and support structure fit nicely with the transition to ESSA and roll out of the ODE`s work on a comprehensive strategic plan for education in Ohio.

There are seven inter-related components of ED STEPS that will be linked for ease of use and real-time data sharing. A core feature of ED STEPS system design is the need for it to be flexible enough to adapt to statutory, regulatory and business designed changes. Once developed, ED STEPS systems will be phased in over the course of a school year according to the customer’s time line for work. Support and training will be provided during each system release. A target completion for the entire ED STEPS systems is expected during the 2019-2020 school year. In the future, other systems including but not limited to Compliance, Comparability, Nonpublic Data, and FLICs could be linked with ED STEPS structure. The main components of ED STEPS systems improvement structure include:

1) Dashboard Summary: A 1-5-page printable summary of the district’s plans, needs, monitoring supports, and programmatic operations tied to funding and outcomes over the last 3 years. Potentially called the “plan report” it could serve as the public view of ED STEPS (along with a guidance library).

2) Decision Framework: The state, district and school’s one and only one required needs assessment. It includes more than just academic needs and will be required every year. The core function is to design 3-year plans and apply for annual competitive and formula funds.

3) One-Plan: A user-friendly and intuitive comprehensive plan that allows districts/schools to design their own unique goals and strategies. It includes features like drop down menus to select answers so the agency can aggregate/report on the plans. It always allows for the districts to write in other goals and strategies as well. Quality plans may be approved for up to 3 years and are linked to annually approved funding applications. For each activity/strategy the district will select from the available types of funds (e.g. Title I, II, IDEA, and GRF). Clicking on the type of fund will provide a listing of allowable uses. A 3-year estimate of available funds will be present in the Plan that will be adjusted during the annual funding application. The overall intent is to “fund the plan, not plan the fund.”

4) Consolidated Formula Application: The annual funding application is to be linked to the 3-year plan. The budget details required in the application should be streamlined to include only what is necessary for approving the ability to draw funds.

5) Consolidated Competitive Application and Process: A consolidated competitive application, like the consolidated formula, created in a way that focuses on the quality of the needs assessment and plans, not the quality of a grant writer. It will provide a listing of the competitive grants for districts to select from based on needs (with the system able to automatically highlight eligibility). An application is created with the selected grants. Needs assessment is repopulated and standard questions are answered once all grants are selected. The applicant addresses grant specific questions and develop plans. A unified/standardized scoring and review process is developed to score grants individually and awards are provided collectively.

6) Guidance Library: A streamlined and updated repository of all important guidance documents (collectively for public view).

7) Communications Portal and Library: Enable communication between ODE staff (individual and team) and district personnel on grant related issues. Also, the location to provide important notifications (i.e. grant awards) and district specific documents and guidance.

ED STEPS will have the following functions:

· Design and develop planning, needs assessment, visual components and common triggers to focus needs assessment efforts at the district and building level.

· Analyze and track grant management progress, status of work, assessment and support of current and future requirements.

· Guide and identify opportunities based on known information and create a framework to unify and simplify the competitive application.

· Master View for ODE, district and building which will display the One-Plan process.

1.2 ED STEPS Timeline Overview

January 2015

Gained approval from IT Governance to conduct an Analysis of CCIP.

Summer 2015

Contracted with PSI on two phases 1) As Is and 2) To Be recommendations.

2015-2016

PSI analysis provided technical flow of current system and gathered internal and external feedback for recommendations. CCIP advisory group formed to give feedback.

November 2016

Concluded PSI analysis.

March 2017

Created ED STEPS Steering Committee.

April 2017

IT Governance approved request to move forward with ED STEPS. Two-phases:

· Phase 1: 6-9 months of planning

· Phase 2: 1-2 years of development, beta testing, education and release

April-June 2017

Designed ED STEPs sub-committees including representatives from all 4 centers. Approximately 50-60 ODE staff regularly engaged in work.

April-June 2017

Pilot district selected for ED STEPS process (non-systems) regarding cross-agency support structure (teams to support the districts with their planning and implementation needs).

July 2017

· Two contract specialists brought on.

· Tech specialist and tech writer to work with Steering Committee, sub-committees, project sponsor and project manager to develop the vision document blueprints for development.

July2017-March 2018

Gather data, design flows, business rules, etc.

Nov-Dec 2017

CCIP advisory group reconvened (renamed ED STEPS advisory group). Feedback for each stage (design, development, and release).

March 2018

Phase 1 completed. Blueprints will provide options for meeting the work that needs to accomplish.

March 2018- June 2018

Phase 2: Determine project approach; level of resources available; funding options, initial and ongoing. Determine in-house or RFP and contract.

July 2018- June 2020

Phase 3: Development phase; Agile approach with iterative deliverables, continue ED STEP advisory for feedback.

1.3 Purpose of the Document

The purpose of ED STEPS or ODE CCIP upgrade project is to make the system processes simple, collaborative and user friendly for the applicant and up-to-date with the most current upgrades and patches. In addition, this project will use best practices to create a standard template that can be followed for future upgrades of ED STEPS.

This document provides a comprehensive overview of ED STEPS. It delivers an outline of the processes, elements, management structure and component functionally of ED STEPS system to internal stakeholders including technical and non -technical ODE personnel. It defines the top-level business rules, workflows, collaborative approaches and interface components.

The purpose includes:

· To enumerate, at a high level, each of the elements and components identified as part of the system and how these elements and components are processed (related). These element details are leveraged (implemented, discussed) by one of four ODE sub-committees and a chair person.

· To explain the technical foundation that has guided the design and service of each component within the CCIP system.

· To provide comprehensive guidance to internal stakeholders and solution providers seeking to implement management structure, tool functionally, and to set expectations as to how these elements will function.

Intended Audience:

· LEA

· District

· Building

· ODE

1.4 Scope of the project

System Components

Component Overview

Dashboard Summary

1-5-page summary for public view of the last 3 years of grant/funding/needs/plans. It will include visual data trending, status and progress reporting.

Communication

Linkage and communication across all systems and data. Use of alerts and queuing.

Development of Decision Framework

Enhancements to the needs assessment requirement (ESEA requirement) to include non-academic issues and the ability to develop needs assessment reports for required grants (e.g. School wide, Title IVA, Title IVB).

Development of One-Plan System

Develop a comprehensive One-Plan for all required plans or a library of federal and state planning requirements in one location. The plan will need the development of a bank of goals and strategies, a bank of components and a drop-down menu of potential answers to goals and strategies.

Development of Consolidated Competitive Application

Like the application for consolidation of federal formula funds across ESEA, IDEA, etc.; this system will include a listing of competitive state and federal grants for districts to select. Significant data and field requirements would be uploaded from the DF and Plan into the system. Includes grant specific questions.

1.5 Goals and Guidelines

· To understand adequacy and workflow process for a new ED STEPS framework.

· To optimally meet the business needs and requirements of district users and the program office.

· To gather, compile, consolidate and analyze the extensive information about needs assessment, goals, strategies, status and progress of the grant process.

· To formulate a process that is easy to understand and simple to navigate for users.

· To provide high quality tools, uniformity and reduce the number of steps it takes to route to specific areas.

· To deliver improved user flow, assist the users by queuing and alert and track the users and associated task specific interactions.

· To make the workflow intuitive, user friendly and collaborative.

1.6 Assumptions and Constraints

Assumptions

Alert and Notification

Alerting enables users to set their own warning and critical thresholds so they can stay on top of finding and resolving problems quickly. Users can view more detailed information on alerts by selecting an alert button.

Configurable Security

Data Security will be the top concern of ED STEPS. System security will protect sensitive data and provide complete control over the process.

Less- comprehensive

ED STEPS process flow is less comprehensive and more selective in nature. Some pre-populated options will be given to select one per category. It will increase the overall productivity of the Grant process.

User Friendly

System will eliminate repetition and unnecessary steps from the process. It will be more satisfying to use and provide easier navigation in all phases.

Document Linking

The ability to link documents together will help to organize documents into logical groups. It will reduce data input and automate the process.

Efficient in Flow and Design

Improved user flow, assisting users by guiding, alerting and tracking the user and task specific interactions. An automated workflow process that supports the notification, coordination and collaboration of people that implement a process.

ODE Support

Support will be provided by ODE experienced staff throughout the grant process to the related audience.

Reports

The Dashboard will generate a report of the Needs Assessment and Planning process to display their progress and status of work.

Constraints

Complex and overwhelming structure

ED STEPS process involves iterative actions, additional features and functionality which is sometimes complex and difficult to understand.

Limited resources

Time consuming process

District will approve building plan. So, building is dependent on district; building would not be able to move forward without district approval.

Accessibility

Only authorized users will be able to do planning and needs assessment.

2. System Functionality Overview

2.1 Executive Summary

CCIP users must deal with a system, once state-of-the-art and cutting edge which has become cumbersome and outdated. While keeping the financial portion of the application fairly intact, the ODE is going to replace the front end of CCIP with a new ED STEPS process flow application. ED STEPS will provide an efficient workflow, a parameter and table-driven system minimizing narrative responses, and a fresh look and feel. It will streamline the work process and provide support and simplicity along the way, a system of tiered E-Plans and supports. ED STEPS system requires four (4) distinct phases, each with distinct functionality and unique workflows. These phases are:

· The Dashboard is the printable summary for districts and an ODE/public view of the last 3 years of needs, plans, funding and outcomes. It ensures linkage and data flow across all systems. Dashboard initiatives are meant to develop a comprehensive profile overview of district information that provides viewers with better statistics showing results, evaluations, and assessments.

· The Decision Framework is the customized state, district and school needs assessment. It can develop reports for the required individual district and school needs assessment (e.g. School wide, Tittle IVA, and Title IVB). It includes academic needs and drives the planning and application for funds.

· The One-Plan is a comprehensive listing of plans for all required state and federal plans. One-Plan ideology satisfies a district’s and school’s planning needs and offers a planning solution which allows users to update and make changes to required plans without losing the integrity of the previous plan.

· The Consolidated Competitive Application provides a listing of competitive grants where districts can select and apply. It mainly focuses on the quality of the needs assessments. It develops standard scoring and grant reward processes. The Competitive Application ensures system awards are based on individual grant scores.

2.2 Workflow

The new ED STEPS process workflow will provide the following capabilities:

· A process of supporting customers, a framework to drive collaboration, and a methodology to streamline and simplify workflow.

· Ensures information from district/school needs and plans is pre-populated where possible.

· Prioritizes areas of need, makes decisions based on an analysis of data, and identifies root causes of prioritized needs.

· Develops a library of plans based on ODE goals and topics, develops SMART goals for each plan, and develops a bank of strategies for each goal.

· Consists of visual trending data, tool tips and visual deadline notifications, and develops a comprehensive profile overview of district information that provides users with better statistics of results, evaluations, and assessments.

· Automatic notification of document updates, download and print options, and other important events.

· A document Library including various important documents related to Decision Framework, One-Plan, navigation within system, guidelines etc.

2.3 Impact on exiting systems

ED STEPS will have an immediate impact on two existing systems… CCIP and Compliance. ED STEPS will replace roughly half of the CCIP system by eliminating the planning portion of the system while retaining roughly half, the financial or budgeting portion. There is less impact on the Compliance system. The scope of the work there is twofold. One, get information in an automated or manual fashion into the Compliance system to indicate which grants were awarded to which applicants. Second, modifications to the system to allow Compliance employees to view ED STEPS data required for an audit. This work is not a rebuild of the system. The detailed impact and explanation for each system is below.

Please refer to the charts below for a before and after pictorial representation of the inter-related nature of these existing systems and the new ED STEPS.

2.3.1 Comprehensive Continuous Improvement Plan (CCIP)

Originally it was thought that ED STEPS system could simply route the users working with the Decision Framework, One-Plan, and Consolidated Competitive Application into the CCIP system and back again after the user has completed the financial portion of their plans. This has proven to be a simplification and there is more of an impact. Simplistically, since ED STEPS is replacing the front-end or planning portion of CCIP, the challenge will be to determine what financial or budgeting portions of the system require data from the planning portions that are going away. The system would likely cease to function or function sporadically without this data. ED STEPS must replicate and provide this data to allow the financial or budgeting portion to continue functioning. The financial portion of the system is solid and well thought of so it is being retained for the foreseeable future.

The intersection of the new ED STEPS and the existing CCIP system occur visually at the Plan Relationship screen. It is not clear where this intersection occurs behind-the-scenes or programmatically from a processing or data perspective, but this needs precisely defined by the CCIP maintenance/support team. This will allow for the maintenance/support team to prepare a detail design document showing what program modules and data files are impacted and must be changed. This can in turn become input to a development plan and schedule with timelines and milestones. The development effort that must go into revising the CCIP system should take place in concert with development of the new ED STEPS system as one affects the other. This will make implementation of ED STEPS more difficult as the timing of the two systems now must be synchronized. Once the data and processing requirements are defined ODE can identify the data components that can be brought over from ED STEPS or allow the CCIP system to function differently if the data is either not available or not required to complete CCIP processing.

Please refer to Appendix J for an overview flowchart of the CCIP System.

2.3.2 Compliance

As already stated, there are two elements of the Compliance system that will be affected by the new ED STEPS application. Neither need be time consuming or difficult.

First, ED STEPS must account for getting information in an automated or manual fashion into the Compliance system to indicate which grants were awarded to which applicants. This may be done by building a data interface to load data from ED STEPS into the Compliance system periodically as grants are awarded. This may also be as simple as a manual entry into a table of the grants awarded and the grant details so that Compliance may track the progress of the grant.

Second, since the planning portion of CCIP will no longer be used, the planning data (e.g. goals, implementations, action steps) for Compliance will no longer be available. ED STEPS data must now be used instead. There are two options for providing the required data. ED STEPS may provide view only access to Compliance employees to the system so that their auditors may view the One-Plan details within ED STEPS system. This might be clumsy and inconvenient as the Compliance auditor would have to navigate two systems during the review. The other option is to generate standard reports out of ED STEPS based on criteria and requirements supplied by Compliance. These standard reports could be run off the Distract Dashboard on demand and provide whatever details and data would be required by the auditor.

Both system intersections between ED STEPS and Compliance need to be reviewed in detail by the Compliance maintenance/support team. The team can then prepare a detailed design document showing how to solve these issues programmatically. The team can use the detail design document to identify module and data changes required and prepare a project plan with timeframes and milestones.

Inter-related nature of systems (before ED STEPS)

Inter-related nature of systems (after ED STEPS)

3. Development Method and Techniques

3.1 Executive Summary

ED STEPS project employs an Agile Methodology for the development of different components of the framework. Agile provides for flexible, iterative development where releases are generated every week. This process allows for refinement of requirements and design functionality over the entire workflow. This framework also allows for a highly transparent and cooperative process with the stakeholders, providing a better sense of project progress than a more traditional approach. User Stories are used as the functional design definitions that the stakeholders will work on, which are added to a backlog that is prioritized based on stakeholder’s priority and technical need.

3.2 The Agile Approach

Recommended Agile Approach for Phase II

Since the Agile approach and process was used for developing the ED STEPS overview document, using Agile during the software development phase of this project becomes easier. All parties are familiar with the approach and their participation and buy-in have been assured. The software development project team must continue with Agile guidance and an Agile adoption strategy. The software development management team must enhance migration to Agile software development concepts using standard Agile terms and examples during progress reporting. The Agile teams themselves must continuously improve Agile adoption at the project and organization levels. The Agile team must look to identify and address impediments at the organization and project levels. The Agile team members must get constant stakeholder/customer feedback and get it often.

This Agile approach will entail regular meetings where completed software modules and functionality are viewed, tested, and either confirmed or enhanced. These steps will empower the small, cross-functional teams. The software development team must include requirements related to security and progress monitoring in the queue of work to be viewed, tested, and either confirmed or enhanced during regular meetings. The software development team will gain the Agile team’s trust by showing value at the end of each iteration. Agile team management will continue to use tools and metrics to track development progress. Software development team management and project team management will track progress daily and openly by having daily deliverables and weekly milestones.

An Agile approach is recommended for all project phases. In the first phase, an Agile methodology was employed allowing continuous feedback within the entire process. Given the immense value and perspective of both internal\external users, it will be imperative for their inclusion in the upcoming phases. Below is a brief diagram of the Agile Approach.

Each of the sub-committees will need to address this ongoing approach, however, I would look to adjust the schedule to upcoming activities and tailor to the unique requirements of the sub-committee itself. Sub-committee members may be switched between sub-committees and the composition of the sub-committees may change by adding new members (e.g. external advocacy). This is a great opportunity to mix the teams up to enhance cross-matrixed collaboration.

3.3 Architectural Strategies

Suggestion: Architectural Strategies

To ensure integration and alignment within current ODE systems, it is recommended that ODE utilize its own resources for the oversight and creation of any proposed architecture. ODE will define tools and technologies to be used that will adhere to ODE guidelines. ODE will define/approve any products, components, application packages, toolkits, etc. to be used in the development of this system. In addition, the following tenants will be followed:

1. Defined solution will interface with existing ODE systems (e.g. SAFE, OEDS, CCIP).

2. ODE will define and manage the changes to existing systems based on the proposed development of ED STEPS platform.

3. ODE will deliver oversight for any external development.

ED STEPS will be built and hosted in the new cloud environment. Details of this environment are now available in the ODE EAS Architecture documents.

4. ED STEPS Process

4.1 Overview of ED STEPS process

The flowcharts and process flows given as Appendix G in this document outline the entire ED STEPS workflow and provide insight into data relationships. The District Dashboard will serve as the entry point and the landing page for the subsequent workflows which will be accomplished by the ELAs and by the internal ODE employees functioning as the support team. Taking input from the district report cards (outside of scope for this project) the Decision Framework allows the district to perform a more focused Needs Assessment based on the eight (8) broad data categories and their sub-categories (Section 6.2.4 of the Decision Framework).

Based on a series of insightful questions the district can identify their primary areas of concern. These, in turn, feed the One-Plan where concerns are converted to goals, strategies, implementations and funding sources. The funding sources are realized by the Consolidated Competitive application where district representatives apply for grant funding. The entire process is simplified and streamlined and asks only of participants that they follow the prescribed workflow to accomplish the tasks at hand.

4.2 Overall Process Workflow and Business Rules

The flowcharts and process flows given as Appendix G are included to show the gathering and use of data components and to define in more detail how the system will work. It is a pictorial representation of the narrative that follows in this and subsequent sections. These documents will be used in the development phase of this project to guide the identification of program components, modules, tables, and data files or databases.

As will be described below, the application represents a series of processes which implies the completion of certain steps before moving forward. The application also defines each of the steps for each of the unique processes. As an example, please refer to Appendix G (1.3 -1.6) for various flowcharts and process flows for the Decision Framework. It shows the gathering and use of data components and how this process step will work.

There are overall business rules and business rules specific to various components. These business rules are those that could be identified at this level of specificity during this phase of the project. It is not meant to be nor is it a comprehensive list. The project will continue to generate additional business rules as the project progresses.

Please refer to Appendix F for all Business Rules.

Below is the sequence of the components.

ED STEPS District Dashboard Summary

(DDS)

5.Component 1: District Dashboard Summary (DDS)

5.1 Overview of DDS

ED STEPS District Dashboard Summary is an online multiple page visual analysis tool that displays key performance indicators (KPI). The DDS is used for district (supervisory), principal (building), and public utilization that contains previous metrics of grants, funding, needs, goals, strategies, plans, and student demographics and profiles. The new DDS UI (User Interface) will replace the present CCIP UI (User Interface).

The ODE SAFE (Security Application for Enterprise) account will be the entry point for the DDS page which aligns with the OEDS (Ohio Educational Directory System) system for role identification. All SAFE roles will allow entry to the DDS. The DDS will leverage OEDS Roles to identify available options that will be presented to the users. It is assumed that the following will be the only views that will be offered in the first phase of the development (district view, building view, ODE internal view). The difference between the 3 views will primarily be the information that is provided in the demographic section of the DDS. For a district, it will be the summary data for the district, and for the building it will be the unique data for the building. For the ODE internal view, it will be either the district or the building with additional search capabilities.

The initial public view of the DDS needs additional discussion and clarification and will gain clarity from the now active Roles discussion. If the user has a SAFE account they would see a link to the Dashboard in SAFE. Once at the Dashboard, there would be a search box most likely for the district. Clarification is needed for whether the public view needs to be hidden behind the SAFE account or whether a public view be accessible if the user has the link (URL). CCIP offers a link not behind SAFE. The Steering Committee should resolve this question before the application is made available. The public link should still take users to the financial information that they can see today. A link on the Dashboard should take users to the financial side.

There are business rules established for the DDS. These business rules are those that could be identified at this level of specificity during this phase of the project. It is not meant to be nor is it a comprehensive list. The project will continue to generate additional business rules as the project progresses. Please refer to Appendix F for DDS business rules.

5.2 The Dashboard practice:

After selecting District Dashboard Summary (DDS) from the available SAFE account, the system will evaluate whether the user is associated with more than one IRN (unique identification number for a defined entity within ODE). If the user is only associated with a single IRN the DDS associated with that user will be presented. If the user is associated with multiple IRN’s (or no IRN’s) the system will present the user with a search option (See Figure 1) that will allow them to search and select the IRN they will be using. Additionally, the system will support an option for a defined role to have an administrative view. When ODE users are working internally in the system, an administrative view will be the most valuable view. It will provide a landing page and the view will have the ability to pull up different IRN`s to review without requiring the user to keep going through the SAFE account.

The search feature will allow users to search by organization name, organization IRN, and county. A list of items will be presented that match the criteria and the user will select from the presented list. The user should only be granted access to their own DDS based on their role and the organization they represent per their current profile in OEDS.

Figure 1: Search Organization

The DDS will not be driven by any calendar open/close events. It will serve as the primary portal for ED STEPS services along with a few other links to valuable information. Most importantly it will serve as the alert and messaging system for the entire process. The DDS will be the communication hub for the ED STEPS Program. The DDS will offer 3 initial views/roles/presentations: district, building, and ODE Internal. They will all build on a common framework (Figure 2) that will allow for future growth. The DDS will have five core components:

1. Navigation

2. Alerts and Queuing

3. District/Building Overview (Enrollment and makeup of students)

4. Document Library/Reporting

5. Custom Views (TBD)

Figure 2. shows a quick overview of a sample screen highlighting each of these sections.

Figure 2: Dashboard Screen

Dashboard Screen (DDS)

Figure 2 depicts an early screen design sample for the Dashboard screen. This will be finalized at time of development. Real estate on the screen will be limited so prioritization will have to take place for what appears on the first screen due to space constraints. The sub-committee will need to define a top level or priority group of data and push the rest to a second screen or multiple screens.

5.2.1 Navigation

As depicted on the left side of Figure 2, the navigation panel allows a user to navigate to other functions of the ED STEPS process as well as other functional areas or systems. As the communication hub, it could also offer additional shortcuts to other supporting processes. The following describes navigation that will be required in the base version of ED STEPS.

As shown above in Figure 2:

Navigation Options

CCIP

CCIP is the Funding Application – This navigation button would go to the existing CCIP platform for Consolidated Entitlement Formula grant work and application.

Planning

The planning button would take the user to the new ED STEPS Planning process.

Decision Framework

The Decision Framework button would take the user to the new ED STEPS Decision Framework Process.

Grants

The Grants button would take the user to the new ED STEPS Consolidated Competitive Grant process.

Fiscal

The fiscal button would take the user to the project cash request in the existing CCIP system.

Customer Team

The customer team button will show a list of the full team and contact information that support the defined IRN. There will be a need to create a table to support this relationship and it should be easy to update by non-IT personnel. The feature should support a search and lookup function to add team members. Additionally, the feature should allow the ability to easily remove members from the customer team. Some examples of the roles that would be a part of a customer team are:

· Superintendent

· Assistant Superintendent

· Treasurer

· Fiscal Representative

· Homeless Coordinator

· Foster Care Coordinator

· Internal roles for Center and Offices

Document Library

A button for the user to easily access the current document library in the existing CCIP platform.

Performance Monitoring

A button for the user to easily access the performance monitoring (student and adult Indicators) which are defined during the One-Plan process.

5.2.2 Alerts and Queueing:

As depicted on the right side of Figure 2, this will be the message center and communications hub for ED STEPS. It will provide alert messages to LEAs and ODE support teams on statuses and activities. This will require a unique table dedicated to workflow and messaging and queueing. There will be an escalation and alerting feature that will notify both the Dashboard and the user’s email account. Moreover, DDS will identify and log the alert actions in a log or history type of table. The DDS will need the ability to clear the alerts.

Example of items to alert on: (A full list of alerts and queuing is being developed by the sub-committee and will be available before development begins.)

· Fiscal year opens

· Budget revision

· 2 weeks out from when things are due

· Equity opens

· A specific date window is closing

· The user has something to approve

· A process the user has started is not complete

· Receive alerts from the compliance system

5.2.3 District/Building Overview (Demographics)

As shown at the top of Figure 2, the district Demographics section will provide the district or the ODE support team information about the current IRN they are viewing or have selected to view. The following is a starting point for the information that will be provided. It is not comprehensive and will be completed during development efforts.

· User Name – Display the user’s name in the district demographics section.

· Enrollment counts – Display either the district or the building total enrollment. Provide a date that data is based on.

· Enrollment by subgroup as defined and used by report cards showing % and the count. Display a chart or table of the enrollment by each subgroup.

· Provide a link (hyperlink) to a comparison to like districts.

· Special Education Rating – Provide a link (hyperlink) to the report.

· Typology – Display the Typology of the district or building for the user.

· Sponsored Pre-schools – Display an indication as to whether the district or building has sponsored a Pre-school or not.

· Management Company – For Community Schools, display the management company if applicable. If not leave blank.

· Sponsor – For Community Schools, display the sponsor if applicable. If not leave blank.

· Different Designations – Building/District Labels, focus priority ADC, Independent, etc.

· School of Promise

· Green Ribbon Schools

· Leave open the option to include future data in this section. One area identified was ways to highlight the positive performing schools or districts.

· Show the Education Service Center (ESC).

· Show the State Support Region (SSR).

· Show the Area Coordinator Region (ACR).

5.2.4 Document Library / Reporting:

As part of Figure 2, the DDS will provide access to the document library and a complete list of the available reports. The reports could be considered views of the different stages of the ED STEPS process, or these could be a grant requirement, or even be a policy. This will be a single place (or portal) for information, guidance and reporting. The system will develop a table to support reports. The table will have a category component so it will be easy to add and remove reports from the system and allow for a better presentation. The complete list of reports is being developed by the sub-committee and will be available by the time development begins. Here are some sample suggestions for what this resource might hold (this is a list of placeholders for reports that needs additional clarification and definition).

Planning

· District Plan Components

· School Improvement

· Schoolwide Plan

· Educator Effectiveness

· Reading Achievement Improvement

· English Learners

· Professional Development

· Parent Involvement

· Strategic Plan

· Sponsor Plan (TBD)

· Sponsor Improvement Plan (TBD)

· Equity Plans

Performance Monitoring:

· Performance of Strategies

· Performance of Implementations

· Performance Measures in General

Decision Framework

· Needs Overview

· Needs Assessment

· District Needs Overview

· Grants:

· Grants Awarded

· Balance Available on any Grants

Other

· Special Education Profile (not here but with a link behind SAFE)

· Fiscal Reports – what has not been budgeted or spent

· Consultant Checklist

· Hyperlinks to Useful Information (i.e. other websites, doc library)

· History and Transaction Logging – Sort and select by Log type – offer logging option

ED STEPS Decision Framework

(DF)

6.Component 2: Decision Framework (DF)

6.1 Overview of DF

The DF will be the only Needs Assessment (NA) tool used for the state’s educational districts. The DF provides a structure for district and building teams (LEAs) to analyze data. The LEAs use the data to identify and implement a limited number (one or two) of high yield strategies which will produce a significant increase in the performance of all students. The areas of influence on which LEAs will focus these strategies are as follows:

· Curriculum

· Instruction

· Assessment

· School climate or parental/community

6.1.1 Business Rules

There are overall business rules and business rules specific to various components. Please refer to Appendix F for DF Business Rules. These business rules are those that could be identified at this level of specificity during this phase of the project. It is not meant to be nor is it a comprehensive list. The project will continue to generate additional business rules as the project progresses.

6.1.2 The Requirements

Initially the following organizational types will be required to use the DF:

· Districts

· Schools or Buildings

· Community Schools

· School sponsors

· Dropout Recovery

Other organizational types may be added later. The general rule of thumb is that any entity will have the ability to do the DF but they are not required to do so unless they seek federal funding or have some other compliance requirement.

6.1.3 Roles Allowed

The sub-committee continues to develop a roles table that will show, based on role, what roles can administer, view, or edit specific information in the DF. This table will be defined prior to software development activities and during production administered by a system administrator. It should not create additional roles but should leverage existing roles using additional classifications.

6.2 The Decision Framework Practice

6.2.1 Access

Users (LEAs) will access the DF through the SAFE account and the District Dashboard using their OEDS role and the role table. DF will open at a defined time for the next fiscal year (somewhere in the September timeframe) after the report card is out. There will be some unique rules for first-time usage that are currently being defined, specifically around what parts of the process the user can get to and when. Once a user has gone through the DF they will be able to move back and forth within the DF.

The DF will initially offer a search option (depicted as Figure 3) much like the ability today, or the opportunity to select an already defined relationship via the IRN and the OEDS role.

Figure 3: Decision Framework Application Search

The user will be able to search via the IRN, name, etc. and they will be allowed to select district or building if their current role allows them to. LEAs should only be granted access to their own DF/NA based on their role and the organization they represent according to their current profile in OEDS.

6.2.2 The Landing Page

The system will next provide a landing page that will hold their status and progress completion throughout the process. Here is a sample landing page (Figure 4) to better show the concept.

Figure 4 - Landing Page example:

After viewing this landing page information, the user will press the Start button and proceed to the data entry portion of the system.

6.2.3 Triggers

All activity in the DF will be based on the triggers for the school, the building or the district. There are school, building and district triggers based on report card data and other performance metrics.

6.2.4 Categories and Sub-Categories

These triggers have been correlated to a specific set of categories or data buckets. This method of categorization will allow for standardization of the DF and support analytical and statistical analysis. Each category will have several sub-categories to drill down and further delineate.

The following are the current list of categories and sub-categories. They are currently being vetted by the DF sub-committee and will be completed before development begins.

· Curriculum/Instruction/Assessment (CIA)

· ELA

· Math

· Social Studies

· Science

· Career Tech

· Graduation

· Students with Disabilities

· Assessment

· Career Tech

· All Students

· American Indian/Alaskan Native

· Asian/Pacific Islander

· Black, Non-Hispanic

· Hispanic

· Multiracial

· White, Non-Hispanic

· Economically Disadvantaged

· Students with Disabilities

· English Learners

· Children in foster care

· Military dependents

· Adjudicated youth

· Homeless children and youth

· Gender

· Human Capital (HC)

· Teacher Evaluations

· Equity

· Teacher Pipeline Recruitment

· College and Career Readiness (CCR)

· Career-Technical Education

· Career Connections

· Secondary Transitions

· School Climate and Supports (SCS)

· Chronic Absenteeism

· Discipline

· Mobility

· Leadership/Administration/Governance (LAG)

· Shared Leadership

· Equity

· Leadership Pipeline

· Operations (OP)

· Transportation

· Child Nutrition

· Fiscal Management (FM)

· Equity

· Shared Services

· Funding Allocation

· Internal Controls

· Community/Family Engagement (CFE)

· Partnerships/Needs (Mental Health, Medical, etc.)

· Assessing the community needs

6.2.5 Questions and Answers

After the landing page, the DF will display an entry page to the user showing the 8 data categories pictorially (see Figure 5). Each sub-category has been assigned a set of questions used to guide the user through the DF process and allow them to provide their specific answers thereby responding to the triggers. The Questions and Triggers table is as complete as it can be now (Decision Framework Questions and Triggers table in Excel). The structure, process, and fields are defined and acceptable. The design of the system to support this table is complete. The sub-committee is currently reviewing this table and will fill in the blanks with the appropriate SMEs (subject matter experts) prior to development time when the ultimate tables must be built. For now, the place holder is here to review again at development time. Navigation flexibility will allow the user to save, exit, and return to answer or update an answer at any time during the fiscal year or as long as the DF is open. The system should automatically save/archive a fiscal year once a new year is open.

Figure 5: DF categories:

Depending on a district’s, school’s or building’s performance the user will be presented with fewer or more questions. This will be a table-driven approach. The business rules will define the flow for priority, sequence and focus (e.g. an independent may have fewer required questions or everything may be based on performance). The system must provide triggers for community schools (not a building or a district) by organization type that would select the proper questions but not duplicate questions since these entities carry some attributes of both.

The user will select any one of the buckets to begin their work. Based on the bucket, the DF will present the list of questions to the user for that bucket. Some questions will be required, others will be optional and others may be suggested. The sub-committee is currently working on how to identify which questions fit which category. The table will contain a flag for required, suggested, and optional.

Each question presented will provide both the questions and a graphical representation of the data to assist the user in their response. The questions will exist in a table associated with the trigger that is building\district unique. The questions will also link to the category as well as a sub-category. The responses will be stored in a table that will capture the category, sub-category, and response as these will be used throughout the process as a captured need for the defined entity.

The user works through the categories until all questions have been answered. They will then mark the DF as complete.

6.3 The Review Process

The sub-committee is currently not anticipating any activity at ODE with the notification that the DF is complete. It is important to note that data becomes available from the DF at different times of year and various components, based on the need being addressed, become available at different times. The DF should be opened in the December-January time frame.

6.4 Root Cause Analysis

The sub-committee is currently defining the process for root cause analysis and feedback. This process should be ready before the development efforts begin. The structure exists on the questions pages to add 1 Root Cause question at the bottom of every question and answer page that focuses on two elements: what is the root cause here and what is being done to improve or resolve it?

ED STEPS One-Plan

7.Component 3: One-Plan

7.1 Overview

One-Plan is a process to address the Decision Framework’s Needs Assessment. The One-Plan system is comprised of a library of federal and state planning requirements. The focus of the One-Plan sub-committee was to use the new ED STEPS process to have the user answer a series of questions that would satisfy the academic or social (e.g. nutrition) need problem and suggest a “plan” consisting of goals, strategies and implementations to achieve the desired results.

The Data Collection Template for One-Plan (an Excel spreadsheet with the same title under the One-Plan Committee folder) must be converted to ED STEPS implementation categories (which are the 8 broad categories from the Decision Framework) before development. The district Improvement Components and EL Plan Components are required in the district plan. The Schoolwide Plan and School Improvement Components need to be available in the building plan. The EL Plan Components have been updated to incorporate the most recent ESSA language, however, the other components have not. They must be before development. The EL Plan Component document provides the description and recommended category for the component in the system.

7.2 Business Rules

These business rules are those that could be identified at this level of specificity. It is not a comprehensive list. The project will generate additional business rules as the project progresses.

Please refer to appendix F for One-Plan Business Rules.

7.3 Plan Submission

The following organizational entities can submit a One-Plan:

· District

· Schools or Buildings

· Community Schools

· SST

· JVSD

· CBDD.

A good rule of thumb to follow is that any entity receiving federal funds must submit a plan.

7.4 Roles Allowed

The DD sub-committee continues to develop a roles table that will show, based on role, what roles can administer, view, or edit information in the DF. This table will be defined prior to software development activities and during production administered by a system administrator. It should not create additional roles but leverage existing roles using additional classifications. The One-plan process will provide a framework for entering plans into a single location and allowing the district to track and monitor performance.

7.5 The One-Plan Practice

The Planning tool will follow the Decision Framework and Needs Assessment. The process will open at a specified time frame for the next fiscal year (the One-Plan will have the flexibility to allow different parts of the plan to open at different times). First time users will have a unique set of rules defined at time of development, however, ongoing usage will support a process for continuous updates and changes. To understand the overall process and work flows, please refer to Appendix G, Exhibits 1.7, 1.8, and 1.9. Alerts and changes will notify the ODE support team.

7.5.1 Access

To begin accessing the One-Plan, users will need a search option, however, where the system can associate the user to an IRN it should offer that as the primary option. Figure 6 depicts this capability.

Figure 6: Search

Users will enter the process via a SAFE account and be taken to the Dashboard. The Dashboard will offer a link or navigation to enter the One-Plan process. The process will identify the current fiscal year that is available (view only access to prior fiscal years will be provided). Upon the opening of a new fiscal year the prior year will close and the new year will begin. Business Rules for closing the old year and opening the new one will be developed at time of software development. The critical concept is that ODE will define planning as a fixed 3-year cycle, not a rolling cycle based on each entity’s participation. Their implementation cycle may be different and not coincide with the planning cycle but this does not change planning. Plans have multiyear impact.

Upon entry, the One-plan will present a welcome or landing page to users where they will pick the year they would like to either view or begin working on.

7.5.2 Plan Participants

Once they begin working they will be requested to indicate the members who participated in the planning (initial checkbox). The second step would be to list names and third would be to queue them to confirm.

Figure 7 shows the most current definition of the roles for those who participated in planning for each of the potential different organization types that have been defined by the One-Plan Sub-committee. Please refer to Appendix C for participation possibilities. Hovering over the information box will be helpful and will yield the type of positions relevant to this entity based on the organization type.

Figure 7: Plan participants:

7.5.3 Goal Creation

Users will then move on to goal creation. The goal creation process will allow the user to view the completed needs table that was created during the DF. The One-Plan will allow users to select the required need or needs that will assist in the development of the goal. The application will allow them to repeat this process multiple times until the user has created all the necessary goals required.

The Goal creation will take advantage of several drop-down items that focus on the creation of a smart goal. One set of need(s) will be used to create a goal. The same needs can be used to support multiple goals. This creates the need to have several tables to support each of the drop-downs. These tables will need to be operationally editable to allow for the addition/removal/edit of contained items. Additionally, updates should recognize whether the value is in use and then only allow for the item to be tagged for removal once it is no longer used within the system. (Concept: active or non-active).

Figure 8 shows current thinking on the needs and the drop-downs on goal representation.

Figure 8: Needs to goal:

Goal creation should be iterative and allow the user to create a single goal or multiple goals at this step in the process with the next step offering a landing page with tracking capabilities (see Figure 10). The tables for the smart goal should be easily editable and should have alert and approval processes to support. These will be defined during the queuing and alerts definition sessions.

Smart Goal creation will utilize the following framework.

“We will by by against . To better illustrate, below (Figure 9) are the dropdowns that will be created/populated with the most current data from the One-Plan Sub-committee as of publication of this document.

Figure 9: Smart goal components:

Measurement

Population

Category

By How Much

By When

Against What

Increase

All

Reading

1%

Calendar

State Assessment

Decrease

1st Grade

Math

2%

OELPA

Maintain

2nd Grade

Science

3%

ELA 1

3rd Grade

Social Studies

4%

4th Grade

Graduation Rate

5%

5th Grade

Absenteeism

6%

6th Grade

Progress to EL proficiency

7%

7th Grade

Attaining EL proficiency

8%

8th Grade

9%

9th Grade

10%

10th Grade

11th Grade

12th Grade

English Learners

Immigrant Children & Youth

From Figure 9 users could construct a Smart goal around Reading that would look like the following example:

Increase 3rd Grade Reading by 5% by June 30th, 2019 against State Assessment

The overall process should offer some sort of landing/tracking page which will offer a visual status of the process or indicate completion status. The system can use color or other attributes to illustrate the point.

7.5.4 Strategy Creation

Once the users have created all their goals the system moves them forward to the strategy selection process. The user will select or define the acceptable strategies they will employ to achieve their overall goal. The goal could have multiple strategies so the system should support a 1 to many relationships between goal and strategy as depicted in Figure 10.

Figure 10 – Goals to Strategies:

The first set of strategies that will be allowed will be the evidence based strategies. This clearing house of strategies, like the What Works Clearinghouse (https://ies.ed.gov/ncee/wwc/FWW), will be operated by ODE. There is a current project to develop this Ohio based clearing house of the acceptable evidence based strategies. Given the team is still in the design stage for this project, the sub-committee is assuming that the clearing house will exist and will allow for users of the planning tool to have a drop down with access to acceptable approved options.

The sub-committee will define additional business rules for defining strategies at time of development. Strategies will be shown based on several criteria (e.g. school status, goal type, perhaps grade spans). Initially, the clearing house should offer some search, sort and selection options.

The One-Plan sub-committee has identified the additional need to allow the user to select a non-evidence based strategy. Users would be allowed to manually enter a name for the strategy as well as a link to the strategy (ability to enter a hyperlink). There could also be the capability to upload a strategy. Additional business rules will be defined for what users can and when users can do this (i.e. everyone can use the evidence based, but only a certain population will be allowed to enter a non-evidence based strategy) (e.g. could be a federal mandate for a non-evidence based strategy).

The Building View is relevant here and will be defined later in the development process.

7.6 Student Indicators/Measures

As the user works through a single goal and selects a strategy for that goal they will need to define a student indicator or student measure for that specific strategy. There will be 1 student measure/indicator required for each strategy the user selects or defines. Figure 11 shows the elements required to capture or compose a student indicator/measure.

Figure 11: Student Indicators:

The student indicators/measurements Descriptor and What to Measure should come from these two primary sources or something closely related:

· The Report Card data categories and sub-categories. Those are:

· Achievement

· Performance Index

· Indicators Met

· Progress

· Overall

· Gifted

· Disabilities

· Lowest 20%

· Gap Closing

· English Language Arts (ELA)

· Math

· Graduation

· Graduation Rate

· 4 years

· 5 years

· K-3 Literacy

· Promoted to 4th

· Proficiency on test

· Prepared for Success

· ACT

· SAT

· Honors

· Advanced Placement Participation

· The 8 components /implementation categories and sub-categories identified during the decision framework. These are the latest as of the last sub-committee meeting on 3 -14 2018. They are being refined and will be finalized before software development begins.

· Curriculum/Instruction/Assessment (CIA)

· Literacy: Reading Achievement Plans

· Literacy: Striving Readers

· Literacy across content areas

· Special Populations

· Students with disabilities

· Assessment

· Career Tech

· Human Capital (HC)

· Teacher Evaluations

· Equity

· Teacher pipeline recruitment

· College and Career Readiness (CCR)

· Career-Technical Education

· Career Connections

· Secondary Transitions

· School Climate and Supports (SCS)

· Value Added

· Chronic Absenteeism

· Report Card

· Discipline

· Leadership/Administration/Governance (LAG)

· Shared Leadership

· Equity

· Leadership Pipeline

· Operations (OP)

· Transportation

· Child Nutrition

· Fiscal Management (FM)

· Equity

· Shared Services

· Funding Allocation

· Community/Family Engagement (CFE)

· Partnerships/Needs (Mental Health, Medical, etc.)

· Assessing the community needs

Descriptor examples identified include:

· Assessments

· Graduation

· School Climate

· Chronic Absenteeism

· Discipline

· Prepared for Success

· Gap Closing

What to Measure examples identified:

· Student Indicator examples:

· Increase reading comprehension for our 2nd grade students.

· The gap will close for my homeless gifted children.

· Curriculum/Instruction/Assessment (CIA) examples:

· All children in this class get the new curriculum.

· Number of Teachers who are prepared or the number of children who get the instruction.

· Dashboard examples:

· Increase the number of children who met the third-grade reading requirements by 5% annually.

· Increase ACT participation by 5% annually.

The How to Measure should be similar to the Smart goal measurement showing an increase or decrease or completion in the What to Measure (e.g. graduation, absenteeism) based on some measurable standard. The When to Measure should be a common frequency that fits with other monitoring frequencies (e.g. quarterly).

7.6.1 Alerts and Queuing

The purpose of the alerts and queuing function is to guide the workflow and communications between and among the users of the system. This means the districts internally, ODE internally, and between the 2 entities.

Since the One-Plan can have multiple goals, the user needs the ability to connect and work with multiple support resources at ODE (e.g. Literacy, Career-Technical education). While the district will have a designated support team, the communication will still need to be guided to specific members or a group of members of that support team based on the goal and the requisite area of expertise. This will be done by mapping the 8 categories and sub-categories of the Decision Framework to the support resources on the support teams. The district’s support options will be either enhanced or reduced based on the support level for that district. This indicator (support level) will need to be kept within the system and used to indicate the support options available to the district.

Since the One-Plan can have multiple goals, the various goals may be worked on and completed at different points in time. The system needs to keep track of the status of the work and feedback/approvals on the various goals so an overall One-Plan goal status can be kept. Multiple sets of work, routing and approvals could be going on all at the same time and the system needs to keep track of these activities.

Both the district and ODE need to be able to view the overall status of the One-Plan goals at any point in the process. Both entities will need to be able to generate a status report or screen showing the status of the various goals of the plan and associated feedback/approvals. The sub-committee envisions something like Figure 13.

Figure 13. One-Plan goal status

Goal

Working

Submitted

Changes Required

Approved

 

 

 

 

 

Goal number 1

 

 

 

 

Goal number 2

 

 

 

 

Goal number 3

 

 

 

 

Goal number 4

 

 

 

 

This goal status will be color coded to better represent goal status:

Green- Work continues, no issues

Yellow - Work slowed by issues within my control, attempting resolution

Red - Work stopped by issue beyond my control, attempting resolution

At the district level, the Superintendent and the Treasurer (or designees) will need to approve the full One-Plan before it can be submitted to ODE for eventual funding. The user needs to be able to initiate routing to these two roles before routing to ODE. The user also needs the ability to route specific goal elements to ODE support teams (or members) for review/feedback/approval as the One-Plan is being developed. This implies the need for the ability to have multiple approvals staggered throughout the course of the planning process. At the end of the process the district will need to submit the entire plan to ODE for review and approval.

Since the support resource at ODE will be servicing multiple districts all within a set period of time, the support resource will need the ability to customize their communications with the district based on their time constraints and have a combination of emails, alerts on the Dashboard, or holding and collating the messages into a weekly or periodic report. The severity/importance of the communication may dictate different handling of different communications (e.g. hold non-critical, email critical).

The system will need to support SLAs for important routing and approvals. Certain requests for review and approval will be time stamped and need to be resolved or responded to within a set period of time. Should that not happen, there needs to be an escalation process defined where a supervisory person should be notified to enforce certain actions needing taken. This escalation and routing needs defined before or during development.

The One-Plan sub-committee has developed a table of alerts and queuing entitled One-Plan Alerts and Queuing and it is attached as Appendix M. It contains the basic messaging required for the One-Plan component. It is most likely not comprehensive, but has most of the communications required. The sub-committee anticipates a few additional ones being added during the development phase of this project. The important communication types, roles, and routing defined will enable development to begin and the messages to be finalized.

The One-Plan sub-committee will also define alert expiration and escalation at that time as well. The system should expire and remove informational messages after a period of time defined by the message originator. The system should allow for a set of escalations per message type to be defined showing routing of the communications up a chain of command to ensure actions are taken on important tasks. Expiration and escalation of messages can be added as cells to the Alerts and Queuing table to allow for keeping all messaging information in one place.

The entire process will culminate with the acceptance and approval of the One-Plan.

7.7 Implementations and Resources

Strategy creation will offer the user an indicator on their current progress toward the completion of their plan.

At this stage, the user will iterate through all their strategies for one of their goals and define their implementations. The user will be able to select/identify the specific strategy and then select the implementations they will utilize to execute successfully on that strategy. Additionally, the user will be prompted to select the resources that they will use to support the strategy. Figure 12 shows a draft example of what that might look like.

Figure 12: Implementations and Resources:

Please refer to Appendices A and C for resource or grant information. The resource information there is comprehensive enough to support development efforts. Additional details and verification of these resources can be done at development time.

7.7.1 Implementation Response

Next the user will need to be able to describe in more detail those implementations that will support the selected strategy. The user will also need to define an adult measure as is now required by the process. Note that each strategy must have one adult measure. Based on the user’s implementation selections, the user will receive up to 8 implementation categories in which they will provide a narrative response as to how they will execute upon the strategy. These implementation categories are:

· Curriculum/Instruction/Assessment (CIA)

· Human Capital (HC)

· College and Career Readiness (CCR)

· School Climate and Supports (SCS)

· Leadership/Administration/Governance (LAG)

· Operations (OP)

· Fiscal Management (FM)

· Community/Family Engagement (CFE)

Each implementation category will allow the selection of requirement data (e.g. School improvement, English Learners, Reading Achievement). The first version will have the user select what requirements this implementation will satisfy; multiple options would be allowed to be selected at one time. The options should allow for the user to hover over (or a popup) to indicate the actual requirements of each of the components.

7.8 Financial Linkage

The user will need to estimate costs in order to build a budget. The rules surrounding building that budget and adhering to it along with exception processing will need to be defined. The rules regarding uses of funds here and for the financial linkage pages also requires additional definition at development time.

For the initial development phase, ED STEPS will send the user to CCIP to complete the Funding Application. There will be an interface built (defined definitively at development time) that will allow access and enable returning to this location in the process. Please refer to section 2.3 Impact on Existing Systems for more details.

7.9 Process Iteration

After the completion of step implementation responses, the user will be presented with a status page showing where their completion status is within the planning phase.

Once a user has completed implementation responses, they may have several paths to take depending on where they are in the process:

· The user may have completed one strategy within a goal but still have additional strategies they may wish to add within the same goal

· The user may have completed all the strategies for one of the goals and now wish to move to the next goal (if there is one)

· If there are no other goals then the user has completed the development of their strategy.

After the user has completed all steps for every strategy for every goal the process is complete. At this point the user should have the option to save and exit, go back somewhere to edit, or submit for approval.

7.10 Audit Process

With this completed work, once submitted, plan components are then sent to the ODE support team for review and approval. Details of this process will be made available at development time. This process will define guidelines for acceptance, rejection and/or supplying feedback.

7.11 Building Process

User’s working on buildings or entities designated as a building will not be allowed to start the planning process if the user has not completed their DF/NA and the district has not completed its planning process.

Buildings (or entities designated as buildings) will inherit goals, strategies and implementations from the districts… so the planning process will be controlled by the districts. Since districts have to approve building plans, the district can manage the building’s planning process in several ways. The system needs to support these various ways.

For tightly controlled districts, the user’s working on buildings will not be allowed to start the planning process if the district has not completed its planning process. The system must allow the district to indicate this preference and advise the building’s planners that they cannot start without district planning completion. Warning messages and blocking of entry must be supported as well as allowing the District a way to notify the Building that planning may commence.

For more loosely controlled districts, the user’s working on buildings may be able to start the planning process regardless of where the district is in their planning. In this case the district may choose to simply accept the building’s plans or review and approve/disapprove the building’s plans. The Building needs a way to advise the District that planning has taken place.

The district may also just dictate the goals and allow the buildings to create strategies and implementations.

ED STEPS Consolidated Competitive Application

(CCA)

8. Component 4: Consolidated Competitive Application (CCA)

8.1 Overview

Federal and state grants are awarded in the State of Ohio by ODE based on competitive and discretionary requirements submitted by schools and districts. Grants are awarded for pre-defined purposes with the expectation of meeting specific services or performance standards.

Presently, the grants application process is submitted through the Comprehensive Continuous Improvement Plan (CCIP), which consists of two parts: 1) the Planning Tool, and 2) the Funding Application. The work for this sub-committee is to redefine the planning tool and identify the proper place to link up with the funding application. The sub-committee is working on defining what needs to be done programmatically and with the Grant table elements that will drive this process.

The Grant table will identify what grants the districts are eligible for and provide the district a view showing just those grants. Business rules will be provided for how the Grant table will be pre-populated. Some grant data for the table will be auto populated and some may be able to be uploaded from a spreadsheet. The Consolidated Application consists of two parts: the Consolidated Formula and the Consolidated Competitive. The Consolidated Formula portion will be included in this development effort as all components necessary to support it are already included in the Consolidated Competitive portion of the application. CCA will initially address Competitive Grants. At some point the sub-committee will need to determine how Discretionary grants (e.g. State Level Title II Funds) and other non-competitive grants will fit into the process. The Grant table will be a crucial element in this table and parameter driven approach to application development. The sub-committee anticipates that these and other elements used to drive the system will be maintained internally by an Applications Administrator much like the software team manages CCIP today.

Please refer to Appendix F for the Consolidated Competitive Application Business Rules.

These business rules are those that could be identified at this level of specificity. It is not a comprehensive list. The project will generate additional business rules as the project progresses.

There is also an effort underway by the District Dashboard committee to define roles and role privileges. This effort should be completed before software development begins.

8.2 Grant Review

As a team, the sub-committee put together a complete list of all grants and reviewed each of them to categorize them as competitive, discretionary, and entitlement(formula). The categorization was focused on how ODE disperses the funds, and not how ODE receives the funds. Below are the definitions and categorization of the grants.

8.2.1 Competitive Grants

Federal or State funds provided in a competitive approach to targeted populations or programs with identified purpose for a fixed or known period-of-time. (Examples include: 21Century, School Improvement, McKinney-Vento)

8.2.2 Discretionary Grants

Federal or State un-mandated funds that are at the discretion of ODE to distribute either by competition or need to targeted populations or programs for an identified purpose. (Examples include: Head start, Special Education Grants to States, Ohio Education Computer Network)

8.2.3 Entitlement (Formula) Grants

Federal funds in a fixed amounts (cap) distributed by need toward targeted populations or programs pre-determined by formula across the entire population. (Examples include: Title I, Title IV) (Exception: Child nutrition has no cap amount)

8.3 The Consolidated Competitive Application Practice

The Consolidated Competitive Application (CCA) process will provide a framework for creation of a flexible yet standardized application process and allow the district (applicants, LEAs) to track the progress of their activity toward reward. The application process will be open to anyone with a defined need and who meets the basic requirements whereby the EDSTEPS process will either suggest/recommend potential grants.

The CCA will create a set of components to create an open framework for the competitive grant\application. Each of these components will have a very specific purpose and the user will be able to add or remove each one. To achieve One-Plan purpose, each of the blocks will require a business rules table. A competitive grant table will support the entire process. This table will contain the grant specific details as well as the logic on what components are required and the sequential presentation order of each component in the grant process. The applicant could view each component as a step in the process, or a page in which the applicant will need to complete.

While the initial scope of the project was to handle the Competitive grants, the functionality provided is also comprehensive enough to be able to handle the Entitlement (Formula) grants as well.

In general, there are six primary phases of a grant, and this is how they are handled today:

1. The Department defines or identifies qualified recipients. This can be accomplished in one of several ways:

0. Entitlement/Formula

0. Funding is provided to defined organizations based on specific criteria

0. Competitive

1. An application can be made available to one or more organization types; or

1. An application can be made available only to a specific list of organizations (IRNs)

0. Discretionary

2. Similar to Formula in that funds are provided based on specific criteria

2. Qualified recipients are notified of funding availability

1. The Department collects information used to determine funding recipients. Again, this can be accomplished in one of several ways.

1. The Department determines what organization(s) will receive funding and how much funding will be provided. This can be accomplished in one of several ways.

1. The Department makes funds available to funding recipients.

3. The Department allocates funds to individual recipients

3. Recipients must be able to enter or revise the budget

3. Recipients draw down funds by submitting a Project Cash Request (PCR) in the CCIP

1. The Department monitors fund recipients.

4. Monitoring is performed and recorded through the Compliance system

1. The Department requires funding recipients to submit grant close out reporting.

5. Recipients close out a fiscal year by submitting a Financial Expenditure Report (FER) in the CCIP

The current process allows applicants to apply for funds or express interest in funds in a variety of ways. The new process will need to support/create an IRN acquisition process that will not deter an applicant from the process. The process for applicants without an IRN should allow them to enter the process and work as if the user was creating a social account (e.g. Facebook, Gmail, Instagram). The user should be able to enter their information and immediately receive an IRN. As this approach presents some security concerns, this process will be defined with Information Services prior to software development.

The Grant Configuration Table will need to be able to allow for selecting components and sequencing the order in which the components are presented. This detailed information can be provided at software development time without affection the underlying design elements.

8.4 List of Components

Component 1

Welcome

The welcome page will provide narrative on the process as well as a personalized starting message.

Component 2

Applicant Information

This page will autofill the user applicant information based on their SAFE login. For nearly all instances this is a 1 to 1 relationship (applicant to SAFE login), but the system will allow for exceptions. If the user is performing work for multiple organizations, the user must be able to select the proper one… so this page should allow the applicant/user to define the organization the user is going to proceed as. If the user is assigned to multiple organizations, then all options will be presented and a drop down will allow the user to select and identify which organization they want to work.

Component 3

Grant Eligibility