The helpdesk model¶
Throughout the adoption process, implementers may have a range of questions to ask about the high level concepts and detailed data model of a standard, and may benefit from advice and support on processes and tools to use at different stages of the implementation process.
Over the mid-term, many of these questions and support needs should be possible to meet through a self-service approach. However, early in the development of data standard, questions may raise new issues, or may highlight gaps in documentation that need to be filled.
Early in the life of a standard it is also important to treat each implementation as a key learning opportunity: generating insights into points at which a standard is hitting, or missing, its policy goal, and highlighting areas where standard updates, new tools, or improved guidance could better put implementers on the right path.
This is where the helpdesk, development and strategy model comes in.
A data standard helpdesk provides a free-to-access service promoted to respond to e-mail enquiries, and to provide reactive and proactive support to implementers of a standard.
The design of a helpdesk responds to a number of working theories.
Implementers don’t read the documentation
The documentation is vital to provide a settled view of what the standard is and does - but most people will not read it in full, or it is read once, and then not again. A helpdesk can signpost people to the most relevant areas of documentation at the right point in time, and can present documentation to implementers through workshops, calls, web-meetings and other media.
People don’t implement standards, they copy implementations
This means that a standard is only as strong as the leading implementations, or the implementations most likely to be copied. That calls for proactive engagement, particularly in the early phase of a standard, to make sure leading implementations and tools meet both the letter, and the spirit, of the standard.
When individual implementers feel like they are part of a wider community, and feel that someone else cares about the quality of their implementation, they are more motivated to get things right. A helpdesk shows that there are people behind a standard: and that the technical artefact is a connection to community, not just something abstract and impersonal. Many implementers, particularly in government, are cautious about posting questions into public fora, and instead are much more culturally comfortable with the idea of asking via private channels for technical assistance.
It's about building community and ecosystems
Often the questions asked in private would make for good public discussions. A helpdesk team can translate individual implementation issues into wider forum or issue-tracker posts, and can bring together the different stakeholders who may have views on those issues. Making connections between implementers, and working to align data publishers and users, can make a difference to the success of implementations.
Policy actors seek compliance with a standard. Users seek data usability. This is a tension to manage. A helpdesk should keep in mind the overall policy goals of a standard, whilst also ensuring the technical correctness of implementations.
Standards are always developing
The documentation will have gaps. A standard will not cater for all use cases. The helpdesk are able to identify gaps, and identify ways to address them through improved resources, or by feeding into the development of schemes and related tools.
A lot of the engagements a helpdesk has can be light-touch: aiming to provide quick replies to simple questions, to help keep implementations moving. In some cases, helpdesk engagements may be more in-depth, involving multiple days of work to support an implementer in planning, executing or evaluating their data publication.
A helpdesk might have the following modalities of work:
- Fielding direct enquiries - with an e-mail address, twitter handle and instant messages going into a ticketing system, from which written replies can be sent, and through which management information on the types of enquiries and enquirers getting in touch can be logged. Enquiries may come direct from implementers, or may come from the advocacy partners seeking to promote adoption of the standard.
- Scoping notes - working with prospective implementers to develop a shared understand of where the standard could help, and to identify options and steps for adoption;
- Mapping reviews - providing templates to map existing systems to the standard, and reviewing implementer produced mappings.
- Implementation guidance - sharing suggestions, resources and examples to highlight relevant technical and policy approaches to implementation.
- Data review and quality assurance - performing automated and manual checks on data quality.
- Training - delivering online and face-to-face training to implementers, and to other support providers, as part of capacity and field building.
- Tool assessment - reviewing open source tools developed to work with the standard and providing assessments of their re-usability.
- Technical analysis for policy advocates - acting as a sounding board for policy and advocacy teams, to help assess the extent to which a technical implementation will meet policy goals.
- Knowledge management - keeping track of prospective and actual implementations, and supporting reporting about levels of engagement with the standard.
- The secretariat of the International Aid Transparency Initiative have written about their helpdesk service that receives around 110 new support requests every month. They note that a number of other providers also offer support to particular segments of the implementing community (e.g UK NGOs)
- The Open Contracting Data Standard helpdesk provides e-mail support, as well as working closely with the Open Contracting Partnership to identify adopters for priority support and outreach. The OCDS helpdesk is run by two partner organisations: Open Data Services Co-operative, and ILDA, who cover support for Latin America.