Smartworld.asia Specworld.

in

31






3
PROJECT SCHEDULING
Unit Structure:
3.1 Developing the Project Schedule
1.1 3.1.1. Schedule Inputs
1.2 3.1.2. Scheduling Tools
3.2 Project Management Software Tools
1.3 3.2.1. Allocate Resources to the Tasks
1.4 3.2.2. Identify Dependencies
1.5 3.2.3 Create the Schedule
2 3.2.4 RISK PLAN
3.3 Developing the Project Budget.
3.3.1 Costing
3.3.2 Budgeting
3.4 Monitoring and Controlling the Project
3.4.1 Checkpoints
3.4.1.1 Checkpoint design
3.4.2 Handling significant deviations from plan
3.4.3 Monitoring System Performance
3.5. The Project Communication Plan
3.5.1 Two Types of Communications Plans for Your Project
3.5.2 Building Your Plan
3.6 Project Metrics
2.1.1 3.6.1 Reasons for Project Metrics
3.6.2 Key Project Metrics
3.6.3 Developing Project Metrics
3.7 Reporting Performance & Progress

1
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

32

3.7.1 Project Status Report

3.1 DEVELOPING THE PROJECT SCHEDULE

Can you imagine starting a long car trip to an unfamiliar

destination without a map or navigation system? You're pretty sure
you have to make some turns here and there, but you have no idea
when or where, or how long it will take to get there. You may arrive
eventually, but you run the risk of getting lost, and feeling
frustrated, along the way.

Essentially, driving without any idea of how you're going to

get there is the same as working on a project without a schedule.
No matter the size or scope of your project, the schedule is a key
part of project management. The schedule tells you when each
activity should be done, what has already been completed, and the
sequence in which things need to be finished.

Luckily, drivers have fairly accurate tools they can use.

Scheduling, on the other hand, is not an exact process. It's part
estimation, part prediction, and part 'educated guessing.'

Because of the uncertainty involved, the schedule is

reviewed regularly, and it is often revised while the project is in
progress. It continues to develop as the project moves forward,
changes arise, risks come and go, and new risks are identified. The
schedule essentially transforms the project from a vision to a time-
based plan.

Schedules also help you do the following:

 They provide a basis for you to monitor and control project

activities.
 They help you determine how best to allocate resources so
you can achieve the project goal.
 They help you assess how time delays will impact the
project.
 You can figure out where excess resources are available to
allocate to other projects.
 They provide a basis to help you track project progress.

Project managers have a variety of tools to develop a project

schedule - from the relatively simple process of action planning for
small projects, to use of Gantt Charts and Network Analysis for
large projects. Here, we outline the key tools you will need for
schedule development.

2
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

33

2.2 3.1.1. Schedule Inputs:

2.3
You need several types of inputs to create a project schedule:
 Personal and project calendars - Understanding working
days, shifts, and resource availability is critical to completing
a project schedule.
 Description of project scope - From this, you can
determine key start and end dates, major assumptions
behind the plan, and key constraints and restrictions. You
can also include stakeholder expectations, which will often
determine project milestones.

 Project risks - You need to understand these to make sure

there's enough extra time to deal with identified risks - and
with unidentified risks (risks are identified with thorough Risk
Analysis).

 Lists of activities and resource requirements - Again, it's

important to determine if there are other constraints to
consider when developing the schedule. Understanding the
resource capabilities and experience you have available - as
well as company holidays and staff vacations - will affect the
schedule.

A project manager should be aware of deadlines and

resource availability issues that may make the schedule less
flexible.

2.4 3.1.2. Scheduling Tools:

Here are some tools and techniques for combining these

inputs to develop the schedule:

 Schedule Network Analysis - This is a graphic

representation of the project's activities, the time it takes to
complete them, and the sequence in which they must be
done. Project management software is typically used to
create these analyses - Gantt charts and PERT Charts are
common formats.

 Critical Path Analysis - This is the process of looking at all

of the activities that must be completed, and calculating the
'best line' - or critical path - to take so that you'll complete the
project in the minimum amount of time. The method
calculates the earliest and latest possible start and finish
times for project activities, and it estimates the dependencies
among them to create a schedule of critical activities and
dates.

3
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

34

 Schedule Compression - This tool helps shorten the total

duration of a project by decreasing the time allotted for
certain activities. It's done so that you can meet time
constraints, and still keep the original scope of the project.
You can use two methods here:

 Crashing - This is where you assign more resources to an

activity, thus decreasing the time it takes to complete it. This
is based on the assumption that the time you save will offset
the added resource costs.

 Fast-Tracking - This involves rearranging activities to allow

more parallel work. This means that things you would
normally do one after another are now done at the same
time. However, do bear in mind that this approach increases
the risk that you'll miss things, or fail to address changes.

3.2 PROJECT MANAGEMENT SOFTWARE TOOLS

There are many project scheduling software products which

can do much of the tedious work of calculating the schedule
automatically, and plenty of books and tutorials dedicated to
teaching people how to use them. However, before a project
manager can use these tools, he should understand the concepts
behind the work breakdown structure (WBS), dependencies,
resource allocation, critical paths, Gantt charts and earned value.
These are the real keys to planning a successful project.
2.5 3.2.1. Allocate Resources to the Tasks:
The first step in building the project schedule is to identify
the resources required to perform each of the tasks required to
complete the project. A resource is any person, item, tool, or
service that is needed by the project that is either scarce or has
limited availability.

Many project managers use the terms “resource” and

“person” interchangeably, but people are only one kind of resource.
The project could include computer resources (like shared
computer room, mainframe, or server time), locations (training
rooms, temporary office space), services (like time from
contractors, trainers, or a support team), and special equipment
that will be temporarily acquired for the project. Most project
schedules only plan for human resources—the other kinds of
resources are listed in the resource list, which is part of the project
plan.

One or more resources must be allocated to each task. To

do this, the project manager must first assign the task to people
who will perform it. For each task, the project manager must identify
one or more people on the resource list capable of doing that task

4
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

35

and assign it to them. Once a task is assigned, the team member

who is performing it is not available for other tasks until the
assigned task is completed. While some tasks can be assigned to
any team member, most can be performed only by certain people.
If those people are not available, the task must wait.
2.6 3.2.2. Identify Dependencies:
Once resources are allocated, the next step in creating a
project schedule is to identify dependencies between tasks. A task
has a dependency if it involves an activity, resource, or work
product that is subsequently required by another task.
Dependencies come in many forms: a test plan can’t be executed
until a build of the software is delivered; code might depend on
classes or modules built in earlier stages; a user interface can’t be
built until the design is reviewed. If Wideband Delphi is used to
generate estimates, many of these dependencies will already be
represented in the assumptions. It is the project manager’s
responsibility to work with everyone on the engineering team to
identify these dependencies. The project manager should start by
taking the WBS and adding dependency information to it: each task
in the WBS is given a number, and the number of any task that it is
dependent on should be listed next to it as a predecessor. The
following figure shows the four ways in which one task can be
dependent on another.

Figure 3.1: Task Dependency

2.7 3.2.3 Create the Schedule:
Once the resources and dependencies are assigned, the
software will arrange the tasks to reflect the dependencies. The
software also allows the project manager to enter effort and
duration information for each task; with this information, it can
calculate a final date and build the schedule.

5
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

36

The most common form for the schedule to take is a Gantt chart.
The following figure shows an example:

Figure 3.2: Gantt Chart

Each task is represented by a bar, and the dependencies

between tasks are represented by arrows. Each arrow either points
to the start or the end of the task, depending on the type of
predecessor. The black diamond between tasks D and E is a
milestone, or a task with no duration. Milestones are used to show
important events in the schedule. The black bar above tasks D and
E is a summary task, which shows that these tasks are two
subtasks of the same parent task. Summary tasks can contain
other summary tasks as subtasks. For example, if the team used
an extra Wideband Delphi session to decompose a task in the
original WBS into subtasks, the original task should be shown as a
summary task with the results of the second estimation session as
its subtasks.

6
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

37

The following figure shows an example of a Gantt chart created in

Microsoft Projects :

Figure 3.3 Gantt Chart drawn using Microsoft Project.

4
5

6 3.2.4 RISK PLAN

A risk plan is a list of all risks that threaten the project, along
with a plan to mitigate some or all of those risks. Some people say
that uncertainty is the enemy of planning. If there were no
uncertainty, then every project plan would be accurate and every
project would go off without a hitch. Unfortunately, real life
intervenes, usually at the most inconvenient times. The risk plan is
an insurance policy against uncertainty.

Once the project team has generated a final set of risks, they
have enough information to estimate two things: a rough estimate
of the probability that the risk will occur, and the potential impact of
that risk on the project if it does eventually materialize. The risks

7
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

38

must then be prioritized in two ways: in order of probability, and in

order of impact. Both the probability and impact are measured
using a relative scale by assigning each a number between 1
and 5.

These numbers are arbitrary; they are simply used to

compare the probability or impact of one risk with another, and do
not carry any specific meaning. The numbers for probability and
impact are assigned to each risk; a priority can then be calculated
by multiplying these numbers together. It is equally effective to
assign a percentage as a probability (i.e. a risk is 80% likely to
occur) and a real duration for impact (i.e. it will cost 32 man-hours if
the risk occurs). However, many teams have trouble estimating
these numbers, and find it easier to just assign an arbitrary value
for comparison.

Many people have difficulty prioritizing, but there is a simple

technique that makes it much easier. While it’s difficult to rank all of
the risks in the list at once, it is usually not hard to pick out the one
that’s most likely to occur. Assign that one a probability of 5. Then
select the one that’s least likely to occur and assign that one a
probability of 1. With those chosen, it’s much easier to rank the
others relative to them. It might help to find another 5 and another
1, or if those don’t exist, find a 4 and a 2. The rest of the
probabilities should start to fall in place. Once that’s done, the same
can be done for the impact.

After the probability and impact of each risk have been

estimated, the team can calculate the priority of each risk by
multiplying its probability by its impact. This ensures that the
highest priority is assigned to those risks that have both a high
probability and impact, followed by either high-probability risks with
a low impact or low-probability risks with a high impact. This is
generally the order in which a good project manager will want to try
to deal with them: it allows the most serious risks to rise to the top
of the list.

This can be very easily done using tools like Microsoft

Project or even by using any spreadsheet package that provides
some basic statistical functions.

3.3 DEVELOPING THE PROJECT BUDGET.

If scheduling is an art then costing could be considered a

black art. Some projects are relatively straightforward to cost but
most are not. Even simple figures like the cost per man/hour of
labour can be difficult to calculate.

8
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

39

Accounting, costing and budgeting are extensive topics in

themselves. Some fundamental principles to keep in mind are
derived from accounting practices:

• The concept of 'prudence' – you should be pessimistic in your

accounts (“anticipate no profit and provide for all possible
losses”).Provide yourself with a margin for error and not just show
the best possible financial position. It’s the old maxim: promise low-
deliver / high once again

• The 'accruals' concept- revenue and costs are accrued or

matched with one another and are attributed to the same point in
the schedule. For example if the costs of hardware are in your
budget at the point where you pay the invoice, then ALL the costs
for hardware should be “accrued” when the invoice is received.

• The ‘consistency’ concept. This is similar to accruals but it

emphasises consistency over different periods. If you change the
basis on which you count certain costs you either need to revise all
previous finance accounts in line with this or annotate the change
appropriately so people can make comparisons on a like-for-like
basis.

Note that the principles are listed in order of precedence. If the

principle of consistency comes into conflict with the principle of
prudence, the principle of prudence is given priority.

3.3.1 Costing:

At a basic level the process of costing is reasonably simple.

You draw up a list of all your possible expenditure and put a
numerical value against each item; the total therefore represents
the tangible cost of your project. You may also however need to
consider “intangible” items.

Tangible costs:

• Capital Expenditure – any large asset of the project which is

purchased outright. This usually includes plant, hardware, software
and sometimes buildings although these can be accounted for in a
number of ways.

• Lease costs – some assets are not purchased outright but are
leased to spread the cost over the life of the project. These should
be accounted for separately to capital expenditure since the project
or company does not own these assets.

• Staff costs – all costs for staff must be accounted for and this
includes (but is not limited to): salary and pension (superannuation)

9
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

40

costs; insurance costs; recruitment costs; anything which can be

tied directly to employing, training and retaining staff.

• Professional services –all large-scale projects require the input

of one or more professional groups such as lawyers or
accountants. These are normally accounted for separately since a
close watch needs to be kept upon expenditure in this area.
Without scrutiny the costs of a consultant engineer, accountant or
lawyer can quickly dwarf other costs.

• Supplies and consumables – regular expenditure on supplies is

often best covered by a single item in your budget under which
these figures are accrued. They are related to overhead below.

• One-off costs – one-off costs apply to expenditure which is not

related to any of the above categories but occurs on an irregular
basis. Staff training might be an example. While it might be
appropriate to list this under staff costs you might wish to track it
independently as an irregular cost. The choice is yours but the
principles of prudence and consistency apply.

• Overheads – sometime called indirect costs, these are costs

which are not directly attributable to any of the above categories but
never-the-less impact upon your budget. For example it may not be
appropriate to reflect the phone bill for your project in staff costs,
yet this still has to be paid and accounted for. Costing for
overheads is usually done as a rough percentage of one of the
other factors such as “staff costs”.

Intangible costs
It has become fashionable to account for “intangible” assets on the
balance sheets of companies and possibly also projects. The
argument goes like this: some contributions to a project are
extremely valuable but cannot necessarily have a tangible value
associated with them. Should you then account for them in the
budget or costing? The “prudence” principle says yes but
practicality says “no”. If you are delving this murky area of
accountancy you should seek professional help and advice.

Typical things you might place in the budget under intangibles are
“goodwill” and “intellectual property”. Personnel-related figures are
a frequent source of intangible assets and so you might find things
like “management team”, “relationships” and “contacts” on an
intangibles balance sheet.

3.3.2 Budgeting:

Once you have costed your project you can then prepare an
appropriate budget to secure the requisite funds and plan your cash

10
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

41

flow over the life of the project. An accurate cost model will of
course entail a fairly detailed design or at the very least
requirement specification so that you can determine your scope of
work. This is normally completed well into the design phase of the
project.

You must be extremely careful with initial estimates and

always follow the “promise low / deliver high” commandment.

Costing and budgeting follow the iterative life cycle as do

other tasks within the project. As you refine your design, so you will
need to refine the costing which is based upon it.

As in scheduling, you need to build in adequate contingency

(reserves) to account for unexpected expenditure. For example, if
due to a failure in the critical path a task is delayed and a milestone
(like software purchase) falls due in the month after it was
scheduled. This can wreck your carefully planned cash flow. But if
you have carefully budgeted your project then variations should be
relatively easy to spot and cope with as they arise.

Just as in scheduling you should have regular budget

reviews which examine the state of your finances and your
expenditure to date and adjust the planned budget accordingly.

Regardless of circumstance, a number of basic philosophies

can help your budgeting immensely by protecting it from subjective
review. By understanding concepts, and making sure that everyone
involved understands them, you’ll be on the right track to an
accurate projection:
 Project costs and project budgets are two different things.
Always start by identifying project costs.
 Project costs are not defined solely in monetary amounts.
Include actual amounts, with shipping and taxes, for
software or hardware purchases that must be made. If you’re
pro-rating the costs of using pre-existing hardware and
software tools, include it in number of hours. Likewise,
developer effort costs are recorded in hours, not dollars.
 Once you’ve laid out your costs, identify your risks and
assign a percentage reflecting how much each risk factor
may affect the project as a whole, or a portion of the project.
Each development team should have a risk value assigned
to it, to cover reasonable costs such as hiring the occasional
contractor to get a timeline under control, unforeseen
overtime, and so on.
 Your budget, then, is the total of the costs, as transcribed
into a monetary figure, plus the total risk percentage of that

11
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

42

cost. Define conversion values that you use to represent

equipment pro-rating and development times.
 Your budget is not an invoice. Once you’ve determined the
hard figures involved, leave it up to your company’s business
representatives to make adjustments for profits. Make sure
they understand your figures reflect actual costs.
 A budget should always be labeled as an estimate, until it is
finalized and approved. This helps to manage expectations
and prevent miscommunications from being written in stone.
 A single person does not create a budget. At the very least,
all of the following should be consulted: lead developer,
project manager, and a business-side driver.

3.4 MONITORING AND CONTROLLING THE PROJECT

To appreciate how project control works you must first

understand that, despite all the effort devoted to developing and
gaining commitment to a plan, there is little chance that the
resulting project will run precisely according to that plan.

This doesn’t mean that you will fail to achieve the objectives
of the plan – on the contrary, you must have a very high level of
confidence that you can achieve those objectives and deliver the
full scope, fit for purpose, on time and to budget.

The plan describes what you would like to do but it models

just one of the infinite number of routes from where you are now to
where you want to be. In practice your project will follow a different
route to the one shown in your plan, you don’t know which one, but
you will need control to make sure it is a route that takes you to
where you need to be, when you need to be there, and at a cost
you can afford.

The power of the plan is that it gives you a baseline against

which you can compare actual achievement, cost and time and
determine the amount of deviation from plan and hence take
corrective action if required.

The essential requirement for control is to have a plan

against which progress can be monitored to provide the basis for
stimulating management action if the plan is not being followed.
Control then becomes a regular, frequent iteration
of: Creating the right environment for control.

12
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

43

Monitoring Taking Corrective

Planning & action &
evaulation Reporting

Figure 3.4 : Project Control

The basic requirements for control are:

a plan that is:
- realistic
- credible
- detailed enough to be executed
- acceptable to those who must execute it (Project Manager
and Project Teams)
- approved by those who are accountable for its
achievement (the SRO/ Project Board);
 a process for monitoring and managing progress and
resource usage;
 a project management organisation of appropriately skilled
people with sufficient authority and time to plan, monitor,
report, take decisions and deal with exceptions;
 a process to make minor corrections and adjustments to
deal with minor deviations and omissions from the plan;
 the commitment of those who will provide the resources
indicated in the plan ( SRO, Project Board, Stakeholders and
resource ‘owners’ in the parent organisation and its related
agencies);
 explicit authority to proceed granted by those who are
accountable for the project.

In all but the smallest or shortest projects you should think

about how to break your project into manageable ‘chunks’ called
stages. Every project will have a minimum of two stages – the first
being Project Initiation. A large project may have a number of
stages, each of which has its own stage plan. When designing your
project’s stage structure look for points where the Project manager
should:

 review achievements to date and assess project viability

 take key decisions outside the level of authority of the
Project Manager

13
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

44

 approve a more detailed plan for the next phase of work

commit resources in accordance with the project or stage
plan
 assess the impact of some significant external event that will
influence the project (eg: legislation, decision point in other
project, review of business operation).

The Project Manager will also be able to identify stage

boundaries by thinking about how far ahead is it sensible to plan in
the fine detail needed for day to day control. In practice, the
detailed plan for a stage will be produced towards the end of the
preceding stage, when the information needed for planning is
available.

3.4.1 Checkpoints:

Checkpoint reports are produced by team managers /

leaders for the Project Manager who needs to have early warning
of deviations from plan and other problems affecting the project
team. Checkpoints provide regular, frequent comparison of actual
progress, resource usage and forecasts against plans. They
provide information for the Project Manager to apply control, eg by
correcting small deviations from the plan. The basic purpose of a
checkpoint is to answer the questions:
 ‘What is going according to plan?’
 ‘What is not going to plan?’
 ‘What is likely not to go to plan?’

Checkpoints are essential controls – missed checkpoints are

usually an early sign of a failing project. The information gathered
at checkpoints should be documented in Checkpoint Reports and
used in the preparation of Highlight Reports.

3.4.1.1 Checkpoint design:

There are many different ways of conducting Checkpoints -

they might be, but do not have to be, achieved through written
reports and meetings. Each project must use an approach that
balances the need for communication and control against too much
management interference in work in progress. Checkpoint design
will cover:
 Frequency of reporting
 Timing (eg: time and day of week)
 Information required from team members (oral reports,
timesheets, written reports)
 Method of conducting checkpoint (eg informal chats, formal
meetings, phone, fax, email)

14
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

45

 Participation (Project Manager? Project Assurance? Team

Members? Suppliers?)
 Content of a report to be used to communicate the findings
of the Checkpoint.

The Project Manager should set Checkpoint frequency

depending on the intensity of activity. Checkpoint frequencies
ranging from fortnightly (eg during procurement phases) down to
daily (eg during implementation and training) are possible within the
same project.

3.4.2 Handling significant deviations from plan:

Project Board members are usually senior managers with

limited time to devote management of the project. In order to
achieve ‘management by exception’ the Project Manager should be
given authority to deal with the inevitable small deviations from
plan. For larger deviations, such as those resulting from requests
for change, poor estimation, delays in deliveries by external
agencies. The Project Manager will require an agreed exception
handling process. This will involve:

 Setting delegated limits (eg. cost and time ‘Tolerances’): The

Project Board should set limits to the allowable deviations
from planned cost and schedule so that the Project Manager
knows how much delegated authority is available to manage
deviations from plan;

 Exception reporting: The Project Manager may use an

exceptional Highlight Reports to notify any forecast (or
actual) deviations from plan beyond delegated limits.
Positive sorts of exception should also be reported in this
way eg: finishing work early or using less resource than
planned.

 Exception planning and decision making: The management

may wish the Project Manager to create a new plan to
replace the current one if it is no longer viable. This plan
would b e submitted for a decision to proceed.

3.4.3 Monitoring System Performance:

A potential problem when software systems are involved is
the potential of the systems not being able to handle increased
volumes of data in the future. To take care of this, performance
monitoring should be a part of all softwares that are likely to grow in
size, identifying potential future bottlenecks in the system, including
lack of disk space, lack or processing power, approaching
transaction limits, long before they become a problem, so corrective
action can be taken.

15
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

46

This process is very complex because softwares will grow in

size due to systems being installed incrementally (e.g., they may be
installed at a pilot location first) and due to future increases in
number of customers over time. It is also complex because new
technology may become available that handles greater capacity but
that will incur additional costs to the organization to implement. It is
proposed that information required for this planning be kept in a
Performance and Adaptability Plan document that identifies future
projections of increases in number of customers handled by the
software, bottlenecks identified so far, and contingency plans for
resolving anticipated future performance problems. The
Performance and Adaptability Plan document would be used by
business planners who would project increases in numbers of
customers, performance monitors who identify bottlenecks in
systems, and capacity planners who would identify requirements for
changes to hardware and or system software.

3.5. THE PROJECT COMMUNICATION PLAN

Good communications among all stakeholders is key for the

success of a project. It’s important to ensure your project team
develops a communication plan so that lack of communication does
not derail your goals.

Even though you may have identified and analyzed your

stakeholders and determined the most effective communications
vehicles – without a well developed and implemented
communication plan, you may have a recipe for disaster. So how
do you develop a communication plan to ensure your project’s
success?

Following are the two types of communication plans to

support and enhance communications throughout your project. As
discussed in previous installments, the first step in building your
plan is to identify your project stakeholders and determine the best
communications vehicle. Next, you build your plan.

3.5.1 Two Types of Communications Plans for Your Project:

For all sized projects, a well-structured communications plan

is a must from the beginning. Projects offer multiple opportunities
for communications to your key stakeholders, and we recommend
exploring two types of communication plans for your project to
exploit these opportunities.

1. Regular or Ongoing Communication Plan

2. One-time or Event-driven Communication Plan

16
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

47

3.5.2 Building Your Plan:

Regular or Ongoing Communications:

Regular, or ongoing, communications include those
opportunities you have to communicate to your project team
members, sponsors, steering committee members, and other key
stakeholders on a regular basis. These types of communication
could include your regular status reports, scheduled project team
meetings, monthly updates with the steering committee, or regularly
scheduled campus updates on a project. Use your stakeholder
analysis to develop these routine and ongoing communications for
the project.

Review this plan at regular intervals (quarterly) to ensure

that you are adequately communicating to those stakeholders who
are closest to the project. The chart on the next page provides an
example of the types of communications to consider for your
regular and ongoing communications. Don’t forget to include your
regular meetings and even one-on-ones that you may have with
your sponsor.

Communicati Purpose Audience Author Communicati Frequency

ons on vehicle
location

Monthly To keep Steering Project - E-mails Monthly

status reports senior committee Manager - Website
to leadership Executive postings
management informed committee
about the
projects
progress
Weekly Monitor the Project Project -E-mails Weekly
schedule progress management Manager - postings on
and report. team website
- meetings
Project Team Keep Project Project Postings in As and
calendar project participants coordinator the when
participants Steering respective needed.
aware of committee members
the key folder
project
deadlines
to help
them
manage
their
schedule

Figure 3.5 : Sample communication plan

17
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

48

One-time or Event-driven Communications:

During the life of any project, opportunities arise for one-time
or event-driven communications. Work with your project team to
identify those opportunities, like the example timeline. This plan
could also include critical issues sessions, vendor meetings,
training schedules, and roll-out schedules.

To gain the most advantage from the communications

opportunities for your project, review this portion of your
communication plan every month with your project team. Review
the past month, and then look forward at least six months to ensure
that as your project plan changes, you are able to capitalize on
every communication opportunity.

When developing your communications plan keep in mind that the

key is to always have the receiver as the focal point—not the
sender. Make your communications deliberate and focused. By
making sure that your plan is clear and thoroughly outlined, you can
help reduce the number of problems and surprises that pop-up and
have a project as successful as a perfect soufflé.

3.6 PROJECT METRICS

Metrics are a set of quantifiable parameters which are used

to measure the effectiveness of a project or undertaking. Values
are obtained for the parameters for multiple instances of the same
entity and they are compared and interpreted as to the change in
the effectiveness. For example, if there are multiple versions of a
product, one metric could be the user satisfaction level (say 1 to 5,
1 being least happy and 5 being very happy)with the user interface
for each of the versions. The effectiveness of the changes in the
user interface can be measured by the satisfaction level of the
users with each of the versions.

Project metrics are in-process or project execution measures

that are collected, analysed and used to drive project process
improvement.

6.1.1 3.6.1 Reasons for Project Metrics:

Project metrics require time and effort and so that work is done for
usually one of these reasons:

 To provide clear and tangible project status information

about project schedule and cost
 To identify areas for project process improvement
 To demonstrate the results of process improvement efforts

18
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

49

 To collect a database of project metrics to analyse trend

information or provide historic comparators and perhaps
used for parametric estimates

To collect project metrics without a clear plan of future action

to use those metrics is simply wasting time and effort. In short, only
collect project metrics that will be used to drive project process
improvements.

6.1.2 3.6.2 Key Project Metrics:

Senior management will often wish to see regular reports of

project progress against time and cost measures. Some project
management methodologies go into some detail with these metrics
including planned versus forecast, cost variance, schedule variance
and earned value. However, more generally, key project
management metrics include:

 Schedule - delivery date and slippage in days from original

delivery date
 Cost - actual budget versus original budget
 Resource - effort, how much time people have used on the
project
 Scope - changes to project as measured through number
and type of controlled changes made
 Quality - quality defects and documentation
 Software - a specialised subject with many potential
measures such as lines of code, code complexity and
function point
 Defects - number and type of problems or issues recorded
for the technology project during its test stage and warranty
period or a defined time period

Other metrics associated with normal operation such as

availability, performance or support call resolution properly belong
with service metrics rather than project metrics.

Project metrics selected should reflect the voice of the

customer (customer needs), as well as ensure that the internal
metrics selected by the organization are achieved. Metrics selected
should be simple and straightforward and meaningful. Metrics
selected should create a common language among diverse team
members.

When drafting metrics for a particular project one should

consider how the metrics are connected and related to key

19
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

50

business metrics. Typically there is no one metric that fits all the
requirements for a particular situation.

3.6.3 Developing Project Metrics:

The most common approach used by teams is to understand

the problem statement, brainstorm metrics, and finally decide what
metrics can help them achieve better performance. The team then
reviews these metrics with executive management to ensure that
they are in synergy with the overall strategy of the business, and an
iterative approach may be utilized.

Care should be exercised in determining what is measured.

Metrics should be based on what, in fact, needs to be measured to
improve the process, rather than what fits the current measurement
system. Metrics need to be scrutinized from the value they add in
understanding a process.

3.7 REPORTING PERFORMANCE & PROGRESS

Performance reporting involves collecting, processing and

communicating information to key stakeholders, regarding the
performance of the project. Performance reporting can be
conducted using various tools and techniques, most of which have
been already described in the previous paragraphs. The most
widely used techniques for performance reporting are:

Performance review meetings that take place to assess the

project’s progress or/and status

Variance analysis which is about comparing actual project results

(in terms of schedule, resources, cost, scope, quality and risk)
against planned or expected ones.

Earned Value Analysis (EVA) used to assess project performance

in terms of time (schedule) and cost (or resources).

Financial and Output Performance Indicators used to measure

financial and physical progress of the project

Information of project’s performance is usually communicated via

Progress Reports and Project Status Reports which are
described in the paragraphs below.

The Progress Report is a document prepared by the Project

Team members (in case of in-house production) or by the
Management Team of the Contractor (in case that the
implementation of the project is totally outsourced) to provide

20
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

51

regular feedback to the Project Manager regarding the progress of

the project. Progress reports should be submitted on a regular
basis to enable the Project Manager to update the Activities
Schedule, identify any schedule problems or potential problems
and act proactively for their resolution. Progress Reports are
usually asked to be submitted every two weeks or every month,
when the project is implemented with own resources. However, in
case that the project is implemented by a Contractor, the progress
reports are usually asked every three or six months. Generally, a
Progress Report should include the following information:

- Reporting period to which it refers

- Project Title
- Project Manager’s name
- Authors of the report
- Date of submission
- Project synopsis (i.e. project goals and objectives, expected
results, project activities, duration, etc.)

Project progress in the reporting period (i.e. activities/ tasks

executed, actual work accomplished, deliverables submitted,
deviations for baseline schedule, estimation of the effort required to
complete activities/ tasks)

Work programme for the following reporting period (i.e.

activities/ tasks to be executed, deliverables to be submitted,
schedule estimates for key milestones, etc.)

Updated/ revised Activities Schedule showing the

percentage of work completed so far and the estimated start or
finish dates for activities/ tasks.

It should be noted that in case of small projects with only few

team members, the Progress Report can be substituted by
personal judgment and observations of the Project Manager or by
day-to-day discussions with the team members on the progress of
the deliverables. On the contrary, in case of large and complex
projects, where progress reporting is an important aspect of
communication management, the Progress Reports should be
formally submitted to the Project Manager by the Team Manager(s)
(or by the Contractor), who have to prepare them by collecting the
relative progress information from individual team members.

3.7.1 Project Status Report:

The Project Status Report is a document prepared by the

Project Manager - using the information provided by the Progress
Reports - to present the status of the project to key stakeholders,
including the Project Steering Committee, the Project Owner and

21
Smartzworld.com jntuworldupdates.org
Smartworld.asia Specworld.in

52

the Funding Agency. Depending on the duration and size of the

project, as well as on specific communication requirements of the
Project Owner or/and the Funding Agency, the Status Report can
be prepared monthly, quarterly or biannually. Usually, Status
Reports are prepared with the same or less frequency than
Progress Reports since they require input from them.

The aim of the Project Status Report is to:

-Provide an overview of project’s progress up to date

- Ensure that the key stakeholders are regularly informed on the

progress of the project

- Inform the key stakeholders about issues that require immediate

action or resolution

Normally the Status Report becomes the point of discussion

for the Status Meeting, which is a regularly scheduled event, where
the Project Manager presents the status of the project to the
Steering Committee (and maybe to the Project Owner or /and the
Funding Agency). In these meetings the Project Manager can invite
members of the Project Team who have expertise in a certain area
of the discussion. It is, however recommended that the Project
Manager invites periodically the Project Team to review the status
of the project, discuss their accomplishments and communicate any
issues or concerns in an open, honest and constructive forum. On
large projects where gathering the entire team is not always
possible, the Project Team members can be represented in the
meeting by the respective Team Manager(s), who can
communicate the status of their team work since they have a better
insight into the day-to-day activities of their team members.










22
Smartzworld.com jntuworldupdates.org