Introduction

As deliverables from a project are implemented and changes are made in an organisation, more staff become conscious of a project as it starts to directly affect them. Often, the judgement of a project’s success is based on stakeholders’ experience of the implementation of deliverables. How well you complete your project directly links to how successful you will be assessed to be.

If the project results in substantial change, see also Chapter 13.

Implementing deliverables

As deliverables are completed they are ready to be implemented. Implemented deliverables enable an organisation to make the transition from current ways of working to new ways – in other words, change. The steps in implementation are:

1. Implementation planning: implementation is complicated and risky. For a complex project a detailed implementation plan should be developed, which:
   • ensures the project’s deliverables are in a fit state to be implemented
   • defines acceptance criteria and go/no-go decisions for the deliverables
   • ensures that the organisation is ready to change in the way proposed (see Chapter 13)
   • assesses the risk to the organisation from a change, and has a defined way to manage the transition
   • plans for resource to deal with unexpected problems that happen in implementation
   • contains appropriate contingency plans for go-live should anything go wrong and disrupt operations.
2. Testing and acceptance. Testing is performed to ensure the deliverables created by the project meet the need as defined in the requirements. Deliverables are normally only accepted if they confirm to defined acceptance criteria (see pages 131 and 133).
3. Implementing and handover: the deliverables are put to live use in the business and handed over to operational departments (see Chapter 13). Types of implementation include:
   • Prototype: sample deliverables are implemented to gather feedback. They are then enhanced based on their appropriateness, effectiveness and how staff respond to them.
   • Pilot implementation: trying deliverables in one area of the organisation and learning from the experience. The learning is used to decide how to carry out implementation in the rest of the organisation.
   • Phased: gradual roll-out across the organisation.
   • Big bang: single once-off implementation across the organisation.
   
   The decision on which approach should be taken depends on:
    
   • speed of implementation required
   • scale of implementation
   • the level of risk associated with the implementation, and if rollback is possible
   • whether or not the implementation can be broken into chunks
   • the type of deliverables and the risk associated with their use
   • the degree of change and likely staff response associated with implementation.
4. Responding to issues: during implementation, unforeseen problems and unexpected outcomes will arise, and staff may resist the implementation. This cannot be planned for precisely, but it is possible to identify many implementation risks. You must be prepared to handle issues as they arise during implementation. It is rarely plain sailing!
5. Closing the project: when all remaining activities in the project are completed (see pages 135 and 136).
6. Project review: perform a review to ensure future lessons are learnt from the project (see Chapter 9).

Testing deliverables

Project deliverables should conform to their documented requirements. To ensure they do, they must be tested prior to implementation. There are many ways to test and the type of testing required depends on the deliverables. Whatever approach to testing is taken, it is only by testing that you can be confident that deliverables are as you expect them to be.

While the actual tests vary between deliverables, there are some generic questions you need to ask to test any set of deliverables:

• Is the set of deliverables complete?
• Does each deliverable work? Do the deliverables work together as expected?
• Do the deliverables integrate smoothly with existing business processes, systems, tools, etc.?
• Does each deliverable work as intended and with all the features you expected to be in it?
• Does each deliverable work to the level of service expected, meeting non-functional requirements?
• Have the deliverables been made, built or created to the level of quality that was required?
• Are there any specific acceptance criteria or processes the customer has defined – and have the deliverables met these criteria?

The sorts of tests that are possible are:

• Formal tests, usually a series of gradually more comprehensive tests that put the deliverables closer and closer to real use. Typical stages from an IT project are:
  • unit test
  • integration test
  • user acceptance test
  • systems test
  • operational pilots.
• Internal pilots: use of the deliverables in an internal environment. Ideally, this is done in such a way that the deliverables can be removed if they do not work as expected or required (removing already implemented deliverables is called rollback).
• Customer trials: trialling of the deliverables with customers. This is normally done for new products and services. It can be testing, or checking attitudes to product features, pricing, etc.

Decisions about what types of tests are needed should take account of:

• The type of project and deliverables.
• The level of risk associated with implementation and use of the deliverables. The higher risk associated with using the deliverables, the more thorough testing should be.
• The project constraints in terms of speed of implementation required and resource available. Time and resource for testing should have been built into the project plan from the outset of the project.
• The type of implementation (big bang or phased – see page 129). A big bang approach often requires more thorough testing than a pilot or phased implementation.

Accepting project deliverables and gaining sign-off

A key principle is that project customers decide when deliverables are good enough, not the project team. One of the most important groups of customers is those who have to use the deliverables once implemented – known as end-users. The customer’s or end-user’s representatives should sign off deliverables as acceptable.

There are several stages of sign-off possible in a project, including signing off project scope and project requirements early in the project’s life. The most important sign-offs are:

• Acceptance for implementation: when operational departments sign off that deliverables can be implemented in their departments. This sign-off is based on the testing results (see page 131) and approval of the implementation plan (see page 129).
• Acceptance that implementation is complete: when customers and end-users of the deliverables sign off that they are satisfied with the implementation and the project can now end.

The primary people involved in the above sign-offs are:

• Project sponsor: he is satisfied with the project and how the risk it exposes the business to is being managed.
• Operational departments: the people and functions who have to use and live with deliverables. There will often be several operational departments involved.
• Benefits case owner: the people and functions that have to achieve the benefits associated with these deliverables.

It is helpful to define the following criteria to manage the acceptance of deliverables:

• Acceptance criteria: predefined criteria agreed with project customers and users. If met, customers will accept the deliverables. Acceptance criteria are usually based on the deliverables passing tests, but may include other requirements, such as having access to documents or user instructions and staff having completed training.
• Go/no-go criteria: predefined criteria agreed with operational departments. If met, the operating departments will agree that implementation can go ahead.

Determining when a project is complete

Ending a project is often harder than expected. There are always further activities that can be done to improve the implementation, or to increase stakeholder satisfaction. However, the project must end – the project team members will be needed to do other work, and costs must be limited or the business case will not be met. To complete a project:

1. Prepare for completion up front. Set stakeholder expectations that the project will be ending.
2. Be clear on conditions to close the project. Completion of a project should not simply occur when a point in time is reached: closure happens after the decision that the project has been completed and the deliverables are of an appropriate standard. Operational departments should be lined up to take responsibility for deliverables as soon as acceptance criteria have been met.
3. Complete closure activities:
   • Complete any outstanding activities, or ensure they are included in the handover to end-users or operational support.
   • Release human resources at the appropriate time (see page 136).
   • Thanks and celebrations. Project team members should be thanked appropriately for their contribution to the project.
   • Review stakeholder satisfaction and agree any actions required to satisfy dissatisfied stakeholders. This includes agreeing what to do with any unfulfilled requirements.
   • Perform project staff appraisals, and for non-project staff organise feedback to their line managers on their performance on the project.
   • Finalise budgets and release any money not spent. This requires ensuring that any final payments have been made to suppliers.
   • Complete any project documentation, such as handover reports and project closure approvals.
   • Perform a project review and identify lessons learnt.
4. Gain sponsor approval to close the project.

Releasing project team members

As tasks on the project plan are completed, project team members can be released. Do not do this prematurely. People should only be released from the team when:

• You are sure that they have completed all the tasks required, not simply that they have worked until a certain date specified in the plan. All the work they were meant to do must be completed.
• You have confidence you will not need them to help you further during implementation.

Projects come to an end. Don’t let this just happen by accident with people drifting off as they feel appropriate:

• Prepare early for this and don’t just suddenly arrive there.
• Manage expectations as to when people will be released. Project timelines will often flex a little, and original plans to let people go on one date may move as the project shifts. Manage team members’ expectations as to when they will be free to go.
• Resist pressure to let critical team members go too early. The benefits from a project can be severely reduced if key people are not available throughout handover.
• Stagger the release of people. It is unusual to be able to release everyone at once, but it is also unusual to need everyone right to the end of the project.