You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

OMB Reports are public reports prepared after each OMB Meeting. They should be published on the public governance spaces of the respective Building Blocks (accessible through the DIGITAL Building Blocks Governance Space) after they have been approved by the OMB. As the reports are available to Member States and relevant stakeholders, please make sure that you DO NOT reveal internal information (explained in more detail below). 

This template was created to help you prepare OMB Reports for your monthly OMB meetings. While it is up to you/your OMB to choose the reporting structure you want to use, we believe that following this template will help you to include all required information in a structured way. Following this template may therefore help you to facilitate accountability to stakeholders, track developments over time, and increase comparability across Building Blocks. Finally, a harmonised reporting structure across Building Blocks may be useful in case auf audits.

As OMB Reports are public (meaning that they are available to the Member States and relevant stakeholders), there are two important things to keep in mind:

  • The information should be comprehensible not just for OMB members, but also for stakeholders that did not participate in the OMB meeting.
  • The OMB Reports should NOT expose internal information (such as risks, issues, onboarding, and promotional activities). Consequently. the following sections from the Project Status Reports are excluded from this template: Colour-coded project status (red - yellow - green); Risks; Issues, Onboarding; Events and Communication).

We believe that following this template will help you to achieve both these objectives. 

  • The template below uses three colours:
    • Black text indicates that the text should not be changed;
    • Red text describes the type of information that should be included. It indicates that you should always include the required information;
    • Green text describes the type of information that should be included. It indicates that you can include information if you wish to. Green text generally serves to provide you space for filling in information that does not fit in any of the other (red) fields.
  • The template consists of five sections:
    • Section 0: OMB meeting indicators;
    • Section 1: Project Management;
    • Section 2: Evolutive Maintenance;
    • Section 3: Support Office;
    • Section 4: Additional Topics.

Please make sure to always include information in the designated sections and columns first. This will make it easier for external stakeholders to understand the information displayed and e.g. distinguish past activities from future ones. 

  • The template includes sections for providing additional information ("Comments", "Additional information") - please make sure that you do not include information that is left out on purpose here, namely:
    • Colour-coded project status (red - yellow - green);
    • Risks;
    • Issues;
    • Onboarding activities;
    • Events and Communication.
  • Whenever you do not report required information (e.g. when the table for change requests is empty), please include the sentence "CURRENTLY NO xxx" above the table, so that it is clear the table is left empty on purpose.



eDelivery September 2022 OMB Report

Date:  

Reporting period:    to  

Project Owner (PO): DG CNECT 

Business Manager (BM): Maya Madrid

Solution Provider (SP): DIGIT

Project Manager (PM): Bogdan Dumitriu

Attendees: 

Maya MADRID (chair, MM)

Bogdan DUMITRIU (BD)

Marcio SAMPAIO (MS)

Michal PILCH (MP)

Monika KOKSTAITE (MK)

Radoslav JAKUB (RJ)

Olha KOSHCHIYENKO (OK)

Dragos SERBAN (DS)

Adrien GOHY (AG)

Kristof POPGEORGIJEV (KP)

Zsombor NAGY (ZN)

Todor TODOROV (TT)

Section 1: Project Management


Overall Progress

Description of the overall project progress in 5-10 bullet points/sentences. The description should be high-level and should:

  • provide information on the focus of the project throughout the reporting period;
  • describe the most important progress made throughout the reporting period.

Please make sure that you do not include internal information, e.g. details related to identified risks or problems.


Milestones Progress

Describe the progress made on the respective milestones throughout the reporting period. In case you wish to include information on future activities (next steps), please use the dedicated column and clearly separate tasks you have worked on throughout the reporting period from those you will work on in the future.

Title

Start Date

End Date

% completed

Status

Activities during the reporting period

Planned activities

Comments

Title of Milestone with link to JIRA Ticket

Date on which work on the milestone began

Date on which work has been completed

OR

Indicative date on which work will be completed

% completed at time of reporting

Below you can find proposed status categories and their explanations. In case different categories work better for your Building Block, please feel free to keep using those.

NOT STARTEDThe milestone has been defined but no work has been done.

IN PROGRESS: Work on the milestone has been done in the past and will continue in the future. This category can apply even when no work was done during the reporting period. 

COMPLETED: All work related to the milestone has been completed.

ON HOLDWork on the milestone is interrupted due to an impediment. 

DISCONTINUED: Work on the milestone has stopped and will not continue in the future. 

Optional: Description of activities/tasks carried out during the reporting period in relation to the specific milestone. It is not necessary to include every task carried out. Rather, the amount and detail of information provided should correspond to the importance of the milestone and be adequate to illustrate the progress made. 

Optional: Description of future tasks/activities ("Next Steps").Optional: Any comments related to the milestone you wish to include. 


OPTIONAL Use Case / Project Progress 

This section is OPTIONAL. You can use it to report one use cases / projects / other initiatives that did not fit under "Milestones". If you use this table, please adjust the title accordingly. If this section does not make sense for your Building Block, you can simply delete it.  

Title

Start Date

Activities during the reporting period

Planned activities

Comments

Title of Use Case / Project with link to JIRA Ticket

Date on which work on the Use Case / Project began

Optional: Description of activities/tasks carried out during the reporting period in relation to the use case / project. It is not necessary to include every task carried out. Rather, the amount and detail of information provided should correspond to the importance of the use case / project and be adequate to illustrate the progress made. 

Optional: Description of future tasks/activities ("Next Steps").Optional: Any comments related to the use case / project you wish to include. 


Section 2: Evolutive Maintenance


Change Requests

The table below should include all change requests that

  • have been identified, processed or closed during the reporting period; OR
  • remain open at the end of the period.

If no change requests have been processed during the period (= the table below is empty), please write "CURRENTLY NO CHANGE REQUESTS" above the table.


Request

Summary

Issuer

Status

Resolution

OMB Decision

Comments

Title of request and link to JIRA Ticket.


Description of the request and its impact (on project, timeline, milestones, ...).Issuer of the request.

Below you can find proposed status categories and their explanations. In case different categories work better for your Building Block, please feel free to keep using those.

OPEN: Request has been recorded but not yet dealt with.

IN PROGRESS: Work on the request is ongoing. 

IMPLEMENTED: Change request has been implemented. 

NOT IMPLEMENTED: Change request will not be implemented. 

If status is "In Progress": Specify work that has been and will be done to implement the change request.

If status is "Implemented": Describe whether the change has been implemented as requested or in an adapted form and explain the reason for this decision. Specify work that has been done to implement the request.

If status is "Not Implemented": Explain why the change request will not be implemented and indicate consequences, if applicable.

Indicate whether the OMB has to make a decision in relation to the change request and if yes, summarise the content of the decision. Also include any past decisions made.Optional: Any additional information related to the request and its follow-up you may wish to include.


Release Calendar 

Include the release calendar for work related to your Building Block. Depending on what works best for your Building Block, include it as a table or as a chart. While it is possible to include past releases, please make sure that the release calendar focuses on the future and mainly depicts planned releases.

Title

Start Date

End Date

% completed

Status

Activities during the reporting period

Planned activities

Comments

Title of Milestone.

Date on which work on the milestone began;

OR

Date on which work will begin.

Date on which work has been completed;

OR

Indicative date on which work will be completed.

% completed at time of reporting.

Below you can find proposed status categories and their explanations. In case different categories work better for your Building Block, please feel free to keep using those.

NOT STARTED: The milestone has been defined but no work has been done.

IN PROGRESS: Work on the milestone has been done in the past and will continue in the future. 

COMPLETED: All work related to the milestone has been completed.

ON HOLD: Work on the milestone is interrupted due to an impediment. 

Optional: Description of activities/tasks that have been carried out during the reporting period.

Optional: Description of activities/tasks that you plan to carry out in the future.Optional: Any additional information you may wish to include.


Section 3: Support Office


  • Select KPIs that showcase your support activities. As a best practice, always include the same KPIs to track developments in your support activities.


OPTIONAL Section 4: Additional Topics

  • Include any additional information that you consider important here. Please include information in the dedicated sections 1-3 first, and only include information here if the sections are not suitable for the information you wish to include. 
  • Please make sure that you DO NOT include information on the following topics:
    • Colour-coded project status (green - yellow - red);
    • Risks;
    • Issues; 
    • Onboarding, events and communication.
  • No labels