School inspection in Eduotopia

Insufficient education services prevent children in Edutopia from learning. A large portion of schools in Edutopia are short on qualified teachers and essential resources such as classrooms, desks, seats, toilets, and textbooks. Some schools have sufficient or even a surplus of resources, while others struggle to retain qualified teachers, obtain necessary resources, and deliver quality education. School inspection is one means to ensure fair distribution of limited resources, support school management, and identify needs for pedagogical training among active teaching staff.

School inspection should take place regularly at each school, but this is often not realistic due to limited time, travel distance, and general resource constraints. In the past, school inspection has often been carried out as a rushed exercise with inspectors jotting observations down on paper, but with no or little time to discuss the situation at the school with head teachers. Ideally, a school inspection should result in feedback to the school head teacher before the inspector's departure and subsequent school inspections should be informed by previous observations and discussions on how to improve the situation. 

Case background

Edutopia has implemented the DHIS2 platform to support education sector management. You can get more information about how different countries use DHIS2 in the education sector here.

Most school inspectors in Edutopia have access to work related desktop computers or tablets, but not smartphones - although many have private smartphones of various brands. The Ministry of Education in Edutopia wants a digital tool that can be used for school inspections. The web application needs to be built on top of DHIS2, which serves as the national Education Management Information System in Edutopia and stores official data collected from schools. A key intention is to enable better data sharing and coordination between district education officers (the managers of the school inspectors), school inspectors, and school head teachers to improve school management. In essence, the ministry wants to see more use of data, not just data collection. 

Until now, inspections have been conducted using printed paper forms or non-standardized Excel formats. At the school level, the inspector’s involvement typically ends on the day of the inspection, and the next visit would often be another round of inspection (sometimes with a new inspector) with no systematic reference to the previous inspection.

Current school inspection workflow

A recent internal assessment carried out by the Ministry of Education found problems in terms of missing data, incorrect data, and duplicate data. The general lack of on-the-job training and lack of intuitive and standardized data collection tools negatively impact school inspectors' understanding of the data collection tools and data quality issues. The internal assessment also documented the existing school inspection procedures and workflows. The most common workflow is as follows:

  1. School inspectors plan the school visits for the upcoming month, sometimes by looking at previous school inspection reports.
  2. School inspectors travel to each school to meet with the head teacher and teaching staff. 
  3. School inspectors perform the inspection using a combination of direct observation, inspection of school management documents such as examination results and school records, and interviews and discussions with the head teacher/school administration.
  4. The school inspector records data on paper-based forms, or sometimes in an improvised Excel spreadsheet, sometimes based on personal preferences and experiences. 
  5. School inspectors and head teachers agree on priority areas for improvement and an action plan for school improvement.
  6. School inspectors produce reports that are sent to the district education officer for approval.
  7. The head teacher receives oral feedback on school performance based on the school inspection report. Sometimes they receive a printed paper report.  
  8. The cycle starts again. Ideally, school visits build on previous visits to ensure that action points have been implemented. However, due to limited time, high staff turnover, and poorly kept records, school inspections often do not build on previous inspections in a meaningful way. 

Infrastructural conditions

All school inspectors and head teachers who will use the school inspection application have access to desktop computers or tablets. Stable electricity is accessible through the power grid or from generators. However, internet connectivity in Edutopia varies throughout the day. In some areas, connectivity is lost for several hours. The most frequently mentioned challenges to using computers and tablets are inconsistent network access and the very high cost of mobile data.

Dealing with resource limitations in schools

The schools in Edutopia receive essential resources such as desks, chairs, textbooks, and newly posted teachers once a year from a national resource distribution and teacher posting mechanism. A few weeks into the academic year, there is a national survey that captures data about learner enrollment and actual teaching capacity and resources available at the school. Some posted teachers do not show up for work, especially in unattractive and remote areas. The data from the school census is digitized and stored on the national DHIS2 platform. Unfortunately, due to resource constraints, a full national survey was last conducted a few years ago. Hence, recent school census data might be missing for many schools. 

When schools suffer from commodity shortages, the central level has limited resources on hand and might not be in a position to alleviate the situation. Some head teachers arrange ad-hoc transfer of resources between schools based on local agreements, but no official national resource redistribution scheme has been institutionalized. As explained by one head teacher: 

“A head teacher may call from a nearby school if they experience a resource shortage. Then, I check if we have more resources than we need. If that is the case, I arrange for the transfer of what we can spare". 

School inspectors should take an active role in facilitating resource distribution between schools, so that proper records are kept and resources accounted for. The school inspectors are in a better position to assess that resources are fairly distributed between the schools they are responsible for. 

School inspector profile

The primary end-user for your application is the school inspector. School inspectors have traditionally been trained as teachers and have worked in the education sector as either teachers or head teachers before becoming school inspectors. However, a cadre of newly recruited school inspectors was recruited immediately after completing college. These school inspectors do not have significant experience as teaching staff. Their recruitment has been necessary due to the increasing data collection burden placed on school inspectors and schools. Essentially, school inspectors spend more time filling out paper forms than they do providing pedagogical guidance. Due to their lack of seniority and experience, some of the newly recruited school inspectors struggle to be taken seriously by experienced head teachers and teaching staff and are seen as 'errand boys' for the district education officers. School inspectors are mostly male. They often need to commute on motorbikes on muddy roads to reach schools effectively. 

There are significant differences in the digital literacy levels of the school inspectors. Some use laptops and tablets in their daily lives and have extensive experience with the use of Excel and mobile web services such as Facebook and WhatsApp. Others have limited experience with the use of digital technologies and are more accustomed to paper-based tools and information flows, while they might occasionally access the Internet to check football results or the news. 

 “What is important for me is that I can provide actual guidance to head teachers and teaching staff at the schools. I need to be able to follow up on school progress over time, rather than just collect data. This means that I need to keep a good and systematic overview of the schools' resources and performance. Sometimes, our reports are subject to a review from the Ministry of Education central office, which means that I must be able to quickly provide an overview of all my schools and the main challenges they are faced with” - Experienced school inspector in Edutopia

Compulsory app requirements

Your group is requested to design and develop a web-based DHIS2 app that supports the work of school inspectors. You should use the provided information about the context, existing paper-based workflows, and the end-user as a basis for how you design your solution. Hence, you should think carefully about the design of a digital workflow that facilitates a smooth transition from existing paper based workflows. Consider designs and terminologies that are likely to be aligned with school inspectors' past experiences (or at least avoid unnecessarily technical terminologies inherited from the DHIS2 platform!), while leveraging the advantages of digital interfaces for data capture and visualization.

Your solution must address the following compulsory requirement:

  • Build a school inspection application. The application should allow the inspector to carry out a routine inspection or a follow up inspection. In a routine inspection – inspectors look at some aspects of a school such as administration, infrastructure, and resources (see technical starting point for more details). In a follow-up inspection – inspectors visit a school previously inspected within, at most, six months. The main objective is to check the progress made by the school since the last inspection. The inspection should build on observations and recommendations made to the school in the previous inspection. It is up to you how you want to differentiate or associated the two different types of inspection. 
  • Both inspection formats require data collection interfaces for registering essential school inspection data associated with the DHIS2 school inspection event program. Inspectors will use the interface you develop as they conduct school inspections. Data capture must have basic validation and feedback in case of wrong or unexpected inputs. 

  • Make sure the user has an opportunity to review all data and assess its quality (for example by comparing newly entered data with historical data trends) before submitting the inspection data.  

It is up to your group to ideate, prototype, and decide how you will design and develop an app that supports school inspection in Edutopia. In addition to this compulsory requirement, you must implement exactly two of the requirements described in the next section, called additional requirements. It is advisable to start with a minimum viable product based on the compulsory requirements as soon as possible.

Additional requirements (implement only two!)

Beyond the compulsory requirement, you must choose and implement two of the five additional requirements below. Implementation of more than two additional requirements will not have a positive impact on the evaluation of your project. The minimum functional extent described for each additional requirement is what you must cover for the requirement to be considered implemented. Think carefully about which requirements go well together and comprise a useful and coherent application in the Edutopia school inspection case. When in doubt about the use context of the application, please document the assumptions you make to arrive at workflow, application design, and development decisions. This will be helpful when you justify and explain your choices in the final group presentation. Don't reinvent the wheel! Make sure to make the most out of the DHIS2 platform resources.

1. School visit planner

The school visit planner feature should make it easy to identify which schools need school inspection. Working on this requires you to familiarize yourself with DHIS2 organization unit hierarchies ('orgunits') to list and compare the school inspection status of different schools. There could be different reasons for prioritizing visits to different schools, such as school performance in examinations, newly established school, long time since last inspection, schools that have requested to be inspected, schools in need of follow-up, accessibility of schools during certain times of the year. You can make your own assumptions about which reasons to prioritize based on the case description and data available in the database. 

Minimum requirements:

  • Show schools in the school inspectors' cluster based on meaningful parameters that you can justify
  • Support the development of an inspection plan including the location of the school, date/time of inspection and the type of inspection to be carried out: Regular or Follow up.
  • Visualize schools in the cluster either in a map or a landing page. It should be possible to select any school and show data from the previous school inspection.

2. School resource count

Every year, the school needs to count the actual resources at hand and update the resources recorded in DHIS2. This exercise involves the school teachers and other staff recording the number of resources such as books, chairs, desks, and teachers by subject. This information is tallied on paper and provided to the school inspector upon request during a school inspection. The resource recount feature should make it easy to identify significant drops or increases in resources available at the school by comparing recount figures with the last official school census data or previous resource counts.

Minimum requirements: 

  • Develop an interface for swift data capture from school resource recounts
  • The school inspector must be able to compare previously recorded data against the newly counted data
  • Significant changes in data should be highlighted either through percentages, rates, or ratios - not just in absolute numbers
  • The feature design should be scalable. This means that you should have in mind the future need to record and manage data related to a large number of different resources in a user-friendly and flexible way

3. Requests resources from nearby schools

When a school is low on material resources such as books or chairs, the school inspector should be able to initiate a transfer of resources from one or more nearby schools with surplus resources. Nearby schools can be schools within the same cluster or district (i.e., schools with the same parent 'orgunit') or they could be nearby in terms of location / geocoordinates. Since the resources of all schools are captured in the same database, it is possible to assess the current resource ratios and absolute numbers of surplus resources at nearby schools. With this information, the school inspector can initiate a resource transfer request. You do not need to consider the further handling of the request by the recipient school(s). You can assume it will be possible for a nearby school to simply accept or decline the request.

Minimum requirements: 

  • Provide an overview of up-to-date ratios (e.g., books or chairs per learner) at nearby schools and absolute numbers of surplus teaching aids and other resources to help identify where there is potential for a resource transfer.
  • Provide an interface to rationalize the resource request before it is issued. For example, allow the user to ensure that not too many requests are issued to different schools requesting a marginal amount of resources, request are not sent to schools that are nearly as low on resources as the requesting school, or use other reasonable parameters to rationalize the request.

4. Offline work

The school inspection application will be used in areas with intermittent or poor internet connectivity. Ideally, it should handle offline situations (such as viewing previous reports or temporarily storing newly collected data) to support school inspection in environments challenged with intermittent Internet connectivity. The Ministry of Education wants the application to support offline workflows when internet connectivity is lost so that school inspections can be carried out and data can be synchronized when internet connectivity is restored.

Minimum requirements: 

  • Develop offline support at least for the school inspection workflows described in the compulsory requirements.
  • Make sure data integrity is not compromised and that your user is well informed about what data is synchronized and when.

5. School inspection analytics

After a school inspection, the school inspector and the head teacher should take a moment to review the inspection results together. This could take the form of data visualizations on a school inspection Dashboard with graphs, tables, or charts. An analytical summary should be helpful for the school inspector and the head teacher in planning school improvements. Provide an inspection report for head teacher approval at the end of an inspection. You will need to rely on external libraries for your graphs and visualizations.

Minimum requirements: 

  • Develop a school inspection Dashboard with representations of relevant indicators calculated from the school inspection. The dashboard could present performance indicators for the school over time, compare with other schools in the cluster, compare with predefined or dynamic thresholds, or a combination of these.
  • Feel free to explore indicators and performance benchmarks and different ways of representing data. We do not expect you to have the domain knowledge to come up with realistic analyses, but you should think about what formats might be appropriate and useful for the intended users. You can provide dummy data if data is missing in order to demonstrate your visualizations.

Surprise us! (optional)

 

It is up to your group to decide if you want to implement one 'surprise' feature.

Implement one additional feature that you come up with yourself. This 'surprise' feature is entirely up to you to define. However, you will have to justify the need for it in the context of the school inspection case. You should also be able to explain how it takes advantage of the DHIS2 platform resources (e.g. existing data, API, Design System, etc). 

Do not prioritize this feature unless you are confident that you have fully covered the compulsory and two alternative requirements, and you are fully prepared to discuss and defend your group project from a development in platform ecosystems perspective, as these elements are essential to the evaluation of your project!