Project Launch Process L020

Review / Confirm Business Needs and Anticipated Benefits

DEFINITION

An initial statement is prepared and agreed to show what business needs and benefits are expected.  This allows the project to keep a focus on achieving those benefits and provides an initial yardstick against which changes can be measured.

SUMMARY

The scope of the project must be based on a firm understanding of the needs which are to be addressed.  Prior to commencement of the project there must be some definition of the anticipated benefits which are sought and what level of costs, timescales and risks are assumed in justifying the work.  Although these considerations are examined in more detail during the project, it is important that there is a common initial understanding before any substantial work is performed.

This process ensures that there is an appropriate definition of the business needs and anticipated benefits.  It will be used throughout the project as a guide to direction and as a measure of success.  The model may be developed further and modified during the project to reflect better information, revised ideas or changes to the project

PATH PLANNING GUIDANCE

This process is optional.  It is not required where there is an existing, documented understanding of the basic business needs and anticipated benefits, which the client organisation has certified as correct.

DEPENDENCIES

Prerequisites (Finish-Finish):

• Review / confirm Terms of Reference (ToR), Scope, Objectives (L010)

Dependent procedures (Finish-Finish):

• Following segment processes

RECEIVABLES

• Project Constitution - Terms of Reference / Scope / Objectives etc
• Any existing Feasibility Study, Benefit Model or Cost/Benefit Analysis etc

DELIVERABLES

• Definition of business needs and anticipated benefits (BNAB)

TOOLS

• Benefit Realisation Core Guide

DETAILED DESCRIPTION OF TASKS

The initial definition of business needs and anticipated benefits should be identified and agreed.  They will be used to form a guide for the conduct of the entire project.  It is important that such things are clearly defined and generally understood before the project team sets about addressing those business needs and achieving the desired benefits.

The information may be drawn from a number of sources.  Existing documentation may be examined where appropriate, for example:

• deliverables from earlier work (if any)
• business case for the project
• feasibility study report
• IT Strategy
• correspondence relating to the business needs and anticipated benefits
• overview documentation relating to current systems
• request for proposal / proposal / contract relating to consultancy assistance or vendor contract (if any).

This should be supplemented by direct interviews or workshops with the project’s sponsor and any other key managers within the client organisation.  These should attempt to identify:

•  why they are undertaking this project in this way at this time
• what are the true business needs
• what do they hope will be the result of the project, in terms of

          -     effects on the organisation and the way it functions
          -     changes to the business processes
          -     changes to the computer systems and infrastructure

• in what way do these changes lead to greater benefits for the organisation.

The benefits identified may be either of a tangible, quantifiable nature in financial terms or of an intangible, unquantifiable nature.  At this time all benefits should be identified and discussed regardless of their nature. 

It may be possible to construct a cost/benefit analysis to demonstrate that there is a financial business case for the project.  It should be clear, however, that this is based on initial assumptions and estimates. The results should be consolidated to form a definition of the business needs and a qualitative statement of the anticipated benefits.  This should be reviewed and agreed by the project’s sponsor to ensure that it is a fair and accurate statement of the organisation’s expectations of the project.

Benefit Model

The project can be guided and managed more effectively if focus is maintained on the anticipated benefits.  This can be achieved by building a benefit model.  A benefit model attempts to measure the anticipated or actual benefits regardless of whether they are financial in nature.  The concept is to assess all aspects of the project against the desired benefits in a balanced way.  Balance means that all forms of benefit are given appropriate weight.

The model will be used throughout the project as a guide to direction and a measure of success.  It may, however, be developed further and modified during the project to reflect better information, revised ideas or  changes to the project.

For each of the forms of benefit identified, a performance measurement metric should be proposed that would show trends and variances.  The calculation does not have to produce a financial result, nor even a mathematically meaningful figure.  It will be used during the project primarily as a test of whether benefit is being achieved above or below the expectation and whether changes produce increased benefit.

The metrics must be such that they can be measured or estimated without undue effort during the project.  The metrics are normally presented as a series of trend charts shown on a single page to give a simple but powerful control panel for the project’s success.

The model should be discussed and finalised with the project’s sponsor and any other key managers within the client organisation.  It is important that they accept that it correctly reflects the balance of benefits that the project is intended to achieve.

The Benefit Model can be documented and included in the Definition of Business Needs and Anticipated Benefits (BNAB).  The overall report should be reviewed and formally agreed by the project sponsor.

Project Launch Process L010

Review / Confirm Terms of Reference (TOR), Scope, Objectives

DEFINITION

The project requires a clear definition of its terms of reference (ToR), scope and objectives.  This is a mandate to operate within the Customer organisation.  It allows work to be correctly focused, and the outcome to be measured against the original goals.

SUMMARY

The project manager should review the project proposal and other relevant documentation to produce a preliminary statement of project ToR, scope and objectives.  He then needs to assemble a core management planning team whose first task will be to validate this document by conducting interviews and workshops with key personnel.  A formal Project Constitution should then be produced and agreed with the project sponsor.

PATH PLANNING GUIDANCE

This process is mandatory.

DEPENDENCIES

Prerequisites (Finish-Finish):

• (none)

Dependent procedures (Finish-Finish):

• Review / confirm business needs and anticipated benefits (L020)

Dependent procedures (Finish-Start):

• Select Path(s) (L030)
• Define and agree project management techniques (L040)

RECEIVABLES

• Project Proposal
• Other relevant documentation  (see “DETAILED DESCRIPTIONS OF TASKS” below), eg any existing Feasibility Study, Benefit Model or Cost/Benefit Analysis etc.

DELIVERABLES

• Project Constitution

TOOLS

• Project Management Methodology and Tools

DETAILED DESCRIPTION OF TASKS

Introduction

A clear definition of the project’s ToR, scope and objectives is needed at outset to:

• to reduce the risk of gradual "scope creep";
• establish the assumptions upon which the project will be planned and executed; and,
• define a foundation for developing the remainder of the management plan.

The document produced at the conclusion of this process (the Project Constitution) defines the mission to be accomplished by the project.  The mission may be refined in subsequent steps, at the discretion of the sponsor and steering committee as more information becomes available. 

It is essential that the ToR, scope and objectives are defined, documented and agreed.  To that extent this process is mandatory.  The precise techniques to be used and contents of the documentation may vary according to circumstances.  The remainder of this process describes a recommended but optional approach.

Review existing documentation

The project manager should review existing documentation to gain an understanding of the project background and history.  Relevant documentation may include, but is not limited to:

• project proposal;
• documentation produced during Project Initiation Phase
• project description and cost/benefit analysis;
• request for proposal (RFP); request for information (RFI); request for quote (RFQ) or equivalent documents;
• pre-proposal survey and interview notes;
• business plans;
• corporate information technology plan;
• organisation charts; and,
• existing functional and/or system documentation.

The strategic objectives of the project should be described in one of the documents.  If these objectives are not defined, the sponsor and project manager should identify specific users to research and document the project's strategic objectives.

During the review process, the project manager should identify and evaluate:

• implied commitments and concessions that have not been formalised or clearly documented;
• constraints;
• unclear and/or undocumented anticipated benefits of the project;
• initial cost, resource or schedule estimates that appear to be unsubstantiated or potentially unrealistic; and,
•  “overkill” - the possibility that the anticipated benefits could be achieved through simpler measures which may cost significantly less than current projections.

The project manager should prepare a preliminary document summarising the key information from the documentation reviewed.  The summary should include:

• the project’s objectives and scope;
• initial cost/benefit analysis;
• a list of topics requiring further information;
• missing information or documentation;
• constraints; and,
• risks.    

Assemble a management planning team

The sponsor and project manager should identify a core management planning team, whose first deliverable will be the Project Constitution, but who will then assist with subsequent management planning tasks.  Team members should be knowledgeable about the subject matter and generally include:

•  the project manager;
• key functional personnel
• key technical personnel
• Specialists in the Application Modules

The core team is generally a small number of people, but the scope of the project will dictate the team size.  Additional resources may be called upon to provide input as needed.  For a large project, developing the management plan may take considerable time and commitment.  Resources assigned to the core team may need to be relieved of their daily responsibilities to ensure the commitment is met. 

The project manager should share background information and documentation with the team and should obtain their input on the preliminary document described in the preceding step.

Conduct interviews and workshops

The core team should review the preliminary document produced by the project manager and then determine the best method of verifying its content, and obtaining additional or missing information.  The objective of verification, and gathering additional or missing information is to refine or define in further detail:

• the objectives and scope of the project, what the project includes and what is excluded;
• assumptions to be used in the development of the management plan;
• needs of the organisation as they relate to the project;
• constraints such as time, cost or implementation schedule;
• risks associated with the project and the degree of severity;
• criticality of the project in relation to corporate objectives;
• commitment from senior management to support the project actively;
• management’s expectations and tolerance levels pertaining to costs and schedules;
• a description of the major deliverables and measurable success criteria;
• an assessment of the organisation’s readiness to undertake the project;
• geographic location requirements or constraints for the project team; and,
• potential staffing, logistical or communication constraints.

Individuals who are best suited to provide input should be identified, such as:

• potential project sponsors;
• company directors and key functional managers;
• information technology management;
• end users;
• members of the committee or group who requested the project;
• members of the committee or group who authorised the project.

Appropriate methods for gathering the information depend on the individuals involved.  The core team should be aware that opposing views may be presented and discussed.  Individual interviews may result in the core team having to reconcile differences through subsequent meetings.  For this reason, facilitated workshops are often the easiest and fastest method to gather necessary information.

A considerable amount of information can be gathered in the interview and workshop process. Not all of the information will relate to the project’s ToR, scope and objectives but the core team should document the information for use in subsequent steps.

Produce Project Constitution and obtain approval from sponsor

The core team should prepare a formal document - the Project Constitution - defining the project’s scope, terms of reference and objectives.  The project boundaries defined here become the litmus test for what is and what is not part of the project.  These boundaries are the foundation of the management plan document and become the basis for the subsequent steps. 

The boundaries may change as the project is defined in more detail - for example, they may shift as the requirements are further defined and broken down.  Once the detailed requirements have been approved, however, the boundaries should become firm.

The core team should discuss the document with the sponsor and obtain approval.  No further management planning should take place until approval from the sponsor has been obtained.

Project Delivery Process 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 an approach to delivery (eg IDDI, Brief Delivery or Implement Only) or a package-specific approach 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.

The Implementation Strategy BIP should be formally agreed and accepted by the customer 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: "provided by Supplier of Consultant"
• 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 and IP Control Log 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 an approach to delivery (e.g. IDDI, Brief Delivery or Implement Only) or a package-specific approach 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, cut-over, systems management/responsibilities etc.

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
• cut-over.

Particular attention should be paid to integration issues and cut-over 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 sign-off

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.

Path Template: Delivery - Implement Only

This path is a subset of the normal Delivery processes.  It does not include design or development tasks as it is targeted at a system that is pre-defined and non-configurable.  However, the same (or greater) care must be taken with environmental, human and organisational issues, as there is less likelihood that an organisation’s overall needs will be fully addressed by a fixed configuration solution.

Ref		Process	Optionality	Definition
D110	Review technical environment and plan installation		Optional - usually required when insufficient detail was included in the Delivery Approach documentation and segment plan	Plan in detail the physical installation of the packaged software, additional systems software, hardware, communications equipment, servers, PCs etc. Note that increasingly this task is performed by the vendor.
D120	Plan, prepare and conduct project team training		Optional - usually required unless whole team have requisite experience in all aspects of the solution.	Normally, team members need training before productive work can commence.  Training may also be appropriate for management and other staff working with the project team.
D130	Install hardware, communications equipment, system software, and applications software as required for development, implementation and live running.		Optional - required when insufficient provision is already available for the project.	Install and commission items required for design, development, implementation and live running.  This includes system environment requirements, eg log ons, access security, accounts, budgets etc.  With medium systems this is often performed by the vendor.
D180	Data Conversion Strategy		Optional - used where existing data will be brought into the new system	A study should be made into the needs for data conversion.  Data availability and integrity is often wrongly assumed during design work.    Recommendations will be made for securing data as required.
D300	Prepare discussion papers		Optional - discussion papers may have been identified in the segment plan or may be used to explore any particular issue that arises as the team see fit.	These are short papers covering a particular subject.  They are not formally controlled, reviewed or signed off.  Their purpose is to assist in the process of deciding an issue during the design work.
D450	Design/Prototype - Brief Implementation Papers		Normal practice	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.
D190	Issues - control, escalate, resolve		Optional - used where there are several people involved in the project	Issues that arise during the design work are noted, logged, controlled and resolved.  Escalation and tie-breaking mechanisms are used where necessary.
D720	Prepare and instigate operators’ instructions, procedures and manual		Optional - depending on suitability of vendor’s standard materials available	Prepare detailed instructions for the  technical operation of the system, including routine and abnormal running, eg security, disaster recovery.  This will normally include operational-standard JCL and the definition of human/machine interactions.
D730	Identify human and organisational issues		Optional - used where there are several users affected by the project.	Assessment of the required organisational change, and resistance to such a change.
D740	Implement change management programme		Optional - used where organisational change is necessary	Prepare and agree a plan for achieving the human and organisational change through communications, publicity, cascade sponsorship, policies, education etc. Instigate and act upon the plan.
D750	Prepare and instigate User Procedures and User Manual / electronic information		Normal practice	Human procedures should be defined and agreed as part of the functional design work. Manuals or electronic documentation of the procedures and how to use the system should be extracted from the implementation papers and expanded/supplemented as necessary.
D760	Plan, prepare and conduct user and management training and education		Optional - used where user and/or management training is required	Full user training is vital both to the successful use of the system and also to its acceptance and successful take up.  An effective programme should be developed based on the identified training needs of all users and management.
D770	Plan, prepare and conduct operations training		Optional - used where operations staff require training	Computer Operations staff must be trained in running the application.  They must be familiar with the normal interactions that are required and what abnormal conditions they might be expected to handle.
D800	Plan, prepare and conduct User / System / Acceptance and Integration testing		Mandatory	Formal testing must be performed to ensure that all significant aspects of the system are acceptable.  Careful planning and preparation is required to ensure it is complete and comprehensive.  Results must be reviewed and signed off by responsible users.
D810	Plan, prepare and conduct technical tuning and volume testing		Normal practice	The system will need technical tuning to ensure acceptable performance.  Volume testing ensures that full volumes of data and transactions can be accommodated.  Testing should prove that normal loads can be sustained and peak loads can be accommodated.
D830	Define, plan and agree handover / cutover		Normal practice	An analysis should be made of the logistical requirements for changing over to the new systems.  Detailed timings must be considered and agreed.
D850	Define and agree terms of reference for live user support activity		Optional - used where post live support will be required	Analyse and agree the requirement and constitution of functional and technical user support for the live system, eg systems control, help desk, scheduling etc.
D880	Load start up data		Normal practice	All initial data should be loaded.  Includes running of conversion suites and manual data entry.
D890	Validate start up data		Normal practice	Complete loaded data should be validated and signed off by the responsible user managers.
D900	Decision to go live		Mandatory	The ultimate governing body or manager for the project should take the definitive decision to go live.  It must be certain that all vital pre-conditions have been satisfied to at least a minimum level, eg testing, data validation, training, organisation.