2016 SDMX Experts meeting, 17-20 October 2016, Aguascalientes, Mexico. More information at: http://www.oecd.org/std/sdmx-expert-group-meeting-2016.htm

1. Checklist for SDMX Design
Projects
http://www1.unece.org/stat/platform/display/SDMXPM/Ch
ecklist+for+SDMX+Design+Projects+Home

2. Introduction
This checklist is intended for the design and creation of new SDMX artefacts and the
management of such a project. It is a core part of the SDMX Guidelines that are
maintained by the SDMX Statistical Working Group (SDMX SWG).
The main target audience:
• SDMX project managers
• Structural metadata artefact analysts/designers
• Trainers for capacity building
The structure of the checklist is based on the Generic Statistical Business Process
Model (GSBPM v 5.0)
The checklist can be used for international or regional SDMX DSD Design projects.
Most checklist steps are adaptions of typical project management principles.

3. Introduction (continued)
The checklist can be viewed:
• either as a "cookbook", used to know all the "ingredients" of an SDMX
artefacts project, or;
• as an actual checklist, i.e. to make sure that all project phases have been
considered in their usual order.
The checklist follows the sequence of steps in most SDMX projects.
A flexible framework, not a “waterfall” model; it identifies
• all the possible phases of an SDMX design project and,
• the inter-dependencies between the phases.
To fix issues from the pilot phases some re-design is required, so the DESIGN
phase will be revisited.

4. Checklist Diagram

5. To start the project either:
• A need for a new implementation is identified
(such as new data flows), or;
• feedback about a current implementation (such
as an efficiency improvement to data
exchange) initiates a review.
It encompasses the following sub-processes :
• Describe Business Needs
• High Level Check of Existing Artefacts
• Identify Stakeholders
• Kick-off Meeting
• Project Governance
• Project Proposal
• Communication & Consultation Planning

6. Describe Business Needs A solid business case is a prerequisite for a
successful project.
Common benefits are:
• Information model to describe statistical data
• established ISO standard for data and metadata
exchange;
• reuse of technologies and standards;
• reduction of reporting burden;
• a metadata-driven approach;
• reduced risk of misinterpretation;
• Web Services (pull model) preferred exchange
method, instead of static pages or bulk
downloads (push model).

7. High Level Check of
Existing Artefacts
• The concept of re-use is central to SDMX
• Central registries exist for data discovery
• The SDMX Global Registry contains
“Global” and “cross-domain” artefacts to
maximise harmonisation and reuse
• There are also regional and local registries
• You may already have a local SDMX registry,
check the existing content to reuse
• Registry specifications are described in the
SDMX Technical Standard, Part 5 "SDMX
Registry Specification: Logical Functionality
and Logical Interfaces"

8. Identify stakeholders
Possible stakeholders for an SDMX implementation:
• Senior management : Essential that senior management drives SDMX
• Subject-matter specialists : They know best the data and metadata to be
exchanged and will design and validate the SDMX exchange structures
• Experts in SDMX standards and implementation :
– Will advise on the best solutions for implementation
– check that the structures conform to SDMX standards and guidelines
– evaluate against implementation solutions
– They can be outside of your organisation, e.g. SDMX WGs and consultants
• Experts in code lists, classifications and methodology : Central to any SDMX
implementation
• Coordination / quality unit : Could take the responsibility for coordinating the
SDMX project
• Data dissemination unit : Needs for data exchange are not necessarily the needs of
data dissemination
• IT specialists : know best how the information is organised and systems
Phase is complete when the list of stakeholders is documented.

9. Kick-off meeting
Traditional project management procedures will generally apply, such as :
• Define project scope
• Set expectations of all key project stakeholders
• Identify project risks
• Discuss project plans
A Preparation Questionnaire can be used to prepare the project scope. It is
mainly for international projects though can be adapted for regional projects.
Input for the discussion can be from previous lessons learned documents.

10. Project Governance
A well-defined project
governance is vital, even if it is
very simple.
Governance structure consists of:
• Smaller project: a single group
• Larger project with multiple
organisations:
– steering group on management
level
– technical group(s) on work level
SDMX expertise and domain
expertise are required in both
groups.

11. Project Proposal
The project proposal:
• summarises the business needs
• states the aims of the project, how the deliverables will satisfy the business needs
• provide a reference for the following checklist steps
• provide information for the later steps in the project
Known risks should be included and managed:
• the available budget
• time limitations
• staff/resource availability
• location limitations, e.g. the pilot countries must be from the same continent
• technical limitations, e.g. the versions of SDMX that may/may not be used
• political restrictions, e.g. regarding confidential data sensitivity
• methodological constraints
The roadmap and work breakdown in the PLAN & ORGANISE stage could be added in
this document.

12. Communication & Consultation Planning
This stage consists of identifying groups to communicate with.
The types of communication are:
• Consultation: get input for the project
• Information: give output from the project
• Presentation: give capacity building and information
Additional group types to consider are:
• SDMX standard bodies such as working groups
• Methodological experts such as classification experts
• Statistical domain experts, who need to be consulted
• Constituencies (regional or international) who may be stakeholders in the exchange
• Technical specialists, in order to start an analysis of the infrastructure and systems.
Special attention should be made to the preparation of pilot phases
Get input from expert bodies to reserve their time in advance.

13. This phase is broken down into the following sub-
processes:
• SDMX Skills & Training for Project Team
• Project Roadmap & Work Breakdown
• Identify Standard Templates
• Collaboration Platform & Issue Log
• Define Pilot Phase(s), scope and participants

14. SDMX Skills & Training for Project Team
Ensure that the project team members have enough SDMX knowledge.
• Consult existing documentation made available on sdmx.org
• Attend webinars, training sessions, and SDMX conferences
• Learn basic tools used to produce XML files
• Make a pilot study on a statistical domain using available DSDs and tools
• Exchange with colleagues from other agencies who implemented SDMX
The phase is complete once the project team members have the knowledge to
perform the subsequent tasks in the checklist, especially in the DESIGN phase.

15. Project Roadmap & Work
Breakdown
Add planning detail to the project proposal:
The WBS may be based directly on this SDMX
checklist.
1. Create Work Breakdown Structure (WBS) by
splitting sub-tasks with dependencies between
tasks
2. Create roadmap by assigning time estimations
to each WBS sub-task
3. Assign team members to WBS sub-tasks if
possible
Consideration should be made to:
• The milestones at the end of each main phase
(DESIGN; BUILD; etc.)
• The pilot review(s) start and completion
• Creation of artefacts in the SDMX registries
• The "Project end" milestone
The WBS may be added to the Project proposal
document.

16. Identify Standard Templates Standard templates:
• save time
• avoid missed steps
• approach tasks in the order according to
established best practices.
Relevant steps have templates attached to
them, e.g. the Generic DSD Matrix.
Check each step for a template that can be
reused.

17. Collaboration Platform &
Issue Log
Collaboration platform provides an essential link
between all persons involved in the project.
Issue log is:
• A list of ongoing and closed issues of the project
• used to order, organize and prioritize issues
associated with the current milestone or
iteration.
• Contains issues arising during the internal project
design and management stages
• Documents the issues arising from the pilot phase
feedback
A issue log template is available here. For larger
projects it is recommended to use an issue tracking
system such as Jira.
This phase is complete when a collaboration platform
and an issue log are available.

18. Define Pilot Phase(s), scope and participants
The pilot phases are needed to:
• Test the project deliverables "in the field“
• Find issues so that they may be rectified
• Give participants experience in using the SDMX artefacts and implementing the data
flows.
Project deliverables are sent to a group of pilot phase participants.
Pilot participants are a mix of agencies and stakeholders involved in the data flows.
Pilot phases:
• Content review: Checks that DESIGN stage material is understandable, well-designed,
and that it covers the scope of the project. The pilot participants review the material
issues are added to the issue log
• Technical review: <covered in the later slide>
If two pilot phases are not possible then the technical review should be mandatory.
Output from the "Define pilot phase“: an agreement of:
• which pilot phases to execute;
• what will the pilot phases contain;
• and how to call for participants.

19. The DESIGN phase is detailed in a separate guideline
"Modelling a Statistical Domain for Data Exchange in
SDMX".
It is recommended to model using SDMX 2.1 artefacts.
Include agreements on integrity rules or validation rules,
they can help testing.
Supporting artefacts are not described in the modelling
guidelines. The following artefacts may be considered in
design:
• Category scheme(s) for organising the dataflows in
categories;
• Provision agreements for defining who is sending or
disseminating specific dataflows;
• Structure set mappings to document the link to other
DSDs.
This phase may be revisited several times depending on the
pilot stages and the issue log.
Available Templates
• Generic DSD Matrix, to be used for organising the
elements of a DSD in a logical and synthetic way
• DSD (complex) matrices used in other SDMX
implementations: National Accounts, Balance of
Payments/Foreign Direct Investment

20. This phase builds the production solution to the
point where it is ready for testing and review. This
phase is broken down into the following sub-
processes:
• Choose Registries (Pilot & Production)
• Create SDMX Artefacts in Pilot Registry
• Implementation & Usage Guidelines
• Create Pilot Review Material
• Internal Technical Testing

21. Choose Registries (Pilot & Production)
• SDMX artefacts should be in an SDMX registry for:
– Maintainability
– Discoverability
– Referencing
• First step of the BUILD phase: create the project SDMX registries.
• Free, registry solutions available: Search SDMX.org for “Registry”.
• If production SDMX artefacts are meant for external use, expose it publicly.
• Pilot/Testing and production SDMX artefacts should be stored in separate registries.
• Before an agency operates an SDMX registry, the agency should be registered in the
central SDMX Agency scheme. Contact hostmaster@registry.sdmx.org to request
this.
At the end of this phase, the pilot and production registries will be decided.
The pilot registry should be implemented and made available for the next phase.

22. Create SDMX Artefacts in Pilot Registry
1. Create the SDMX artefacts (Code Lists, DSDs, etc.) from the design material
such as the DSD matrix. Can use the authoring tools in the SDMX registry
2. Fill "Description" fields in the SDMX artefacts for understanding
3. Finalise and make the SDMX artefacts available in the pilot registry
At the end of this phase, the SDMX artefacts should be available and ready for
use for the internal project testing.
Could be iteration from internal tests before making artefacts available for the
pilot phase participants.

23. Implementation & Usage Guidelines
Should cover the following aspects:
• The scope, purpose, and deadline of the technical pilot;
• what is expected from pilot participants;
• an explanation of the technical pilot material and usage guidelines;
• an explanation of the SDMX artefacts
• details on how to use the tools, e.g. the SDMX registry;
• technical particularities, e.g. SDMX message formats expected, SDMX
header fields
Annexes should be included for examples and information, such as references
to guidelines, technical specs.
This phase is complete when the implementation and usage guidelines have
been drafted.

24. Create Pilot Review Material
Should include:
• The updated deliverables from the DESIGN stage;
• the BUILD stage deliverables such as the implementation & usage
guidelines;
• test material such as example data messages;
• the DSD xml-schemas
• the location of the pilot SDMX registry
• the issue log that was created in the PLAN & ORGANISE stage

25. Internal Technical Testing Required in order to:
• prove that the technical pilot has a
chance of success
• fix problems and revise the pilot
material
• enable the pilot coordinators to get
up-to-speed and offer support to
piloting agencies
This phase is complete once the
completion of the internal testing has
been signed-off by the ownership group.

26. MANDATORY TECHNICAL PILOT
Three distinct phases:
• COLLECT phase: Get feedback from pilot participants and add it to the central issue log.
• PROCESS phase: Consolidating feedback, remove duplicates and following up issues that lack clarity.
• ANALYSIS phase: the project group steps through the issues log and decides actions based on the
issues. For example, an issue may be that a code is missing for a dimension, so a new code is required.
Technical review aim: test that the project's artefacts can be implemented.
Send to participants:
• Deliverables from the DESIGN and BUILD stages
• Test material such as example data messages and xml-schemas
Procedure
1. The pilot participants review the material
2. implement their SDMX system for processing
3. Perform the system testing such as validating data messages against the DSDs
4. Send the feedback and data messages by adding to the issue log

27. This phase manages the release of the final
products to the outside world. These activities
support users to access and use the outputs
released.
This phase is broken down into the following
sub-processes:
• Define Maintenance Agreement
• Publish SDMX Artefacts in Production
• Publish Maintenance Information
• Project Ends & Operationalise Maintenance
Agreement
• Provide Support

28. Define Maintenance Agreement
A crucial document that describes how to maintain the project's deliverables.
The MA is required to end this project and to kick-off the maintenance process.
Used by stakeholders to:
– initiate a change in the domain's artefacts
– to contact someone for help
Used by the project team/ownership Group to
– maintain the MA itself
– Make decisions on change requests
The MA documents:
• who is responsible for what
• what can be done and when
• Reference information on artefact usage, such as Code Lists
The document should contain these sections:
• An introduction and purpose
• A description of the ownership group mandate, including the domain involved;
• Maintenance information broken down by Domain: maintenance agency, main stakeholder(s);
• Contact details for the maintenance agencies;
• Governance details of the ownership group
• Maintenance Timelines. "Regular maintenance"; and "Fast-track maintenance“ tables
The published checklist contains a template for the Maintenance Agreement document.

29. Publish SDMX Artefacts for Production
1. Ensure that all issues are fixed with the SDMX artefacts from the pilots
2. Ensure that all of the SDMX artefacts' "Description" fields are complete
3. Copy the SDMX artefacts from the technical pilot registry to the production
registry and finalise the artefacts
4. Ensure that the versioning of the artefacts conforms to the SDMX
versioning guidelines
This phase is complete when the project's SDMX artefacts are final and
available for use in the production SDMX registry.

30. Publish Maintenance Information
The maintenance agreement for the SDMX artefacts should be made available
to the project stakeholders for transparency, guidance and to enable feedback

31. Project Ends & Operationalise Maintenance Agreement
An important project milestone.
The project has ended and the maintenance agreement takes over.
Make announcements defined in the "SPECIFY NEEDS: Communication &
consultation planning" phase.
Consider adding news and information to the SDMX.org site. Contact the
SDMX.org webmaster contact@sdmx.org.

32. Provide Support Provide ongoing support available for the project
deliverables and project community.
Availability of such support should be clearly
communicated.
Support details are in the maintenance agreement.
The types of support could be:
• User workshops on how to implement the SDMX
system
• Webinars between the project team and
implementors
• The implementation and usage guidelines
• The learning material available on SDMX.org and
other sites
This phase is ongoing, though milestones could be
when this information has been communicated to
the SDMX community.

33. This phase logically takes place at the end of
the project.
This phase is made-up of three sub-processes,
which are generally sequential, but which can
overlap:
• Conduct Project Evaluation
• Document Lessons Learned
• Give Feedback to SDMX Working Groups /
secretariat

34. Conduct Project
Evaluation
1. Determine persons / team to conduct
evaluation
2. Gather inputs required for evaluation
3. Conduct detailed analysis and
evaluation of all gathered inputs
The phase is complete once the analysis
and evaluation is finished and
documented.

35. Document Lessons
Learned
Document the lessons learned for the future
versions of these SDMX artefacts, and for other
SDMX projects in other domains.
• Produce report detailing findings, and
recommendations for improvement
• Submit evaluation report to appropriate
boards for discussion
• Agree on action plan for the proposed
recommendations
• Set up metrics to monitor the success and
benefits
• Implement action plan

36. Provide Feedback to SDMX
bodies
In order to improve the standard and
guidelines, feedback is requested by SDMX
working groups on issues that were
encountered when implementing standards
and guidelines, or to send ideas for
improvements:
• Feedback on technical
standards: twg@sdmx.org
• Feedback on SDMX statistical
guidelines: swg@sdmx.org
• Feedback on the overall SDMX initiative
and governance: secretariat@sdmx.org

37. Any Questions?
Google for “SDMX Design Checklist”