SRS Compliance Paper

Shared Registry System

Compliance with DRS

Post-Implementation Review

Written by: Doug Mercer

On: 25 January 2002

Version: 1.1

2 Background

This paper is a response to a motion put before the InternetNZ Council meeting of December 1^st 2001, carried unanimously:

01/149 MOVED: (Gray/President) "THAT the Recommendations in the "Post Implementation review of the Domainz Registry System" report dated 25 October 2001 (Section 17) be accepted and referred to the SRS IOC for a report on compliance in the new system at the next Council Meeting.

In this report, the recommendations from Section 17 of the post-implementation review are addressed individually with comment on the manner by which they have been recognised and addressed by the SRS Implementation Project. For a full understanding of each recommendation it is necessary to refer to the DRS report itself. Because of its highly sensitive and confidential nature, it was not possible to repeat or paraphrase the content of the DRS report in this document.

The SRS IOC will be provided with further assurance on the current implementation approach when the independent QA of the project, currently in progress, has been completed.

3 Recommendations

3.1 Governance (17.1)

This section deals mainly with the process for policy development and the relationship between Domainz and InternetNZ. Section 17.1.3 has relevance for the SRS with its suggestion that 'where the capital spend is large in relation to the size of the company, the Directors of the Board have an overarching responsibility to satisfy themselves that they are fully informed of relevant information and risks'. It recommends external assurance processes as one method to ensure this.

In the context of the SRS, the IOC is the 'Board'. The IOC is kept informed on the progress and status of the SRS on a weekly basis and a Risk and Issue reporting system has been established with the IOC on the escalation path. External QA has been, and will be, commissioned for all project phases, including the structure and management of the project in general and individual deliverables.

3.2 Consultation and Communication (17.2)

The main thrust of this recommendation is the need for a communication plan (17.2.1). The SRS Project Plan currently has a section dedicated to communication where all the known communication requirements and issues are documented. It states that a formal communication plan will be drafted in early-2002 (currently planned for February).

The current document identifies the SRS stakeholders (InternetNZ, InternetNZ members, Domainz, .nz providers, name holders, news media) and outlines the respective communication policies with them. A communication schedule is also provided. The communication plan will likely expand on this information.

As a general response to section 17.2.2 to 17.2.4, consultation to date has been extensive. Consultation was seen as the key to achieving stakeholder buy-in to the requirements definition phase and the results and reactions to date indicate it has been effective. There is no intention to change this open approach, within the bounds of the communication plan, and relationships between stakeholders and the SRS Implementation team remain good.

Discussion lists have been monitored as a means of recognising issues and gaining feedback (17.2.5) but they are not part of the formal communication process.

3.3 Tender Processes (17.3)

Several tender processes have been followed by the project to date (Domainz RFP, Register RFI, Register RFP) and more may follow. In the this regard, the SRS project team have followed industry-standard and risk-averse procedures.

Well-defined requirements were provided with the Register RFP. A fixed price contract was not sought (17.3.1). Financial risk mitigation will be achieved through a phased approach.

All three evaluation processes to date were structured and formally documented, including evaluation criteria, prior to commencement of evaluation (17.3.2).

All dialogue and correspondence with vendors, including e-mails, was documented and filed with the tender documentation (17.3.3).

Evaluation criteria were documented and agreed prior to evaluation of responses (17.3.4).

Reference checking has been performed on the one vendor selected to date (Catalyst IT) covering all the areas recommended (17.3.5).

Benchmarking (reasonableness checking) was performed on the Register RFP responses, where time and costs were compared against other proposals and internal SRS estimates (17.3.6).

The contract with Catalyst is specific on all the recommendations in 17.3.7. Although there are no explicit financial incentives, the time and materials schedule for the technical architecture phase has a maximum cost, after which Catalyst will bear any overrun costs. This approach might also be followed for subsequent phases, depending on the nature of the work.

Detailed project plans are not included in the contract (17.3.8) as this is outside the scope of the engagement.

3.4 Analysis and Design (17.4)

The project has not yet reached the detailed analysis and design phase. The report's recommendations follow industry standard practice and are completely in line with the intended SDLC (Systems Development Life-Cycle) for the SRS.

3.5 Development Standards (17.5)

Development standards will be agreed with Catalyst IT. Versioning, documentation, etc will form part of this. These were areas that RFP respondents were asked to address and Catalyst's compliance with this contributed to their selection.

Audit on development will be performed at three levels. Catalyst have committed to providing their own internal quality checks, the SRS Technical Project Manager will continually monitor their output, and independent QA will be commissioned on key deliverables.

3.6 Acceptance Testing (17.6)

The acceptance testing phase of the project has not yet been planned. Recommendations 17.6.1 to 17.6.6 follow industry standard practice and are completely in line with the intended SDLC for the SRS. The SRS Project Plan states that a formal Acceptance Testing Plan will be put in place.

It is not intended to use e-mail lists as a primary mechanism for logging issues or faults (17.6.7). It is likely that Catalyst's own system will be used if it meets our requirements.

3.7 Data Conversion (17.7)

The migration/data conversion phase of the project has not yet been planned. Recommendations 17.7.1 and 17.7.2 follow industry standard practice and are completely in line with the intended SDLC for the SRS. The SRS Project Plan states that a migration plan will be produced.

3.8 Documentation and Training (17.8)

Documentation and training have not yet been planned. The SRS project plan currently states that a documentation needs analysis and a training needs analysis will be performed (17.8.1). More work needs to be done before documentation and training acceptance criteria can be determined (17.8.2). All documentation created for the project, regardless of its source, will be owned and held by InternetNZ (17.8.3).

3.9 Cutover and Support (17.9)

All the recommendations in this section will be followed. The cutover will be planned in detail, including backout options (17.9.1), and support agreements will be signed and in place beforehand (17.9.2 and 17.9.3)

3.10 Project Management (17.10)

A detailed project plan has been produced in line with recommendation 17.10.1. It is currently in draft form and has been reviewed by the SRS IOC. The plan should be viewed as a living document that will expand and change as the project progresses. Currently, the following statements can be made about it.

• The project timeframe and budget are about to undergo a major review, due to the signing of the Catalyst contract. It can be assumed that the review will include all work necessary at Domainz and a single schedule developed that all parties are comfortable with.

• Full project costs have not been included because they have not yet been approved.

• It fully describes key project control processes, including Risk and Issue Management and Change Management.

• It does not yet contain detailed planning or information on future project phases such as Acceptance Testing and Migration. These will be completed as the need arises.

Risks, assumptions and constraints are reviewed weekly as part of the process of producing the Technical Implementation Weekly Progress Report (17.10.2). New risks and significant changes are documented in the report.

Dependencies with external activities will be identified when the Domainz and SRS plans are merged (17.10.3).

The SRS has an Implementation Manager and a full time Technical Project Manager (17.10.4). Domainz has a full time Business Analyst.

The standard project control techniques recommended (17.10.6) will all be used by the project. The first two, relating to project meetings, have yet to be implemented but will be when the project team is assembled over the next few weeks. The latter two, relating to monitoring and change management, are already partially in place and will be implemented more fully in conjunction with Catalyst's own practices.

The project already has a steering group in the form of the IOC (17.10.7).

Quality assurance reviews along the lines mentioned have already been planned and will begin soon.

4 Summary

The recommendations in Section 17 of the report on the DRS are all very sensible and totally in line with what the SRS management team consider to be industry-standard practice. There are no issues with any of the recommendations and most of the actions would have been taken regardless of the existence of the report. The SRS is fully compliant with the recommendations made.

The real risk to the SRS, or any project, is not usually that there is a lack of understanding of good SDLC practice but, for a variety of reasons, that it is not adhered to. The review of the DRS and all the background issues associated with it mean there is very little risk of the same problems re-occurring with the SRS. Rarely has a project been subject to such high levels of scrutiny and QA at all of its stages. This can only be advantageous to the project and should give considerable cause for optimism and a high quality result.

The advice generally given to stakeholders is that if they have any concerns or questions regarding the direction of the project, they should feel free to contact the Technical Project Manager. The 'open door' policy has worked well to date and will continue.

5 Distribution List

Copies of this document will be distributed to the following people:

• SRS IOC members;

• SRS Implementation Manager;

• SRS Technical Project Manager;

• Executive Director, InternetNZ;

• Chief Executive, Domainz.

SRS_-_DRS_Comparison-v1.1.doc