Testing, integration and implementation

In Chapter 5 I touched on the need to test and implement the deliverables from your project. There is an additional stage to consider as well, and that is integration. For major projects the topics of testing, integration and implementation need specialist resources and significant time to complete. Poor testing, integration and implementation are often the basis of project failure. These are three very large topics, which cannot be covered in the context of this book, and this section simply gives a brief introductory overview of them.

Testing is a complex subject and there are, for example, people and teams whose sole role is to perform testing on complex projects such as major software developments. There are many types of testing for different types of deliverables. Generically the types of testing tend to fall into the following five categories:

1. Testing for completeness. Do you have all the deliverables you expect to have?

2. Functionality testing. Does each deliverable do what it is meant to do?

3. Quality testing. Is each deliverable of the quality level required? Quality can be measured in many ways, but would include issues such as reliability.

4. Usability testing. Is each deliverable in a form that can be used easily by the customer, and that they are happy with?

5. Operational testing. When a deliverable is used in the real world, does it work as expected and can it be operated without disrupting everything else it interacts with?

The process of formal testing has to be very rigorous and highly structured. To pass, a deliverable is checked against a very specific and predefined set of tests. These tests are written in a document called a test specification. Ideally this test specification was written at a similar time to the requirements and is a mirror document to it. For every requirement there should be a corresponding test step.

This is reasonably straightforward if the deliverables from your project are distinct and complete deliverables in their own right. However, often there are multiple deliverables which have to work together. Bringing many deliverables together and making them work seamlessly is called integration or systems integration. For example, if your project is to build a new gear box for a kit car you have built, then at some point you must integrate the gear box with the rest of the car's engine. Similarly, if you have developed a piece of software it often has to work with other pieces of software, including the operating system on your computer. Without trying to explain the mechanics of integration, which are complex and depend on the specific type of deliverables, there are three important things for the project manager to understand:

1. Where integration must happen, it is a distinct task that takes time and resources. It needs to be built into the Project Plan and shown as a separate series of activities.

2. Integration is only possible if the various component deliverables have been designed to be integrated. The gear box for your kit car cannot be designed any way you like, it has to be designed to work with the rest of your car's engine. This may sound very obvious, but it is common for complex deliverables to fail when it comes to integration.

3. Integration will not happen by itself, someone with the necessary skills has to do it. Simply having people on the project team responsible for building all the individual component deliverables is not enough, you have to have someone responsible for overseeing the integration itself.

Once a set of deliverables is integrated and shown to be working, it is ready to be implemented. In a normal business environment the deliverables from any one project must be made to work with the people who work there. So for example, a new computer system has to be explained to the people who must use it. Deliverables such as new computer systems, new processes for working, new organisational structures are changes to the way people work. For such changes to be successful, they need to be willingly adopted by the people involved. If you look at many business disputes, and major project failures in the press, they are often because of failed or poorly implemented changes.

The art of getting people to adopt new deliverables and ways of working is normally called change management. At the very simplest, this means the bringing of deliverables into a working environment. It also encompasses training people to use them. One of the most challenging pieces of change management is preparing people for the change that new deliverables bring about, and overcoming any objections so that they work entirely successfully. Change management is not something that happens at the end of a project, it needs to happen throughout the life of a project. When the project completes, all the preparation has been done and thus the change can be implemented smoothly.

When you consider testing, integration and implementation all together, you can get a series of test stages that need to be built into the plan for your project, such as:

1. Unit test. When the individual deliverables from the project are tested.

2. Integration test. When the deliverables are tested together as a complete working system.

3. User acceptance test. When the end users of the system test to see whether it works as they expected.

4. Operations test. When the integrated deliverables are tested within the live operational environment to ensure they work in the real world.

To put these activities into perspective, for a major programme of work the stages of testing, integration and implementation may take 50 per cent or more of the total length of the project.

Top of Page