Selection and implementation of packaged software - Introduction

Introduction

The next few blogs will be focused on the selection and implementation of integrated packaged software.  It is designed to provide a best practice approach to the definition and generation of business solutions which are primarily constructed using standard, configurable software components - referred to as “packages”. 

We will use many special techniques which are only appropriate in a package-focused solution. The techniques will allow the project to be conducted more effectively and efficiently; and hopefully, they also lead to a better overall business solution.

However, neither this approach nor any other approach can provide a good package-based solution if packages are not the right answer for the business needs of the customer organisation.  It is important, therefore, that the organisation evaluates the business imperatives before defining and instigating an integrated packaged software solution project. 

During the next few articles I will address the full life-cycle of a business system from conception through to the appraisal and/or replacement of old systems.  It deals with the life-cycle in terms of the following segments:

• Project Launch - definition of the scope, objectives, terms of reference for the project then setting up the appropriate team and infrastructure,
• Requirements - definition of business needs, requirements and priorities, plus an initial “vision” of how they may be addressed,
• Selection - evaluation of options, normally using a formal tendering process, and the definition of the preferred overall business solution,
• Delivery - the achievement of the desired business solution in terms of the successful integration of people, skills, organisation, processes, technology, and systems; this may involve such activities as design, development, documentation, testing, training, conversion of data etc,
• Post-implementation management - the management, control and support of the operational systems at strategic, tactical and routine levels,
• Post-implementation review - the evaluation of a new system after it has had time to settle down to establish how successful its introduction has been and what further actions might be taken to realise maximum benefit,
• Business Benefit Assessment - A review of an old system to identify the extent to which it is providing benefit to the organisation and what actions might be taken to ensure the best overall business solution is provided for the organisation; typically such a review would recommend improved business practices, upgrades, re-implementation or replacement, and thus the assessment may become the start of a new life-cycle.

A Structured Implementation Approach

Each process will be defined and documented separately.  This allows them to be revised, regrouped or supplemented as desired.  The different ways in which individual processes are combined for a specific purpose is called a “Path”.  Path Templates are documented to provide guides to sample approaches.  Typically these might show the most complete approach, the minimum possible approach and the validation of work already performed by other people not following this approach.

Processes

Each group of related activities or tasks is detailed as a “Process”. Processes may be mandatory, normal or optional.  In some cases, alternative processes can be defined for the same part of a project where there are differing needs and market conditions to address.  There are alternative processes depending on the circumstances of the client or of the scope or requirement.  In this way the apprach has been left open so that many different valid paths can be defined through the processes.

Where a new need is identified, new or revised processes can be added into this framework without disturbing the overall design.  This allows the approach to be made extensible simply and rapidly to meet all needs in the ever-changing marketplace.

For each process there is an explanation of its purpose and content coupled to an example sub-plan for the process.  This is known as a Process Plan. This approach also provides the means to develop a project plan aligned to the process paths

Paths

The combination of optional processes and alternative processes that is chosen and agreed for any segment of work is defined as a Path.  A number of standard paths have been identified.  These are described as Path Templates, ie a list of all processes normally conducted within a segment when a given approach is called for.

Path Templates do not define all possible paths.  On the contrary, Path Templates only define example paths.  The approach permits any path to be selected, provided that it leads to a valid combination of processes and meets the custome organisation’s needs.

The combination of processes for any given project is defined in the project’s Path Plan.  This is agreed before or during the project launch.