Project Requirements Process R060

R060 - External Technical Review

DEFINITION

Review of what is currently technically feasible within the scope of the project.

SUMMARY

An external review is undertaken to look at what is currently technically feasible within the scope of the project, for example by examining journals and other literature, reviewing demonstration copies of software, talking to vendors etc.  The scope of the review may be restricted by the technical constraints as identified in R040, or to a pre-determined package solution if a strategic choice of package architecture has been made prior to the project, eg where the project is part of an Application Software integrated implementation programme.

The external technical review helps to stimulate ideas for the System Vision (see Process R070) - but do not confuse technical feasibility with desirable functionality!  It is useful to identify the state-of-the-art in terms of technical capabilities, eg applications software, architecture, networks, user interfaces, etc.  Information should be gathered to assist in deciding whether these are desirable.  The most cost effective solution will often be based on an established technical architecture rather than a newly developed one.

PATH PLANNING GUIDANCE

This process is optional.  It is used where there is incomplete knowledge of the “state-of-the-art” in technical possibilities.

DEPENDENCIES

Prerequisites (Finish-Start):

• Project launch

Prerequisites (Finish-Finish):

• Review/Confirm ToR, Scope, Objectives (L010)
• Constraints (R040)

Dependent procedures (Finish-Finish):

• System Vision (R070)
• Final report (R150)

RECEIVABLES

• Project Constitution or other definition of project scope
• Technical constraints

DELIVERABLES

• External Technical Review - part of the Definition of Requirements (DoR)

TOOLS

• Tools: Package Information Sources

DETAILED DESCRIPTION OF TASKS

Purpose of the study

Very few people would claim to have a complete understanding of the “state of the art” in technical capabilities.  The capability of the systems on the market improves constantly, as does the ability of applications software to exploit the technical architecture.

We collectively have a very detailed knowledge of a vast range of technical architectures. Most of our consultants will read specialist journals on a regular basis and will have a reasonable understanding of their areas of specialism.  It is unlikely, however, that either the client organisation or Consultant can feel certain that all possibilities have been recognised and evaluated unless a specific review is performed.

Where there is a desire to seek a competitive advantage by identifying either the current best architecture or emerging new architectures, it may be of value to conduct an externally focused review of technical solutions.

A single choice of integrated packaged software will often not cover all the business needs of an organisation.  In the context of a complete solution, there may be an investigation into which solutions may be used in conjunction to give the full spectrum of needed functionality. 

Form of the review

The External Technical Review is undertaken as a free-ranging study of potential technical solutions.  Its scope will be defined by:

• defined scope of the project,
• the organisation’s IT strategy or policies,
• the technical, organisational and financial constraints as identified in Process R040,
• any predetermined and fixed decisions concerning the components of the overall solution.

There is no prescribed method or approach for undertaking the study.  Its nature, scope and approach should be discussed and agreed with the project’s sponsor.  Techniques may include:

• consultation with industry and IT specialists within the consulting organisation - in particular, those specialising in the relevant business, process and technical areas,
• trawl through specialist IT journals and journals addressing the business area or application area; this would normally be achieved through on-line information services.
• telephone interviews or visits with contacts in “friendly” organisations (the friendliness of other organisations varies substantially by industry and according to the individual organisation; they may often be willing to discuss technical architecture but not business practices and systems),
• review of marketing materials or personal contacts with vendors,
• attending seminars or briefings,
• trying out systems by using demonstration copies of software.
• access to vendor information through Consultantss partnership arrangements, eg SAP, AXAPTA, Oracle,

In addition to information on the individual products and services, it might be valuable to examine the relationships between  products.

The External Technical Review should also attempt to assess the potential desirability of the technical options identified.  It should not normally make conclusive decisions in favour of a specific architecture unless there are strong reasons to do so, for example, to exploit existing investment in IT equipment and infrastructure.  It should, however, identify the potentially desirable aspects of the technical architecture such that a series of architectural requirements or questions can be proposed for inclusion in the Definition of Requirements (DoR) and subsequent Invitation to Tender (ITT).

Documenting the findings

The findings would normally be documented in a textual form.  They should be talked through and agreed with the project’s sponsor and key client managers .  It would be normal for the client organisation’s IT management to take a particular interest in these considerations.  Any implications should be noted and agreed.

A list of specific technical questions exploring a vendor’s technical architecture may be prepared.  This would identify desirable aspects of the technical architecture, for example, client/server architecture, distributed databases, graphical user interfaces, networks, needs to integrate or interface with specific other systems etc.  This list should be in a format suitable for subsequent use in the “Requirements Matrix” of questions or requirements to be specifically answered by vendors in the Invitation to Tender.

The findings will be published and agreed formally in the Definition of Requirements report (DoR).