Abstract
Project planning is an important part of project management. The paper argues against activity or network planning at the start of a project, which is the traditional approach to project planning. It proposes a different approach: tiered planning with milestone planning as the main planning tool. Milestone planning is focused on milestones – instead of activities – and is goal-directed and results-oriented. The milestone planning presupposes strategic choices. And after the milestone planning, there is also need for activity planning. Software has been developed specifically for milestone planning. This kind of software is quite different from the traditional network planning software.
The Planning Challenge
Planning is the core of project management. Network planning is the pride of the project management profession. Knowledge about network planning distinguishes project managers from other categories of managers. Most textbooks advocate that a network plan should be made at the start of the project.
However, network planning does not secure success. Many unsuccessful projects have very detailed plans. This seems to contradict normal expectations. What's the explanation? Why is activity planning at the start of the project to be considered harmful? (Andersen, 1996).
As implied by the definition of a project (“a unique endeavor”), it is doubtful whether project planners can foresee all the activities at the beginning of the project. This is especially true for change or renewal projects. Some may perhaps argue that this is feasible, if the planning is done well. But the problem is not just to identify the potential activities. We face an even more formidable problem: the kinds of activities that should be undertaken depend on the results, the successes or misfortunes, of earlier activities. To make an optimal choice among the alternative activities in the latter part of the project, the outcomes of preceding activities have to be known. One consequence is that decisions taken without this knowledge result in less than optimal solutions. Besides, a focus on activity planning draws attention away from the more important issues. The main questions at the initial planning stage should be what kind of results the project should achieve. We should also discuss in which order the results and the sub-results necessary for achieving the end results, should be delivered. The most prominent plan in the project should highlight this. A network activity-based plan takes attention away from these important issues in the planning process.
Unsuccessful projects are characterized by rigorous attention to detailed planning. But the greater the detail, the more likely stakeholders will start disagreeing among themselves. The project is wasting its energy. It should have had a different type of planning, building scenarios, promoting political embeddedness among stakeholders and lobbying backing for the project.
Some argue that detailed plans are basically symbolic in nature. We plan because we've been told to plan. Some (managers) feel safer with detailed plans. Plans give an impression that the project knows what it needs to do to succeed – that it has the situation under control. But in reality, the project will be groping around in the dark, changing direction regularly.
The most dangerous situation emerges when the project gives detailed plans more status than reality. The map counts more than the territory. This drives projects onto the rocks. Projects must realize the limitations of their plans. We do not reject planning, but we do stress the importance of tiered planning.
Several empirical studies have explored correlations between project success and project planning. They confirm planning's importance. One of them finds a positive correlation between planning standards and project success (Dvir & Lechler, 2004). Project success is about goal achievement, and about satisfied end users and project partners.
A positive, significant correlation between planning (defined in terms of functional and technical standards of the deliverables) and project success was found by another study. This study concluded that the importance of early and generous investment of time and energy in project goal-setting and requirements of deliverables (Dvir, Raz, & Shenhar, 2003). And without the involvement of clients or end users, success will prove elusive. End-user involvement should start as soon as possible and continue through every project stage. Planning tools and procedures are useful, but which of them are used does not seem to affect performance. Planning is part of the project manager's responsibility, preferably in close consultation with end users.
Tiered planning
We propose three planning levels: strategic, tactical and operational project planning.
Strategic planning is about determining a project's strategy – how it goes about solving the challenges facing it. There are many ways of performing an assignment. All planning presupposes a strategy – it is impossible to draft plans without one. But strategies are often discussed and formulated with insufficient clarity.
We should have at least two sets of plans (Andersen, Grude, & Haug, 2004). One plan pertaining to the global level, and largely impervious to change, and one set of plans focused on the details, flexible plans, able to change in response to changes. To the outside world, the project should seem like a haven of stability; within the project, however, change will often be on the agenda. So we advocate two levels of plans: one plan expresses the project's milestones (we will call it a milestone plan); on the other level we have plans describing how those goals will be reached (these are activity plans). It is imperative to plan what we want to achieve before we discuss how to get there.
Project strategies
A project strategy is a set of general guidelines or principles used by the project to solve problems and exploit opportunities related to its assignment. The project strategy governs the choice of approach in the project.
There is not one right plan for all projects. The type of plan depends on the project's strategy. We have different types of project strategy (Grundy & Brown, 2002):
- – Positioning strategies
- – Implementation strategies
A positioning strategy looks ahead to the scenario planned by the base organization. It describes in principle how the project goes about reaching that goal (the position). It can comprise the development of a product, alliances with other companies, acquisitions, competence-building, or several change activities. This part of the project strategy must comply with the base organization's general strategy. Indeed, the base organization itself may have drawn up that part of the strategy, which is therefore something the project has to accept and take into account.
An implementation strategy is more detailed, but it is also a recipe saying how, in principle, project work should proceed. Project work is highly sensitive to choice of strategy. Imagine a project aiming to create change in a limited area, which delivers a product at the end of the project based on familiar technology and knowledge and expert analyses on the options available to the end user. Compare this with a project introducing change across many areas, where the results are delivered gradually, the users play a major role, and experimentation and improvisation are encouraged, new technology used, and the project mainly instigates change processes within the base organization. These two projects represent two different project worlds. That is why it is essential to review project strategies.
Milestones
A milestone anticipates what the project is supposed to achieve at a pre-set date. It should describe a desired state of affairs, a desired future situation. There are two important aspects to this. First, the concept refers to a point in time, not a period of time. Second, it looks forward to what we want to create, not how we create it.
Many define a milestone as an event in a project. It is not a very sensible definition really, because it mixes two different things together. A milestone should describe what we want to achieve; when we get there, that's the event. Most people avoid this level of precision, but by referring to milestones as events, for instance, attention may be diverted from what the project is supposed to achieve or deliver.
Milestones should preferably be felt as a natural part of the project. Of course, what people mean by “natural” depends on their experience and qualifications in subjects of relevance to the project. Natural milestones are, for example, normal decisions and consignments within the type of project we are planning.
The way a milestone is formulated should allow us to determine whether the desired state has been achieved or not. This is a major point. It is relatively simple to say whether a milestone has been reached if it is an actual object, something we can inspect and verify. If it is an abstract quality, on the other hand, we are in a different ball game altogether. When is a document good enough? How can we tell if people in the base organization are ready for change? Because abstract quantities like these lack natural cut-off points, in theory, work on them can go on forever. It is important therefore to describe the milestone in terms, which let us call it a day. The milestone should help us say when a job is finished, when the result is good enough.
Milestones are also control stations in the project, an opportunity for stakeholders to assure themselves that the project is moving in the right direction. Milestones focus attention on things of concern and interest to the base organization. They allow the project owner and base organization to assess performance. It is impossible for outsiders to keep track of a project without knowing what it is trying to do. Milestones affecting the base organization will also attract more interest in the project. Everybody can follow its progress - and share in the celebrations to mark milestones.
Milestone plan
The milestone plan charts the logical ties or dependencies between milestones. The milestone plan shown in Exhibit 1 should be understood as follows: to reach a state set out in milestone plan M5, the state described by milestone M4 must be in place. It is logically impossible to reach milestone M5 before M4. A milestone plan is therefore a logical plan. It shows the logical interconnections between milestones.
Exhibit 1 Milestone plan
The same philosophy is behind customary network planning. There, however, we focus on activity interdependencies. The milestone plan is not concerned with activities. Reaching a given milestone does involve, however, a number of activities. Some believe that a milestone plan shows that milestones have to be completed one by one. That is wrong. In general, we do not have to wait before setting off on another milestone. Works on M5 can, in principle, begin before M4 is finished.
It is important we remember what a milestone plan actually tells us: that we cannot achieve a milestone (we cannot finish the work) before we have reached previous milestone. It is a crucial point: milestone plans are prepared without deciding which activities get us through the different milestones. That is why milestone plans can be understood by non-experts in the field. It is also why we call the plan a logical plan: it charts the logical interconnections between states.
If past experience is anything to go by, milestone plans represent an effective means of communication between the base organization and the project. The project owner and line managers have a plan they can refer to. It presents a relatively comprehensible picture of what the project is aiming at, and the connections between milestones and project. We also know from experience that milestone plan shortcomings and logical flaws are quickly discovered by management and employees in the base organization, which shows they understand the plan and its implications. When the plan is understood and accepted by the project owner, he can use it to monitor progress and take action whenever necessary.
It is preferable not to alter the milestone plan, despite alterations regarding activities. There is obviously a more urgent need for this type of plan when we are working in unfamiliar territory and know little about the necessary activities. The milestone plan remains valid as it is even if activity plans have to be changed radically. It is psychologically important during follow up to maintain a plan that does not change between every reporting period. Constant alterations easily lead to loss of respect. The milestone plan is in this sense a robust plan: impervious to alterations concerning activities.
To explain the multidimensional aspect of project management, we shall introduce what we refer to as a result path. A result path is a sequence of closely interrelated milestones. It consists of milestones, each of which helps the project create a predefined product. The result path is a technical focus area. Interconnections between result paths show that work on the different types of deliverables is interconnected.
The number of paths in a plan depends on the nature of the project, in other words the number of deliverables on order or technical focus areas. Although there are instances of plans with only one path, usually there are between two and four. More than that and the plan risks transparency. Every path has a name, which tells us what people are doing in this part of the project.
Time scheduling
Scheduling is usually based on knowledge of all activities and the time needed to complete them. On this basis and information on activity interdependencies we estimate the time needed to reach every milestone. What do we do when we do not know which activities to carry out?
The recommended approach would be to inspect synchronization between the milestones (and the consignments they represent) and base organization operations. Milestone completion dates are set on the basis of optimal synchronization.
To projects established to renew the base organization, this option is very interesting. It differs fundamentally from customary scheduling in projects. We do not have to know the project's activities beforehand. It is not bound by the project or its frame of reference. It revolves instead around the base organization. The project's deliverables are synchronized with processes in the base organization. The chief concern is to ensure that the base organization get the products at the optimal time for the base organization – the project adapts to the base organization, not the other way round.
Entrainment has a fundamental effect on project work (Ancona & Chong, 1996). The base organization, due to certain events, may want the deliverables sooner than envisaged and the project feels is best. The new urgency may be down to changes in the market or internal matters. In any event, the needs of the base organization should determine delivery scheduling. The project may find it has to lower ambitions for some of its milestones to satisfy the new schedule. Or it may have to allocate more time between deliveries than it strictly needs to on the basis of project capacity. If the base organization needs extra time to absorb the deliverables, the project will necessarily respond by slowing progress.
Network plans
We dismiss the idea of making a detailed plan for the overall project at the start of the project. That does not mean that detailed plans are useless or unnecessary. Far from it. Every project needs plans detailing activities to be performed and designating responsibility for them. Our basic philosophy here is to wait with the detailed planning until absolutely necessary. And rather than preparing a single detailed plan, it is better to draft many smaller ones.
Our focus is on achieving the milestones. It would be sensible therefore to have a detailed plan for every milestone. Unfortunately, the situation of the project is not always transparent. It we are pursuing several milestones concurrently (which is what we often do, as illustrated by the use of result paths); it would help to incorporate the different milestone plans in a single comprehensive plan. It makes detailed planning more complicated, but there is no getting away from the necessity of working along parallel routes each leading to a different milestone.
A detailed plan does not have to be in place until work on the milestone in question is ready to start up. (We emphasize that the milestone plan does not say when work on the milestone will begin, that is something the people responsible decide without the help of the milestone plan.)
The detailed plan takes its cue from the project's situation (project history up to the present moment), along with the people and resources available to the project. These circumstances may have changed radically since project initiation, which in itself is reason enough to defer detailed planning. The plan sets out all activities necessary to reach the milestone (or milestones when there are more than one). The plan must allow for the logical dependencies between activities, that is, which activities must be completed before another is put in motion.
IT support
Modern management and administration require IT support. No projects should be allowed to proceed without it. Empirical studies indicate widespread use of project management systems (which is how IT support is generally referred to) (White & Fortune, 2002). IT support is used especially in connection with project planning. There is a wide and growing range of systems available.
Choice of IT support is based on the approach of the project management to running the project. If milestone planning is the chosen approach, the software needs to support this type of planning. (Goal Director is a custom built program for milestone planning. The software is the property of GDPM Systems. The company's homepage is: www.gdpm.no.)
No one IT system suits all projects. The purpose of the tool is to underpin the chosen operational mode and project culture.
