Project Delivery Process D450

D450 - Design / Prototype - Brief Implementation Papers

DEFINITION

Design or define each topic within the project, using prototyping techniques wherever appropriate,  documenting the recommended approach and details in a Brief Implementation Paper (BIP) per topic.

SUMMARY

A key feature of the Software Application Implementation Project  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.

Brief Implementation Papers (BIP) are used to document the design decisions.  These will cover functional, technical and environmental design issues.  The Brief Implementation Paper is  intended for use in simple cases where it is unnecessary to publish the requirements, options, issues and recommendations to a wide body of reviewers for consideration.  It is the main type of document used in a Brief Delivery approach where a rapid cost-effective delivery is required.  Where broader discussion and detail is required, the full Implementation Paper format should be used (see Process D400).

Brief Implementation Papers should be drafted, reviewed, agreed and signed off in accordance with the IP Control Log (IPCON) - see Process D200 (or D100 if a “full” approach was used).

PATH PLANNING GUIDANCE

Normal practice for Brief Delivery.  A number of individual topics will be defined and agreed in the IP Control Log (IPCON).  In the segment plan these would normally be given numbers in the range D4xx.

DEPENDENCIES

Prerequisites (Finish-Start):

• Define topics in IP Control Log (see Process D200/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

RECEIVABLES

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

DELIVERABLES

• Brief Implementation Papers (BIP) as defined by the IP Control Log (IPCON)
• Prototypes of various components, eg screens, reports, processes, tables
• Updated segment plan (if required)

TOOLS

• Skeleton Deliverables: Brief Implementation Paper (BIP)
• Guidelines: Functional Design
• Guidelines: Modeling Techniques
• Guidelines: Various guidelines are available for specific topics - see the “IP Guidelines” Library
• Application Software reference model
• List of Application Software functionality.
• Some common Implementation Papers or Brief 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 - D730
• System Handover plan - D830
• System Support and Administration - BIP in D860 (or IP in D850)
• •Transition to Live Service - D870

DETAILED DESCRIPTION OF TASKS

The basic content of this process is the detailed design of the package-based solution.  In some cases, the design work may be entirely based upon the team members’ knowledge and experience plus the vendor’s systems documentation.  In other cases further investigation and review may be required.  Prototyping and BPR/BPI techniques may be used.  The resulting design decisions are agreed and recorded using a Brief Implementation Paper (BIP).

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.

Prototyping is often used to confirm requirements and to validate options.  It may then be used to select and demonstrate a preferred approach.  Finally, the development and implementation details may be documented by copying them directly from the design prototype into the detailed instructions section of the Brief Implementation Paper.

The prototype may be built in two steps.  First an initial model, if possible based on preconfigured standard solutions, like the Consultant's sample industry models or the Software Application reference model, will be used as a starting point.  The initial model will be refined in subsequent process modelling workshops to adapt the package to user specific needs.

Development of the system can be carried out as an extension to this 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 Brief Implementation Papers.  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 Redesign / Improvement (BPR / BPI) 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, for example, as may be defined in the Project Constitution (PCON) and Delivery Approach Definition (DAD).

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 D240 or D140 if a “full” approach was taken).

Brief Implementation Papers

The Brief Implementation Paper (BIP) is used to document the agreed design resulting from the design prototyping process per topic.  A separate paper is produced for each topic, as defined in the IP Control Log (IPCON).

The objectives of the Brief Implementation Paper are:

• to indicate the preferred solution,
• 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).

In a Brief Delivery, it is assumed and required that the design decisions should be reviewed and signed off by a small empowered group of management.  Accordingly, informal techniques should be used to examine and agree the requirements, options, issues, recommendations and detailed implementation instructions.  When these have been agreed, the resulting recommendations should be documented in the simplest possible form.  The underlying requirements, rejected options and justifications are not normally included in Brief Implementation Papers.

Topics should be defined such that they are of a manageable size.  Clearly the underlying issues will vary in size and complexity and the Brief 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.

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 BIP.  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 D200.
Summary of agreed approach	This section describes the agreed approach.  Normally the logic for this will have been discussed and agreed with the responsible user and other key management and team members before documenting the full details of the preferred solution as described in the following section. The summary may contain an overview of the business processes the approach will support, the package modules and components that will be used as well as a brief description of the technical platform to be used.  Areas which are not covered by the standard package, but require additional development or complementing systems should be described. A timeplan showing major activities to implement the package and needed human resources will show up the required effort for the implementation. This part could be initially developed based on the initial model (see process D364) rather than the detailed prototyping and design.
Implementation Details	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.  It may be possible to omit this detail if it is recorded in another format, for example, in the parameter table of the package. For the selected modules in the package the following package components may be described: Design of the organisational structure (clients, companies, etc.) Used package functions: Online functions Periodic functions (like production planning runs or months-end processing) Procedures  used (like the layout of availability checks or plausibility controls) Handling of master data Handling of transaction data Major customisations design 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 may 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.

The level of detail may be lower in topics covered in the initial model where they are based on preconfigured standard solutions or where they are to be expanded upon in subsequent process workshops.  For the initial model, a brief review of the prototyped business processes, the used modules and components and a rough outline of timeplan and responsibilities can be given, whereas the results of the process modelling workshops will describe the chosen solution including online and periodic functions, used procedures, master and transaction data, and customising design.

Authorship and Review

Responsibilities for the authorship and review of each Brief Implementation Paper should have been defined in the IP Control Log (IPCON).

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 (see Process L080).  At least one other team member should read the paper, raise queries and suggest amendments before it is issued.  The reviewers 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 Brief 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 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.

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 Brief Implementation Papers should be agreed by client users and should normally be formally signed off according to the responsibilities defined in the IP Control Log (IPCON).  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.  Accordingly the, Application Software Implementation Procedure  permits more than one stage of review and sign off.

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

At specific times BIPs or groups of BIPs 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 / BIP issues.

Types of topic / Brief Implementation paper

Topics and the brief 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 D200 (or D100 if a “full” approach was used).

The following table only gives some example lists of topics for a range of applications.  It is increasingly useful to break topics down by areas of business processes rather than areas of package functionality.  Each project should consider carefully what the best breakdown would be.

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

Organisational structure

Package tuning

Prototyping standards

Report distribution

Report standards

Security

Screen design/standards

Supplier 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 supplier details with AP and purchasing

Goods inspection

Goods inwards/reception

Materials on loan

Materials returned

Material scrapping/disposal

Multiple Stores

New materials issue/return

Stocktaking

Stores location coding

Supplier 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

Coding

Controls

Financial reporting

Foreign currency

Joint venture accounting

Management reporting

Modeling/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
• Stores

Accounts Payable (Functional papers)

Accounting issues

Contractors payments

Foreign currency

Invoice processing

Invoice matching

Joint venture billing

Payment processing

Supplier coding

Technical papers - feeders:

• GL interface
• Purchasing
• Stores

Accounts Receivable (Functional papers)

Accounting issues

Credit management

Controls

Customer coding

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 coding

Purchase order

Purchase request

Supplier coding

Tendering control

Technical papers - feeders:

• Accounts Payable
• Production scheduling
• Stores interface

Maintenance (Functional papers)

Budgeting

Common coding standards with stores

Common/standardised spare parts

Equipment coding

Equipment tracking/history

Parts coding

Periodic servicing

Planning/scheduling

Tag numbers

Technical specification

Time/cost analysis

Time/cost recording

Works Orders

Technical papers - feeders:

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

Owners manual & Work Book

The finished Brief 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”.