Business Management: Project Delivery Process D600

D600 - Technical Specifications

DEFINITION

Create conceptual specifications for any IT development work and other technical activities. Define the technical requirements and approach to a sufficient level that they can be used in the detailed design, programming and construction of a component of the overall solution.

SUMMARY

Most projects involve some conventional IT development work, for example building interfaces, conversion programs and communications networks. Although it is not uncommon for the appropriate staff to be part of the Application Software Implementation project team, these activities are often “sub-contracted”* to

• the organisation’s IT department or

• to the package supplier or

• an external software house,

The Application Software Implementation Methodology does not define or prescribe a conventional custom program development methodology to be used for custom programming tasks. In most cases the client organisation will have well-established procedures which should be followed. This is the case whether or not the staff involved are part of the Application Software Implementation project team. Where there is no established methodology in use by the developers concerned, an appropriate approach or techniques may be agreed, normally based on an industry-standard approach or an appropriate Consultant’s defined methodology.

There is a need to define the technical requirements to a sufficient level that they can be used in detailed design, programming and construction. The basic approach is similar to the design of package-based parts of the design. The requirements, options, recommendations, and details are analysed and set out in an Implementation Paper (or Brief Implementation Paper). One Technical Implementation Paper will be written for each discrete area of development.

The purpose of the Technical Implementation Paper is to state the requirements and required approach sufficiently clearly that the developers can commence their activities, following their normal approach, without any need for further investigation or agreement. The level of detail would normally be a “conceptual design”, leaving the developers to develop a full detailed design in accordance with their normal approach.

Note that this work is sometimes performed by, or with the help of, the system’s supplier, particularly where modifications concern or are closely linked to the technical design of the packaged parts of the solution.

Technical Implementation Papers should be drafted, reviewed, agreed and signed off in accordance with the Definition of Topics (DoT) - see Process D100. They should be formally agreed and accepted by the client organisation and by the developers undertaking responsibility for delivery of the technical component. It may also be appropriate to agree it with the package vendor, particularly if there is any consequent question about support and upgradability of the software supplied.

PATH PLANNING GUIDANCE

Optional - used where non-Application Software Implementation Methodology IT development tasks are involved in the overall technical solution.

There will normally be one technical specification process and corresponding Technical Implementation Paper per discrete area of development. These may be shown on the segment plan as processes D60x.

Note that this process covers generic needs for custom development. Alternatively, related specific processes are available:

D602 - Finalise interface design

D604 - Finalise data conversion routine design

D606 - Finalise design for functional modifications / additions / custom reports

DEPENDENCIES

Prerequisites (Finish-Start):

Delivery Approach Definition (DAD) or similar high-level definition of the overall business solution.
Definition of Topics (DoT)

Prerequisites (Finish-Finish):

Various dependencies may exist between the different Implementation Papers, including these Technical Implementation Papers. These will have been considered during the detailed Segment Planning. In particular:
Integration Issues IP - see process D160
Data Conversion Strategy IP - see process D180

Dependent procedures (Finish-Start):

Instigation of corresponding non-Application Software Implementation Methodology parallel tasks (see Process D650, D656, D658)

RECEIVABLES

Delivery Approach Definition (DAD) or similar definition of high-level design
Definition of Topics (DoT)
IP Control Log (IPCON)
Integration Issues IP - see Process D160
Data Conversion Strategy IP - see Process D180

DELIVERABLES

Technical Implementation Papers
Updated segment plan (if required)

TOOLS

Skeleton Implementation Paper
Guidelines: “Modelling Techniques”
Guidelines: “Custom Development”
IP Guidelines: “IP-Data Conversion”
IP Guidelines: “IP-Database”
IP Guidelines: “IP-Languages”
IP Guidelines: “IP-Handover”
Examples: “Interfaces and output files worksheet”
Examples: “Conversion Worksheet”
Examples: “Contingency Plan”
Guidelines: “Application Software Implementation Methodology development workbench”

DETAILED DESCRIPTION OF TASKS

The Technical Implementation Paper

The key deliverable from this process is normally a technical Implementation Paper (or Brief Implementation Paper).

The objectives of an Implementation Paper are:

to assist key management and team members to understand and agree upon the business requirements for the topic,
to explore all options to address the business requirement (including procedural, process redesign, non-automated solutions),
•to indicate the preferred solution and to identify why that recommendation is being made such that key management and team members will understand and accept the recommendation,
to define how the recommendation will be implemented in sufficient detail that no further design decisions will need to be taken (ie no further consultation, agreement or sign off is required),
to highlight any unresolved issues which may affect the various details, recommendations and decisions presented in the paper - such outstanding issues should normally be resolved before the paper is finalised.

The use and format of an Implementation Paper is considered in detail in the Process D400 - Design / Prototype. The comments in D400 apply equally to Technical Implementation Papers, and should be read in conjunction with this Process. Alternatively, if a brief approach has been agreed and is appropriate, the Brief Implementation Paper approach can be used instead- see Process D450.

In addition to the generic comments about Implementation Papers, the following additional comments apply to Technical Implementation Papers:

Detailed requirements should still address business needs, but are more likely to contain technical information where the technical detail is a genuine requirement, for example the precise data format required for an automated input to a package. Accordingly, it is normal to see a wider range of techniques used to record such needs and some very detailed low-level information. For example, technical papers often contain:

data dictionary entries, record layouts, data models, database definitions etc
system specification documentation for other systems involved
details of any special techniques or approaches required to exploit the coherence of the overall technical solution, eg using the package’s built-in database, data dictionary or 4GL tools
detailed translation tables to convert from old data to new
validation rules and tables
details of timing, size, performance requirements
backup, recovery
details of standard automated controls and standard clerical procedures required to control the programming suites.

Options will vary considerably and normally include full automation and full manual treatment of the requirements.
Full systems integration is increasingly becoming a user demand, and the techniques to achieve it are constantly improving. This evolution tends to add greatly to the complexity of the most-functional options. Full integration cannot normally be achieved unless it was planned and designed into all the systems involved. Very often, the Implementation Paper will need to convince the management that full integration is too costly in terms of time, effort and money.
The option may sometimes include whether to accept the package’s functionality or whether to undertake modifications to the package itself.
Options may include options as to who does the work, eg should it be subcontracted out to the vendor.
Given that custom programming can often be expensive, time consuming and high-risk, very serious consideration must be given to evaluating the options and forming a recommendation.
The options frequently cross system and organisational boundaries and imply work on other computer systems affecting other IT teams and user departments - these issues must be included in the considerations, particularly any lead time or availability constraints.
Existing computer systems are often badly understood and poorly documented. Substantial work may be necessary to evaluate work required unless there is an effective existing system maintenance function covering the area. Always check the facts carefully.
The detailed instructions will often be very technical in nature. They should give enough detail so that further research and agreement is not necessary.
Large tables of facts may be best presented as appendices, eg validation tables, conversion tables, record layouts etc
It is not necessary to provide a full detailed program design specification as this should be defined as part of the non-Application Software Implementation Methodology work, performed in accordance with the agreed approach to custom development. The program designer would normally take the Technical Implementation Paper as the statement of user requirements.

The contents of these Technical Implementation Papers will be affected by earlier, more strategic work concerning the technical shape of the solution. In particular, attention should be paid to the:

Delivery Approach Definition (DAD) - see process S700/S710
Technical Plan IP - see process D110
Integration Issues IP - see process D160
Data Model - see process D170
Data Conversion Strategy IP - see process D180.

Technical specifications frequently fall into one of the following areas:

interfaces between systems
existing data validation, clean-up and conversion programs.

Some further guidance on these areas is given below by way of example task lists.

System Interfaces Design

Objectives:

Finalise the interfaces and output files need and determine how they will be created

Hints:

Every attempt should be made to adapt the client’s business processes to the standard interfaces of the software package and reduce the number of enhancements needed.
This approach requires very good understanding of the underlying database structure and contents, since any missing, incomplete or incorrect data (special attention to any control fields) might let the Application package malfunction. Not only current definitions of the Application data base fields but also definitions for upcoming releases. Subsequent changes might let open definitions be fixed into a new terminology, and thus let custom field definitions change their meaning.

Steps:

Compare interfaces and output files of the existing system and the new system, identify any changes and complete the Interfaces & Output Files Worksheet

Manual and automatic interfaces
Temporary and permanent interfaces
Microcomputer uploading and downloading
Data required
Level of detail
Frequency

Evaluate interface alternatives and select approach

Complexity
Cost
Resources
Timeframe
Organisational Impact

Organise analysis and prepare the implementation papers for system interfaces

Background
Alternatives
Recommended Approach

Review Implementation Paper with client sponsor and obtain approval to proceed
Complete System Change Requests (if required) for any identified system enhancements

Finalise Data Conversion Design