Project Selection Process S700

S700 - Implementation Strategy and Architecture

DEFINITION

Following the detailed investigation of requirements and the evaluation of potential vendors, package modules and business solutions, the overall recommended approach is determined and agreed including:

• Business Processes
• Organisation
• Technical components, e.g. package module, custom programmed modules, technical architecture etc
• Scheduling issues, e.g. Priorities, phasing, sequencing, timing

SUMMARY

This process provides the main conceptual design document for the overall business solution.  The recommended architectural approach and implementation strategy are presented in the form of an Implementation Paper (IP) known as the Delivery Approach Definition (DAD).  Alternatively, in small projects, the DAD may be produced in the form of a Brief Implementation Paper (BIP) covering only the Implementation Strategy - as described in Process S710.

The requirements will have been established in detail.  These are now re-stated as a high level summary, cross referring to the original documentation for the detail.  This summary is used to express the scope of the recommended system and to ensure that this is understood and agreed.

Various options will have been examined in detail during the Selection segment.  These are listed and the key findings relating to each option are stated.   The costs, benefits and risks attached to each of these should be summarised if they played a significant part in the decision making process.

The recommended overall approach is then stated.  This conclusion should be justified to explain why it is the recommended approach.  The justification should include a re‑examination of the costs, benefits and risks involved in the recommended approach.  These may need to be compared with the equivalent  facts for the rejected solutions.

The recommended approach will frequently involve more than one component.  The overall discussion of requirements, options and recommendations can be broken down into these separate areas if appropriate, but the final conclusion should address the best overall solution including all components.

The full business solution is then detailed.  This will include:

• Business Processes
• Organisation
• Technical components, e.g. package module, custom programmed modules, technical architecture etc
• Scheduling issues, e.g. Priorities, phasing, sequencing, timing

A large scale implementation gives several options in sequencing the project, e.g. a more system or module-oriented approach vs. a more function or process-oriented approach.  A high-level implementation strategy should be stated, showing the phasing of the major work components.  Management-level plans will be required showing tasks and initial estimates for resourcing.  (Note that these figures and timings are required for the Cost/Benefit analysis described above.)

The recommended strategy will normally use the an Integrated Design Development and Implementation (IDDI) approach.  This may be in the form of the IDDI Path Template, or the techniques may be applied from one of the alternative paths, eg Brief Delivery.  Where an integrated package, such as SAP, Oracle, MS Dynamics, is being implemented using a “Project Model” approach, the IDDI stage of the project  would be conducted using “Design, Prototype and Construction” followed by “Readiness and Rollout”.

The delivery work segment will include preparation of technical environment, technical installation, design tasks, development tasks, testing, training, organisational change management, conversion of data, cutover, systems management/responsibilities etc.  These are described in detail in the Delivery Segment.

All aspects of the Delivery Approach Definition (DAD) should be reviewed and agreed with the client organisation’s senior management/sponsor.  It should be formally agreed and accepted by the client organisation.

PATH PLANNING GUIDANCE

This process is normal practice in full selection exercises.

It may not be appropriate in very simple cases, for example, where only a single component has to be selected to provide the full business solution and where another document adequately covers the decisions made during the evaluation.  Where the issues and consequent business cases do not require discussion and publication, the deliverable can be in the form of a brief implementation paper (BIP) covering only the implementation strategy as described in the alternative process - S710.

DEPENDENCIES

Prerequisites (Finish-Start):

• Completion of Requirements Segment (or alternative basis for the definition of requirements, e.g. client’s own document)

Prerequisites (Finish-Finish):

• Completion of other appropriate selection tasks (or alternative basis for the definition of technical components, e.g. pre-determined by client)

Dependent procedures (Finish-Start):

• Quality Audit (QA) (Q100-Q180)  for Selection Segment.
• Planning and conducting Delivery Segment

RECEIVABLES

• Selection Reports (SR) as appropriate
• Definition of Requirements (DoR) (including business needs, constraints, business process design, system vision, detailed requirements etc)
• Project Constitution (L010)

DELIVERABLES

• Delivery Approach Definition (DAD)

TOOLS

• path planning tools and materials for Delivery Segment
• Examples: “Application Blueprint”
• Examples: “Technology Blueprint”
• Guidelines: “Implementation Strategy”
• Guidelines:  “Modelling Techniques”
• Methodology: “Why SIIPS”
• Benefit Realisation Core Guide - Benefit Model etc

DETAILED DESCRIPTION OF TASKS

Scope/control

State the scope of the DAD paper.  This may include details of:

• which parts of the business will be supported,
• which organisational units,
• which business process areas,
• any pre‑defined elements of the technical solution, eg chosen package solution (including all the selected modules and other software components), technical architecture, etc, and
• all surrounding systems (like feeders, complementing systems, migration programs etc.)

This will normally be the same as the originally agreed scope of the project.  If not, the differences should be highlighted and agreed.

Update / create Definition of IPs/Topics (DoT) and IP Control Log (IPCON) to show the scope, objectives and status of the DAD paper.

Requirements

Extract a summary of business requirements from the detailed requirements documentation (re‑using existing material wherever possible).  The purpose of this is to ensure that all reviewers share a common understanding of the scope and requirements.  The level of summary should ensure that the key facts are presented, particularly where they have played a major part in the subsequent evaluation.  Detailed requirements should not be included unless essential to the eventual decision - cross refer the reader to the detailed requirements documentation.

Options

List the business, organisational and technical options which could provide solutions to the overall business requirements.  Technical options will normally have been the subject of a specific selection exercise.  The detailed evaluation of these may be contained in Selection Reports (SR).  The SR should be referred to wherever possible - only the summary and any key details need to be reproduced in the DAD.

In complex implementations involving multiple sites, options will also involve sequencing and approach to the rollout.  Options for rollout across many sites include the following:

• global system for global roll-out
• global package module oriented, functional kernel developed centrally with local site adaptations
• global business division kernel (like the sales & marketing) developed centrally with local site adaptations
• lead site develops a pilot system with subsequent global standardisation and following local adaptations
• purely local and unique systems.

Consider the overall implications for each business, organisational and technical option.  For example, significant factors might include:

• fit with business and technical requirements
• risk
• cost
• net benefits
• timescales
• ability to provide required resources
• quality of final solution
• flexibility
• ease of future support and development.

Recommended Approach

Based on the detailed evaluation of the business options, determine the recommended approach in terms both of technical components and of revised business processes or organisation.  This should be informally discussed and agreed with key members of senior management before being published.

Prepare a justification for this recommendation.  This should normally include a reappraisal of the risks, costs and benefits.  To re‑appraise the costs and timescales needed in a discounted cash flow calculation, it will be necessary to prepare a high‑level plan for the Delivery Segment - see below.  Both tangible and intangible costs and benefits should be considered.  It is useful to prepare these in the form of a Benefit Model against which future progress, deviations, design decisions and changes can be assessed. It may be necessary to compare the net costs and benefits with “losing” options.

Detailed Approach

Determine the detail of the recommended full business solution.  This may include:

• Business Processes
• which processes will be supported,
• how might they be organised, and
• what are the performance targets,
• Organisation
• which business units will be involved in the implementation,
• who will be responsible for the project and its different activities,
• who will be responsible for the running system,
• Technical components
• which package modules will be used / which modules will be custom programmed,
• how will the technical architecture be organised (eg 1 / 2 / 3-layer Client /Server architecture, server and network layout, operating system and database decisions, utilities)
• Scheduling issues
• what are the priorities,
• will it be one project or a multi-project program (maybe including multi-site and multi-module co‑ordination),
• sequencing of module and/or process implementation,
• phasing of activities,
• timing and major milestones to be reached.

The overall architecture will be documented using the analysis and design techniques that have been agreed with the client organisation for the overall project.  If no specific method has been adopted it may be appropriate to include some high level diagrams.  The configuration of the system can be shown using:

• “Application Blueprints” - ie simple high‑level diagrams showing the different software components and how they relate to each other, and
• “Technology Blueprints” - ie simple diagrams showing the technical configuration of the overall system including networks, servers and workstations
• “Process mappings” showing the major steps of the processes and package modules that support each step.

The recommended strategy will normally use an Integrated Design Development and Implementation (IDDI) approach.  This may be in the form of the IDDI Path Template, or the techniques may be applied from one of the alternative paths, eg Brief Delivery.  Where an integrated package, such as SAP, is being implemented using a “Project Model” approach, the IDDI stage of the project  would be conducted using “Design, Prototype and Construction” followed by “Readiness and Rollout”.

The delivery work segment will include preparation of technical environment, technical installation, design tasks, development tasks, testing, training, organisational change management, conversion of data, cutover, systems management/responsibilities etc. Some guidelines on “Implementation Strategy” are available in the tools.  Some materials supporting the use of IDDI can be found in the “Methodology” section.

Sufficient detail must be given so that the Delivery Segment can be scoped and planned without further research.  In addition to the technical details of the solution, this may include outline strategies for:

• organisational change,
• training and education,
• testing,
• data cleansing,
• data conversion and
• cutover.

(Note that the initial investigation of these topics is a good use of any spare time while awaiting the vendors’ responses during the selection process.)

Particular attention should be paid to integration issues and cutover considerations to ensure that the overall implementation strategy is viable.  This level of detail will often be used to form the specification for further delivery work, and may, therefore, become significant in contractual negotiations.

Integration issues within the conceptual design of the package components are vital to consider up front, before installation procedures for separate modules are started.  Consideration must also be given to planned future implementations as well as the current project.  If module usage and the organisational model in the system are not defined properly, different parts of the system might not be compatible when later customising the separate modules.

A high‑level evaluation should be made to establish the constraints on resources and timescales, for example:

• the availability of key staff and the amount of other staff resources available,
• the time required to deliver equipment, or
• the availability of training courses for project participants.

It will normally be necessary to agree tentatively which resources would be available for which tasks.  (Note that these figures and timings are also required for the Cost/Benefit analysis described above.)

Based on these considerations, a high‑level implementation strategy should be stated, showing the phasing of the major work components.  Management‑level plans will be required showing tasks and initial estimates for resourcing.

Review and signoff

The Delivery Architecture Definition document produced by this process is the main report from the requirements and selection process.  It acts as a conceptual design document for the overall business solution and also defines the high‑level management plan for the delivery segment.

As such, it is a key document which should be discussed and agreed with the project’s sponsor and other key decision makers within the client organisation.  It may also be appropriate to present the overall findings, recommendations and plans to a wider audience of the key client organisation managers who will be involved in the delivery work.

Delivery Approach Definition

Typical contents of the DAD might be:

1. Sign-off Control
2. Scope of this document      
3. Management Summary         
4. Requirements  
1. Business process requirements        
2. Organisational requirements     
3. Technical requirements       
4. Priorities and scheduling     
5. Options       
6. Recommended approach      
1. Components      
2. Costs and benefits    
7. Detailed approach   
1. Business Processes    
2. Organisation      
3. Technical components           
4. Priorities and scheduling
5. Implementation strategy and management plan
1. approach to customisation
2. approach to integration
3. approach to training
4. approach to testing
5. approach to rollout
6. approach to systems handover
7. approach to post-implementation management
8. proposed skeleton Path Plan for delivery  
6. Acquisition of resources / contractual issues
8. Issues