Collecting requirements
For some projects, once you know what the deliverables are, you have all the information you need to develop them. For others, you need a series of more detailed information about the deliverables that together precisely specify the deliverables. This more detailed information is called requirements, and the complete collection of requirements is called the requirements catalogue or requirements specification. For example, in the office re-fit project scope included putting new furniture into the office, such as desks and chairs. This was enough information to allow the project to be planned and managed. However, there could be some very specific additional detailed information, such as the type of chairs required, the number of drawers needed for each desk and so on. These more detailed pieces of information are examples of requirements.

Some very large or complex projects have thousands and thousands of requirements; moreover in large businesses there is a specialist discipline, business analysis, whose role is primarily to analyze business problems and develop the requirements list necessary to overcome them. In large projects, for example in software development, one of the first major stages of the project is often to collect requirements, which can take many weeks in its own right.

There may be some situations in which you want to collect more detailed requirements than you would include in the Project Definition, but do not need to go to the extent of employing professional business analysts. (Remember the information in the Project Definition was there so you could scope the project, not so you know every detail of every requirement.) The aim is to get an exhaustive set of requirements that goes beyond the limited scoping information in the Project Definition and which fully defines the deliverables.

The way to develop requirements is through a series of structured interviews with your customers, to gauge exactly what it is they want from the project. If you ask people what they want delivered, they may go on giving you far more requirements than you can possibly deliver. So it is important to understand that every requirement typically adds some time and some cost to the project. Therefore when people are giving you requirements, you should understand whether these are:

• Mandatory: The project will not be complete without them, and your customer will not be satisfied without them. Unless all the mandatory requirements are met by the end deliverables from the project, it is a failure.

• Nice to have: Whilst not mandatory, these are requirements the customer really wants you to fulfill, and unless there is a good reason, usually in terms of unacceptable extra cost or time to the project, you will try to deliver these as well.

• Optional: Requirements the customer wants you to fulfill if it is reasonably straightforward, but will not be too worried if you cannot.

Using external contractors and companies on your project

In many projects you may end up using staff who do not work for your business as part of the project team. The use of contractors, consultants and third party suppliers is common to projects. These external contractors may have specialist skills, provide some service you do not know how to do yourself, or may simply be an additional resource to get over any shortages you have whilst running the project.

For individual contractors, you should manage them as you would any other member of the project team. There are many advantages and disadvantages of using a contractor compared to a colleague who works for the same business as you. As the project manager, you generally have a little more leverage over them than employees, as if they do not deliver what you have employed them to do, you may not pay them. This usually focuses their attention!

An alternative scenario with an external company working on your project is where they take total responsibility for a section of the project and they manage it themselves. If you do this your project management task can become a lot simpler, as what was a whole series of complex tasks on your plan may become a single task with a start and end date, the details of which are invisible to you. This 'black box' type of task has many attractions. For one thing, you don't need to worry about who is doing something or how they do it – only the start and end date and the cost. However, for this to work well you really have to trust your third party supplier. They are often just as likely to be late as you would have been in doing it yourself!

If you do choose to use a third party supplier to be responsible for a whole section of the plan, then they must plan this task themselves. When they tell you how long they will take and how much they will charge you should:

• At least challenge their timelines and costs: ask why can't it be done cheaper or quicker? You will often find that with some respectful but demanding challenges a supplier can deliver more quickly and more cheaply.

• Ask to see their plan, so you can at least check that they have one. If they do not, you should not be confident in their ability to do your work, unless the task is quite simple.

• Make them put some periodic milestones in their plans which are visible to you. This will give you confidence that their work is on track as the project progresses – or at least it will forewarn you if it is not.

Testing, integration and implementation

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.

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 organizational 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.