Scoping and starting

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

Decide on aims and objectives

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 theory of change 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 Open Stand principles so your open standard is developed fairly, transparently and cooperatively

• Ensure aims and objectives are SMART (Specific, Measurable, Achievable, Relevant and Time-bound)

Choose the development method

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.

For example, BSI, the national body for standards in the UK, favours formal development, using its principles of standardisation method.

Authoritative bodies like W3C, IEEE, and BOMOS also have standards development processes you can follow.

In contrast, Google – the corporation behind the general transit feed specification (GTFS) – favours agile methods, featuring rapid iteration based on agile software development.

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:

• 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 Service manual 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 roles and responsibilities, and providing project management or product ownership skills will help make development easier to manage

• 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

Plan the development

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.

• Develop conceptual models 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 governance method 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 ‘How to set up a W3C community group’ for examples of a community platform.

Get approval for development

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

Expected outputs

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

• The communication channels that help you keep in touch with your community – for example, online forums, newsletters, social media, email accounts, repositories like GitHub, offline meetups, groups like W3C community groups or Google groups

Useful tools

The open standard for data canvas 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 ‘How to use the canvas’

An empathy map 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