S710 - Define Implementation Strategy
DEFINITION
Following the evaluation of potential vendors and solutions, the overall recommended approach is agreed and documented including:- checklist of technical components, e.g. packages / custom programmed modules
- Scheduling issues, e.g. Priorities, phasing, sequencing, timing
SUMMARY
The recommended approach is presented in the form of a Brief Implementation Paper (BIP) known as the Implementation Strategy BIP.
The requirements will have been established and various options will have been examined in detail during the Selection segment. These are discussed with the client. The costs, benefits and risks attached to each of these should considered if appropriate.
The agreed overall approach is stated. Details are given sufficient to identify how the requirements will be met. This may include:
- Checklist of technical components, e.g. packages / custom programmed modules
- Scheduling issues, e.g. Priorities, phasing, sequencing, timing
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. The recommended strategy will normally use a Software Application Implementation Process approach to delivery, eg IDDI, Brief Delivery or Implement Only as appropriate. It 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.
The Implementation Strategy BIP should be formally agreed and accepted by the client organisation.
PATH PLANNING GUIDANCE
This process is normal practice in Short Form selection.
It may be inappropriate 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 require significant discussion and publication, an alternative approach is available as described in the process - S700. In S700, a full Delivery Approach Definition (DAD) may be produced in the form of an Implementation Paper. The full DAD would act as a conceptual design document as well as an Implementation Strategy.
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
DELIVERABLES
- Implementation Strategy BIP
TOOLS
- Skeleton Deliverable: Implementation Strategy BIP
- path planning tools and materials for Delivery Segment
- Examples: “Application Blueprint”
- Examples: “Technology Blueprint”
- Guidelines: “Implementation Strategy”
- Guidelines: “Modelling Techniques”
- Benefit Realisation Core Guide
DETAILED DESCRIPTION OF TASKS
Scope/control
Update / create Definition of IPs/Topics [DoT] and IP Control Log [IPCON] to show the scope, objectives and status of the Implementation Strategy paper.
Options
Discuss with the client the 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).
Consider the overall implications for each 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
Agreed Approach
Agree and document the client’s preferred approach. It may be necessary to help the client to present and agree the findings to other senior managers. The summary of the approach should include basic information about the impact of the system, such as costs and benefits. It may be appropriate to prepare these in the format of a “Benefit Model” covering both tangible and intangible costs and benefits for use in the future measurement of the project’s benefits in comparison to the initial expectations.
Implementation Details
Determine the detail of the agreed solution. This may include:
- Checklist of technical components, e.g. packages / custom programmed modules
- Scheduling issues, e.g. Priorities, phasing, sequencing, timing
It may be helpful to document the overall architecture 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.
The recommended strategy will normally use a Software Application Implementation Process approach to Delivery such as Integrated Design Development and Implementation (IDDI) or Brief Delivery. It 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 of Software Application Implementation Process. 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 might be used to form the basis of the specifications for further delivery work, and might, therefore, become significant in contractual negotiations.
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.
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 Implementation Strategy document produced by this process 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 any other key decision makers within the client organisation. It may also be appropriate to present the plans to a wider audience of those key client organisation managers who will be involved in the delivery work.
No comments:
Post a Comment