Project Delivery Process D600
Blog: Biz-Performance, David Brown
D600 - Technical Specifications
DEFINITION
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
Objectives:
- Finalise what data will be needed to effectively operate the new system and how that data will be collected and converted
- Finalise the cutover method to transfer operations from the existing system to the new system
- Determine a contingency processing approach in case the implementation schedule cannot be met
Hints:
- Vendors frequently provide custom conversion programming to load existing data into the new system files. However, some vendors will only provide standard conversion programs that load existing data into the new system files from a standard layout. If only standard conversion programs are provided, additional programming is required to extract and translate existing data and organise it into the standard layout.
- Printed copies of the new system database or master file layouts can be useful as worksheets for identifying the source for each element.
- The existing system frequently does not contain all the data needed by the new system; nor is the data current, accurate or complete. It should also be expected that the numbering schemes and coding structures will be different from the new system. Depending on the data to be converted, a mix of conversion approaches may be needed, consisting of manually reviewing and cleaning up the existing data, translating and loading available data with conversion programs and manually loading any additional data needed. Depending on the amount of data to be converted and the skills of the project team, converting the data manually may be a more practical solution.
- Because processing and reconciling both the old and new systems can be time-consuming and expensive, it is important to balance the effort involved in the selected cutover approach with the risk associated with processing and data errors. Cutover alternatives include:
- Linear – Begin new system operations and immediately discontinue old system operations
- Parallel – Duplicate processing of both systems for a specified period of time
- Phased – Begin operations of the new system and phase out operations of the existing system
- Modular – Implement the new system, but only one department, product line or module at a time, with a period of observation in between.
- The contingency plan may be formal or informal, but should reflect the risks associated with not meeting the implementation schedule. At a minimum, the plan should clearly identify the following:
- Alternate method for continuing business operations
- Method for collecting interim data
- Arrangements for ongoing use of conversion equipment and resources
- Measurements and events for determining when the contingency plans should be activated.
- If available, the implementation strategy developed in the Delivery Approach Definition can provide a starting point for determining the detailed data conversion requirements for the new system.
Steps:
- Identify the data requirements for the new system
- Master file fields
- Transaction fields
- Historical balances
- Determine sources for each data element
- Existing system files
- Existing manual forms
- New data to be collected
- Determine the collection and conversion method for each data element and complete the Data Conversion Worksheet
- Direct electronic conversion
- Electronic translation
- Collect and enter manually
- Collect, translate and enter manually
- Determine timing and sequencing for converting data elements
- Master file data
- Historical data
- Current balances
- Review existing data for accuracy and completeness and determine data correction and reconciliation tasks
- Prior to conversion
- After conversion
- Evaluate conversion programs provided by the vendor and identify changes and additions
- Determine any special conversion equipment needed
- Determine any special operation procedures during conversion
- Backup frequencies
- Hours of service coverage
- Evaluate the risk associated with system data errors and determine system cutover approach
- Linear
- Parallel
- Phased
- Modular
- Determine the initial support to be provided and system handover milestones
- Evaluate the risks associated with not meeting the implementation schedule and prepare a contingency plan, if needed
- Evaluate conversion alternatives and select approach
- Complexity
- Cost
- Resources
- Timeframe
- Organisational Impact
- Organise analysis and prepare the implementation paper for data conversion
- Background
- Alternatives
- Recommended Approach
- Review implementation paper with client sponsor and obtain approval to proceed
- Complete a system change request (if required) for any identified system enhancements