Unit 3 Activity Planning, Risk Management, Resource Allocation

Contents:
 Activity Planning: Introduction, Objectives of Activity Planning, When to Plan,
Project Schedules, Projects and Activities, Sequencing and Scheduling Activities,
Network Planning Models, Formulating a Network Model, Adding the Time
Dimension, The Forward Pass, Backward Pass, Identifying the Critical Path, Activity
Float, Shortening the Project Duration, Identifying Critical Activities, Activity-on-
Arrow Networks.

 Risk Management: Introduction, Risk, Categories of Risk, Risk Management

Approaches, A Framework for Dealing with Risk, Risk Identification, Risk
Assessment, Risk Planning, Risk Management, Measures, Applying the PERT
Technique, Monte Carlo Simulation, Critical Chain Concepts.

 Resource Allocation: Introduction, Nature of Resources, Identifying Resource

Requirements, Scheduling Resources, Creating Critical Paths, Counting the Cost,
Being Specific, Publishing the Resource Schedule, Cost Schedules, Scheduling
Sequence.
1.

Recommended Books:
1. Software Project Management McGRAW 6th Edition, Bob Hughes, Mike
Cotterell, Rajib Mall
2. Software Project Management McGRAW 4th Edition, Bob Hughes, Mike
Cotterell, Rajib Mall

 Prerequisites and Linking:

UNIT-I Pre-requisites SEM-V SEM-VI
Program Evaluation Software Engineering Projects Projects
and Programme
Management
 UNIT-3
Chapter 06
Activity planning

Introduction:

Scheduling:
‘Time is nature’s way of stopping everything happening at once’
Having
– worked out a method of doing the project
– identified the tasks to be carried
– assessed the time needed to do each task
need to allocate dates/times for the start and end of each activity
Objectives:
• Feasibility
• Resource allocation
• Detailed costing
• Motivation
• Coordination

Activity networks:
These help us to:
• Assess the feasibility of the planned project completion date
• Identify when resources will need to be deployed to activities
• Calculate when costs will be incurred
This helps the co-ordination and motivation of the project team

Defining activities:
Activity networks are based on some assumptions:
• A project is:
– Composed of a number of activities
– May start when at least one of its activities is ready to start
– Completed when all its activities are completed
• An activity
– Must have clearly defined start and end-points
– Must have resource requirements that can be forecast: these are
assumed to be constant throughout the project
– Must have a duration that can be forecast
– May be dependent on other activities being completed first
(precedence networks)
Identifying activities:
• Work-based: draw-up a Work Breakdown Structure listing the work items
needed.

• Product-based approach
– list the deliverable and intermediate products of project – product
breakdown structure (PBS)
– Identify the order in which products have to be created
– work out the activities needed to create the products

Hybrid approach:
The IBM MITP approach suggested the following 5 levels
• Level 1: Project
• Level 2: Deliverables
• Level 3: Components – which are key work items needed to produce the
deliverables
• Level 4: Work packages: groups of tasks needed to produce the components
• Level 5: Tasks

The final outcome of the planning process:

The chart tells us who is doing what and when.
i.e. Sequencing and scheduling Activities.
A project plan as a bar chart.
Network Planning Models:
PERT (Program Evaluation Review Techniques) vs CPM
PERT was devised to support the development of the Polaris missile in the late
1950’s. CPM was developed by Du Pont Chemical Company who published the
method in 1958.
PERT is an activity-on-node notation – the ‘nodes’ are the boxes which represent
activities
CPM uses an activity-on-arrow notation where the arrows are the activities.

Formulating a Network Model:

Figure: Project Activity Network Framework with a check-point activity added

Figure: Project Activity Network Fragment represented as a CPM Network

Constructing Precedence Network:

• One start node
• One end node
• Node has duration
• Links have no duration
• Precedents are the intermediate preceding activities
• Time moves from left to right
• No loops
• Network should not contain dangles

Representing Lagged Activities:

• Two activities in parallel so long as there is a lag between the two.
• Where there is a fixed delay between activities e.g. seven days notice has to be
given to users that a new release has been signed off and is to be installed.
 Types of links between activities:

Finish to start: The following activity starts when the previous one has been
finished
e.g. testing starts when coding has been completed.

Start to start: When one activity starts another has to start as well
e.g. when prototype testing starts amendment documentation has to start as
well.

Finish to finish: when one activity finishes the other must finish too
e.g. when the testing of the prototype is completed so is the documentation
of any amendments. You could use these with lags e.g. documentation of the
changes to the prototype starts 1 day after the testing and finishes 2 days
after testing has been completed.

Start to finish:

In the example when the cutover to the new system takes place, the operation
of the temporary system is no longer needed. Although the cutover depends
of the acceptance testing to be completed, the implication is that the cutover
might not start straight after acceptance testing.
Start and finish times:
The time that an activity can start depends on its relationship with the other tasks in
the project. The earliest start is when the earliest of the preceding activities upon
which the current activity depends will be completed, so that the current one can
start. If it starts at this time the earliest the current activity can finish is the earliest
start plus its duration.
However, it may be that the activity, although it can start, can be delayed because
later activities do not have to start right way. This gives us a latest finish date. The
latest start date is the latest finish date less the duration of the activity.
When a student is given coursework to do they do not necessarily start it straight
away. They might note when it has got to be handed in, work out that it will only
take about three days to do - with a bit of luck - and wait until three days before the
hand-in before they start.

• Activity ‘write report software’

• Earliest start (ES)
• Earliest finish (EF) = ES + duration
• Latest finish (LF) = latest task can be completed without affecting project end
Latest start = LF - duration

Example:
earliest start = day 5
latest finish = day 30
duration = 10 days

earliest finish = ?
latest start = ?
Float = LF - ES - duration
What is it in this case?

The earliest finish (EF) would be day 5 plus 10 days i.e. day 15.
The latest start (LS) would be day 30 – 10 days i.e. day 20
The float would be 30 – 5 – 10 = 15 days
This also is the same as LF – EF or LS - ES

‘Day 0’:
• Note that in the last example, day numbers used rather than actual dates
• Makes initial calculations easier – not concerned with week-ends and public
holidays
• For finish date/times Day 1 means at the END of Day 1.
• For a start date/time Day 1 also means at the END of Day 1.
• The first activity therefore begin at Day 0 i.e. the end of Day 0 i.e. the start of
Day 1

This also means activity A could finish on Day 5, for example, and a dependent
activity B could then start on Day 5 as well (not Day 6).

All this may make more sense if you think about an activities that finish and start
halfway through a particular day.

Although we talk about ‘Days’ other time units could be equally valid e.g. Hours,
weeks, months. In case of weeks point out that we usually assume 5 day working
weeks in our calculations – unless otherwise specified.

Notation:
Forward pass:
• Start at beginning (Day 0) and work forward following chains.
• Earliest start date for the current activity = earliest finish date for the previous
• When there is more than one previous activity, take the latest earliest finish

Example of an activity network:

Work out the earliest start and end dates for each activity.

Backward pass:
• Start from the last activity
• Latest finish (LF) for last activity = earliest finish (EF)
• work backwards
• Latest finish for current activity = Latest start for the following
• More than one following activity - take the earliest LS
• Latest start (LS) = LF for activity - duration
Example: LS for all activities?

Identifying the Critical Path:

• There is at least one path in the network which defines the duration of the
project. It is known as the critical path.
• Activity’s float – the difference between an activity’s earliest start date and
latest start date.

Activity Float:
Float = Latest finish - Earliest start - Duration
Float can also be calculated as the difference between the earliest and latest start
dates for an activity or the difference between the earliest and latest finish dates.

Critical path:
• Note the path through network with zero floats
• Critical path: any delay in an activity on this path will delay whole project
• Can there be more than one critical path?
• Can there be no critical path?
• Sub-critical paths
Yes, there could be more than one critical path if the two longest paths through the
network were of equal length.

Where the target completion date for the project was imposed rather than calculated
from the earliest finish dates, it might be later that the earliest finish date. In this case
there would be no chains of activities with zero floats

The durations of activities are only estimates to start with. As the project proceeds,
the estimates will be replaced by actual durations which could be different. This
could change the sequence of activities identified as the critical path. Sub-critical
paths are chains of activities, not on the planned critical path, but which have small
floats and which could easily become the critical path as the project develops.

Free and interfering float:

Total float = LF – ES – duration (or LS-ES or LF-EF)
Free float = ES for following activity less EF for the current
Interfering float = total float – free float

Shortening the project duration:

• Reduce the duration of task
• Applying more resources to the task
• Working overtime
• Procuring additional staff
• Look on critical path

Identifying Critical Activities:

• The critical path identifies those activities which are critical to the end of the
project.
• Activities may use up some of their float
• Non-critical activities may become critical

Additional Example:

Sr. No. Activity Name Predecessor Duration (days)

1 A - 3
2 B A 4
3 C A 2
4 D B 5
5 E C 1
6 F C 2
7 G D, E 4
8 H F, G 3

Activity on Arrow Network:

Rule and Conventions:

• One start node
• One end node
• Node has no duration
• Time moves from left to right
• Node are numbered sequentially
• No loops
• No dangles

Network Analysis:
• Forward pass
 • Backward pass

Critical path:

• It is the longest path through the network.

***************************
 Chapter Seven

Risk management
This set of overheads looks at risk management.

It discusses the definition of ‘risk’ and ‘risk management’.

Some taxonomies of risk are touched upon.
The main steps in risk management are then presented in turn:
1. Risk identification
2. Risk analysis and prioritization
3. Risk planning
4. Risk monitoring – this is not dealt with properly because of time and space
constraints

The PERT risk technique is touched upon and also the critical chain concepts.

Risk management:
• Definition of ‘risk’ and ‘risk management’
• Some ways of categorizing risk
• Risk management
– Risk identification – what are the risks to a project?
– Risk analysis – which ones are really serious?
– Risk planning – what shall we do?
– Risk monitoring – has the planning worked?
• We will also look at PERT risk and critical chains

Some definitions of risk:

Note that good risk management may identify situations where an unexpected future
event might present an opportunity to be exploited e.g. a task being less difficult
than expected.

‘the chance of exposure to the adverse consequences of future events’ PRINCE2

‘an uncertain event or condition that, if it occurs, has a positive or negative effect on a
project’s objectives’ PM-BOK
• Risks relate to possible future problems, not current ones
• They involve a possible cause and its effect(s) e.g. developer leaves > task
delayed

Categories of risk:
This is based on Lyytinen’s sociotechnical model of risk
• Actors relate to all those involved in the project including both developers,
users and managers e.g. a risk could be that high staff turnover leads to
information of importance to the project being lost
• Technology – both that used to implement the project and that embedded in
the project deliverables – risk could be that the technologies selected are not
in fact appropriate.
• Structure – this includes management procedures, risk here is that a group
who need to carry out a particular project task are not informed of this need
because they are not part of the project communication network
• Tasks – the work to be carried out. A typical risk is that the amount of effort
needed to carry out the task is underestimated.
A risk could be well belong to more than one of the four areas – for example,
estimates being wrong could be influenced by problems with actors (e.g. lack of
experience with a technical domain) or the structure (over optimism of managers
keen to win work).

Risk Management Approaches:

• Proactive:
– The proactive approaches try to anticipate the possible risks that the
project is susceptible to.
– After identifying the possible risks, actions are taken to eliminate the
risks.
• Reactive:
– Reactive approaches take no action until an unfavourable event occurs.
– Once an unfavourable event occurs, these approaches try to contain
the adverse effects associated with the risk and take steps to prevent
future occurrence of the same risk events.

A framework for dealing with risk:

The planning for risk includes these steps:
• Risk identification – what risks might there be?
• Risk analysis and prioritization – which are the most serious risks?
• Risk planning – what are we going to do about them?
• Risk monitoring – what is the current state of the risk?
Risk identification:
Approaches to identifying risks include:
• Use of checklists – usually based on the experience of past projects
• Brainstorming – getting knowledgeable stakeholders together to pool
concerns
• Causal mapping – identifying possible chains of cause and effect

Boehm’s top 10 development risks:

Barry Boehm surveyed software engineering project leaders to find out the main risks
that they had experienced with their projects. For each risk, some risk reduction
techniques has been suggested.

Risk Risk reduction techniques

Personnel shortfalls Staffing with top talent; job matching; teambuilding;

training and career development; early scheduling of key
personnel

Unrealistic time and cost Multiple estimation techniques; design to cost; incremental
estimates development; recording and analysis of past projects;
standardization of methods

Developing the wrong Improved software evaluation; formal specification

software functions methods; user surveys; prototyping; early user manuals

Developing the wrong user Prototyping; task analysis; user involvement

interface

Gold plating Requirements scrubbing, prototyping,

design to cost

Late changes to Change control, incremental development

requirements

Shortfalls in externally Benchmarking, inspections, formal specifications,

supplied components contractual agreements, quality controls

Shortfalls in externally Quality assurance procedures, competitive design etc

performed tasks

Real time performance Simulation, prototyping, tuning

problems

‘Gold plating‘ refers to inclusion of features that in fact are unnecessary and which
end up never actually being used.
Risk prioritization:
Risk exposure (RE)
= (potential damage) x (probability of occurrence)
Ideally
Potential damage: a money value e.g. a flood would cause £0.5 millions of damage
Probability 0.00 (absolutely no chance) to 1.00 (absolutely certain) e.g. 0.01 (one in
hundred chance)
RE = £0.5m x 0.01 = £5,000
Crudely analogous to the amount needed for an insurance premium

If there were 100 people chipping in £5,000 each, there would be enough for the 1 in
100 chance of the flooding. If there were 2 floods then the system collapses!
In practice, with project risks, these quantitative approaches are usually impractical
and more qualitative approaches are used instead. See the next overhead.

Risk probability: qualitative descriptors:

Managers would be happier identifying an approximate range rather than a precise
probability.
Probability level Range

High Greater than 50% chance of happening

Significant 30-50% chance of happening

Moderate 10-29% chance of happening

Low Less than 10% chance of happening

Qualitative descriptors of impact on cost and associated range values:

Similar tables can be produced for the impact on project duration and on the quality
of project deliverables.
The problem with the qualitative approach is how do you combine the judgements
about probability and impact – you can’t multiply them together.
Impact level Range

High Greater than 30% above budgeted

expenditure
Significant 20 to 29% above budgeted expenditure

Moderate 10 to 19% above budgeted expenditure

Low Within 10% of budgeted expenditure.
Probability impact matrix:

R1, R2 etc refer to particular risks. They are located on the grid according to the
likelihood and impact ratings that have been allocated to them. A zone around the
top right hand corner of the grid can be designated and risks falling within that zone
are treated as requiring urgent action.

Risk planning:
Risks can be dealt with by:
• Risk acceptance
• Risk avoidance
• Risk reduction
• Risk transfer
• Risk mitigation/contingency measures

Risk acceptance – the cost of avoiding the risk may be greater than the actual
cost of the damage that might be inflicted

Risk avoidance – avoid the environment in which the risk occurs e.g. buying an
OTS application would avoid a lot of the risks associated with software
development e.g. poor estimates of effort.

Risk reduction – the risk is accepted but actions are taken to reduce its likelihood
e.g. prototypes ought to reduce the risk of incorrect requirements

Risk transfer – the risk is transferred to another person or organization. The risk of
incorrect development estimates can be transferred by negotiating a fixed price
contract with an outside software supplier.
 Risk mitigation – tries to reduce the impact if the risk does occur e.g. taking
backups to allow rapid recovery in the case of data corruption

Risk reduction leverage:

Risk reduction leverage =
(REbefore- REafter)/ (cost of risk reduction)
REbeforeis risk exposure before risk reduction e.g. 1% chance of a fire causing £200k
damage
REafter is risk exposure after risk reduction e.g. fire alarm costing £500 reduces
probability of fire damage to 0.5%
RRL = (1% of £200k)-(0.5% of £200k)/£500 = 2
RRL > 1.00 therefore worth doing

You could think in terms of the analogy to insurance. An insurance company might
reduce the fire insurance premium from £2k to £1k on condition that a fire alarm is
installed. The insured would save £1k a year by investing £500 so it would be worth
doing.

Probability chart:
An estimate of activity duration is realistically a range of values clustered around the
most likely value are trailing off on either side of this central value. How can we take
account of this in project planning? An answer might be the PERT risk technique.

Using PERT to evaluate the effects of uncertainty:

Three estimates are produced for each activity
• Most likely time (m)
• Optimistic time (a)
• Pessimistic (b)
• ‘expected time’ te = (a + 4m +b) / 6
• ‘activity standard deviation’ S = (b-a)/6
Most likely time (m) the time we would expect the task to take normally

Optimistic time (a) the shortest time that could be realistically be expected

Pessimistic (b) worst possible time (only 1% chance of being worse, say)
 Some straightforward activities (data input of standing data might perhaps be an
example) might have little uncertainty and therefore have a low standard
deviation, while others (software design, for instance?) have more uncertainty and
would have a bigger standard deviation.

A chain of activities:

Task a M b t S
e

A 10 12 16 ? ?
B 8 10 14 ? ?

Fill the missing gaps?

Task A te = (10+ (12 x 4) + 16)/ 6 i.e. 12.66 s = (16-10)/6 i.e. 1
Task B te = (8 + (10 x 4) + 14)/ 6 i.e. 10.33 s = (14-8)/6 i.e. 1
Task C Te = (20 + (24 x 4) + 38)/6 i.e. 25.66 s = (38-20)/6 i.e. 3
• What would be the expected duration of the chain A + B + C?
• Answer: 12.66 + 10.33 + 25.66 i.e. 48.65
• What would be the standard deviation for A + B+ C?
• Answer: square root of (12 + 12 + 32) i.e. 3.32

Assessing the likelihood of meeting a target:

• Say the target for completing A+B+C was 52 days (T)
• Calculate the z value thus
z = (T – te)/s
• In this example z = (52-48.33)/3.32 i.e. 1.01
• Look up in table of z values – see next overhead

The target, in this case 52 days, is one that could be based on an externally imposed
deadline e.g. the start of the London Olympics. The STANDARDIZE calculation in
Excel can be used to calculate the Z value.

Graph of z values:
There is about a 15% chance of not meeting the target of 52 days. The Excel
NORMSDIST can be used to do this calculation.

Monte Carlo Simulation:

• An alternative to PERT.
• A class of general analysis techniques:
– Valuable to solve any problem that is complex, nonlinear, or involves
more than just a couple of uncertain parameters.
• Monte Carlo simulations involve repeated random sampling to compute the
results.
• Gives more realistic results as compared to manual approaches.

Steps of a Monte Carlo Analysis:

1. Assess the range for the variables being considered.
2. Determine the probability distribution of each variable.
3. For each variable, select a random value based on the probability distribution.
4. Run a deterministic analysis or one pass through the model.
5. Repeat steps 3 and 4 many times to obtain the probability distribution of the
model’s results.

Critical chain concept:

Note that this plan tends to start activities as early as possible – for example see
Activities E and H. While the float on these activities could be used as a buffer if they
were late, other activities e.g. F. although of substantial duration do not have the
same kind of cushion. In the case of F, the planner would have to make any safety
buffer part of the core activity duration.

One problem with estimates of task duration:

• Estimators add a safety zone to estimate to take account of possible
difficulties
• Developers work to the estimate + safety zone, so time is lost
• No advantage is taken of opportunities where tasks can finish early – and
provide a buffer for later activities
Developers will tend to start activities as late as is compatible with meeting the target
date as they often have other urgent work to be getting on with in the mean time.

One answer to this:

1. Ask the estimators for two estimates
– Most likely duration: 50% chance of meeting this
– Comfort zone: additional time needed to have 95% chance
2. Schedule all activities using most likely values and starting all activities on
latest start dates
This approach means that the ‘safety buffer’ in the estimate for an activity is moved
from the individual developer to the project as a whole.

Most likely and comfort zone estimates:

 3. Identify the critical chain – same a critical path but resource constraints also
taken into account
4. Put a project buffer at the end of the critical chain with duration 50% of sum
of comfort zones of the activities on the critical chain.
5. Where subsidiary chains of activities feed into critical chain, add feeding buffer
6. Duration of feeding buffer 50% of sum of comfort zones of activities in the
feeding chain
7. Where there are parallel chains, take the longest and sum those activities

Plan employing critical chain concepts:

Executing the critical chain-based plan:

• No chain of tasks is started earlier than scheduled, but once it has started is
finished as soon as possible
• This means the activity following the current one starts as soon as the current
one is completed, even if this is early – the relay race principle
Buffers are divided into three zones:
• Green: the first 33%. No action required
• Amber : the next 33%. Plan is formulated
• Red : last 33%. Plan is executed.

*******************************
 Chapter 8
Resource Allocation

Schedules:

• Activity schedule - indicating start and completion dates for each activity
• Resource schedule - indicating dates when resources needed + level of
resources
• Cost schedule showing accumulative expenditure

Resources:
• These include
– labour
– equipment (e.g. workstations)
– materials
– space
– services
• Time: elapsed time can often be reduced by adding more staff
• Money: used to buy the other resources

A key point is that money (by definition) is the means by which one resource can be
converted to another. However in practice this may be problematic because of
resource constraints e.g. staff need time to become expert in a new technology
regardless of the amount of money that might be available to buy expertise.

Resource allocation:
• Identify the resources needed for each activity and create a resource
requirement list
• Identify resource types - individuals are interchangeable within the group (e.g.
‘VB programmers’ as opposed to ‘software developers’)
• Allocate resource types to activities and examine the resource histogram.
Note that at this point we have to assume that we are dealing with, for example,
‘standard’ software developers who have an average productivity. When we allocate
actual people we may find that we have a trainee or a super-expert and this will
affect productivity. A short-coming in productivity in an individual might be
compensated for by a lower cost (as would be expected with trainees).

In the example in the text we start by scheduling every activity to start at the earliest
possible date. However in Lecture/Chapter 7, in the section on the critical chain
technique it was suggested that we plan to start activities as late as possible.
Whatever the starting procedure, we then need to deal with resource clashes.

Resource histogram: systems analysts

The resource histogram helps us identify where the demand for a resource exceeds
the supply.
If we use a tool such as MS Project, the tool will generate the resource histograms for
us.

Resource smoothing:
• It is usually difficult to get specialist staff who will work odd days to fill in gaps
– need for staff to learn about application etc
• Staff often have to be employed for a continuous block of time
• Therefore desirable to employ a constant number of staff on a project – who
as far as possible are fully employed
• Hence need for resource smoothing

This shows an attempt to smooth the previous resource histogram. Note that in
order to do this, we have had to. Add another week to the schedule.

Resource clashes:
• Where same resource needed in more than one place at the same time
• can be resolved by:
– delaying one of the activities
• taking advantage of float to change start date
 • delaying start of one activity until finish of the other activity that
resource is being used on - puts back project completion
– moving resource from a non-critical activity
– bringing in additional resource - increases costs

Prioritizing activities:
Where more than one activity is competing for the same limited resource at the
same time then those activities need to be prioritized.

There are two main ways of doing this:

• Total float priority – those with the smallest float have the highest priority
• Ordered list priority – this takes account of the duration of the activity as well
as the float.

Burman’s priority list:

Give priority to:
• Shortest critical activities
• Other critical activities
• Shortest non-critical activities
• Non-critical activities with least float
• Non-critical activities

Resource usage:
• Need to maximise %usage of resources i.e. reduce idle periods between tasks
• Need to balance costs against early completion date
• Need to allow for contingency

Critical path:

• Scheduling resources can create new dependencies between activities – recall

critical chains
• It is best not to add dependencies to the activity network to reflect resource
constraints
– Makes network very messy
– A resource constraint may disappear during the project, but link
remains on network
• Amend dates on schedule to reflect resource constraints

The point about not adding links to the network to deal with resource constraints is
not in the text, but is based on practical experience. The notation for activity
networks does not tell you why one activity might be dependent on the completion
of another.
Allocating individuals to activities:
The initial ‘resource types’ for a task have to be replaced by actual individuals.
Factors to be considered:
• Availability
• Criticality
• Risk
• Training
• Team building – and motivation

Availability – who is free? Note that this will change during the course of the project
as some tasks are completed earlier or later than planned

Criticality – You would want to put your more experienced, ‘safer’, staff on the critical
activities.

Risk – this is similar to the point above, but some activities could be off the critical
path but still have risks e.g. to the quality of subsequent products.

Training – despite concerns about minimizing risk, it is healthy to take some risks in
order to develop staff capabilities by allocating challenging tasks to relatively
inexperienced staff.

Team-building – identifying people who work well together can pay dividends;
chopping and changing plans all the time may in theory optimize project
performance, but can in practice be demotivating for staff.

Cost schedules:
Cost schedules can now be produced:
Costs include:
• Staff costs
• Overheads
• Usage charges

Staff costs – includes not just salary, but also social security contributions by the
employer, holiday pay etc. Timesheets are often used to record actual hours spent on
each project by an individual. One issue can be how time when a staff member is
allocated and available to the project, but is not actually working on the project, is
dealt with.

Overheads e.g. space rental, service charges etc. Some overheads might be directly
attributable to the project; in other cases a percentage of departmental overheads
may be allocated to project costs.
Usage charges – some charges can be on a ‘pay as you go’ basis e.g. telephone
charges, postage, car mileage – at the planning stage an estimate of these may have
to be made

Cost profile:

This shows how much is going to be spent in each week. This could be important
where an organization allocates project budgets by financial year or quarter and the
project straddles more than one of these financial periods

Accumulative costs:
The project manager will also be concerned about planned accumulative costs. This
chart can be compared to the actual accumulative costs when controlling the project
to assess whether the project is likely to meet its cost targets.

Balancing concerns:
Successful project scheduling is not a simple sequence.
Because of the inter-linking of different concerns project planning will need to be
iterative. The consequences of decisions will need to carefully assessed and plans
adjusted accordingly.
 *******************************************************************

Graded Questions :

Chapter 06
Activity Planning
1. Describe Activity networks.
2. Differentiate between Work based, Product based and Hybrid approach.
3. Differentiate between PERT (Program Evaluation Review Techniques) and CPM
(Critical Path Method).
4. What are the rules of Constructing Precedence Network? Give example.
5. What are the different types of links between activities?
6. Differentiate between Forward and Backward Pass.
7. How will you identify identifying the Critical Path in a Activity Network?

Chapter 07
Risk management
1. Define Risk Management.
2. What are the different Categories of risk?
3. What are the different Risk Management Approaches?
4. What are the different Boehm’s top 10 development risks?
5. Explain Risk planning.
6. Define Risk reduction leverage.
7. Explain Monte Carlo Simulation.
 Chapter 8

Resource Allocation
1. Explain Resource allocation.
2. Explain Resource smoothing with suitable diagram.
3. Give the Burman’s priority list.
4. How do you prepare Cost schedules?