Writing Project Constraints

When defining a project, it is important to sketch the context in which it is likely to unfold. This is very similar to the approach taken in developing a context for decision making (see decision article Defining a Context') . One of the components of a project context is the set of constraints likely to be encountered. It is important therefore that these be identified clearly before any commitment is made to go ahead with even with the detailed planning of the project.

Before we proceed though, we ought to have a clear idea of the difference between risks and constraints. A constraint is a barrier or limitation that is either already present and visible, or definitely will be so during the lifespan of the project. Its effects on the project or any part of its planning or execution are beyond dispute.

On the other hand, a risk is a potential problem, something to which our project might be exposed some time in the future. There is sometimes the mistaken idea that risk management relates to problems about which we know little. Actually, there is not much we can do about such problems. Risk management is most effective when dealing with problems we do know about, the only uncertainty being whether or not they will occur. The weather offers a good example of this. We all understand what it is, but cannot confidently predict its behaviour. Risk management tries to counter the unpredictability of problems. Constraint management has no such need. Constraints are perfectly predictable.

So how do we deal with constraints? It turns out that a very simple approach is appropriate. List all of the factors that you think will have a limiting and therefore negative impact on the project. This can be done in a table as will be shown below. In attempting to identify these constraints, it might be helpful to organise them into categories such as:

You will probably be able to identify many more that relate particularly to your organisation.

Along with each constraint, you should also identify, how you might respond to it. These response strategies need only be expressed in very broad terms at this stage. For example, if we are concerned that the team does not have adequate skills to deal with certain work on the project, we might simply identify 'Training Program' as a strategy. Later, this will be elaborated into a set of tasks such as

Perform needs analysis,
Identify training vendor,
Locate venue,
Issue invitations
Conduct Training
Evaluate Training

These tasks should eventually be included in the work breakdown structure where they will be estimated, resourced, scheduled, costed and monitored like any other task. Only in this way can we be sure that our strategies will be implemented.

The following table shows how we might capture this information.

Constraint analysis is a vital part of the project definition process, one that is simple and relatively quick to do, and yet is indispensable in defining the project's context.