Project Delivery Process D010

D010 - Preliminary Assessment

DEFINITION

An initial fact-finding study to establish in detail the scope of the project, work required, resource requirements, resource availability, timescale requirements, priorities etc.

SUMMARY

This process is typically used when a project is commencing with the delivery work segment (design/development/implementation) with no solid existing basis for the implementation strategy.  It provides an alternative to the implementation strategy which would normally have been completed already as part of Process S700 or S710.  The relevant facts, information, needs and issues are assessed.  The recommended approach is normally presented in the form of a Brief Implementation Paper (BIP) known as the Implementation Strategy.

The agreed overall approach is stated.  Details are given sufficient to identify how the identified needs will be met.  This may include:

• Checklist of technical components, e.g. package modules / 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.

The recommended strategy will normally use a Software Application Implementation Delivery Process approach to delivery (eg IDDI, Brief Delivery or Implement Only) or a package-specific approach (eg Design/Prototype/Construct) 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 processes of Software Application Implementation Project Processes.

The Implementation Strategy BIP should be formally agreed and accepted by the client organisation.  It will then form the basis for the subsequent detailed planning of the project work, organisation and approach.

PATH PLANNING GUIDANCE

This process is optional.  It is used where insufficient information is available to define the overall approach and to plan the project at a detailed level.

DEPENDENCIES

Prerequisites (Finish-Finish):

• Project Constitution, including scope, objectives, terms of reference, mandate etc (L010)
• Business needs and anticipated benefits (L020)

Dependent procedures (Finish-Finish):

• Detailed segment plan for Delivery (L120)
• Project team structure (L130)

RECEIVABLES

• Project Constitution, including scope, objectives, terms of reference (or equivalent information)
• Business needs and anticipated benefits (or equivalent information)
• Any other information relating to the work of the project or the proposed solution

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”
• Methodology: Software Application Implementation Project Processes
• Benefit Realisation Core Guide

DETAILED DESCRIPTION OF TASKS

Fact finding

The following types of fact finding tasks will typically be required for the preliminary assessment:

• Review and agree scope, objectives  and terms of reference
• Obtain and examine documentation regarding chosen technical solution
• Review / establish business needs and anticipated benefits
• Review / establish technical, organisational, political, financial and time constraints
• Review / establish detailed requirements and priorities
• Demonstration / prototyping of chosen technical solution
• Overview and detailed training for components of the chosen technical solution
• Installation of package-based components for use in prototyping the needs and solutions
• Review security requirements
• Identify improved business processes and work practices
• Formulate System Vision - ie overall view of how the business needs will be met (techniques can be drawn from Process R070 if required)
• Assess organisational impact of changes
• Define approach to end-user training
• Identify network requirements and plan
• Identify location of equipment and environmental needs
• Establish conversion & cutover requirements
• Establish interface and integration requirements
• Review / define approach to testing
• Estimate system workload / capacity requirements
• Review hardware & communications installation schedule
• Establish staff resources available and skill levels
• Confirm overall approach and path plan

Scope/control of implementation paper

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 within the pre-defined solution.  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. package modules / 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 Project Process approach to delivery (eg IDDI, Brief Delivery or Implement Only) or a package-specific approach (eg Software Application Implementation Project Process Design/Prototype/Construct) as appropriate.  It will include preparation of technical environment, technical installation, design tasks, development tasks, testing, training, organisational change management, interfacing/integration needs, conversion of data, cutover, systems management/responsibilities etc. These are described in detail in the delivery segment processes of Software Application Implementation Project 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 work 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.

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.