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:
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:
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:
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