Project Delivery Process D130

D130 - Install hardware, communications and software

DEFINITION

Install and commission hardware, communications equipment, networks, systems software, and applications software as required for the new system and set up the overall operational environment.

SUMMARY

This process will, normally result in a number of stages of installation, matching the needs of the project.  Initial tasks will be primarily focused on providing an initial system and environment for the design and development of the overall solution.  The requirements to extend this configuration into a full working system will be further elaborated by various IPs based on actual designs and needs.  In accordance with these evolving definitions of needs, further additions or changes may be required resulting in the need to install and commission further items.

In accordance with the Technical Plan IP, install and commission

• hardware,
• communications equipment and networks,
• system software, and
• applications software items.

This includes system environment requirements such as log-ons, access security, accounts, budgets, etc.

The installation plan is likely to be divided into stages.  Typical stages might be:

• development system,
• testing system,
• full-size system for volume testing
• final full configuration.

Note that with medium systems this is often performed by the vendor.  In large systems, the majority of the work may be carried out by the organisation’s IT department.  It is important that adequate control be maintained.

Normally, significant purchases will have been finalised prior to the delivery segment of the project.  Where this is not the case, and where further minor items are required, the acquisition process must be completed, although the project team will not normally accept any responsibility for decisions made without their full participation and review.

It may be necessary to prepare the physical location prior to installation.  This will most often be the case if significant new hardware is required.

Significant items acquired and installed may require formal installation testing and acceptance.

PATH PLANNING GUIDANCE

Optional - required when insufficient provision is already available for the project.

DEPENDENCIES

Prerequisites (Finish-Start):

• Technical Plan IP - Process D110

Prerequisites (Finish-Finish):

• none

Dependent procedures (Finish-Start):

• development tasks requiring the system

RECEIVABLES

• Technical Plan IP
• Delivery Approach Definition (or similar definition of high-level design)

DELIVERABLES

• Working system(s)

• Installation sign off

TOOLS

• Guidelines: “Installing Hardware”
• Guideline: “Package Installation”
• Examples: “Installation Signoff Letter”
• Examples: “System Delivery Worksheet”
• Examples: “Facilities Improvement Worksheet”
• Examples: “System Supplies Worksheet”
• Examples: “Technology Blueprint”
• Examples: “Application Blueprint”
• vendors’ technical documentation

DETAILED DESCRIPTION OF TASKS

The needs and plans for installation of hardware, communications and software should initially have been laid out in the Technical Plan - see Process D110.  This may subsequently be amended or further requirements may be defined as a result of other detailed design work.  The tasks in this process are to acquire (if necessary) and to put in place the required items, both as defined in the original Technical Plan and as subsequently agreed.

Complete system selection and acquisition

All details of the major components and their procurement should normally have been dealt with prior to the delivery segment of the project.  Where this was not the case, and where other minor items are required, the project team will need to finalise the details and ensure that the required items are acquired.

It may be appropriate to review the requirements and any un-finalised selection decisions.  If any substantial work is involved or if the impact of the decisions could be significant, the organisation should be advised to perform the appropriate requirements and selection segment tasks, eg validate requirements and confirm selection.

The project team should not accept any responsibility or liability for decisions taken without their full participation and review.  Accordingly, it is normal practice to note any such circumstances and to inform the client organisation in writing that the items concerned will be or have been procured in accordance with the organisation’s wishes without any warranty or specific endorsement by the project team.  In most cases the formal contract should be between the organisation and its vendor (nb different considerations may apply where sub-contractors are supplying items to a prime contractor - this should have been defined in the contracts).

Normally, the overall systems architecture will closely follow that defined in the Delivery Approach Definition (DAD) (or similar overall design document) and the Technical Plan IP.  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 configuration 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.

Preparation

The delivery schedules and responsibilities must be finalised and reconfirmed.  Any necessary improvements to the site or environment must be addressed.  The example worksheets: “System Delivery Worksheet” and “Facilities Improvement Worksheet” may be used to record these needs and monitor their progress.

Any required consumables must be acquired, eg paper stocks, disks, tapes, backup cassettes, pre-printed materials, etc.  It may be convenient to record these needs on a System Supplies Worksheet - see example.

Where new hardware is to be installed - see the guidelines document “Installing hardware”.

Installation and testing

All necessary components should be installed, tested and commissioned to provide the level of service required for design and development.

All items and aspects of the systems environment should be tested to make sure they work to the required standard.  This will normally be applied to the standard unmodified versions of the products supplied - it is a test that items were correctly delivered to the agreed specification - not that they will meet the users’ defined requirements.

Most items supplied by an external vendor should be tested on a formal basis to show whether they appear to meet their basic specifications as required.  Very often, vendors will supply standard tests which can be used for this purpose.  Depending on the agreed terms for the item concerned, these tests might be final acceptance tests or interim tests.

If a high standard of testing is required due to the wishes of the client or the demands of the contract, a formal controlled approach to the testing can be used.

More commonly, the client organisation will accept basic tests defined by the vendor or by the project team and formally accept the items without detailed controlled tests.  This is acceptable provided the approach is agreed by the client organisation and it is agreed in writing that neither the project team.

Major components of the solution will often not be fully accepted until the system tests or user acceptance tests at the end of the development process.  However, it is normal to test their basic operability at this stage and in many cases, a stage payment to the vendor will be due contingent upon these tests.

Minor components such as a PC or a standard word processing package are unlikely to have formal acceptance tests defined as they are normally acquired “off the shelf”.  They should be tested by the team and rejected if unsuitable or faulty, subject to the precise terms of contract agreed with their vendor.  It will not normally be possible to defer full acceptance until the final system acceptance tests.

The first stage is normally to install a system (or possibly more than one system) that the design and development team can use to prototype aspects of the design and to build and test the final solution. Testing at this time should aim to demonstrate that the system is sufficiently good for this purpose. Typically, this will include showing that

• developers can access the system and run the necessary programs (real-time and batch),
• any development tools can be used,
• data will be backed up routinely and can be restored without problem,
• standard, un-modified copies of programs and initial data are retained and protected from update,
• staff have appropriate levels of access defined by the system’s security controls.
• physical change controls and audit trails are applied as appropriate.

Where there will be more than one team active simultaneously, it may be of value to provide separate environments to protect the development work of each team from the others.  For example, a team writing and testing interfaces into a system could interfere with another team developing the normal entry facilities or another team testing operational job control procedures.

Subsequent stages of installation will normally be defined to expand the initial development system for use in testing, training, volume testing, live data loading and live running.  The needs will often become more reliably defined during the design and testing work.  It is common to find that there is a greater need for throughput capacity or data storage than was originally estimated.  Accordingly, the project team should monitor these needs and adjust the technical plans accordingly.  The volume testing activities and the team’s growing understanding of how to configure the system for optimum performance (“tuning”) given its precise functional design often identifies needs for further additions, upgrades or changes to the physical configuration.

These subsequent installation stages should, nevertheless, be planned and controlled in a similar manner to the initial installation.  Acceptance tests should be performed.

These subsequent stages do not normally involve the introduction of new technical approaches, it is more often simply an expansion of existing technology, for example:

• more disk space,
• more CPU memory or power,
• more user workstations and remote printers,
• faster communications network links
• software licences for larger numbers of users.

Signoff

Where items have been acquired and tested, it may be appropriate to seek a formal signoff of this aspect of the Project Team’s work.  An example “Installation Signoff Letter” can be found in the Tools.