This section unpacks the ‘scoping and starting’ stage to open standard development, with focus on how to research, plan and approve the goals, features, budget, schedule and resources to develop your
Last updated
Was this helpful?
The aim of developing an open standard or data is to create a robust product that solves a problem or meets a need.
To ensure the open standard has the intended impact, it is useful to decide on your aims and objectives.
Typical activities to help you decide aims and define objectives:
Review research into the problem and feedback
Develop a to identify and clarify your aims
Consider core features that are essential to the success of the standard
Consider features that make the standard interoperable (work well with existing standards) by reusing open formats, vocabularies, identifiers and more
Consider features that make the standard easy to adapt and extend – particularly if it will be used in variety of ways
If the standard is to be used globally or in regions speaking different languages, consider translations of the standard, guides and resources
Consider tests for the standard and any products (data, models, vocabularies) to ensure it will work in real-world situations
Adopt the five so your open standard is developed fairly, transparently and cooperatively
Ensure aims and objectives are SMART (Specific, Measurable, Achievable, Relevant and Time-bound)
Your research, aims and objectives will help you select the right development method for your standard.
In ‘first steps’, we explored the variety of people, organisations and processes involved in developing open standards for data.
Some standards developers don’t follow a set development method at all.
To help you choose the right development method for your open standard, consider:
expectations of the funder and adopters — the people and organisations using or funding the standard may have preferences or expectations about the development method. A formal standards body may be the preferred development partner as they can bring expertise, contacts and a tested method. Alternatively, agile methods may already be in use or familiar
anticipated risks, schedule and budget — where the schedule or budget is constrained or there are high risks, these can impact the preferred development method. Both sequential development that happens in a set order and agile development that favours cycles, come with risks and benefits that need evaluating
The development method you choose will affect how you plan development.
Agile methods favour iterative development so that features may be prioritised, added and removed.
Sequential methods favour specifying and designing all the features before development starts, with some having more flexibility for changes than others.
Other methods may vary, with many standards-developing organisations producing their own development methods.
The development plan should give everyone involved with the project an idea of the scope, schedule, features and budget for the open standard.
Activities to help plan development include:
Prioritise and test the core or essential features to produce a robust open standard. It is useful to develop use cases, scenarios to understand what is core or essential, and what is optional and may be excluded. Core features may include supporting a number of file formats, translations, providing human and machine-readable documents, making the standard easy to adapt and extend, and interoperable (work well with existing standards).
Decide who owns the intellectual property on your standard and contributions. As your standard will be developed in the open, you may allow people and organisations to contribute to its development. Consider how you will manage contributions and how contributions will be licensed.
Engage early and often and plan to continue engagement throughout the standard’s development.
Make testing part of your development plan so that your open standard is robust and works in real-world situations. Expect to test the open standard or data produced using the open standard for a variety of scenarios. Early adopters can help make sure the open standard or data produced works as intended.
With a development plan in place, you may need approval from the person or organisation that owns or funds the standard to begin development.
The responsibility for approving the standard may also fall to a board, committee or working group – some formal standards bodies have specific steps to follow before development is approved.
Approval may be needed for the:
scope of the standard
aims and objectives, including a theory of change or other assessments
people and organisations who will develop the standard
early adopters
prioritised features
development plan
identified risks, schedule and budget
By the end of the scoping and starting stage, you should have:
A development plan that includes engagement and testing
A stakeholder map of the people and organisations who will adopt the standard, early adopters, and those who will use or be affected by the standard, data produced using the standard or related products and services
The scope, features and use cases that demonstrate a strong reason for creating the standard, compelling scenarios for how the standard will be used and the core features it will contain
A governance method that outlines how changes to the standard will be managed
Intellectual property guidelines that describe who owns intellectual property and other rights on the standard and any contributions
An open license that allows anyone to use the open standard
The funding model that outlines how development, advocacy and engagement will be funded and who is providing the funding
For example, , the national body for standards in the UK, favours formal development, using its method.
Authoritative bodies like , , and also have standards development processes you can follow.
In contrast, Google – the corporation behind the (GTFS) – favours , featuring rapid iteration based on agile software development.
how clear the requirements are – formal development favours completing the design before development. This is more successful when requirements are clear and straightforward. Where requirements are less clear, an agile method may be more suitable. The UK government for example, favours agile delivery to support discovering and clarifying requirements
how well the team understand the development method – a good understanding of the method, clarifying , and providing project management or product ownership skills will help make development easier to manage
Develop or other diagrams if necessary to ensure everyone involved in development and testing understands the underlying concepts, flow of information and scenarios. This understanding can help identify core features for development and keep development on track.
Decide on phases of work in line with your development method. You may decide upfront or at a later date what work to complete in each phase, how to test the product and data, and who will sign off the tests. Your chosen will help to manage changes as the standard is developed.
Choose the development infrastructure that will support your development team’s work. These are the tools and platforms where your development will happen and how you will share progress and resources with your community. Consider platforms that support sharing test data and test models. Read ‘’ for examples of a community platform.
The communication channels that help you keep in touch with your community – for example, online forums, newsletters, social media, email accounts, repositories like , offline meetups, groups like or
The can help you think through why the standard is needed, who it is for and how it will work. Clearly articulating the purpose of the standard will keep it on track – see ‘’
An to consider who will use the standard and how. The outputs will impact the types of tools, guidance and support needed by users of the standard