Project Delivery Process D400

D400 - Design / Prototype - Implementation Papers

DEFINITION

Design or define each topic within the project, using prototyping techniques wherever appropriate,  documenting the requirements, options, recommended approach and details in an Implementation Paper per topic.

SUMMARY

A key feature of the Application Software Implementation approach is the division of the overall work into a number of discrete topics.  This allows rapid and effective progress with the design.  Business Process Redesign techniques will be applied as appropriate.  Normally, prototyping techniques will be used to elaborate the design and to validate its overall coherence.  Prototyping by the project team may be supplemented by iterative prototyping sessions with a wider user audience.

Implementation Papers are used to manage these discrete topics.  As requirements, options and design details are defined, they are recorded in the Implementation Paper.   These topics will cover functional, technical and environmental design issues.

Implementation Papers should be drafted, reviewed, agreed and signed off in accordance with the Definition of Topics (DoT) - see Process D100.

The Implementation Paper is the hub of the flow of design information.  Information in it will normally be gathered from earlier work, and will normally be used as the basis for design documentation, user documentation, testing plans, training plans etc.

PATH PLANNING GUIDANCE

Normal practice.  A number of individual topics will be defined and agreed in the Definition of Topics (DoT).  In the segment plan these would normally be given numbers in the range D4xx.

DEPENDENCIES

Prerequisites (Finish-Start):

• Definition of Topics (Process D100)

Prerequisites (Finish-Finish):

• individual papers will have dependencies with other individual papers;  the details of such dependencies will vary according to the precise nature of the project.
• prototyping tasks will require the development system to be set up and usable (see process D130).

Dependent procedures (Finish-Finish):

• overall freeze / sign off of design
• development of full solution - processes D7xx

Dependent procedures (Finish-Start):

• individual papers will have dependencies with corresponding development tasks under processes D700 / D710 for package parameterisation and tasks within the D6xx processes for any areas of custom development; certain parts of the procedural and organisational processes (eg human procedures, training, test plan) will also depend on results from this process.

RECEIVABLES

• Definition of Topics (DoT)
• IP Control Log (IPCON)
• Delivery Approach Definition (DAD) or similar definition of high-level design

DELIVERABLES

• Implementation Papers (IP) as defined by the Definition of Topics (DoT)
• Prototypes of various components, eg screens, reports, processes, tables
• Updated segment plan (if required)

TOOLS

• Skeleton Implementation Paper
• Guidelines: Functional Design
• Guidelines: Modelling Techniques
• Guidelines: Various guidelines are available for specific topics - see the “IP Guidelines” Library
• Various example implementation papers
• Some common Implementation Papers are considered in more detail under other specific processes which create them, eg
• Technical Plan - D110,
• Project Training Needs Analysis - D120
• Development System Admin - D150,
• Integration Issues - D160,
• Data Availability and Purity - D180
• Organisational Impact - D 730
• System Handover plan - D830
• System Support and Administration - D850
• Transition to Live Service - D870

DETAILED DESCRIPTION OF TASKS

The IDDI Concept

Integrated Design Development and Implementation (IDDI) remains the single most powerful feature of an Application Software Implementation Project in comparison to other approaches.  IDDI assumes that package components are technically reliable and coherent such that the project team do not need to take a serial approach to the design work.

By relying on the technical coherence of the solution, it is possible to work on different functional or environmental aspects of the system independently in parallel.  This leads to substantial savings in elapsed time, in effort and in scheduling staff resources.

Each individual aspect of the system will undergo its own cycle of design, delivery and implementation with appropriate sign offs in between.  The key differences are:

• these are small manageable amounts of work that encourage good full review by user management with a minimum drain on their time and the avoidance of bottlenecks caused by large volumes of paper to review in a short time,
• when little work can be performed on one topic, the team can be concentrating on others, thus making the best use of their time.

It is the Implementation Paper which is used to manage these discrete topics.  As requirements, options and design details are defined, they are recorded in the Implementation Paper.

Prototyping

The package-based components of the solution will be ready to use as soon as the applications have been installed.  This makes them an excellent design aid.  Ideas can be tried out and tested before becoming fixed in the design.

During an Application Software Implementation Project’ Integrated Design Development and Implementation (IDDI), prototyping is often used to confirm requirements and to validate options.  It is then used to select and demonstrate a preferred approach.  Finally, the development and implementation details will be documented, often by copying them directly from the design prototype into the detailed instructions section of the Implementation Paper.

This design prototyping is commonly conducted in two different ways:

• the project team explore the requirements, options and recommendations in detail using prototyping techniques,
• partially complete subsets of the possible solution are presented to a wider user audience in iterative prototyping workshops for further comment, review and input.

Development of the system can be carried out as an extension to the design prototyping to build a full system prototype ready for formal testing.  Depending on the environment, the target system may be developed directly from the design prototype or it may be  created from the detailed instructions in the Implementation Papers.  This subsequent development will also be conducted in parallel tasks, some of which may overlap with non-dependent design tasks.  This “final” version of the system is built in subsequent processes - see, for example, processes D700 - Set up system parameters, codes, structures etc and D710 - Set up screens, queries & reports etc.

Business Process Redesign

Major aspects of Business Process Improvement/Redesign (BPI/R) may have been considered and defined already:

• prior to the project,
• during the requirements segment, and,
• in particular, in the Delivery Approach Definition (DAD).

During the design and prototyping activities, Business Process Redesign concepts and techniques should be applied to seek the best solution to the organisation’s business needs.  This must, however, be confined to the defined scope of the project as may be defined in the Project Constitution (PCON) and Delivery Approach Definition (DAD).  Typically, level 2 BPR/I techniques would be performed during the requirements work and only the level 1 “process optimisation”, ie fine tuning and design, would be carried out during the detailed design work in this process.

Any beneficial redesign outside this scope should be noted, but should not be developed until formal changes to the project’s scope have been agreed using the Change Control procedures (see process D140).

Implementation Papers

The Implementation Paper (IP) is used to manage the design prototyping process per topic.  A separate paper is produced for each topic, as defined in the Definition of Topics (DoT).  It is used to document and log progress through the prototyping process - ie it is written as the work is done as part of that work - it is not a separate task to document the results of the design or prototyping process.

The objectives of the 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.

Format and content of an Implementation Paper

The basic contents of an Implementation Paper (IP) have been defined to meet the objectives stated above.  Although the purpose and contents are defined, there is some flexibility in the layout and sequencing of the paper, the basic rule being to meet the overall objectives as simply as possible.

Topics should be defined such that they are of a manageable size.  Clearly the underlying issues will vary in size and complexity and the Implementation Papers will do likewise.  It may be possible to join together a number of small related aspects of the design into one topic, for example, all the individual accounting control requirements could be grouped together.  It might conversely be necessary to divide large difficult topics into a number of smaller areas.  As a guide, the size of the actual text in the resulting Implementation Paper (ie excluding control sheets, table of contents etc) could be described as follows:

1-5 pages      -        small

5-15 pages    -        normal

15-25 pages -        large

25-35 pages -        very large

over 35 pages  -        too large

The following table summarises the nature of each section and the tasks which may be performed.

Section	Content / Tasks required
Sign-off Control	This section forms a status control sheet for the IP.  For control purposes this information should also be logged in the IP Control Log (IPCON).  The control sheet shows responsibilities, other circulation, sign-off status, amendment history.  Further details about the purpose and meaning of this information can be found in Process D100 - Prepare / review / agree IP / Topic descriptions and sign-offs.
Scope of this document	This section provides a definition of the scope and objectives of the IP.  It may be taken directly from the Definition of Topics (DoT).  It is used to allow all readers to understand what should be covered by the paper and what is not relevant to this paper.  Further details about  this information can be found in Process D100 - Prepare / review / agree IP / Topic descriptions and sign-offs.
Management Summary	A brief management summary may be written to allow review by senior management and communication of the basic principles to other interested parties.  Note that the sign off for a paper must always be at a detailed level.  The summary is only relevant to other readers.  The management summaries of all IPs may be collected together to form an overall management summary for the system.
Requirements	The basic requirements should already have been established at an earlier stage in the project.  Where practical, the relevant aspects of these can be copied into this section of the IP to remind the readers what the business requirement is.  This will also lead to an amount of re-validation of those requirements.  In certain cases it may be more appropriate to retain detailed requirements in other existing documents to which cross references are made.   Where the requirements are not already expressed in a sufficient level of detail for the design work, further investigation, definition and agreement of detailed requirements may be required.
Options	This section lists the options which have been identified and considered.  All reasonable options to meet the business requirements may be considered including technical options, procedural changes or business process redesign.  Some options may have been identified in the selection segment of the project.  Further options  may be identified from the knowledge of the participants, from further research and by testing out scenarios using the prototype system.  The advantages and disadvantages of each option are considered and validated.  In some cases, part of this evaluation may be taken from the Selection Segment.  Where appropriate the options can be tried and tested using the prototype.  Key user management may be invited to see the options in operation and to confirm the extent to which they address the true business requirements.  The advantages and disadvantages will be noted in this section of the IP.
Recommended Approach	This section describes the recommended approach and gives an explanation for the recommendation.  The choice may be made for a number of reasons, for example necessity, cost, simplicity, benefit, risk etc.  Normally the logic for this will be discussed and agreed with the responsible user and other key management and team members before continuing to explain the full details of the preferred solution as described in the following section.
Detailed Approach	Details showing how to build and implement the preferred solution will be formulated.  This may not necessarily be the complete detail, but it should cover all design decisions such that no further consultation, review, agreement and sign off will be required.  Very often, the design details can be drawn directly from the design prototype, for example, by copying prototype parameter tables and screen layouts etc.  The detailed instructions are also used as the prime source for the generation of user and operational documentation, training materials and test definitions/scripts.  Wherever possible, this section should be written such that it can be reformatted for the other purposes without redrafting.
Issues	This section notes any outstanding issues that need to be resolved.  By the time the IP has been finalised there should normally be no outstanding issue, although, in some cases, it may be possible to defer the issue or agree not to address it.  Issues noted should be entered into the project’s issues control and resolution system - see Process D190.

The conventional format of an Implementation Paper may follow the pattern described above, ie:

Sign-off control

Scope

Management Summary

Requirements

• item 1
• item 2
• item 3
• etc

Options

• item 1
• item 2
• item 3
• etc

Recommended Approach

• item 1
• item 2
• item 3
• etc

Detailed Approach

• item 1
• item 2
• item 3
• etc

Issues

Where there are a number of separate considerations grouped together in a single paper, it may be more useful to lay it out as follows:

Sign-off control

Scope

Management Summary

Item 1

• Requirements
• Options
• Recommended Approach
• Detailed Approach

Item 2

• Requirements
• Options
• Recommended Approach
• Detailed Approach

Item 3

• Requirements
• Options
• Recommended Approach
• Detailed Approach
• etc.

Issues

Both of these formats are acceptable - the key requirement  is that the format chosen should give the best overall benefit.

The central role of the Implementation Paper

The Implementation Paper (IP) links together many of the earlier pieces of information and is in turn used as a source for later documentation - it is an objective of an Application Software Implementation Project  that text and other information be re-used as much as possible to minimise the work required.  Accordingly, the approach to style and level of detail for any Application Software Implementation Project  document should always be decided with this requirement for re-usability in mind.

Sequencing of topics / IPs

It is necessary to sequence the design and prototyping work allowing for in-built dependencies.  These will vary according to the package concerned and the needs of the project team.  Sequencing design tasks requires careful consideration by a specialist at the time the detailed plan is established and during Process D100 - prepare / review /agree topics / IP descriptions and sign offs.

Where iterative prototyping workshops are being held with the user population, the stages of design need to be tied up with the scheduling of workshops so that users can review a coherent part of the system.  These needs may clash with the normal dependencies of the design work.  In such cases, the design topics may need to be closed “in principle” but re-opened as they come under review during the prototyping workshops.

Sequencing with Application Software systems

It is best to configure the Application Software System through the IMG, keeping the status memo up to date.  Additionally, textual documentation should be maintained detailing screen customisation.

• Set up Organisational Structures as previously defined.  Included are the settings of the client codes, company codes, plants, storage locations, valuation areas, sales organisations (if SD is implemented), purchasing organisations (if MM is implemented), and warehouses (if WM is implemented)
• Configure and Customise Master Data in terms of fields to be used, the numbering structure, type of number assignment, the numbering intervals, match code tables, and other options tables for master data.
• Configure and Customise Transaction Data in terms of fields to be used, types of number assignment, the numbering intervals, document flow, match code tables, and other option tables for transaction data.
• Configure Periodic Data, i.e. the batch processes and long-running transactions that are activated on a periodic basis:
• Review previously defined periodic processes
• Review the schedule timing of periodic processes
• Review the established backup procedures
• Integrate tune-up and reorganisation runs into the system
• Customise procedures such as purchasing authorisation process, availability check in SD, etc.
• Configure and Customise Reports and Forms required by the various business functions.
• Customise standard reports using the Application Software utilities
• Update documentation on report usage
• Configure user master records and authorisation for persons who should use the Application Software System.
• Identify users
• Assign users to organisational structures
• Create user master records
• Set up user authorisations
• Approve user authorisations.

Authorship and Review

Some implementation papers will require inputs from more than one team member.  In such cases one person should be allocated responsibility for the production of the paper and assume authorship, accepting and editing contributions from the others.  However, wherever possible, no more than two staff should be involved with any one paper.  These responsibilities should have been defined in the Definition of Topics (DoT).

All papers must pass through some form of quality assurance procedure.  The quality assurance may be of two types:

• technical quality assurance to ensure that the proposed solution is technically sound and maximises the use of package facilities,
• user quality assurance to ensure that the designed solution meets the user requirements.

Technical quality assurance will primarily be carried out within the project team.  This may have been defined in the project’s Quality Plan.  At least two other team members should read the paper, raise queries and suggest amendments before it is issued.  These staff should be from the appropriate professional discipline and/or background to enable them to comment effectively.  The paper must be signed-off by the team leader to confirm that this has been done.

In some cases it may be useful to issue discussion papers relating to parts of the subject covered by a single implementation paper (see Process D300).  This should be done if the subject matter is thought to be potentially contentious.  The use of discussion papers provides early warning and allows such issues to be settled or defused before the final implementation paper is issued.

Discussion papers are also a useful vehicle for sounding out user and management opinion if there are several viable options available.  However, if discussion papers are to be used then:

• they should be short,
• circulation should be restricted to only those directly concerned with the subject matter,
• recipients should be asked to respond in writing.

It is sometimes possible to issue parts of an implementation paper as discussion papers as they are written so that most, if not all, of the final implementation paper has already been effectively quality assured before it is issued for formal quality assurance.

Those responsible for the quality assurance of any paper should respond with any queries or suggested amendments in writing before an agreed date.

Once responses have been received, three possible courses are available:

• if the queries or changes are minor, simply amend the paper and re-issue the paper for signing off,
• if there are a significant number of queries or changes, hold a formal meeting with the quality assurance staff to discuss and agree the resolution of the queries;  the prototype may be used to demonstrate the issues - the paper can then be amended and issued for sign off,
• if there are major objections to the paper it may be necessary to restart the prototyping and design process altogether and then restart the quality assurance process.

Sign off

All implementation papers must be agreed by client users and should normally be formally signed off according to the responsibilities defined in the Definition of Topics (DoT),.  This might include:

• the nominated quality assurer to indicate that it meets the correct technical standards,
• the user manager (Project Director) to indicate that the solution outlined in the implementation paper satisfies the user requirements,
• at least one other member of the steering committee.

Due to the complexity inherent in any integrated systems implementation, it is necessary to allow for issues to be raised in other parts of the project which may affect the current topic.  Since there can be no linear set of dependencies through the various aspects of a complex project, these issues may be raised after the current topic has been reviewed and agreed.  

Normally IPs will first be signed off “in principle”.  This indicates that all key reviewers accept the IP but recognise that the topic may need to be re-opened if issues occur elsewhere.  At this stage the IP is only open to amendment where issues are raised from other parts of the project through the Issues Control mechanism - see Process D190.  Further sign-off is required if a subsequent change affects a significant aspect of the paper.

At specific times IPs or groups of IPs will be frozen or baselined after which no change can be tolerated without full change control authorisation.  The issues control and resolution process handles all cross-aspect / IP issues.

Types of topic / Implementation paper

Topics and the implementation papers that describe them cover all aspects of design.  There are three main types:

• Functional  - examine the required functionality and how it will be achieved using the package.

• Environmental - examine the requirements and actions relating to the project, user or technical environment rather than the functionality of the system, eg security requirements and training needs.
• Technical  - describe technical work required to implement the system, eg interface programming, conversion programming, technical set up.

The list of topics to be used on any one project is defined in Process D100 - Prepare / review / agree IP / Topic descriptions and sign-offs.

The following table gives some example lists of topics and implementation papers for a range of applications.

Environment Papers

(not application specific)

Acceptance testing

Change control

Control procedures

Data take on approach

Database implications

Documentation standards

Feeder testing

Handover

Languages

Operational readiness

Operations procedures

Organisational impact

Package tuning

Prototyping standards

Report distribution

Report standards

Security

Screen design/standards

Vendor liaison

System upgrade policy

Technical testing

Testing plan

Training needs

Training plan

User procedures

Volume testing

Materials

Functional papers

Budgeting

Cycle counting

Dynamic binning

Common vendor details with AP and purchasing

Goods inspection

Goods inwards/reception

Materials on loan

Materials returned

Material scrapping/disposal

Multiple Storage locations

New materials issue/return

Stocktaking

Storage location coding

Vendor codes

Used material issue/return

Technical papers - feeders:

• Fixed Assets
• GL
• Maintenance interface
• Production scheduling
• Purchasing

General Ledger

Functional papers

Accounting issues

Allocations/recharges

Archiving

Budgets

Chart of Accounts

Numbering

Controls

Financial reporting

Foreign currency

Joint venture accounting

Management reporting

Modelling/decision support

Other reports

Period end

Project accounting

Security

Screen enquiries

Statistical data

Year end

Technical papers - feeders:

• Accounts payable
• Accounts receivable
• Fixed Assets
• Manufacturing
• Purchasing
• Inventory

Accounts Payable

Functional papers

Accounting issues

Contractors payments

Foreign currency

Invoice processing

Invoice matching

Joint venture billing

Payment processing

Vendor numbering

Technical papers - feeders:

• GL interface
• Purchasing
• Inventory

Accounts Receivable

Functional papers

Accounting issues

Credit management

Controls

Customer numbering

Customer records

Foreign currency

Joint venture sales

Period end

Receipts handling

Voucher processing

Year end

Technical papers - feeders:

• GL interface
• Sales Order Processing
• Shipping & distribution

Purchasing

Functional papers

Foreign currency

Import documentation

License control

Order/delivery expedition

Materials/parts numbering

Purchase order

Purchase request

Vendor numbering

Tendering control

Technical papers - feeders:

• Accounts Payable
• Production scheduling
• Inventory interface

Maintenance

Functional papers

Budgeting

Common numbering standards with inventory

Common/standardised spare parts

Equipment coding

Equipment tracking/history

Parts numbering

Periodic servicing

Planning/scheduling

Tag numbers

Technical specification

Time/cost analysis

Time/cost recording

Works Orders

Technical papers - feeders:

• Fixed Assets
• GL
• Inventory interface
• Production scheduling
• Personnel/payroll
• Process Control
• Production Planning
• Project Planning

Owners manual & Work Book

The finished Implementation Papers may be used as the definitive documentation for the project.  If they are of permanent value in documenting the design and construction of the system they can be filed in an “Owner’s Manual”.  If they were of temporary value during the project, they will be filed in the project’s  “Work Book”.  This should have been identified in the Definition of Topics (DoT).