About pilot 7

Last modified: 2026-10-29 21:17by Erik Hagen ID: f8256f11-4edc-440a-b6cb-56ddb29e9d02 SAMT-X/samt-bu-pilot-7

This page is based on the draft plan «Gjennomføring av Pilot 7» (carrying out Pilot 7), version 0.1. Much is not settled yet, and the page says so where that is the case.

INTRODUCTION

This is a description of the plan for carrying out pilot 7 – Digital dialogue between kindergarten/school and home. Although the plan describes the work as a phase-driven process, we assume that we will work iteratively, repeating some phases when needed.

The project owner is the Norwegian Digitalisation Agency (Digdir). The pilot is led by Christiane Fröhlich (Digdir).

SCOPE AND DELIMITATION

Background

The work is based on the case description 11. Digital dialogue between kindergarten/school and home.

Parents and guardians often have to deal with several digital solutions to communicate with kindergarten, after-school care and school. Which solutions are used varies between municipalities and institutions. As a result, parents may have to use several apps and user interfaces to follow up messages, calendar information, activities and history. The information is scattered, and it can be hard to get an overview of the communication that matters for the children’s everyday life.

At the same time, municipalities and educational institutions have already invested in existing solutions. It is therefore not sensible to assume that the challenge should be solved by developing yet another app or by replacing all existing solutions.

The pilot’s objectives

The central question for the pilot is how existing solutions can work better together, so that parents can choose how they want to receive and follow up communication, without compromising privacy, information security or the organisations’ responsibilities. The pilot therefore builds on reuse, interoperability and open interfaces rather than developing a new app.

The objectives are to:

  • map which solutions, standards and common components already exist, and what can be reused
  • find out how messages, calendar information and history can be shared securely between different systems and apps
  • clarify what must be in place regarding privacy, access rights and responsibility
  • clarify how pupils and students can communicate with each other about school matters
  • make a concrete proposal for how the solutions can work together (a simple technical prototype and architecture)
  • draft common requirements that municipalities and others can set for suppliers
  • make it possible for the voluntary sector and innovators to follow the same approach to more coherent communication

The pilot’s products

The pilot has the following products:

  1. Solution design: a sketch of how today’s systems and common solutions can work together to give parents one combined channel
  2. Common standards and integration model: a proposal for how messages, calendar information and history can be shared between different systems in a standardised way
  3. Technical prototype: a simple demonstration of how information from different systems can be combined in one user interface
  4. Legal clarifications: an overview of what must be in place for privacy, access rights and the division of responsibility. It may also be relevant to look at how pupils themselves can use the solution (input from Demokratiløftet).
  5. Common supplier requirements: a proposal for requirements that make it easier for different systems to exchange data, and that reduce supplier lock-in
  6. Hackathon: a hackathon has been proposed to find possible solutions and prototypes

Carrying out the pilot shall also provide input for updating the project’s «playbook» for this kind of project.

Delimitation

The pilot shall concentrate on demonstrating how existing solutions can work together, not on developing a new service or app. The pilot is limited to:

  • mapping relevant solutions and reusable components
  • developing a simple prototype that shows selected information in one place
  • trying out integration patterns and standards
  • clarifying legal, organisational and security prerequisites
  • proposing common requirements and recommendations for suppliers

Benefit owners

The benefit owners are not settled yet. The most important expected benefits are simpler communication for parents, less fragmented information and better interoperability between existing systems:

  • better interoperability and less need for parallel solutions, for municipalities and system suppliers
  • a better overview of messages, notices and calendar information for parents
  • more choice for parents and pupils
  • common requirements and open interfaces can make it easier for more actors to offer solutions (the market and innovators)
  • safer communication for pupils

STAFFING

The pilot needs the following competence:

  • Pilot owner and project manager
  • Architecture and integration: how different systems can be connected and exchange data
  • Standardisation: common formats, APIs and standards for messages, protocols and information
  • Development: developers who can build and test a simple technical prototype
  • Law and privacy: access rights, privacy, information security and archiving
  • User insight: knowledge of parents’ needs and of school and kindergarten, preferably through a pilot municipality
  • Procurement and supplier dialogue: drafting common requirements and involving suppliers in the work

Staffing is not settled yet. That is work package 1.

EXECUTION

Duration of the pilot

The duration is not settled yet.

The pilot’s work packages

Each work package is followed up as an issue in samt-bu-pilot-7.

1. Find a pilot owner and build the team

Activities:

  • Appoint a pilot owner
  • Establish an autonomous, cross-disciplinary team
  • Clarify resource needs
  • Set goals

Deliverables:

  • A named team with committed capacity
  • A plan for execution and use of resources

2. Mapping and user needs

Activities:

  • Map today’s communication between home, kindergarten, after-school care and school
  • Gather insight from parents, staff and municipalities
  • Map existing systems, apps, APIs, standards and common components
  • Identify relevant suppliers and technical limitations
  • Decide what is to be tested

Deliverables:

  • A map of today’s solutions and system landscape
  • A description of user needs and the problem

3. Architecture and standardisation

Activities:

  • Propose a target architecture and information flow
  • Define how messages, calendar information and history can be exchanged and represented
  • Map relevant standards and integrations
  • Describe how parents can get the information in one place
  • Clarify needs for authentication, access control, traceability and the like

Deliverables:

  • Solution design and architecture sketch
  • A description of interfaces and integration principles

Activities:

  • Clarify the legal basis, purpose and controller responsibility
  • Clarify access rights, for both parents and pupils
  • Assess archiving requirements
  • Identify responsibility for possible errors, for example missing synchronisation

Deliverables:

  • Documented legal assessments (privacy and the like)
  • An overview of security requirements and access rules
  • A description of open issues and measures needed before any production use

5. Technical prototype and hackathon

Activities:

  • Develop a simple prototype that combines information
  • Demonstrate a combined view of messages and calendar information
  • Test possible integration patterns
  • Hold a hackathon with developers, suppliers and innovation communities

Deliverables:

  • A working prototype
  • A summary of the hackathon and recommended solutions

6. Common supplier requirements

Activities:

  • Draft supplier requirements
  • Gather input from municipalities and relevant suppliers
  • Document recommendations

Deliverables:

  • A proposal for common supplier requirements
  • Documented experience for the playbook

Dependencies and milestones

Dependencies and milestones are not settled yet.

Practical execution

How the team will work is not settled yet. The starting point in the template is the same as for the other pilots: iteratively along agile principles, in sprints of two or three weeks, with a planning meeting at the start and a demo at the end of each sprint, and at least one retrospective during the pilot period.

The pilot’s tasks are followed up as issues in samt-bu-pilot-7, on the board SAMT-BU Pilot 7.

Not settled yet

The overall plan, goals (OKR), budget, risk analysis and communication are not settled yet.