Railton Consultants Ltd Quality Manual

Railton Consultants Ltd Quality Manual Document No. RCL30114/MAN/1502 Revision 03 February 2015 Approved: Date:

REVISION/REVIEW REGISTER A REVIEW/CHANGE OF THIS DOCUMENT WAS CARRIED OUT AS FOLLOWS: DATE REVISION CARRIED OUT BY AMENDMENT AND BRIEF REASON 9/8/2011 00 N Edmunds Draft Version 9/4/2012 01 N Edmunds Revised following comments 26/10/14 02 N Edmunds Expand the description of Quality Centres and include new manuals such as Environmental Management, Sales and Marketing and Supply Chain management 20/02/15 03 N Edmunds Updated to include audit requirements and for PR10033 which requires the collection of quality data for processes. Included references to security procedures and documents. RCL30114/MAN/1502-03

CONTENTS 1 PURPOSE... 1 2 SCOPE... 1 3 ANNUAL REVIEW PROCESS... 1 3.1.1 Annual Quality Review... 1 3.1.2 Annual Software Security Review... 1 4 INTERNAL COMPANY COMMUNICATIONS... 2 5 PROJECT BASED APPROACH TO WORK... 2 5.1 Internal Projects... 2 6 COMPANY DOCUMENTATION... 3 6.1 Guide To Project Based Working... 4 6.2 Software Development Procedure... 4 6.3 Document Control Procedure... 4 6.4 Source Code Control Procedure... 4 6.5 Human Resources Manual... 4 6.6 Financial Procedure... 5 6.7 Sales and Marketing Manual... 5 6.8 Supply Chain Manual... 5 6.9 Health and Safety Procedure... 5 6.10 Environmental Management Manual... 5 6.11 Software Operation Manual... 5 6.12 Software Maintenance Manual... 5 6.13 Information Security Procedure... 5 7 AUDIT... 6 8 ISSUE MANAGEMENT... 6 8.1 Review Processes... 6 8.1.1 Annual Quality System Review... 6 8.1.2 Customer Feedback... 7 8.1.3 Course Participant Reviews... 7 8.1.4 Staff Appraisals... 7 8.1.5 Project Closeout Review... 7 8.1.6 Quality Data Collection... 8 8.2 Quality Centres and Action Tracking... 8 8.2.1 Project Technical Issues... 8 8.2.2 Quality System Issues... 9 9 RECORD RETENTION... 9 10 REFERENCES... 10 RCL30114/MAN/1502-03 i

APPENDIX A - GLOSSARY... 12 APPENDIX B RCL QUALITY DOCUMENTS... 13 ii RCL30114/MAN/1502-03

1 PURPOSE The purpose of the quality manual is to describe the operation of the Quality Management System (QMS) to be applied at Railton Consultants Ltd (RCL). It includes or refers to the following: The annual review process Internal company communications Project based approach to work Company documentation System for rectifying defects Record retention time In general terms this manual describes the project-based approach used by the company. It is subject to an annual review in accordance with Board policy. 2 SCOPE The quality manual covers all aspects of work within RCL and is intended to implement the Quality Policy defined by the Board in the Quality Policy Document {reference i}. 3 ANNUAL REVIEW PROCESS This section describes the contents and objectives of the annual quality review and also describes the role of the software security review. 3.1.1 Annual Quality Review The annual quality review should: Include a review of quality policy Include assessment of quality problem report resolutions (see issue management below) Include assessment of customer questionnaires and project reviews Identify any general regulatory requirements on the company Set the date for the next quality review Plan the development of the quality management system Plan how to improve the quality management system Identify board level training needs Scheduled annual company hardware asset utilisation plan identifying any needs Scheduled annual company software installation plan and identify any needs Perform annual industry technology review for presentation to the board identifying opportunities and likely issues for the company Take into consideration the results of the annual software security review. 3.1.2 Annual Software Security Review This is to be completed annually. It will focus on all aspects of IT security but in particular it must describe how client data is to be protected. In the future, the development of a security manual is also to be considered, as is a move towards compliance with BS7799. However, it is unlikely that this can be completed during the current annual cycle due to resource shortages, as current resources are committed to addressing other improvements to the overall quality system. RCL30114/MAN/1502-03 1

4 INTERNAL COMPANY COMMUNICATIONS This section describes how internal communications are organised within the company: The small nature of the company means that internal communication can be performed in a very simple and direct manner, in particular: After each monthly Board meeting the views of the Board are communicated to staff by a collective team brief. At this brief, the staff can pass back points and queries which will normally be addressed at the next Board meeting or more urgently by an individual Board member if required. The results of bi-weekly project meetings are communicated to team members either by the project manager briefing project members in a separate team meeting or more normally by the direct involvement of team members in the project management meetings. In addition the current size of the company means that an informal communication system can frequently be used in the company to great effect. 5 PROJECT BASED APPROACH TO WORK A project based approach to organisation of the quality system is employed by the company. This is described fully in the Guide to Project Based Working {Reference ii}. Within the company all activities are managed as if they were projects. This allows the application of an almost uniform quality process across the company. This process includes on-going internal activities such as human resources. When time permits, the process may be modified to avoid this incongruity by the addition of some complexity to the quality system, if this appears to be of benefit to the company. In addition, all projects are categorised according to their internal complexity or the required rigour of implementation as being between A for the most complex to C for the most straightforward. This is done to allow a graded application of quality assurance tailored to each client's financial capabilities, requirements and approach. 5.1 Internal Projects As already stated within the company, there is a number of key internal standing projects listed in the table below. Each of these projects governs an area activity within the company. To find more detailed information about the purpose of each area, who is responsible for the area and any applicable standards, documentation and deliverables the identified Project Quality Plan (PQP) listed in the table should be consulted. Project ID Project Title PQP Reference RCL30114 Quality RCL20103/PLN/1504 RCL30124 Health and Safety RCL30124/PLN/2100 RCL30125 Environment RCL30125/PLN/3101 RCL30117 Human Resources RCL30117/PLN/1504 RCL20102 Technical Infrastructure RCL20102/PLN/5535 RCL30123 Training RCL30123/PLN/2500 RCL20103 General Administration RCL20103/PLN/1132 2 RCL30114/MAN/1502-03

Note that although the general administration project controls a number of entities called projects in the document management system these do not constitute projects from a quality management system perspective. They are: RCL20101 - General Finance RCL30105 - General Sales and Marketing RCL30129 - Facilities Management RCL30126 - Training Room RCL30110 - Local Support Similarly there is also a number of projects in the document management system which are used solely to generate a series of documents with unique references. These are also not to be confused with projects from a quality management system perspective: RCL30108 - Invoices RCL30112 - Software Delivery Notes RCL30111 - Asset Register RCL30132 - Reviews RCL30133 - Change Requests RCL30134 - Test Records RCL30135 - Test Specification 6 COMPANY DOCUMENTATION Overall guidance for the operation of the company is set in the Corporate Policy Document {Reference i}. This is reviewed annually and states the general intentions of the Board for communication to all employees. Individual elements in the company document system are mostly described in one of two other key documents and these should be referred to for more detail. They are: Guide to project based working {Reference ii} The Software Development Procedure {Reference iii} Two other principal documents describe the control of information within the company, together with any externally supplied documents and information. These are: Document Control Procedure {Reference iv} Source code control procedure {Reference v} The day to day operation of key company systems and their associated documentation is described by three other key documents. These are: Human Resources Manual {Reference x} Financial Procedures {Reference xi} Health and Safety procedures {Reference xii} Sales and Marketing Manual {Reference xiv} Supply Chain Manual {Reference xv} Environmental Management Manual {Reference xvi} Finally two other potential documents, which are not currently formally implemented, are also described below. These are: RCL30114/MAN/1502-03 3

Software Operation Manual Software Maintenance Manual A diagram giving an overview of how the company documents relate to one another is given in Appendix B. 6.1 Guide To Project Based Working The first of these, the guide to project-based working, has been mentioned above and describes the central role of the Project Quality Plan (PQP) and associated documentation in managing company projects. It also describes how projects are to be organised and managed within the company. 6.2 Software Development Procedure The second document describes the processes to be applied for the development of software, which is the company s primary activity. The appropriate use of documents and techniques to be employed in this activity within the company is also described. The company Code Review Procedure {Reference b} is particularly significant part of the software development process for ensuring the appropriate quality of end products. 6.3 Document Control Procedure The document control procedure describes the control and identification of the conventional documents and externally supplied media which essentially change slowly over time through a revision or require a unique identification process. This process is automated through the use of the company's Project Documentation System (PDS) which is described in the first document. Currently approvals are logged by scanning the front sheet signature into the approved directory in PDS but RCL is planning to include electronic approval of documents in the enhanced PDS system. The new system should also provide access to the most recent documents only, by default. Currently, PDS does not prevent the accidental use of obsolete documents. 6.4 Source Code Control Procedure The source code control procedure describes the processes used to control the detailed changes required for the source code of a project by the use of the server based Subversion code control system (SVN). Its use is not limited to source code control but is used for any information requiring fine grained distributed control such as the user s calendar backups. Backups are used to preserve products and components and data as described in the related General Backup Procedure {Reference e} 6.5 Human Resources Manual This document concerns itself with aspects of the company relating to human resources. Its purpose is to ensure that RCL is compliant with any current legal requirements and that the welfare of the staff is considered during operations. This document describes the procedures for the: Maintenance of personal and training records Induction of new employees 4 RCL30114/MAN/1502-03

Dismissal of employees Employee review process Maintenance of training records Maintenance of the employee handbook {Reference a} The disciplinary and grievance procedure {Reference d} Control of employee contracts Monitoring of subcontractors 6.6 Financial Procedure This document records the procedures to be applied governing the financial activities of the company. 6.7 Sales and Marketing Manual This document records the procedures to be applied governing the sales and marketing activities of the company. It focuses on details of how the company should present itself on the Internet, how marketing procedures should be performed and how tenders should be constructed. 6.8 Supply Chain Manual This document describes the processes related to purchasing, including the selection of components, inspection and tracking of items. The processing of faulty components is also included in this document. 6.9 Health and Safety Procedure This document describes the health and safety procedures to be applied to the core activities within RCL. This document is intended to be expanded to cover more areas of work as part of a continual process of improvement. Related to this is the company's Accident Reporting Procedure {Reference c} 6.10 Environmental Management Manual This document describes the processes to be applied to the management of the environmental impact of all the company's activities and sets out review periods and processes for the company. 6.11 Software Operation Manual This document describes the use of software in the company. It is currently stored in the source library as html pages under https://prod01/svn/rc/proc. It is intended that these documents should be transferred into the company PDS document server as a formal document or set of documents at a later date. 6.12 Software Maintenance Manual This document should be created to describe the maintenance operations performed by RCL. It has not been formalised because there is very little maintenance work performed outside the normal development cycle. However, as the company pursues its objective of creating a set of standard product-based deliverables, this document should be created to formalise activities in this area. 6.13 Information Security Procedure The company information security procedures are defined in this document. Each year, the Board will appoint an information security manager who will be responsible for company information security. The information security procedure should be reviewed RCL30114/MAN/1502-03 5

annually and updated by the information security manager. An information security review should also be produced each year by the information security manager. The review will recommend courses of action for company information security over the next year to be approved by the Board. 7 AUDIT All internal processes at RCL are potentially subject to audit in order to check processes for operation in accord with the company's goals and procedures. There are three causes of audits which are identified below: Areas which were identified as requiring improvements as part of the annual quality review should be audited. These will be identified in the annual quality report. Randomly selected key areas for 'spot check' audits identified by the quality manager during the year. The nature of the business means that most audits are likely to focus on aspects of the software development process. When audits are requested by clients as part of a contractual obligation. In all of the above cases, it is the responsibility of the quality manager, who is appointed annually by the Board, to ensure that suitably qualified or experienced staff are appointed to perform any audits and that the associated audit reports are completed. Persons performing audits should preferably be trained as auditors but must at least have sufficient knowledge and familiarity with the type of process being audited to be able to make useful judgements about the compliance of processes to the intended procedures. Each audit shall produce a report as an output. Audit reports should include recommendations of any changes required in existing procedures or identify any non conformances and record them as problem reports within the issue management system. 8 ISSUE SUE MANAGEMENT This system describes the defect rectification system employed at RCL 8.1 Review Processes This section describes the review processes applied within the company. If any of these review processes identify issues which cannot be immediately resolved, they are recorded for resolution in either the minutes of an appropriate meeting or in the company action tracking database described below. 8.1.1 Annual Quality System Review Annually, the board initiates a review of the whole Quality Management System and as a result agrees a set of aims and objectives for the following year. This has already been described in section 3 above. 6 RCL30114/MAN/1502-03

8.1.2 Customer Feedback On completion of a project, customer feedback is sought by requesting the completion of a form. This information will be reviewed at the project closeout meeting and any possible defects recorded. Any defects identified must be resolved or logged in an external system to the project before the project can be closed. 8.1.3 Course Participant Reviews Following a course, supplied by RCL, the views of participants are sought and any defects arising are recorded in meeting minutes or as an action tracking system problem report. 8.1.4 Staff Appraisals Another form of system assessment, particularly in the area of staff training, is the annual staff appraisal. This is used not only to record staff training needs within the human resources system but also any other company operational issues that may require resolution. As with other matters, these are either recorded in meeting minutes or in the action tracking database. 8.1.5 Project Closeout Review Project closeout reviews are intended to assess the overall performance of a project. This is normally performed as a part of the project closeout meeting, where staff members are invited to supply their perceptions about the project and also attempt to identify any defects in the project's processes. This review will be structured to focus on the following areas; Human Resources and Training Project Management and Planning Coding Documentation Testing Quality Client Relations Sales and Marketing The project team members are asked to identify at least one positive outcome in each area before also identifying any defects that arose in the area. They are then asked to propose changes in process to ensure good outcomes are repeated and process failures are eliminated. Any other issues identified during the project, together with any recommendations, must be resolved or transferred to another project before the first project can be closed. A project closeout report must be produced summarising the outcome of the meeting. This will also include any quality data collected as described below. The project manager is also responsible for producing a re-estimate of the amount of work required to complete the project as part of the project closeout report. This is recorded to improve future estimation processes when similar work is tendered for. RCL30114/MAN/1502-03 7

8.1.6 Quality Data Collection The non-standard nature of the company's processes mean that qualitative measures are the most appropriate for monitoring quality improvements. The project process will be assessed on a numeric scale by all available staff involved on the project in order to identify how well the project was performed in each of the review areas identified in 8.1.5 above. The assessment is performed by the member of staff giving a rating from 0% (complete failure) to 100% (unqualified success) by marking a line between two points. This can then be measured to determine a percentage 'success' figure. The figures from each project over the year will be averaged and presented in the annual quality review to give a numeric indication of areas which are not thought to be improving and should be subject to further consideration by the quality department. 8.2 Quality Centres C and Action Tracking This section describes how non conformity data is controlled by the action tracking databases. As already stated all activity in the company is treated as a project. Projects are frequently initiated by a single commercial contract but the nature of software development that projects are not cleanly closed and will tend to continue as a chain of contracts as long as clients remain interested in activities such as support. This is discussed further in the Guide to Project Based Working {Reference ii}. Most projects are also identified as Quality Centres (QC), unless they are purely used for administrative or record keeping purposes. As a result, normally, all departmental and development projects are quality centres. Each quality centre represents a subdivision in the common company action tracking database. A manager is assigned to each quality centre and is responsible for progressing any issues reported against that quality centre. Possible defects that are observed within the company should normally be logged in the company action tracking database against the relevant project quality centre. If no suitable quality centre can be identified then the Quality Project quality centre is used as a default. The current company quality manager is always assigned as the project manager of the quality project. As such he is responsible for ensuring the resolution of any issues assigned to the Quality QC. Normally, technical issues related to a project will be dealt with by that project s own issue tracking mechanism. If for some reason this system fails or the issue cannot be resolved at a project level, then by default the issue will become a quality system issue. The resolution of all quality management issues will be documented in the minutes of the Quality Project bi-weekly project management meeting. 8.2.1 Project Technical Issues Technical project issues such as defects in documentation, code or project specific processes will be dealt with in the following way: 8 RCL30114/MAN/1502-03

Recorded for resolution against the project-specific problem quality centre in the company action tracking database held as part of the RCL document management system. Progress on these issues will normally be recorded by the Code Custodian who will report their status to the bi-weekly project management meeting. The project manager of each project is responsible for ensuring that the project management team review and progress problems in the problem database as part of the bi-weekly meeting. Alternatively problems can be reported directly to the project manager, who is responsible for either ensuring the issue is resolved or calling an immediate project management meeting to bring the matter to resolution. Issues which cannot be dealt with in this manner should be treated as Quality System Issues (see below). 8.2.2 Quality System Issues Any quality system issues will be dealt with in the following way: They will be recorded against the Quality QC in the company problem reporting and action tracking database in the RCL document management system, and will be reviewed at the bi-weekly project management meeting. The quality manager, who is also project manager of the ongoing quality project, is responsible for ensuring that the quality management team review and progress problems in the problem database as part of the weekly meeting. Alternatively, problems can be reported directly to an RCL Board member who is responsible for resolving the issue and reporting the issue to the Board at the next meeting or calling a Board meeting to bring the matter to resolution in a timely manner. 9 RECORD RETENTION Currently there is an outstanding defect identified within the quality management system because no record retention times have been set. This is partially because there is no capacity for setting review periods or retention times within the existing document management system. Within the new document management system retention times will be established for: Project / Customer Review records Annual policy review Monthly board minutes and actions Quality project actions and minutes Project management minutes and actions Project quality plans Staff HR records Staff appraisal records Staff training records Financial records Health and safety records RCL30114/MAN/1502-03 9

Company policy documents Company procedures 10 REFERENCES References from this document are tabulated below. I ii iii iv v vi vii viii ix x xi xii xiii xiv xv xvi xvii Corporate Policy RCL30114/PLN/1501 Guide To Project Based Working RCL20103/PRC/1009 Software Development Process RCL20102/PROC/5516 Document Control Procedure RCL20102/PROC/5511 Source Code Control Procedure RCL20105/PROC/5510 Security Review RCL20112/RVW/5518 Project Quality Plan Template RCL20103/PLN/1007 Cat. C Project Quality Plan Template RCL20103/PLN/1028 User Requirements Template RCL20103/PRC/1012 Human Resources Manual RCL30117/PRC/1527 Financial Procedures RCL20101/PRC/5017 Health and Safety Procedures RCL30124/PRC/20103 Quality Management Review RCL30114/RVW/1500 Sales and Marketing Manual RCL30105/MAN/5008 Supply Chain Manual RCL30146/DOC/9751 Environmental Management Manual RCL30125/DOC/3105 Information Security Procedure RCL30147/PRC/3502 Indirect references to other company procedures and guides: a b c d e f Staff Handbook RCL30117/PRC/1510 Code Review Procedure RCL20102/PROC/5517 Accident Reporting Procedure RCL30114/RVW/1500 Disciplinary and Grievance Procedure RCL30117/PRC/1502 General Backup Procedure RCL20102/PRC/5519 Security Handbook RCL30147/NTS/3501 10 RCL30114/MAN/1502-03

g Security Induction Presentation RCL30123/NTS/2506 RCL30114/MAN/1502-03 11

APPENDIX A - GLOSSARY The table below presents a glossary of terms associated with the pod pre processing system user requirements. Term FS PQP QA QMS PR Description Functional Specification Project Quality Plan Quality Assurance Quality Management System Problem Report (Issue) 12 RCL30114/MAN/1502-03

APPENDIX B RCL QUALITY DOCUMENTS Quality Manual 13 RCL30114/MAN/1502-03