Project Launch Process L030

Blog: Biz-Performance, David Brown

Select Path

DEFINITION

The paths and processes most appropriate for this project are identified and agreed to provide a skeleton high-level management “Path Plan”.

SUMMARY

The Implementation Approach has been designed and constructed as a highly flexible methodology which can provide a best practice approach for any package-focused business solution. This flexibility means that there is a large number of options available. At the beginning of the project the overall high-level approach must be initially decided ( it may subsequently be revised between segments if necessary – see the “Review Path Plan” Path Templates – Processes L310 and L320).

Selecting the best Path may often be carried out prior to the actual start of the project, particularly where sub-contractors have produced proposals and agreed terms of contract. Where it has not already been agreed, the Path should be established early in the Project Launch segment, based primarily on the needs and constraints of the client organisation.

The most suitable approach is chosen, based upon a number of factors, for example:

he scope and size of the business processes and business area involved,
the complexity of organisational factors,
the flexibility and complexity of the probable systems solution,
the scope and extent of systems integration required,
legal and commercial requirements of the client organisation,
the type of industry,
the type of application,
the environmental culture,
the importance of the systems to the organisation’s business,
resource availability and constraints,
skills and experience of internal and external staff available, particularly in respect of experience with package-based solutions in the area concerned,
financial constraints and budget,
time constraints and budget,
cost vs benefit issues,
risks involved.

The output from this process is an agreed high-level view of how the project will be conducted, expressed in terms of processes to be performed along with comments regarding any options within the processes. This may also include a broad view about resourcing and timescales, although these will not be firm estimates at this stage. The full Path Plan is developed subsequently in a later Process L090.

PATH PLANNING GUIDANCE

This process is mandatory.

DEPENDENCIES

Prerequisites (Finish-Finish):

Review / confirm ToR, Scope, Objectives (L010)
Review / confirm business needs and anticipated benefits (L020)

Dependent procedures (Finish-Finish):

Produce Path Plan (L090)

RECEIVABLES

Project Constitution or other definition of project scope
Definition of Business Needs and Anticipated Benefits

DELIVERABLES

Skeleton high-level “Path Plan”

TOOLS

Path Templates
Process descriptions

DETAILED DESCRIPTION OF TASKS

Processes and Paths

Each area of activity within is detailed as a process.

Processes may be mandatory, normal or optional. Alternative processes may sometimes be defined for the same aspect of a project where there are differing needs and market conditions to address. In many cases there will be alternative processes depending on the circumstances of the client or the scope of the business requirements. In this way it can be 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 sall needs in the ever-changing marketplace.

For each process there is detailed documentation including:

its definition,
a summary of its purpose and content,
planning information concerning when it should be used and how it relates to other processes,
details of deliverables, receivables, tools and materials,
detail of the issues and approach.

This detail may be coupled to an example sub-plan for the process. This is known as a “Process Plan” or “mini-plan”.

The combination of optional processes and alternative processes that is chosen and agreed for any segment is known as a “Path”. A number of standard paths have been identified. These are described in “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 combination of processes for any given project is defined in the project’s “Path Plan”. This is agreed before or during the Project Launch segment.

Path selection

Selection of a path is akin to planning a journey where the starting and desired finishing points are known and an itinerary for the journey needs to be decided upon. During the Project Launch it is usual to plan the entire path through all the segments involved. The path is then reviewed after the completion of each segment to determine if the route through the next segment(s) is still valid or whether it needs modifying in the light of experience and knowledge gained in the previous segment.

There may even be different approaches within the same project. It is possible, for example, that a selection might follow “Full Selection” processes for a key distinctive element in the system but might use an approach closer to “Short Form” selection for standard constituents.

The columns on the framework diagram indicate the main examples covered in siips Path Templates (example paths). Their intention is as follows:

Column 1	Column 2	Column 3	Column 4
New paths for use with integrated packages.	“Full” paths – these are the most complete way of doing things – but beware, it would never be normally to plan in every option.	Short ways of doing things. These paths illustrate how a minimal subset of processes can be chosen	By-passes – these are paths where the full normal work does not have to be done for some reason – normally because it has already been done.
Project Model	Full Requirements	Catalogue Requirements	Validate Requirements
Design / Prototype / Construct	Full Selection	Short-form Selection	Confirm Selection
Readiness & Rollout	IDDI	Brief Delivery	Implement Only

In addition, it also shows that Custom Development may form part or all of the delivery solution, although these techniques are not prescribed in the siips methodology, as they are not package specific.

Factors in path selection will include:

Factor	Comments
Scope and size of the business processes and business area involved	The larger the scope of the business needs, the more likely it is that a “full” approach will be required to cope with the degree of complexity.
Complexity of the organisation	Short approaches rely on a single source (or a manageably small number of sources) for information and decision making. Conversely, a large number of decision makers with overlapping interests can make progress very slow and require formal techniques to reach consensus.
Size of client organisation	A small organisation may not have sufficient staff resources for involvement in a full approach
Scope and integration	The number of applications or modules to be implemented and the extent to which they need to be integrated with other systems.
The complexity of the application(s)	The more complex the applications or modules, the more likely a full process will be needed.
The type of applications	Different applications or modules generally need different skills and different approaches; for example, fixed assets systems generally require a large effort in collecting new data, whereas payroll systems will normally involve the custom development of fully automated conversion of existing data.
Importance to the business	Where the system is vital to the competitive position of an organisation a full process is likely to be desirable.
Legal and commercial requirements of the client organisation	Many organisations are required to follow specific approaches either by law or according to their internal standards or normal practices. For example, this is particularly common with public sector organisations where regulations usually require a demonstrably fair approach rather than one which is quick and cost effective.
Industry	Many industries or types of organisation have specific preferences based either on their peculiar needs or simply on the custom within the industry. For example, banking and financial sector clients generally place much greater emphasis on testing, security and control aspects of the work, whereas manufacturing clients generally prefer to try things out in practice before buying.
Environmental Culture	Which approach suits the culture of the organisation? Will they benefit most from a collaborative approach or a directive approach? Do people expect to be consulted or receive orders? Will the staff readily accept the project and work with the team for the benefit of their employers, or are they more likely to resist the project?
Time constraints and budgeted time/effort	If time is limited then a Short Form / Brief Delivery path is more likely to be favoured.
Financial Constraints and Budget	If the client has a limited budget then a Short Form / Brief Delivery path is more likely to be favoured.
Resource Constraints	Which human resources can be made available for the work? For example – how many user managers and user staff can be made available; how many IT staff?
Application / package / module skills and experience of the internal and external staff available	If the available experience of the application area and/or package modules is limited then a Short Form / Brief Delivery path should be avoided if possible as there will be no suitable material on which to base this approach and the risk of serious error is significant.
Cost vs Benefit vs Risk	Very often the best value for money is not given by the most complete solution. In business, commercial risks can be taken in the hope of maximising profits. It is possible to weigh the expected costs against benefits, and to factor in considerations concerning any increased risks involved in more rapid approaches.