International Journal of Project Management Vol. 14, No. 2, pp. 89-94, 1996
Pergamon
Copyright © 1996 Elsevier Science Ltd and IPMA
Printed in Great Britain. All rights reserved
0263-7863/96 $15.00 + 0.00
0263-7863(95)00056-9
Warning: activity planning is
hazardous to your project's health!
Erling S Andersen
Department of Information Science, University of Bergen, N-5020 Bergen, Norway
Project planning is an important part of project management. This paper argues against the
commonly used practice of activity planning. It claims that this kind of planning at an early
stage is either impossible to do in a meaningful way or gives miserable results. It proposes
milestone planning as an alternative approach. Milestone planning is goal-directed and resultsoriented, and not activity-based. A project responsibility chart is used to clarify the responsibilities
for achieving the different milestones. A different approach to scheduling is suggested. The proper
role for detailed activity planning is described. Copyright © Elsevier Science Ltd and IPMA
Keywords: project planning, milestone, milestone planning, activity planning, project responsibility chart, scheduling
Textbooks tell you about it. Project management software
requires it. It is impossible to make the traditional network
plan without it. Namely, activity planning at the start of the
project. This means that all of the activities of the project
are identified at the outset and are put together in a complete
network plan t .
Most authors agree that a project is a unique endeavour.
It is a special task that has not been done before. The
natural implication of uniqueness is that it is impossible to
know all the activities of the project at the initial planning
stage. Although activity planning at an early stage is contrary
to the definition of a project, the value of it is taken as a
self-evident truth.
This article argues against the traditional activity planning
at the start of a project. It proposes a very different approach:
milestone planning.
The fundamental problem of activity planning
Why is activity planning at the start of the project to be
considered harmful? As implied by the definition of a
project, it is doubtful whether project planners can foresee
all the activities at the beginning of the project. 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
PM
'4[2--B
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.
Making activity plans
Despite this kind of critique, many projects still make a
complete network plan for the whole project at the outset.
How can it be that project planners are able to make a
detailed project plan, when either activities cannot be foreseen or they depend on the outcomes of earlier activities?
There are several answers to this puzzle.
First, it can be done because the actual project is not a
completely unique task. The project has similarities to
earlier, completed projects. The planners believe that they
can use the experiences from these former projects, using
their activity lists and precedence relations to draw the new
activity plan.
Second, the project is solely technical, and the planners
can choose the project activities based on their knowledge of
technical matters. There is in fact only one optimal technical
solution in the project. The planners further assume that
people--managers, users or customers--with idiosyncratic
behaviour will not interfere either. It may, of course, be
questioned whether this is a project in the true sense of the
definition. Merely carrying out certain technical activities,
partly in a chronological order, partly in tandem, should not
be a sufficient condition to call the whole thing a project.
89
Warning: activity planning is hazardous to your project's healthY: E S Andersen
Third, it is possible to make the plan because there are
implicit or explicit decisions taken as to what kinds of
activities to undertake in the whole project. Such decisions
imply that some activities are chosen and others are rejected.
Project planning can apparently be done in this fashion.
It has a clear disadvantage. Planners are compelled to make
decisions early in the project, when very little is known of
the project's future. In fact, because the planners are
ignorant of the future, many decisions will be taken unconsciously. More optimal solutions may become apparent
with the passage of time; the planner chooses early solutions,
not optimal solutions.
Fourth, a plan may be made up of vague descriptions of
activities. Such examples are 'planning' and 'implementation'. The planner thereby avoids taking precise decisions
on which activities the project is to execute. On the other
hand, the plan is not very helpful. More importantly, it
becomes a way of hiding the real issues confronting the
project.
The alternative: milestone planning
What is the alternative to activity planning? We recommend
a very different strategy. The recommended approach is
called milestone planning z. Some define a milestone as the
completion of an activity, usually an especially important
activity. A typical example is: ' . . . completion of a large or
important set of activities '3. That definition should be set
aside. It implies an orientation in thought toward activities.
A milestone is defined here as a result to be achieved.
The milestone is a description of a condition or a state that
the project should reach by a certain point in time. A
milestone describes what is to be fulfilled, but not the
method to fulfil it. A milestone can be reached by a wide
variety of activities. It is unusual to have one specific
activity or only one chain of activities that lead to a
milestone. Instead there are alternatives: there are many
different activities or many different chains of activities. By
using milestones and doing milestone planning, resultoriented thinking is introduced instead of activity-oriented
thinking.
When milestones are planned first, a procedure that is
well known from other problem-solving areas, for example,
from the area of planning a computer-based information
system, is being followed 4. The question of 'What' is
answered before ' H o w ' is considered. That means that
when a project is planned, the results to be achieved are
discussed and agreed upon first. This is outlined in the
milestone plan. It covers the end results as well as the
intermediate results, which are necessary stages to the final
results. After agreeing on this plan, questions about the
methods and means to achieve the different results are to be
answered, i.e. which activities are most suitable in order to
obtain the different results.
Making a milestone plan
A milestone plan shows the milestones of the project and
the logical dependencies between them. Figure 1 presents
a very simple milestone plan. It should be interpreted in the
following way: milestone M4 cannot be reached before
milestone M3 is achieved. Likewise, it is logically impossible
to obtain the results described by milestone M3 before M2.
A milestone plan diagrams the logical precedence relations
90
(
M1
()
MS
()
M3
M4
Figure 1 Milestone plan
between milestones. It is a practical application of the ideas
expressed in the precedence analysis of Langefors 5. These
ideas have been successfully applied to the field of information systems development by Lundeberg et al. 4.
At first glance, a traditional activity network and a milestone plan appear to be the same. They are very different.
The milestone plan is about milestones, i.e. intermediate
and end results of the project. It is not concerned with the
activities of the project. Some activities to achieve M4 may
start even before M 1 has been reached, others may have to
wait until M3 has been accomplished. The milestone plan
does not say anything about activities. Its focus is on
results. The activity plan, on the other hand, describes
activities only. It does not reveal the results that should be
achieved.
Example: milestone plan
Let us look at an example of a milestone plan. The
managing director of a company has assigned to a project
the task of drawing up an action plan to improve the
physical work environment within the company. A
milestone plan for this project is shown in Figure 2.
The milestone plan shows that a description of the present
situation should be developed first. It is important to note
that the milestone plan does not say anything about how this
should be done. For example, all employees or only a
group of employees may be interviewed or sent questionnaires or some experts may observe the actual workplaces.
No decision is taken at this stage on how the milestone is
to be reached. First, what the project is to achieve should
be determined, then a discussion on how to achieve it can
take place. Note that a description of the existing situation
can be valuable in itself. It is advantageous to have a picture
of the actual physical work environment. The milestone
does not only serve as a checkpoint in the work towards a
completed project, it can also provide valuable information
for the business.
The next milestone requires a description of the desired
situation. Work on developing a picture of the desired work
environment may start before the description of the present
situation is completed. A final description of the desired
situation is not possible, however, before we have the
description of the present situation; the description of the
desired situation must take into account all the conditions
mentioned in the description of the present situation. Once
more we stress that we have taken no decisions on which
Warning: activity planning is hazardous to your project's health.t: E S Andersen
(
MI
When there is a description o f the present physical work situation
When there is a description o f the desired physical work situation
When the requirements for change are stated and prioritised
M4
(
(
When ideas for measures to tackle the prioritised requirements for change are
available
When an evaluation o f the consequences o f the various measures is available
M6
When the selected measures are included in an action plan, which is submitted to
the managing director
Figure 2 Milestone plan for a project which will draw up an action plan to improve the physical
work environment
activities the project should engage in in order to develop
the description on the desired future state of the work
environment.
The requirements for change will be the difference
between the desired situation and the present situation. It is
self-evident that it is impossible to obtain an overview of all
the requirements for change and prioritise them for action
before obtaining the description of the desired situation.
Ideas for measures to be taken must be generated, but at
this stage we do not take any decisions on how to arrive at
them. The consequences of the various measures must be
evaluated and the best measures will be included in the
action plan.
So much for the example. It underlines the central point
that the milestone plan is set up without taking any decisions
on which activities must be started to reach the different
milestones. This means that a milestone plan can be read
and understood without having any detailed insight into the
underlying activities. For this reason we call it a logical
plan; it shows the logical dependencies between the states.
We can see from the milestone plan in Figure 3 that
milestone A1 cannot be reached before B1 is reached. B3,
for example, cannot be reached before both A2 and C3 are
reached. Some more dependencies are shown in the milestone plan. As we saw in the simplest plans, there might be
a dependent relationship between milestones in an individual
result path. The plan also shows that there are dependencies
between the paths. This means that project results of one
type depend on what has been achieved in other areas.
When implementing a computer-based information system
in an organization, educating the users of the system and
reforming the organization to utilize the system better may
be simultaneous tasks. A project would therefore have
goals for personnel development and organizational development as well as the development of the information
system itself. The milestone plan for such a project would
have result paths for all three kinds of results.
In this way, the milestone plan is apparently both rich in
Result path A
Result path B
Result ruth C
Result paths
The milestone plan is usually more complicated than the
one shown in Figure 1. A project typically has multiple
goals. It aims to fulfil several kinds of results simultaneously.
It would be in the true spirit of milestone planning to have
the plan show the project working towards different kinds
of results. This can be done by introducing the idea of a
result path. The result path is a collection of milestones that
are primarily directed towards the fulfilment of one kind of
result. This is illustrated in Figure 3.
Each path is given a name which describes what is going
on in that part of the project. The first one or two letters
in the designation may be included in a reference code to
identify the milestones. In the Figure the three result paths
are called A, B and C. The milestones in path A are
assigned the labels A1 and A2, the milestones of path B are
called B i, B2, B3 and B4, and so on.
BI
CI
C2
A2
C3
B3
Figure 3
Milestone plan with result paths
91
Warning: activity planning is hazardous to your project's healthY: E S Andersen
information and a tool for pedagoguery. By the use of the
result paths, it shows the readers o f the plan what kind of
results the project is aiming at. The milestones show what
the project has to achieve, and in which order, to accomplish
the given task.
Example: milestone plan with result paths
We extend our previous example o f drawing up an action
plan to improve the physical work environment. Let us
assume that the managing director has changed his mind
and instructs the project to look into the social working
environment as well as the physical. He is asking for a
more comprehensive action plan involving both aspects o f
the working place.
A milestone plan has to be drawn up for this new project.
This milestone plan should have three result paths: one for
the physical work environment, one for the social work
environment and one for the total action plan. In this way
it would be obvious to all readers o f the milestone plan that
this project is aiming at achieving results on these three
levels.
The milestone plan is shown as Figure 4. We recognize
the three different result paths. When studying the dependencies between milestones, we should notice that a
description o f the desired social work environment is a
prerequisite for the description o f the desired physical work
environment. This means that the project cannot have completed a design of the desired physical work environment
before it knows what the ideal social situation should be.
W e emphasize that this is not a statement which expresses
a dependency between activities. Instead it reveals an
important logical condition about some o f the results to be
achieved in the project. Many potential activities are
available to us when it comes to the work o f clarifying the
desired future state o f the social and physical work environment. Many o f them may take place in parallel. We have
not yet discussed which ones to undertake. What we have
Physical env.
)Pl
Total plan
done is to make known that some results have to be achieved
before others can be obtained.
Milestones and responsibilities
Linear responsibility charts are a useful and well-known
tool within project planning. A responsibility chart has
usually been used to link responsibilities to the activities in
the project. It is o f course, important to clarify responsibilities for carrying out each activity. Yet it is even more
important to be able to define the responsibilities for reaching
the different milestones, i.e. for achieving the necessary
results.
The use of a milestone plan makes it possible and easy
to link together the milestones and the responsibilities for
achieving them. A project responsibility chart will show
who is responsible for each milestone. Such a chart makes
it clear who has the responsibility for planning the work,
procuring the needed resources and doing the actual work.
It is also o f importance to state who is to be asked for advice
and who is to be informed.
Example: project responsibility chart
Figure 2 showed a very simple plan for the project o f
drawing up an action plan to improve the physical work
environment in a company. We later saw that a milestone
plan is usually more extensive, but this plan played a role
as a simple introduction to the milestone plan concept. W e
will now show in Figure 5 what the project responsibility
chart might look like for this task.
In a milestone plan, each milestone is formulated as a
description of a state. It is the work leading up to the
milestones that will be regulated on the responsibility chart.
W e do not, therefore, repeat the whole milestone formula.
W e can select a formulation which clearly shows that it is
the work up to the milestone we are looking at. Or we can
use keywords from the milestone and let it be understood
Social env.
St
When there is a description of the present situation
( P3
When there is a description of the desired social
work situation
When there is a description of the desired physical
work situation
~
$3
When the requirements for change are stated and
prioritised
When ideas for social measures are available
When ideas for physical measures are available
When total budget for change is decided
When an evaluation of the consequences of the
various measures are available
When the selected social and physical measures are
included in an action plan
Figure 4 Milestone plan for a project which will draw up an action plan to improve work environment
92
Warning: activity planning is hazardous to your project's health.r: E S Andersen
Scheduling
X - E x e c u t e s the w o r k
D - T a k e s d e c i s i o n s s o l e l y or u h i m a t c l y
d - Takes decisions jointly or partly
P - M a n a g e s w o r k a n d control progress
T - P r o v i d e s t u i t i o n o n the j o b
C - Must be consulted
I - Mu|t be informed
A - A v a i l a b l e for a d v i i c e
k,II Description of present situation
X/P
A
C
X
X
d
X
C
X
I
X
C
M2 Description of desired situation
X/P
M3 Requirements for change
X/P
M4 Ideas for measures
X/P
C
M5 Consequences of the measures
X/P
X
M6 Action plan
X/P
C
D
T
A
I
X
C
Figure 5 Project responsibility chart (see Figure 2 for the project's
milestone plan)
that the responsibility chart applies to the responsibility for
achieving that milestone. Milestone M1 is called 'When
there is a description of the present physical work situation'.
On the project responsibility chart in Figure 5 it says
'Description of present situation'. These are keywords
from the complete milestone formulation.
The project responsibility chart shows what responsibility
the different parties have for realising the milestones. Let
us illustrate this by looking at milestone M1.
The responsibility chart states that the project manager is
responsible for managing and controlling the work that has
to be undertaken in order to achieve the results described
by the milestone. In this sense he or she has the main
responsibility for reaching the milestone and delivering the
planned results.
The project manager is, together with a personnel consultant and the work environment committee, also assigned
the role of doing the work of achieving the milestone M 1.
An external consultant may be engaged to teach the people
involved in the work how to do it in the best manner. It is
fairly typical in a small project that the project manager is
given executive tasks besides his or her managerial role.
The managing director is available for advice. The
affected line managers must be consulted. This means that
the head of production must make a statement on the actual
situation in the production department, the head of marketing
on the situation in the marketing department, and so on.
When it is stated (milestone M2) that the affected line
manager should make a subsidiary decision on the desired
situation, it means that the head of production will decide
on matters for his department, the head of marketing for
his, and so on. But we see that the managing director makes
the principal decision. This means that the director has the
right to reconsider whatever the line managers have decided.
One person may be included in several parties. For
example, one person may be both an elected employee
representative with certain tasks and an affected user with
other responsibilities.
A further evaluation of the milestone plan is made during
the work on the project responsibility chart. If there are any
logical flaws, problems may occur in filling in the responsibility chart. Work on the responsibility chart may lead you
to return to, reassess and alter the milestone plan.
Time scheduling is an important part of project planning.
One vital question is if it is possible to prepare a time
schedule without having made a detailed activity plan at the
start of the project. The answer is " y e s " , but the scheduling job is very different from the way it is done on the
basis of an activity plan. There are at least two possible
approaches.
One way to make the time schedule would be to allow the
project management to state when the different milestones
should be achieved. This means that it sets the dates on
which the different milestones should be reached. But even
with such an approach, criteria for setting the dates and the
appropriate length of time between milestones has to be
established. Otherwise, the planning would simply be
guesswork. One criteria for time allocation could be the
relative importance of each milestone in the project.
The basic assumption behind such a criteria is that there
is a direct relationship between the quality to be achieved
and the time and effort spent on achieving the milestone.
The greater the time allocated to achieve a specific milestone, the higher the quality of the results. The most
important milestones of the project ought to have the
highest quality.
Implicit in this scheduling approach is an idea of how
much time is required on average to reach a specific
milestone. The project responsibility chart would also show
the project management who is in charge of the milestone
and what kind of manpower is allocated for the work on it.
However, even assuming that previous experience is used
to allocate time, the fundamental philosophy of this approach
is that it is almost impossible to imagine which activities
have to be completed in order to reach a certain milestone.
Therefore, the planner should not attempt to solve this
impossible problem. Instead, the planner should allocate
time and personnel resources on the basis of which milestones will contribute most to the success of the project.
Allocating time and resources according to priorities is a
common practice in many different planning areas.
This may be illustrated by the example in Figure 4. The
project management may think that the description of the
desired social situation is the most important milestone in
the project. It constitutes the foundation for the description
of the desired physical work environment and requirements
for change. When scheduling, a good proportion of the
available time should be allocated to the work on this
milestone.
Some are very sceptical of this approach. They would
argue that it is impossible to allocate the available time
between the different milestones in a reasonable way
without discussing which activities need to be done. A
second approach, that meets this objection half-way is to
determine what kind of activities have to be executed, and
identify the most time-consuming of them.
A milestone can usually be achieved by a variety of very
different kinds of activities. As pointed out earlier, milestone M 1 in our first example could be achieved either by
doing intensive interviewing, or by conducting a survey
with written responses, or by actually observing the present
conditions. The various kinds of actions require different
lengths of time. This means that the kind of approach which
will be used must be decided in order to determine the time
required.
93
Warning: activity planning is hazardous to your project's health/: E S Andersen
Not all of the activities necessarily need to be named.
Only the one or two time-consuming activities need to be
identified. A written survey would, for instance, require a
lot of activities, but the length of the answering period
given to the respondents and the number of rejoinders
would be the most important aspects when it comes to
determining the length of time required.
Some may feel strongly that making a time schedule on
the basis of a complete and detailed activity plan is the right
approach to project planning. However, while in the middle
of the project, the following problem may arise: Given the
results of some earlier activities, it is no longer optimal to
do the planned activities. Other activities would generate
much better results, but require a different time schedule.
There are then two alternatives. The 'new' activities and a
new time schedule may be chosen, with the consequence
that the previous schedule is no longer followed. On the
other hand, it may be impossible to implement the necessary
changes because of so many commitments to the existing
plan. The less optimal plan may have to be followed
anyway. This is a Catch-22 situation: Damm'd if you do,
damn'd if you don't.
Activity planning
The main idea of this article is not to argue against detailed
activity planning. The idea is that activity planning should
be done only when it is strictly necessary and not before all
the necessary information is available. The consequence of
this argument is that a detailed activity plan should not be
prepared at the start of the project.
Before work on a particular milestone is started, a
detailed activity plan for achieving this milestone has to be
provided. The activity planning for achieving a specific
milestone may wait until close to the starting of the work
on this milestone. With this approach all of the relevant
information is available for the planning. An activity
responsibility chart, defining the responsibilities for each
activity should also be prepared. This is the traditional use
of a responsibility chart. It must, of course, be in accordance
with the project responsibility chart.
Conclusion
This article has advanced the arguments against detailed
activity planning at the early planning stage. It has argued
that project planners should be result-oriented. Instead of a
94
detailed description of activities, a plan showing milestones
(meaning results to be achieved) and result paths (highlighting what kind of results the project is aiming at) should
be prepared.
This discussion has not taken into consideration the fact
that projects are quite different. The milestone planning
approach is most useful in what is called internal projects,
i.e. projects that are characterized by organizational
development and strong competition for internal personnel
and management attention 6. The argument against detailed
activity planning is not so relevant in projects with well
defined goals and well defined methods of achieving them 7.
However, every real project is unique with its own unclear
future.
References
1 Cleland, D I and King, W R Project Management Handbook 2nd edn,
Van Nostrand Reinhold, New York (1988) 329
2 Andersen, E S, Grude, K V and Haug, T Goal Directed Project Management London 2nd edn, Kogan Page (1995). See also Andersen, E S,
Grude, K V, Haug, T and Turner, J R Goal Directed Project
Management Kogan Page, London (1987) and Turner, J R The
Handbook of Project-based Management McGraw-Hill, London (1993)
3 Meredith, J R and Mantel Jr, S J Project Management 2nd edn, John
Wiley and Sons (1989) 301
4 Lundeberg, M, Goldkuhl, G and Nilsson, A Information Systems
Development: A Systematic Approach Prentice-Hall (1981)
5 Langefors, B Theoretical Analysis of Information Systems Studentlitteratur, Lund, Sweden (1966)
6 Mikkelsen, H, Olsen, W and Riis, J O Management of internal
projects lnt J Project Management 9 (2) (May 1991) 77-81
7 Turner, J R and Cochrane, R A Goals-and-methods matrix: coping
with projects with ill defined goals and/of achieving them lnt J Project
Management 11 (2) (May 1993) 93-102
Professor Erling S Andersen holds a
master's degree in economics from
the University of Oslo, Norway,
where he also taught for a number of
years. He now has a chair in information science at the University of
Bergen, Norway. He is also an
adjunct professor at the Norwegian
School of Management, Oslo,
Norway. He has published several
books in the fields of information
systems development, project management and management in
general.