Project Delivery Process D110

D110 -Review technical environment and plan installation

DEFINITION

Plan in detail the physical installation of the packaged software, additional systems software, hardware, communications equipment, servers, PCs etc.  This may involve several stages of installation as the project progresses.  Note that with medium systems this task is often performed by the vendor.

SUMMARY

Early access to a working basic system is usually an advantage during the design work.  It can be used to explore options and to illustrate possible approaches.  Working with prototypes means that a system to configure the prototype has to be set up for the design phase. Later on, when the productive system is set up, a very different technical environment in terms of capacity and network (though generally not in terms of operating system or database) might be installed.

Setting up the packaged software can be a complex task and should be planned carefully.  Often there are lead time delays in meeting all the technical needs, for example new equipment may need to be bought and installed, communications systems may need to be set up.  New skills or support arrangements may be required within the client organisation’s IT department.  This may lead to training or recruitment needs and can lead to organisational change issues.

The technical requirements are collated and reviewed.  The various technical options are then considered and evaluated.  An overall technical approach is recommended and detailed instructions are aid out for the required actions along with responsibilities and timing requirements.  These details will be presented in the form of an Implementation Paper - the Technical Plan IP (TP).

Any effect on the path plan or segment plan will be reviewed and dealt with as appropriate.

PATH PLANNING GUIDANCE

This process is optional.  It may not be necessary in simple cases where sufficient detail concerning all stages of installation has already been established in the Delivery Approach Definition (DAD) document or from another source.

DEPENDENCIES

Prerequisites (Finish-Start):

• technical architecture defined

Prerequisites (Finish-Finish):

• finalisation of the high-level design architecture/scope of project

Dependent procedures (Finish-Start):

• acquisition and installation of hardware and software - Process D130

RECEIVABLES

• Delivery Approach Definition (DAD) or equivalent statement of overall design architecture (Processes S700/S710/D010)

DELIVERABLES

• Technical Plan IP (TP) incorporating:
• hardware, software, communications and configuration design for the development, testing and operational environments,
• logistic and practical needs, eg ordering hardware, installing systems software, connecting networks.

TOOLS

• skeleton Technical Plan (TP)
• Examples: “Technology Blueprint”
• Examples: “Application Blueprint”
• Examples: “System Delivery Worksheet”
• Examples: “Facilities Improvements Worksheet”
• Examples: “System Supplies Worksheet”
• various guidelines on installing hardware and software

DETAILED DESCRIPTION OF TASKS

Requirements

All aspects of the technical and operational environment may be relevant.  Very often, detailed technical requirements will not have been stated earlier in the project, other than where they were relevant in the selection process.

Requirements can relate to:

• physical needs such as hardware, software, PCs, terminals, printers, communications lines, networking equipment, upgrades, consumables, etc
• logical needs such as Transaction Processing service resources, database services, user profiles, user accounts, usernames, logons, accounts, passwords, security clearances, network set up, and remote printer definition,
• operational needs such as inclusion in scheduling, archiving, batch runs, backup and recovery procedures, inclusion in disaster recovery plans, update of Data Protection / privacy registration and procedures if appropriate (as defined by local legislation and client’s normal practices),
• IT planning needs such as revision of IT plans, update of capacity planning data, update of network plans and data,
• human resources with the necessary skills to perform and support the above tasks.

The new systems may require new support arrangements involving new skills or revised organisation within the client organisation’s IT department.  There may be a need for training or for recruitment to provide specialist support skills.  There may be an impact on the current personnel and any organisational change issues may need to be dealt with (see the processes dealing with organisational impact and change for guidance).

Note that at this stage, the requirements need only be considered in sufficient detail for the production of the Technical Plan.  Where appropriate, detailed Implementation Papers will be produced at a later stage to design specific technical aspects of the solution.

Requirements will normally change during the life of the project.  A small configuration is often sufficient for design and development, but greater resources will be required to support the implementation of a full sized system.  Further resources may again be required as users progressively take up the new system.  The following activities frequently lead to a change in the level of system resources required and should thus be considered separately in defining the requirements:

• installation and installation testing
• design prototyping
• development
• system testing
• user training
• volume testing
• data conversion
• live data load
• live running
• any further phases of live running or take up of the system

In particular, note that there may be a need to provide discrete environments for design prototyping, development, testing, training and live usage such that these activities do not unreasonably interfere with each other.  This can lead to a need for multiple technical environments depending on the software and systems software in use.  The discrete environments may be separate machines, separate systems, or just logically separated within the system.

At the design stage, details of requirements for the full sized system may only be tentative, dependent upon future design decisions.  The plans for the installation and design work must, however, be final as they will immediately be put into action.

Options

The available technical options will depend upon the technical architecture of the chosen solution and of the client’s existing technical infrastructure.  These will normally need to be discussed and agreed with the client’s IT specialists and the supplier.

Recommended approach

The recommended options are stated and agreed.  These should be agreed by both the sponsoring user management within the organisation and the IT management.  It would be beneficial to get agreement also from the vendor if appropriate.

Detail of recommended approach

Full detail of the recommended approach should be stated in the form of a plan.  This may show dependencies, time, resourcing and responsibilities.  In complex cases it may be most valuable to use the same tool that is used for the main project planning and control.  Any impact upon the overall Path Plan or Segment Plan should be considered and addressed as appropriate.

Detailed configurations and required acquisitions must be shown.  This may include site preparation. The format in which these details are prepared and controlled may be based on the example worksheets: “Facilities Improvements Worksheet” and “System Delivery Worksheet”.  Requirements for consumable items may be recorded as in the example “System Supplies Worksheet”.

Normally, the overall systems architecture will closely follow that defined in the Delivery Approach Definition (DAD) or similar overall design document.  If the detail has changed or been refined, the final detailed configuration of the system can be shown using new or updated “Technology Blueprints” - ie simple diagrams showing the technical configuration of the overall system including networks, servers and workstations.  In some cases it may also be appropriate to create or update an “Application Blueprint” - ie a simple high-level diagram showing the different software components and how they relate to each other.

The detail may also cover the agreed approach to organisation, management and individual responsibilities relating to the technical plan.  This may cover:

• skills requirements
• training needs
• recruitment needs
• re-organisation
• responsibilities for the tasks identified
• responsibilities for the  continuing management, support and operation of the system.