0% found this document useful (0 votes)
56 views6 pages

Resource Allocation Models in Project Planning Tools: Abstract

Fuck your self

Uploaded by

Krishan verma
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
56 views6 pages

Resource Allocation Models in Project Planning Tools: Abstract

Fuck your self

Uploaded by

Krishan verma
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Copyright © IFA C Ex pe rie nce with the

Ma nageme nt o f Software Projects.


India na, USA, 1989

RESOURCE ALLOCATION MODELS IN


PROJECT PLANNING TOOLS
A. Fuggetta
CEFR IEL - Centro pn la Ricerca I' la FOn/wzioll1' ill Ill gt'!;lInia
dell'IIlJonnaziolle, Milalto , Italv

Abstract. Project planning tools are more and more widely adopted by many
organizations and professionals, who aim at supporting the management of their
activities in an efficient way. However, although these tools present user-
friendly interfaces and sophisticated printing capabilities, they lack powerful
means to describe resource allocations and, consequentially, resource costs. This
paper reports on some experiences derived from the use of these tools in small
research organizations, and discusses possible enhancements to existing resource
allocation models in order to cope with the identified deficiencies.

Keywords. Management systems; software engineering; software tools; project


planning; project control.

ESPRIT research programme funded by the


INTRODUCTION European Community.

This paper reports some considerations and 5. Each person in the organization is
ideas that have been derivE!d from a two years normally involved in more than one
long experience with the use of some project project: moreover, he/she can be involved
planning tools in two small research in other activities, such as lecturing.
organizations, operating in the information
technology area (Telecommunications, 6. Often, even a limited change in the
Computer Science, Electronics). allocation of resources has relevant effects
on the schedule (this is due to the small
The characteristics of the workplaces where dimension of teams, the skill of people,
these experiences were matured can be and the nature of the activities).
summarized as in the following:
One of the lessons that we learned from these
1. Small organizations (30-50 people). experience can be summarized in the following
statement: very often, in projects like the ones I
2. Members of the organization are graduates have described above, the process of laying
or Ph.D.s in computer science or electrical down the sequence of tasks and the
engineering: some of them are part-time identification of their links do not constitute
consultants (typically, university the critical aspect of the planning activity;
professors). rather, the proper description of resource
allocations across the different tasks in which
3. Projects are small (often less than 5 man- they are involved turns out to be an intricate
years): typical activities are feasibility and cri tical job.
studies and development of research
prototypes. Project teams have an average To tackle this problem properly, during these
size of 3-5 people. two years we have evaluated several
commercially available tools such as Timeline
4. Often, the project is part of an 1.0 and 2.0, Prima vera 3.0, and Superproject
international joint effort, sLch as the Expert 1.0. The overall result of this study
confirms that these tools present high quality
64 A. Fugge tta

interfaces and printout capabilities, but lack tuning is not performed, the user will probably
some of the functionalities needed to cope with obtain a plan that has been delayed only for
the above-mentioned problem, as we will see representation problem, not due to an intrinsic
in the next sections. scarcity of resources. It is clear that in these
cases the critical part of the leveling task is
performed by the user, not by the tool.
SOME CONSIDERATIONS ON Moreover, sometimes one must identify means
THE MANAGEMENT ACTIVITY to by-pass the standard mechanisms provided
by the product to describe the allocation of
From the previously described experience, I resources. In the more complex case, the project
have consolidated two major beliefs: planning tool is used only to have a nice
printout of PERT or Cantt charts and to fa-
All the activities which share the same set of cilitate their update, but it does not support
resources must be managed by the project the core of the management problem.
planning tool as a single project 1. In fact, only
in this case it is possible to have
EXPERIENCE WITH
1. meaningful results from the scheduling and CURRENTLY A V AILABLE
leveling processes and PROJECT PLANNING TOOLS

2. meaningful reports about costs distribution The comments in the previous section are
and resources usage. centred on the relevance that the process of
allocating resources to tasks has in the
Notice that with "all the information", I development of an efficient and effective plan.
mean all of those data that can directly or
indirectly affect the significance of scheduling To better understand this position, it is worth
and leveling, even if they are not directly briefly describing the resource allocation
related to any specific project (for example, models adopted by most of currently available
data about conference participation). tools. The following classification is based on
Clearly, powerful reporting aids are needed to the evaluation of the previously cited tools
allow the user to easily split the schedule and on simpler experiments conducted in a less
data, according to specific ~election criteria, systematic way with other products.
and analyse them in a more detail.
It possible to identify four different basic
In general, in situations like the one I depicted models:
above, the boundary of a management problem
should be defined by looking at the resources Full resource. This approach was followed by
one has to manage, instead of keeping into the early products in the market (see for
account each project separately. example Timeline 1.0) and, as far as I know, it
is not adopted any more. In this schema, each
Tasks and resource allocatiun must be specified resource can be allocated only to one task at a
using a user-oriented view of the problem: time: if there is any allocation conflict, one of
scheduling and leveling must be performed by the tasks is delayed until the resource is free.
the tool, not by the user. With presently Clearly this approach is not acceptable and, in
available project planning tools, everything fact, it has been replaced by more flexible
goes right until one decides to put resources in models.
the plan: at this point, one has very often to
conceive some tricks in order to obtain a Total time spent on task. In this case, the user
reasonable final schedule. For example, in specifies for each resource the total time spent
order to have a resource allocated properly, in on task (T). This information and the task
some cases one has to split tasks and manually duration (D) allows the tool to compute the
compute the resource allocation. If this manual allocation rate of the resource as T /0
(Primavera).

1 In this context, the term project is used to Percentage of time spent on task. This
denote a set of tasks that are managed as a approach represents a dual model of the
whole by the project planning tool. previous one. The user specifies the task
duration and the allocation rate (for example
Resource Allocation Models in Proj ect Plannin g T ools 65

50%) and the tool computes the total time the allocation of resource time is
spent on the task by the given resource uniform.
(Timeline 2.0, Prima vera, Superproject
Expert). For example, if a resource has been allocated
on a 40 days long task for a total amount of
Total hours and daily allocation. The planner time of 3 days (1 working day =8 hours), it is
specifies the total time that the resource will assumed that it will work on that task for
spend on the task and the daily allocation. 24/40 = 0,6 hours/day = 36 minutes/ day.
The resource will work on that task until the
total available time has expired (Superproject Days

Expert). o 10 2J 3J

To allow a more flexible allocation of resources


Task A
to tasks, a few tools (for example, Prima vera)
8
provide an additional mechanism to constrain
a resource allocation within a specific time
AM. R 4
interval. This approach is based on two
concepts:
o
Lag. This is the initial delay with which a
resource starts working on a task; the default Task B
value is typically 0 (the resource starts
8
working as soon as the tasks is started), while
the maximum value must be less than the task
A1I,R 4
duration.
o
Allocation Duration. This value is used to
define the amount of time the resource will
actually work on the task: the default value is
equal to the task duration Fig. 2: A solution for Example 1.

o 10
A first consequence of this approach is that
reporting is sometime meaningless.
Let us consider, for instance, the previous
Task A
example: some tools produce reports that
6 describe the daily plan for each resource, i.e.,
a list of activity names which the resource is
All. R 4
expected to work on during a given workday,
o along with the allocated time for each of
them. In that context, this kind of report is
Task B
quite useless since a plan that foresees a daily
allocation of 36 minutes each day for a 40 days
long task is rather unusual. What one would
expect is that the resource will spend its time
in units of 2 or 4 hours in a few days along the
task duration.

As a second comment, notice that the uniform


distribution assumption is adopted also by the
Fig. 1: Example 1: Overlapping task with a leveling algorithm: what happens can be
shared resource. clearly described by the following examples.

Notice that each tool does not implement all Example 1: Overlapping tasks with common
of the above-mentioned models: however, all resources. Let us consider the tasks of Figure 1,
of them share a common assumption about how where a resource R is shared between the two
the resource time is distributed 'llong the tasks A and B (both tasks are 20 days long). R
allocation duration: is allocated on task A four hours each day
66 A. Fuggetta

(e.g., he is lecturing in a class), while the Days


global allocation of R for task B is 12 days (96 0 10 aJ 3)

hours). Since the leveling process assumes a


uniform distribution, the daily allocation for Task A
task B is computed as 96/20 =4,8 hours/day. If
a standard daily allocation of 8 hours is 8
assumed, the scheduler delays task B until A11. R
task A terminates or, at best, it signals the 4
need of overscheduling for the resource.
0
Clearly, if we drop the assumption of uniform
allocation, we can have the situation of Figure
2, where the two tasks are properly scheduled,
8
- Task B

without any delay or resource overscheduling.

To cope with the above situation using


presently available tools, the user has very
often to split task B in two subtasks and
manually specify the two different allocations
that would keep into account the above-
All. R
4

0 I
mentioned problem (Figure 3).0 Fig. 4: Example 2: foreground and
background activities.
Days
o 10 aJ 3) 1. It delays task A until B is terminated .

_ _ _ _ _ _ _ _ TaskA 2. It splits task A in two subtasks - Al and A2


- and insert task B between them (this is
_ _ _ _ _ Task B1 done by Superproject Expert).

In both cases, the final deadline is delayed


----- Task B2 only because the leveling and scheduling
algorithm has uniformly distributed the effort
along task A. As an alternative, it is possible
to distribute the initial effort for task A over
27 days, without delaying the task completion
Fig. 3: An inadequate solution for Example date (Figure 7).0
1.
Days
Example 2: Background and foreground o 10 aJ 3J
activity. Consider the case of Figure 4: resource
R is partially allocated for 15 days to task A;
the daily allocation is computed as 15/30 = 0.5
days =4 hours. 8

""'.R 4
Let us ::.uppose now that resource R has to
attend a three days conference (Task B): since
task B requires the entire resource and cannot o
be delayed (the conference is held at a fixed
date), the scheduler has to rearrange the plan
in order to accommodate the new event. The 8
- Task B

I
strategy that an existing scheduler algorithm
will choose is likely to be one out of the An. R
4
following alternatives (Figures 5, 6):
0

Fig. 5: First solution to Example 2.


Resource Allocation Models in Project Planning Tools ti7

These two examples demonstrate that, when of the daily allocation to distribute resource
used to model real situations in dynamic time along the task duration. The resource time
environments, current project planning tools T is segmented in T /V pieces of length V; each
provide mechanisms that are often of them can be moved along the task duration
oversimplified. in order to optimise the overall resource
utilization, with the unique constraint that
1. They leave to the project manager the every allocation unit must be completely spent
burden of optimising resource distribution in a single day. For example, if the task
and project deadlines. duration is 20 days and the total resource time
is 3 days, an allocation unit of 4 hours means
Days that the resource will work on that task from 3
o 10 aJ :D to 6 days (with a daily allocation of 4 or 8
I I I I
hours), depending on the fact that one or two
ToskA1 allocation units are spent for each workday.
8 TaskA2
Days
o 10 ::;D

_______________________ T~A

- Task B

.AJI.R 4
8

AI.R
o

8
- Task B

Fig. 6: Second solution to Example 2.

2. Reporting is mad£' unclear by the


proliferation of tasks cleated only for
representation problems. Often, some of
the reports generated by the tool are not
very useful, since the cost and resource
AJI.R
4

0 I
usage infonnation are split across many Fig. 7: A better solution for Example 2.
tasks that do not have a problem-related
semantics. In this way, the user can specify a resource
allocation using a very intuitive model. Once
3. Changes in the original schedule can the total time has been specified (or computed
invalidate the de-facto manually on the basis of the task duration and the
perfonned distribution of resources percentage of the resource used), one tells the
planner how it can allocate resource time on
the task. The planner can initially satisfy a
WISHES TO TOOL DESIGNERS resource allocation request putting one
allocation unit for each day. If more resource
Our experience shows that the basic time is requested in the same period, it can add
assumption that must be dropped from current new allocation units or try to move one or more
project planning tools is that resources are units in order to find enough holes for the new
uniformly allocated along the task duration. request.

A possible approach to override this Clearly, the hypothesis of non uniform


hypothesis could be based on the definition of allocation has a severe impact on the
a new entity that describes how a resource complexity of the planning algorithm. The
spends his/her total time on a task. In approaches that can be followed to solve the
particular, one could force the scheduler to al- above-sketched problems tend to make the
locate resource time using an allOcation unit U. scheduling and leveling activities
This information is used by the planner instead
fi8 A. Fuggetta

unmanageable in an automatic way, if the


general case is considered 2. However, it is felt REFERENCES
that current tools do not take advantage of the
evolution of many techniques that have been Bimson, K.D., L. Boehm Burris, (1989).
developed in the last few years. If we look at Assisting Managers in Project Definition:
available tools, we discover that they are Foundations for Intelligent Decision
based on algorithms that compute the solution Support. IEEE Expert, Summer 1989, pp.
using a deterministic approach. On the 66-76.
contrary, in the research community, a
significant number of projects are now applying Breakthrough Software, (1985).
AI techniques (in particular, heuristic Timeline Ver. 2.0 - User's Guide.
searches) in the design and development of a
new generation of planners and schedulers that Canzi, V., G. Guida, W. Polo ni, and S. Pozzi,
provide the project planner with a higher (1989). CRONOS-II: A Knowledge-based
level of functionalities and services. For Scheduler for Complex Manufacturing
example, Bimson and Boehm Burris (1989) Environments.
describe an expert system for project planning Proceedings Second ACM-IEEE
and control called Watson, that is able to International Conference on Data and
actively support the user during the design of Knowledge Systems for Manufacturing and
the schedule. In the Factory Automation Engineering, Gaithersburg, MD, October
research area, there is a relevant number of 1989.
projects that address the scheduling problem in
presence of particular technological constraints Computer Associates, (1987).
on resource availability using heuristic tech- Superproject Expert Ver. 1.0 - User's Guide
niques (see, for example, Canzi and colleagues, & Reference Manual.
1989). Hayes (1989) and Keng and Yun (1989)
describe new planning models that focus not Hayes, c.c., (1989). A Model of Planning for
only on the generation of feasible schedules, Plan Efficiency: Taking Advantage of
hut also on the identification of nearly optimal Operator Overlap. Proceedings Eleventh
plans in presence of resource conflicts. International Joint Conference on
Artificial Intelligence, Detroit, MI,
We can reasonably expect that this kind of August, 1989, pp. 949-953.
techniques can be also successfully adopted in
our area of interest. Keng, N., D.Y.Y. Yun, (1989).
A Planning/Scheduling Methodology for
the Constrained Resource Problem.
CONCLUSION Proceedings Eleventh International Joint
Conference on Artificial Intelligence,
Project planning and control is a complex and Detroit, MI, August, 1989, pp. 998-1002.
critical activity and currently available tools
do not fully support the user in some of the Primavera Systems, Inc., (1987).
problems that must be solved. They provide Prima vera Ver. 3.0 -User's Guide.
user-friendly interfaces and high quality
printing capability, but offer only primitive
support to the problem solving activity.

In the next few years, we expect significant


advances in the models upon which these tools
are built and, in particular, the one used to
describe resource allocation. According to our
experiences, this task is the most critical and
difficult to carry on in an effective and effi-
cient way.

2Many problems of this type have


unmanageable computational complexity.

You might also like