1. Taking SMEs from Word-based narrative to topic-based structure

2. Cross-references between documents

3. Multi-level numbering

4. No subheadings

5. Unexplained subheading nomenclature

6. Different list numbering styles

7. Offline (outside CDB) Current process for managing requirements Microsoft Word / Quark Create / amend document Output Requirements for review Controls Database Draft and review Upload new or revised requirement information (not all document content) to CDB Word / Quark templates Formatting. presentation, and PDF Enter Requirement

8. Current process for managing requirements Key issues CDB is a legacy system which is difficult to support and expand to meet the requirements of this project CDB doesn’t capture enough information to recreate the RGS document in its entirety, not just the measures and controls Microsoft Word and Quark templates don’t validate the document structure which allows the author to potentially deviate The published RGS content and format is dependent upon the individual Microsoft Word or Quark document Potential multiple repositories of the source information

9. Project vision Within three years, RSSB will enable: the provision of discrete, assessable requirements to the GB mainline rail industry; the efficient authoring of requirements and less on-going change; and single source of validated information for standards produced by RSSB, accessible to both RSSB and stakeholders, by adopting a new authoring culture and technology for creating and managing discrete requirements which can be associated with relevant related information. Source: Project Vision version 1.0 16/04/2013

10. Project background This project will specify, procure, install and implement new requirements management processes and tools for the S&TS directorate to support improved change control and management of requirements, standards and associated documents. This project will also address training and migration of existing data to the new tool.

11. Proposed replacement process Requirements Management Database *Enter requirements Requirements Review Create / amend document(s) Capture corporate memory Publish document build Draft, review and approve PDF(Web) (HTML/Media)?Data Create document build Postscript(Print) *All content required to create a document will be created, stored and managed new system

12. Proposed replacement process Structured Authoring All data required to create a document will be stored within the Requirements Management Database All corporate memory relating to a document lifecycle (drafting, review, publication) will be retained An authoring process driven by creating validated small discrete and reusable chunks of information Adoption of an open authoring standard such as Darwin Information Typing Architecture (DITA), if feasible within the project constraints Version control and build/release management for all information stored within the system

13. Proposed replacement process Structured Authoring – How will it work at RSSB? Technical authors can focus on creating, organising and reusing the relevant information Potentially replace the off-line A3 print-off with a review process that allows commenting and editing conducted within the system The system will constrain how a requirement is structured All history relating to information used to produce a document is stored and visible within one system Authors Technical authors get to spend more time creating or editing content, and less time battling with document templates

14. Project plan and timescales March 2013 to Jan 2014 Detailed requirements gathering workshops and review sessions Expression of interest to potential supply base Create and approve detailed requirements documentation Update existing Outline Business Case to Detailed Business Case for review and approval February 2014 to April 2014 Supplier tendering and selection Revise Detailed Business Case to reflect detailed costs from preferred supplier Contract award and kick-off April 2014 to July 2014 Develop technical writing training material Technical writing training sessions Training feedback and review NEXT STAGE

15. Requirements gathering workshops Defined existing workflows and processes Including what was broken: controls database Developed requirements for a new system: – Authoring needs – Access for reviewers –Version control – Outputs to multiple formats 9 workshops

16. Requirements gathering workshops Identified issues and concerns –Would the tools be suitable? –Would this go the way of other projects? –Would this be son of CDB? –What of the SMEs that can’t write? –What’s in it for me? –Backlash 9 workshops

17. So what worked? Issues must be raised and addressed Find a very good project manager Examined current processes: involved and engaged Requirements gathering exercise Show the current system is broken Establish a strong business case Identify WIIFMe Communicate often

18. So what worked? Don’t rush

19. Project plan and timescales July 2014 to October 2014 Develop prototype system Presentation and consultation with users Collect feedback for incorporation to final design October 2014 - December 2014 Implementation planning and design December 2014 - March 2015 User training IT infrastructure deployment Regression testing Data migration New and updated management procedures Warranty period and go-live Project close and hand-over to business unit

20. Introduction to new concepts Any questions?