Management of Projects Involving Development

Many projects are conducted rather like a one horse race. Someone has put up the rails around the track, someone has trained the horse to run, someone starts the race on time. The Project Manager hurries the horse along, avoiding obstacles on the track, and everyone is a winner. There are problems to be overcome, but they are problems of a static structure - some equipment is late, or there aren't enough electricians. The CPM tools used to help manage these projects are suited to the relative simplicity of the project structure, where the plan is sequential and everything that is planned is to be carried out. The tools display their limitations when it comes to resource shortages - either activities are delayed or overloads occur - there is no facility in the plan to describe whether to get more resource if it can be cost-justified, or adopt an alternative way of doing things - the kind of thinking that is second nature to a Project Manager.

The constraints on putting up a high-rise are very strong - the plans are complete in every detail, the bricklayer knows how to lay bricks, gravity enforces the sequence, and there are no circumstances under which you will leave out the 23rd floor.

There are other sorts of projects where none of those constraints operates - a software project, say. There may be no more than a mission statement as a guide, there are alternative technologies to consider, the workers may need to develop expertise as the project proceeds, a good idea halfway will junk all that has gone before. Where development is occurring, CPM project management tools give a deterministic and simplistic view of the project's progress. There may be several levels of development in the project:

We are not yet sure whether we are building an office block, a hotel or a residential development, or some combination, but start planning it as a project - treat the engagement of the architect as an activity and plan out the different possibilities in sufficient detail, with a deadline for the first level decision, but close off each option as late as possible.

We have many projects, the successful completion of some of which will cause the termination of others. How can we sensibly prioritise them, when they interact strongly, some gobbling up the potential market of others, some needing others in parallel.

We are developing a new product, be it a no frills home loan or electronic device or computer software. There are many decisions to be made along the way - we are not yet sure of what we are doing in detail, let alone how we are going to do it or how long it will take - our plan should help us with all these things.

Using the horse race analogy, in development projects the rails around the track often lead to a swamp full of alligators so the track needs re-fencing, the horse needs to be trained how to run during the race, and the race was started a year too late, given the constraints on the business.

Highly constrained projects have a sequential flow, while development projects have an interaction among the elements, the How of the project potentially changing the What. It is these backward and forward interactions that make managing the development project so hard. If we want improved performance in managing development projects, much more decision support and decision making needs to be embedded in the project plan.

One way of achieving this is to change from the Critical Path method to a Constraint Reasoning (CRM) approach, where all of the constraints on the project are described in the plan. CPM was already describing the predecessor/successor and resource constraints in a sequential fashion, but there are many other types of constraints on a development project.

Differences Between CPM and Constraint Reasoning

In a CPM plan, while we are working out Early Start, each activity node acts as though it had a MAXIMUM operator before it. This MAX operator waits until it has the values of all predecessors to it, takes the maximum value, passes that to the activity node, which then broadcasts the value to all succeeding nodes. The method uses no information about what lies later in the network, and can provide no cross information to other paths. Resource levelling or smoothing complicates this picture somewhat, but basically the method is, for each node

or diagrammatically as shown. The constraints, or predecessor-successor relations, reverse their effects when working out Early and Late Starts, but cannot change their direction of effect in response to dynamic conditions in the network.

The CRM plan has a seemingly similar node structure, with ANDing of numeric values taking place at each node. This means that the range of variability shrinks to encompass the minimum range overall. No part of the network is ignored, with any changes in value being immediately propagated in all directions. Cutting of ranges and the reduction of variability proceeds continuously, and inconsistencies are flagged immediately they are encountered.

The Constraint Reasoning network is not limited to MAX operators, but can have the full range of analytic operators embedded in it. Logical connections allow the switching on and off of alternative paths, and the laying of traps that only take effect on the satisfaction of certain conditions. Constraints are not initially directed, the operators that make them up responding to the flow of information at their connections, not to some imposed algorithm. The simplest use of Constraint Reasoning might be to tie the duration of an activity to the duration of another activity (Activity2 will take twice as long as Activity1), but the duration could instead be tied to the difference in starting times of two activities, or resource usage of another activity or any other identifiable or constructable point in the constraint network.

Some New Types Of Activities

The greater modelling freedom provided by CRM allows the inclusion of new types of activities and modelling in the network.

The activities in a CRM plan are logically controllable for existence - that is, they have a logical connection which turns them, and their effects, on and off. Straightforward activities, which must occur, are unconditionally set true. Other sorts of activities can have logical interdependencies which enable them to compete with other activities for existence.

Sometimes you are not sure how events will unfold in the project, so cannot decide between two or more potential and mutually exclusive paths (something as simple as air or sea freight, or perhaps different technologies to produce similar outcomes). One path might be shorter but more expensive, or involve development and have higher risk, but have longer in-service life. If other activities will cause the project to be delayed, there is no point paying a premium for a time saving that won't materialise. The logic deciding between the two paths can be built into the network, and draw on as many influences as you wish. The two alternative paths can themselves be mini-projects, and don't need to have common starting and ending points, as shown in the diagram.

Some activities in the plan may have risks associated with them - risks that they may not occur, or that the duration becomes extended. There are two ways of handling this, backup activities and contingent activities. Human rated equipment, such as cars and planes, has many parallel and backup systems, so it makes sense to have backup activities in the high-risk areas of mission-critical projects.

Backup activities are worked on in parallel with the activity having completion risk. The backup activity may take longer to complete than the minimum duration for the main activity. However, if completion of the main activity does become a problem, the work spent on the backup activity has been good insurance for getting the project finished near the initial deadline.

Contingent activities are embedded in the plan, ready to be scheduled if failure occurs on some primary activity. As distinct from backup activities, work on the contingent activity only begins when failure has occurred on the primary activity. If the primary activity succeeds, the duration of the contingent activity is forced to zero, rendering the activity nonexistent.

If the duration of the project is strongly constrained so that the contingent activity is forced out of existence, the risk of the project can be made to increase, reflecting the fact there is now no contingency against failure.

If the existence of an activity is not yet fixed, it observes changes taking place on its Start and Finish pins. If the maximum possible duration between the Start and Finish values becomes less than its minimum real duration, the ACTIVITY switches its duration to zero and sends FALSE out of its Logical Control pin. If connected through an exclusive OR to another activity, the other ACTIVITY will be forced to exist.

A constraint on cost can feed back through the logic in the plan to force the duration to zero, or a lack of resources may force the activity out of existence.

Conclusion

This has been a brief introduction to Constraint Reasoning when used to model projects involving development. The technique allows difficult and dynamically variable projects to be described, their operation simulated and their complexities managed. A project plan built this way can start out looking very similar to a CPM plan, the difference being that virtually any required business, environmental or technical constraints can be easily added to the Constraint Reasoning project plan.