Project Requirements Process R150

R150 - Collate and Agree Final Report

DEFINITION

Prepare, review and agree the final Definition of Requirements (DoR) report.

SUMMARY

The Definition of Requirements (DoR) report is the prime deliverable from the Requirements Segment.  It does not require any additional investigative work - it is essentially the collation of all significant information, findings and recommendations from the Requirements Segment processes.  The contents should normally have been drafted during the individual Requirements Segment processes in a suitable format for direct inclusion in the Definition of Requirements report without substantial editing.

The report will contain information already discussed and agreed with the project sponsor and other key decision makers within the client organisation.  It should not, therefore, require any substantial discussion or further work for the report to be reviewed and formally agreed by them.  Nevertheless, the report is the foundation of all future decisions and designs - it should be reviewed thoroughly and any final issues should be resolved.  The acceptance of the Definition of Requirements should be signified formally in writing.

PATH PLANNING GUIDANCE

This process is normal practice.

DEPENDENCIES

Prerequisites (Finish-Start):

• (none)

Prerequisites (Finish-Finish):

• Foundation (R010)
• Business Vision / Objectives / Do-Wells (R020)
• External Business Review (R030)
• Constraints (R040)
• Needs for business change and priorities (R050)
• External Technical Review (R060)
• System Vision (R070)
• Organisational Impact (R090)
• Detailed Requirements (R100)
• Feeder Review (R110)
• Gap Analysis - existing system versus requirements (R120)
• Establish Architectural Options (R130)
• Establish Costs and Benefits per Option (R140)

Dependent procedures (Finish-Finish):

• Post-requirements inter-segment processes, eg QA review
• Selection Segment launch

RECEIVABLES

• Foundation - existing systems and business processes
• Business Vision / Objectives / Do-Wells
• External Business Review
• Constraints (technical, organisational and financial)
• Business Needs and Anticipated Benefits
• External Technical Review
• System Vision: functions, data, volumes, performance, scope, objectives, boundaries / interfaces, technical goals, timescales
• Organisational Impact
• Detailed Requirements
• Feeder Review
• Gap Analysis - existing system versus requirements
• Architectural Options
• Costs and Benefits / Benefit Model

DELIVERABLES

• Definition of Requirements report (DoR)

TOOLS

• Skeleton Deliverables: Definition of Requirements

DETAILED DESCRIPTION OF TASKS

Preparing the Definition of Requirements (DoR)

The contents of the Definition of Requirements (DoR) will be drafted as part of the individual Requirements Segment processes.  As the issues are agreed with the project’s sponsor and other key decision makers they will be collated into a draft version of the final report.  The collated draft materials should be reviewed for clarity, style, coherence etc.  It is important that the facts, evidence, findings, options, recommendations and details are presented in a clear, unambiguous and complete manner.

It would be normal for this document to be reviewed according to the project’s defined approach to quality.  The project team should take steps to see that all agreed aspects of the requirements definition fit together without contradictions or gaps.  If any shortfalls or inconsistencies are identified in the materials, these should be addressed and agreed as appropriate.

The report will mostly contain information already discussed and agreed with the project sponsor and other key decision makers within the client organisation.  It should not, therefore, require any substantial discussion or further work for the report to be reviewed and formally agreed by them.  Nevertheless, the report is the foundation of all future decisions and designs - it should be reviewed thoroughly and any final issues should be resolved.  The acceptance of the Definition of Requirements should be signified formally in writing.

Presenting the conclusions

Depending on the wishes of the project sponsor, it would also be normal to prepare the key findings and recommendations from the segment in the form of a presentation to key management within the client organisation.  This should be based on the Definition of Requirements, but should only attempt to cover the key points for example:

• What are the business needs?
• What are the main options?
• What is the recommended approach?
• What are the benefits of this approach?
• What will the system look like?
• What is the way forward?

This presentation may also be a good opportunity to discuss the way forward in detail, for example, the Path Plan for the Selection Segment (if not already defined).  It is an ideal opportunity to sell the concepts and benefits to other management within the client organisation who might become “sustaining sponsors” during the Delivery Segment.