Initiating Processes

Initiating the project means setting up the project from the idea or inception and making sure it is:

the right project

in the right place

at the right time

for the right purpose

Initiating processes include:

Clarification of the project purpose and justification

Stakeholder - needs analysis

Designation of user requirements

Establishment of clear and shared project objectives

Generation of options to deliver the project objectives

Evaluation of options and selection of the most appropriate

Documentation of this process as the Project Proposal/Definition Document

In some projects where all of the above have been clarified it is possible to continue straight on to
planning the project. However it is important to check whether all key stakeholders are in agreement
on all of the points listed above before proceeding to the planning stage.

Research indicates that most projects that end up failures have either skipped the project
initiation phase altogether or have been through inadequate initiation processes. In many
cases the more obvious objectives such as "on time" and "on budget" were emphasised at
the expense of other more important and often not immediately apparent objectives.
The project is initiated or defined to determine its viability. Essentially, a GO/NO GO decision about its
viability needs to be made by the end of the initiating process. For instance this might be a decision
as to whether a sustainable commitment can be made to the necessary resources if the project is to
proceed.

The steps for initiating the project will be presented in sequence, however, in reality this is
an iterative process. You will find that in many cases you will need to go back through these
steps several times until you have initiated or defined the project and have obtained a
satisfactory level of agreement about the project objectives.

Agreement is essential
If agreement from all key stakeholders in all the areas listed above is not obtained the chance of
failure is high. When issues are contentious the level of agreement sought might be agreement to
carry on with the project in spite of residual disagreements about particular issues. This must be
documented. See also the section onStakeholder Needs Analysis.

Project Purpose and Justification

It is always a risk to run a project that does not have a sound purpose. The justification and validity
of the project needs to be confirmed before the project proceeds, otherwise, the time, cost and
quality of the project can be compromised.

Initial interview with your Sponsor:

Clarification of the purpose and justification with your Sponsor is vitally important. You need to
establish the following with your Sponsor:

Justification of the project in relation to university strategic plans

Priority of the project in relation to other projects that might be competing for funds or
resources - this will indicate the level of importance of the project to the university and
therefore the likelihood of other projects taking priority if resources become scarce

Line of authority (sign-off) regarding project expenditure

Requirements for project reporting

Escalation procedure if risks are triggered in relation to the project - who will be prepared to
manage organisational issues if they arise in relation to the project in order to make sure that
the project is delivered on time and on budget (if these are priorities)

If there are other related projects or work being undertaken that might have an impact on
your project

If any decisions have already been made or any work has already been done in relation to
your project

The benefits that the Sponsor hopes to achieve by the project

Comment:

When working on a project you must keep the benefits of the project always in mind even when
monstrous challenges are thrown in your path.

Template:
The linked project purpose and justification template prompts you to re-state the purpose and
justification of the project as handed to you by your Sponsor or senior manager. It should be verified
by your Sponsor before proceeding with the next stage of the project.

Stakeholder - Needs Analysis

This involves doing research to determine:

The key stakeholders associated with the project

The needs of the key stakeholders

At the conclusion of this process an agreement about the real requirements of the project has to be
reached.

Identification of the stakeholders

If all of the relevant stakeholders are not identified at the beginning, the success of the project/phase
can be placed in jeopardy.
You must identify who the project is being done for, who will be affected, what they want or expect
and their actual needs.

Care needs to be taken in this identification process. Someone who is initially considered
irrelevant to the project can suddenly become important to it. The quiet, little person in the
corner can often end up being the most important stakeholder!

Some definitions:

The sponsor pays the bills or authorises the expenditure

The end-users use the product of the project

The champion paves the way and must be keep informed and interested

Prioritising stakeholders
You must determine the primary or key stakeholders for the project. They can be interested in the
outcomes of the project or, alternatively might cause problems along the way.
Key decision makers will attract priority in having their needs and expectations met and it is
important to be aware of unstated agendas within this group.

Analysing the needs of stakeholders and clients

The client's needs, and those of the key stakeholders, should be fully understood.

Sometimes stakeholders will have conflicting needs that must be resolved before the
project can proceed.
One of the purposes of the stakeholder analysis is to separate "needs" from "wants". Ask
the question "what will make this project successful for you".

Documentation:
Clear and accurate documentation is critical to the process.

It is important that the needs are documented in the terminology of the key stakeholders
so that no ambiguity can exist and a meaningful agreement can be achieved. In the
analysis, the client's needs should be reviewed, constraints should be identified, the
determined needs should be realistic, the findings should be documented and, most
importantly, approval from the key stakeholders should be obtained in writing.
The project manager must identify and resolve the needs of key stakeholders and make sure that
needs are managed throughout the project.

Often new stakeholders appear during the project. Keep an eye out for them.

Template:
The linked stakeholder-needs analysis template guides you through the documentation of stakeholder
needs.

Project Risk
It is good practice to start thinking about risks early in the project. The stakeholder-needs
analysis is a sensible place to start a log or list of potential risks as risks may be attached to
stakeholders.
You will find a more extensive discussion later under the section on Project Risk.

Template:
The project risk template is a guide to the analysis and planning of project risks.

Project User Requirements

The user requirements of the project must be defined and documented. Approval and confirmation
must be obtained before the project can proceed.

Obtain agreement about needs:

Separate needs from wants

Group the needs that are similar

Identify any conflicting needs

Negotiate agreement between stakeholders with conflicting needs

This process often requires a number of meetings with stakeholders. For large projects
value management may assist in arriving at optimal agreed needs through collaborative
facilitated processes.

Express the agreed needs in functional (measurable) terms:

Stakeholders often express their needs in terms of a particular product or solution to the problem
which has created the need for the project in the first place. It is important to re-state the agreed
needs in terms of "what the end product(s) of the project should do".
Stating the agreed needs in functional terms permits the project manager to offer a range of solutions
to the client or key stakeholders. If the project outcomes are restricted to solutions offered by key
stakeholders too early in the analysis process important alternative options might be overlooked.

Document the final set of agreed requirements

Obtain sign-off from all key stakeholders

Template:
The linked project user requirements template offers a guide to this process.

Project Objectives
From the agreed project user requirements you can establish the agreed project objectives.
They are traditionally stated in terms of time, cost and quality (or functionality) as the project
manager is constantly balancing schedule, budget, quality in relation to the scope of the project.

Generally speaking there is only one objective related to time (one required completion
date) and one objective related to cost (one agreed budget objective) but there might be
several objectives relating to quality or functionality.

There might be a range of quality (functional) objectives. For instance, if the project
involved the implementation of new safety procedures for a section of the university the
quality (functional) objectives might be:
- Install equipment to required standards (tested as per regulations)
- Train staff in use of equipment (measured by testing)
- Install user instructions adjacent to equipment as per regulations (measured by
observation in position)

Alignment with project purpose:

The project objectives should be aligned with the project purpose stated earlier. However it is possible
that there will have been some variation or deviation from the initial purpose in the process of
discussion and development of the user needs. Any change in direction must be verified with the
project Sponsor, documented and agreed by all key stakeholders.

Key Success Factors:

The project objectives will ultimately provide the measure of how your project will be judged.
Obtain agreement in writing about the final Project Objectives with your key stakeholders.

Alternative Approaches/Options
Having carefully defined measurable objectives for your project it is now time to explore a broad
range of options for the delivery of your project.
You might have to work through a range of options or different approaches to determine:

what the end product might be?

who will deliver the project?

The range of options or alternative approaches available to you will depend upon what decisions have
already been made by others with respect to the project.

For instance the university might have existing supplier agreements which will restrict what
kind of equipment you will be able to use in the project or there might be a limited range of
suppliers. Budget restrictions might eliminate the possibility of using outside contractors to
do the work.

What the end product might be?

In some cases there might be a range of options that will suit the needs of the stakeholders and endusers. Effective exploration of possible options depends upon the objectives being stated in functional
terms which are measurable - not stated as solutions to the perceived problem.

For example, taking into account the needs of the end-users the final solution to what will
most satisfactorily address the objective "to communicate regular updates and changes to
sections of the university" might involve use of personal email notices, posters posted in
the workplace and regular staff information meetings. One option by itself might run the
risk of only reaching a proportion of the staff concerned.

Who will deliver the project?

This question addresses whether the project will be delivered by internal resources or external
resources or a combination and from where those resources will be drawn.

Evaluation of Options/Alternatives
The options or alternatives for the delivery of the project should then be evaluated against the:

project objectives, in terms of time, cost and quality

risks involved

extent to which the required scope of the project is addressed.

The impact of the options or alternatives on the various stakeholders must also be
considered.
The process of evaluation of options will be more or less formal depending upon the nature of the
project.

Evaluation might simply require a round table discussion and agreement.

In projects which incur high risks to the university a formal evaluation process must be adopted and
carefully documented for approval by senior management.

Time and cost estimates:

In some cases estimates in terms of time and cost will be required from potential suppliers before
evaluation of options can be completed.

Time must be set aside to allow for these estimates to be obtained.

The degree of accuracy of time and cost estimates will depend upon the amount and accuracy of
information that can be given to suppliers.

It may not be appropriate, at this stage in the project, to dedicate extensive resources to
gathering the information required - this will result in a relatively low level of accuracy of
the forthcoming estimates. As the project moves into the planning stage the level of
accuracy can be successively refined.

Risks:
The evaluation process can engender many risks. Not least are those associated with
assessing estimates of time, cost and functionality.

Often risks are associated with

assumptions or constraints. Potential risks should be recorded in the project risk template.

Template:
The linked template sets out a suggested process for formal evaluation of options or alternatives.

Project Vision (Scope) Statement and Project

Proposal
This is the end of the Initiation Process for the project as a whole. Your project should be now be
defined. That is, you should have reached agreement with your key stakeholders about the following:

Project objectives (time, cost and quality or functionality)

The exact nature of the product of the project

Who will deliver it

It is good practice to write a short statement at this stage which defines what the project is going to
deliver. It should be no longer than one or two sentences.

The Vision (Scope) Statement functions as a kind of project "vision" statement. It is used to
keep the attention of the project team and key stakeholders on the purpose of the project
during the planning and implementation phases when projects are likely to suffer from
"scope creep" or change in direction, particularly as new stakeholders arrive.

Example of a Vision (Scope) Statement:

Upgrade room B17 using internal project manager and external contractors for works, by 1st
February 2003, for a cost of $50,000. Upgrade to include repair or replacement of damaged
seats, replacement of non-functioning light globes and repainting of walls.

In some cases a budget or time frame has not been assigned at this stage of the project so
you must simply state that the "time frame and/or budget are to be determined". These
will be determined during the planning phase of the project.

A note about "Fuzzy" Projects:

With "fuzzy" projects the exact nature of the product of the project may not be known at this stage.
Time and cost might also be unknowns. However you should have defined the project objectives and
be ready to plan at least the first stage. See more about defining "Fuzzy" Projects.

Feasibility Studies:
Often the project definition process will result in the need for a feasibility study. This is conducted
before approval to plan the project is given. The feasibility study becomes the next phase.

Project Proposal
You are now in a position to prepare a Project Proposal. This document is also known as the Project
Definition and provides the major input into the Project Plan.

Template:
The linked project proposal template summarises the results of the Project Initiation process into a
one or two page document to be signed off by the Project Sponsor and any other key stakeholders.

Planning Processes
Once the project has been initiated, objectives are clear and agreed and options have been evaluated
the project can be planned.

Early in the inception of the project a Business Case might be required before the project is
approved. It is good practice to include a preliminary or high-level Project Plan in the
Business Case. The planning tools described in this section may be applied at high level or
they may be used to plan the project in detail once approval has been given to proceed
with the detailed planning of the project.
Detailed planning requires increased commitment of resources. Therefore there is a logical approval
GO-NO GO decision at the end of the Initiation Phase before the commencement of the Planning
Phase.

The potential for adding value to the project is still high in the Planning Phase in
comparison with the cost commitment. Costs to make changes to the project are starting to
increase but are still low in relation to the subsequent phases.
There are three major project planning activities:

Scope

Time

Resources and Cost

Risk planning relates to all of these

In addition there are planning activities which facilitate the implementation of the project. These are
associated with:

Quality

Project Organisation

Communications

Procurement

Project Scope
The scope is what the project contains or delivers.
When starting to plan the scope of the project think about the BIG PICTURE first! At this level it is
best to concentrate on the major deliverables and not get bogged down with detail.

It is just as important to agree on what is OUT OF SCOPE as it is to define what is IN

SCOPE as stakeholders will often have different ideas regarding what is supposed to be IN
the project and what IS NOT. Obtain agreement up front to avoid unnecessary disputes
later on.

Example:
A project for which the objective is to collect and publish course information by the beginning of the
next academic year:

IN Scope

OUT of scope

Assumptions/

Risks

Constraints

Details of all

Details of courses

Details of courses offered

It will be difficult to obtain

courses

from other

by the Faculty are

course details from all Course

offered by

Faculties.

available at the required

Directors on time for the

level of detail

project to be completed within

the Faculty
Details of courses

the required timeframe.

not approved by
September of this
year.

This is a useful task to conduct with key stakeholders and can help clarify issues at any
time in the Initiation or Planning phases. Generally speaking assumptions and constraints
will generate risks to the project that must be managed.
During this process issues may not be resolved to the agreement of all key stakeholders at one
meeting. Any unresolved issues should be noted at the end of the document for elevation to top
priority for discussion at subsequent meetings until resolution is achieved.

Template:
The linked Broad Scope template will assist you to define what is IN and what is OUT of the project.

Scope Definition
This is where we get down to detail! It provides the detailed information for the Scope Plan, often
called the Scope Definition document. It provides the basis for estimating cost, time and resources,
performance measurement and responsibilities.

Generally the Scope Definition document is presented in list format but development of the
document requires some brainstorming activities that are best done with the key
stakeholders and the project team involved using some simple tools like "sticky" notes on
the wall.

The most useful tool is the Work Breakdown Structure (WBS)

Defining the project scope involves brainstorming all the tasks or activities needed to deliver the
project. The project is subdivided into interim deliverables and the activities or tasks needed to
deliver each one are listed below.

The example below is a WBS for production of a book. Note that in this case the major
deliverables are also the project phases.

The major deliverables (second top row of the WBS) could also be intermediate products of the
project, all of which are put together at the end to deliver the project as a whole. The Work
Breakdown Structure for a conference is such an example. The rule is - use whatever method feels
most appropriate at the time.

The sequence of events does not matter when creating a Work Breakdown Structure. The most
important aspect is to make sure that all the necessary activities have been included, including
management activities, such as meetings and approvals.

The development of the WBS depends on the progressive breaking down of the project into
units of work. It identifies all the pieces of work that need to be undertaken to complete the
project. Each unit of work should be measurable in terms of cost, effort, resource and time.

Template:
There is no template provided for a work breakdown structure. The preferable technique is to do the
task collaboratively with your key stakeholders and project team with "sticky" notes. This achieves
"buy-in" by stakeholders and team members and reduces the likelihood of omitting key tasks!

Project Time
There are four aspects to Project Time:

Activity Duration Estimating

Scheduling

Milestone planning

Bar or Gantt chart

Activity Duration Estimating

Once having defined the activities or tasks you must decide how long each task will take before they
can be arranged in sequence.

Duration and Effort

There are two kinds of time commitment for each of the activities of a project.

Duration is the amount of time from the beginning of the activity to its completion. Duration
has a direct effect on the schedule.

Effort or resource time is the amount of time required for the people to complete it. Effort is
directly related to the cost of the time expended on the project.

Examples:
Duration and effort are not usually the same. For instance an approval may take three weeks from
start to finish, giving it a duration of three weeks, but it might only take one or two hours of your own
time, leaving you free to do other things. On the other hand a task might involve three people for
three weeks. In which case the duration is three weeks but the effort is equal to nine weeks.

Risk
All estimates are just that - informed guesses about how long a particular task will take to
complete. In the project risk template note down any risks associated with the estimates of
duration you have made.

Estimates:
When estimating the duration of an activity or task consider:

Part-time working on a project

Time lost and interference from non-project activities

Skill and experience of the people who will be doing the task

Priority of the project - will other activities take precedence if time is short?

Availability of staff with special skills

Be realistic with your estimates - don't massage estimates to suit unrealistic deadlines. A project
that is manipulated to meet an unrealistic timeframe will invariably fail!

Template:
The linked Activity Durations template might be of assistance.

Schedule
Using the activities and the durations we can now place them in sequence and develop
the Schedule for the project.
The schedule allows progress of the project to be assessed, communicated and coordinated and it
identifies key milestone dates to be met.

Some tasks can be done at the same time. Others will be dependent upon previous tasks
being finished.

The "sticky" note method:

Particularly early in the project agreement, "buy-in" and the advantages to be gained from expert
opinion is best obtained through involvement of the key stakeholders in developing the initial
schedule. Simply ask the participants to arrange the sticky notes from the Work Breakdown Structure
in order of sequence. Then draw arrows between the sticky notes to indicate the order of events and
the dependencies.

The diagram above for the first phase of a staff survey project is called a Precedence
Network because it describes the dependencies between activities or tasks.

Critical path
The pathway through the sequence in which the total of the durations is greatest is called the
CRITICAL PATH. It indicates the minimum total time from start to finish of the project or phase.

In the example above, the CRITICAL PATH runs through the following activities - 'identify questions' 'obtain approval' - 'conduct initial interviews' - 'refine survey' because this pathway is the longest
total duration.
The total length of the critical path is 27 working days. That is, the project will take a minimum of 27
working days from start to finish. The activities - 'literature search' and 'define focus groups' are not
on the critical path. They can be done in parallel with other activities.

Risk
There are always risks associated with a network or schedule. The most influential risks in
terms of the schedule tend to be those on the critical path. For example a risk could be
associated with the activity 'obtain approval', especially if the approval requires sign-off by
senior managers. If the duration has not been estimated correctly the initial interviews would
have to be delayed. Often it is difficult to get focus groups together. This could constitute a
major delay to the entire project.
You should enter any risks associated with the schedule in the Project Risktemplate.

Reducing time to completion - shortening the critical path:

If your network calculations do not meet the scheduled completion date for the project, as per the
project objectives, the critical path might need to be shortened. This can be done by adding
resources, which will allow activities to be completed in a shorter duration, or certain activities might

be undertaken at the same time, or in parallel. It is not good practice, and is particularly unfair to
project personnel, to "massage" activities into unrealistic timeframes!

Milestone Plans
This tool is used to indicate key dates. Milestones are either set for the projects or established by the
project team as dates to be met. Milestones might indicate the key dates to be met during the
execution of the project, such as a report to a board meeting.
Generally milestone plans are effective communication tools. They can be used to create a sense of
urgency and to reinforce with key stakeholders and the project team the key dates in the program to
be achieved.
Milestone plans are not used as planning tools unless the project manager is extremely
familiar with the type of project or the project is a "fuzzy" project which must be planned
step by step.
An example of a Milestone Plan for a training session is shown below:

The milestones are commonly included in the Project Proposal document.

Bar or Gantt chart

This tool is one of the most easily understood of the schedule formats. It lists the tasks with a task
bar next to each task showing its time duration.

The project schedule is commonly presented as a Gantt chart. It is an excellent communication tool,
however, as the Gantt chart does not show dependencies very clearly it is less easily manipulated
than the precedence network.

Milestones (traditionally represented by a diamond shape) can be plotted on the bar or

Gantt chart for easy reference to key dates in the schedule.
Beware too much technology too soon in the process!
In recent years the use of computer enhanced scheduling systems has meant that the production of
the schedule has become a solitary activity.

It is strongly advised that the initial schedule be created as a "group activity" otherwise
there are risks of insufficient commitment by key stakeholders to the durations and
dependencies and lack of expert information at a key stage in the planning process. Once
the key stakeholders and project team have ownership, the schedule can be converted
using an appropriate computer based scheduling program.
It is unlikely that one person (the scheduler) will have expert knowledge of every task in
the project!

Template:
The linked Gantt chart template might be of assistance.

Project Cost
There are three aspects to project costs:

Human resource costs

Goods and services costs

Final budget

Human Resource planning

When you started thinking about the effort in relation to the activities on your Work Breakdown
Structure you were beginning to plan the human resource commitment for the project. However
some resources cost more to the project than others. Also they might be more difficult to obtain.

Even if human resource time for your project is treated as "sunk" costs - costs that are
attributable to the administrative unit or faculty rather than the project itself resources
must be carefully planned to make sure that they are available when needed to work on the
project.

Example:
A typical human resource planning schedule:
Activity
Skills
Hours Cost per Tot
Date Source
from
require require
hour
al require
WBS
d
d
(includin cost
d
g
overhea
d)

Install

Technic

cabling

al IT

from

level B

20

$35

$70

27-02-

Extern

03

al
labour

TSG
room to
terminal
point
room
G37

Connect
telepho
ne

Total

Technic
al Level
C

$32

$32

$73

3-0303

Intern
al
labour

Templates:
A Human Resources Planning template and a more detailed Human Resources Procurement templates
are linked.

Risks:
There are many potential risks associated with planning of human resources for the project. In
the example above the external labour might be unavailable when required. You should enter
any risks into the Project Risk template before continuing.

Resources - Goods and services

Resources to be planned for the project also include equipment, space and materials. A detailed
resource schedule should be prepared based on the items listed in the WBS.

Activity from WBS

No. of
items

Cost per unit

incl. GST

Total
cost

Date
required

Source

Cable from TSG room to

terminal point room G37

20
metres

10

$200

22-02-03

ABC
supplies

Telephone handset

$66

$66

1-03-03

Tefunkel
and co.

Total

$266

Ideally these schedules should provide enough information so that your colleague can conduct the
project if you are absent. Supplier details should be linked and alternative suppliers included if
necessary.

Template:
A Goods and Services Procurement template is linked.

Risks:
As with planning human resources there are many potential risks associated with planning of
goods and services for the project. In the example above the supplier might be unavailable
when required. You should enter any risks into the Project Risk template before continuing.

There is also a risk associated with having too many documents to keep track of - it is easy to forget
to check one. Keep it simple but accurate!
In a small project it is often simpler to conflate the resources schedules for project
personnel and goods and services into one document. See the linkedCombined Resources
template.

Budget
Determining the budget for the overall project is now a simple task.
Simply sum the costs of the Human Resources and the Goods and Services for the project
from the previous templates.
However the accuracy of the project budget depends upon the accuracy with which you have
determined the Work Breakdown Structure, the accuracy of the estimates for effort for each of the
activities and the reliability of the estimates you have obtained for goods and services.
Cost estimation:
If you are unable to confidently assign a cost to an activity or task in the Work Breakdown Structure
you will need to break that item down further into sub-tasks until you can be confident to assign the
amount of effort and the cost of non-human resources.
The accuracy of the budget estimation will also depend upon the position in the project life cycle.
During the Initiation phase of a project you would be unlikely to expend too much time obtaining
detailed estimates. Therefore the expected level of accuracy will be much less than in the Planning
Phase of the same project, when you have been given approval to assign resources to the project to
plan the project in detail
It is important to discuss the relationship between the level of accuracy of the budget and the phase
of the project with your Sponsor so that you have a shared understanding of the level of accuracy
expected.

The same comment applies to the time schedule!

The diagram above illustrates the successive increase in accuracy as costs are estimated
during the life cycle of a project, the arrows indicating approval points. The % accuracy will
vary in each case.

Project Risk
Throughout you have been asked to note potential risks to the project in the Project Risk
template.
All projects are subject to uncertainty and therefore to risk. Risks should be identified and ranked in
terms of impact, probability and responses developed for those risks incurring medium to high impact
or probability.
The following strategies are available to manage risks:
avoidance - plan in such a way to avoid the risk altogether
mitigation - plan to reduce the risk
acceptance - simply accept the risk if there is no alternative or if it is very unlikely or of little
potential impact
procurement - contract out the risk - however the contract still needs to be managed carefully
contingency planning - determine alternative strategies if the risk is triggered
insurance - transfer the risk through insurance (also a risky strategy)
A typical risk planning matrix for a science seminar in which highly combustible experiments are to be
demonstrated is illustrated below:
Risk

Impact Proba- Reduction

bility
Strategy

When

Response if
Triggered

Management
Responsi-

Financial
Responsi-

Fire in
theatre

High

Low

- Theatre
designed
according to
codes
- Fire drills
for staff
involved

During
seminar

- Alarms/ fire
brigade
- Officer on
duty evacuate
attendees as
per plan

bility

bility

Officer on duty

Uni. unless
caused by
chemicals in
demo. then
hirer.

- Trained
officer on
duty
- Fire
retardant
apron to
stage area

In major projects or where external contractors are being used it is also wise to agree with the
contractor to assign the financial responsibility for the risk if it is triggered. This might be a shared
responsibility with designated % financial commitment.

Template:
A Project Risk template is linked.

Project Quality
Quality is a subjective measure, often meaning different things to different people. In quality
planning, the level of quality required of each of the project deliverables needs to be determined and
agreed with key stakeholders before the project commences.
Also it is important to determine which of the quality aspects are most important to key stakeholders.

Using the Work Breakdown Structure, you should identify with your key stakeholders,
where and how it is most appropriate to verify that quality objectives have been met in
order to ensure the success of the project.

Project Quality vs. Process Quality

The quality of the outcomes of the project is linked to the processes introduced to ensure quality.
However it is important that the processes do not lose sight of the outcomes of the project - the
quality criteria for the major deliverables.

The matrix below might be used as a guide:

Deliverable
from WBS

Quality
criterion

Method of
measure

When

Person
responsibl
e

Recovery
procedur
e

The quality criteria are the agreed standards for the project deliverables. It is often useful
to set a benchmark or example. Documenting recovery procedures for rectifying any faults
discovered in the process will assist others who are involved in the project team. The
quality plan should also include who will be responsible for rectifying the fault.

Template:
A suggested Project Quality template is linked.

Project Organisational Planning

Organisation charts are useful tools to show the relationship of people and structures which govern
and influence the project. Many projects have complicated reporting and approval relationships.
Successful management of the project depends upon how well you manage those relationships.
However first they need to be identified.
In the example project organization chart shown below the direct reporting relationships are shown in
solid line and the lines of influence are dotted:

Roles and responsibilities

An important part of project organizational planning is identification of responsibilities and authority in
the project. Roles, responsibilities and authority must be negotiated and understood by all
stakeholders. It is not uncommon in projects for influential stakeholder groups to assume control
beyond their level of designated authority, resulting in negative consequences for the governance of
the project.

Examples:
If the role of the Stakeholder/User group is to advise the project, it is important that the extent of the
role be made clear to all concerned so that the group does not inadvertently assume a decision
making capacity.
The role of the Project Sponsor is usually to authorise expenditure and variances to scope or schedule
and to act on the Project Manager's behalf to negotiate high-level support for the project.
Steering Committees might comprise senior managers to whom direct requests for staff and support
may be made via the Sponsor.

When defining the roles and responsibilities it is essential to be clear to all key stakeholders
about appropriate response times for advice, sign-off, approvals etc. so that the project
remains on schedule.

Template:
A suggested Roles and Responsibilities template is linked.

Communications Planning
Communications is by far the most important driver in project management and more often than not
it is the least adequately planned part of the project and least effectively carried out.
Communications planning involves planning for all the communications with project stakeholders. A
useful tool is the reporting schedule. It can help you identify the frequency and types of information
required by different stakeholders.
Stakeholde Reporting
r
needs

Sponsor

Status
report including
schedule,
budget,
variances,
issues

Format

Preferred
medium

When

Spreadsheet for
schedule and
budget status,
table for scope
status and issues
plus a one page
summary

Email
attach. 24
hours
prior to
face to
face
meeting

Meeting
last
Mon. of
each
month
prior to
Board
meeting

Person
responsible

Project
Manager

Communication protocols include the:

method of communication

standards

templates

security

ethics

time frames and reporting schedules.

who requires the information

version control method

Communication can often be difficult. There can be misunderstandings; one way

communication; lack of verification; insufficient, inaccurate and inappropriate information;
information can be withheld and inappropriate communication media may be used.

If you don't know what to report ask what the stakeholder needs to report to his/her
senior manager and in what format. It is a waste of time to report too much detail and a
waste of time to provide too little!

Template:
A sample Project Communications Management Plan template is linked.

Procurement
This involves planning for all the resources - people, goods and services - required by the project. It
includes selection of goods and services, writing and evaluating tenders and estimates and
negotiating contracts to obtain goods and services for the project.

Goods and services:

Warning:
Writing of tenders, evaluation of estimates and selection of tenders are depedent on the degree
of rigour that you have put into developing a detailed Work Breakdown Structure.
You should seek legal advice with respect to negotiating and writing contracts.

In planning the procurement needs for a project it is useful to use a template like the following:

Activity from the

WBS

Selection process
(estimates,
tender,
evaluation,
contracts)

Expert to be
consulted

Person
responsible for
managing

When
neede
d

Purchase of cabling

Standard estimates
process.

Purchasing dept.

Project Manager

28-0303

Finance dept.
/solicitor

Project Manager

28-0403

Contract for lease of Standard formal

hardware
tender, evaluation,
selection and
contract

Risk:
The relationship between procurement and project risk is complex. There are many sources of
risk associated with procurement strategies.
For example - contracting out the risk in the project is a risky business! The contract must be
carefully written to reflect the management needs for the project. There is a direct relationship
between management of the scope of the project and ability to manage within the terms of the
contract. A detailed Scope Definition is required before the tender documents and the contract
can be written for the project.

Templates:
A sample Goods and Services Procurement template and a sample Human Resources Procurement
template are attached.

Project Plan
The Project Plan iteratively brings together the:

Scope Definition

Time Schedule

Resources Schedule

Budget

and

Risk Schedule

Quality Processes

Organisation and Responsibilities

Communication Strategy

Procurement Strategy

It is a key communication and decision-making document.

A summary of the project plan is included in the Project Definition document orProject
Charter and the Project Proposal.

Change Management
It is also useful at this stage to indicate how you will manage changes with regard to the project
objectives. This will be discussed in more depth in the Implementation section. See Change
Management processes.

Template:
A template for a Project Plan is linked. The Project Plan summarises the results of the Project Planning
process into a brief document to be signed off by the Project Sponsor and any other key stakeholders.
The Project Plan is the basis for monitoring and controlling the project. All changes to the project
must be recorded against the project plan.

Implementing Processes
The nature of the implementation processes will depend on the type and size of the project. Scope,
time, cost, risk, quality, project organisation, human resources, communications and procurement
must be managed.
The requirements for successful implementation of a project are:
Planning
Managing the project team
Managing stakeholders
Managing change
Project reporting
Good communications
Project Records

We execute and control against the Project Plan.

As indicated in the control cycle below it is almost impossible to conduct and manage a project if it
does not have a developed project plan.

Managing the Project Team

Team skills
If you are working with or managing a team or a group of stakeholders team management skills are
essential. These skills are best acquired experientially through workshops and practice.
Other skills that are particularly useful for the Project Manager are negotiation and conflict resolution.
Refer to the Newsflash link on this site for information about the latest workshops.

Roles and Responsibilities

Definition of responsibilities for a project should occur during the planning phase. However
communication of those responsibilities must be continuous during the Implementation phase.
There should be no ambiguity about roles and responsibilities. That means responsibilities must be
defined in detail.
The most useful investment of a Project Manager's time early in the Implementation phase is spent
with individual project personnel to make sure they are clear about their responsibilities and have the
required information and skill to carry out the work.

It is the responsibility of the Project Manager to:

Identify the skills required for each part of the project.

Locate appropriate project staff

Arrange for training if necessary

Keep staff up to date with regard to any changes

Look after the morale of the project staff

Managing Stakeholders
Key stakeholders can change during the project and existing stakeholders often change their minds
about important issues. You will not be able to prevent this but it must be managed.

Dr. Ed. Hoffman, Head of Project Management at NASA, has been quoted as saying that
'successful project management depends upon managing the stakeholders' expectations
throughout the process'. (Conversation with author, UTS 2000.)
Managing expectations requires constant communication with key stakeholders to ensure that there
are no nasty surprises.
Stakeholders, particularly Sponsors, Clients and End Users, also have responsibility to the project.

Scope creep
This is unauthorized increase in scope or functionality. 'Scope creep' is a major cause of time and cost
delays as well as reduction in quality. It can often be caused by over commitment as a result of
casually taking on more work than initially agreed. A stakeholder will request something in addition or
something different from what has already been planned and agreed. Changes to scope will have
impacts on time, cost and quality and could also trigger other kinds of risks.

The key stakeholders need to be constantly reminded of the agreed scope of the project
and that any changes will only occur according to the agreed procedures. The Scope
Statement, which was developed at the end of the Initiation Phase is very useful to help
control scope creep.
The Project Manager must not automatically agree to everything a key stakeholder wants. It is the
role of the Project Manager to point out to key stakeholders what the impact of any change to the
project will be on the cost, time and quality objectives of the project.

Requests for information

It is sensible practice to ask stakeholders to agree to supply information within an agreed period of
time. A delay with respect to a request for information during the Implementation Phase can cause
serious delays to the project as a whole. Stakeholders must be aware of the potential impact of
delays.

Managing Variance (Change)

Once the Implementation Phase has begun an agreed form of Variance or Change Management
procedure must be in place. This is a formal process for recording, assessing and obtaining
agreement to any variances/changes.

Variances/Changes can result from:

Stakeholder/user requirements

Work which was more difficult than anticipated

Delays in procurement

Increases or decreases in estimated costs

Risks triggered

Mistakes

Any change must be assessed for its impact on the project objectives.
The impacts are reported in terms of the three project objectives
- time, cost and quality.
Changes may be treated as risks during the Implementation Phase and are reported in an Issues
Log (Risk Log). Each change request or risk is given a number and action date. It is closed once a
decision has been made and the Project Plan is updated and signed-off by the sponsor.
The impact of any change must be assessed before a decision is made regarding how to
manage it.
The change may be accepted, refused or modified by the Project Sponsor or Steering Committee.
The calculations required are as follows:

Planned schedule completion date

31- 07-03

+/- change due to issue no. 7

+ 28 days

Revised schedule completion date

28-08-03

Planned budget

$27,000

+/- change due to issue no. 7

+ $5,000

Revised budget

$32,000

Changes to scope and quality or functionality must be noted.

Template:
A simple Variance Request template is linked.

Project Reporting
When to start reporting
Although reporting has been addressed in the Implementation Phase section, in reality management
begins from the time you get involved with the project.
Therefore a reporting system must be negotiated up front with the Project Sponsor and must be in
place from the beginning of the project. The content, format and frequency might vary as the project
moves through its life cycle but regular reports happen throughout the entire project.

What needs to be reported?

Ask your stakeholders what they need to report to their stakeholders. This question will guide you
with respect to the level of detail needed in your reports and the frequency.
It is a waste of time to report unnecessary detail but it is also a waste of time to report insufficient
detail.
There are four essential types of reports:

1. Project Proposal
The Project Proposal is developed at the conclusion of the Project Initiation phase and requires "signoff" or the authority to proceed to the next phase. It contains the summarised results of the initial
high-level planning process. In large projects the Project Proposal may be substituted by a Business
Case. Detailed planning follows approval of the Project Proposal.
2. Project Plan
The Project Plan is developed at the conclusion of the Planning phase of the project. It is a detailed
document comprising:

Scope definition (items from the WBS listed with functionality under the headings of the key
deliverables plus exclusions)

Schedule (including project milestones)

Budget

Risk schedule (major project risks and management strategy)

Project organisation structure (reporting and approval pathways)

Roles and responsibilities (project team and key stakeholders)

Quality system (procedure and standards)

Procurement schedule (human resources; goods and services)

Communications strategy (protocols, templates, reporting schedule)

Change management procedure

3. Variance Request
A Variance Request is a formal process that documents any changes to scope or any risks triggered
which might result in variances to the project objectives, in terms of time, cost or quality.
4. Status Report
A Status report is required at regular intervals throughout the project. The frequency and the format
should be negotiated with the Project Sponsor.
The level of detail to be included is an important consideration also to be negotiated with the Project
Sponsor. Essentially the status report summarises the following:

Schedule - original approved completion date, authorized changes and current estimated completion
date
Budget - original approved budget, authorized changes and current estimated budget

Issues - any issues or risks triggered that have resulted in approved changes to scope, schedule,
budget, quality or functionality.

Issues & Risks Log

It may also be useful to produce an Issues and Risk log. This helps keep track of issues or risks as
they arise and records status, action, responsibility and closure of the issue or risk.

A note about detail

Reporting is an essential part of project management. However the level of detail should be
appropriate to the risks associated with the project.
It is possible to spend all your time preparing reports leaving no time to manage the project!

Communications
This is quick note about communications! Good communications is so easy to pay lip service to and so
difficult to achieve effectively. Communications underpins the project success.
As some people are naturally more gregarious than others it is important to be eternally vigilant
regarding Project Communications.

Assigning responsibility for Project Communications to a member of the project team who is
a naturally good communicator often makes sure that the job is done and what's more the
person enjoys doing it!

Appropriate and timely information

The Communications Management Plan which was developed during the Planning phase is a useful
tool to make sure that those who need information receive it on time and in a format they can use
and understand.

The use of templates

Standard templates save time and assist in achieving clarity of the information transfer. They must be
clearly set out, without overcrowding of text, and the format should remain constant throughout the
project.

Take the time to explain the templates to the stakeholders so that they are familiar with the
data layout and extent and what is required of them in terms of response.

Feedback
It is good practice to require a response to your communication attempts so you can verify that the
person receiving the information has received and understood.
Sign-offs can be delayed for a number of reasons, but clear feedback loops and early agreement
regarding responsibilities will assist in obtaining sign-offs on time.

What hasn't been written hasn't been said!

Negotiations and agreements are usually transacted verbally however written clarification is always
essential as a follow-up.

The purpose of the written document is two-fold. It is essential for your project records, in
case of future disputes or disagreement. Putting the agreement in writing helps refine and
clarify meanings between the parties concerned.

Version control
All documents must have a version control panel which indicates:

Number and name of project

Number of revision

Date

Responsible officer issuing document

File identification and location

Project Records
ile everything!
Version control is essential.

UTS Records Procedures

You will need to maintain the following project files:

Correspondence

Minutes of meetings

Stakeholder contact details

Project Initiation
Details of project purpose, stakeholder needs analysis, agreed objectives, options explored,
evaluation criteria, final agreed solution

Project Proposal
Signed-off copy

Project Plan
Signed-off copy plus amendments

Change Requests

Issues (Risks) Log

If you are keeping a separate log

Status Reports

Procurement documents
Tender documents, evaluation criteria, contracts, job descriptions, letters of engagement.

Instructions issued
To team members, suppliers or contractors.

Handover documents
Leases, as-built drawings, maintenance agreements, training manuals.

Project Archives
See section on project Closure.

Keep a diary!
A Project Diary is an invaluable tool. Use it to note telephone conversations, instructions,
thoughts and insights.

The abbreviations forced by electronic diaries have reduced the effectiveness of an extremely
useful recording tool!

Closing Processes
To ensure the success of the project and the value of lessons learnt, project closure involves three
processes: commissioning, handover and project evaluation. Project closure should be planned.

The tendency to escape before closure is completed is very high amongst members of the
project team, contractors and suppliers!
Knowledge Management
The final phase of the project provides the opportunity to capture and transfer project knowledge for
use in future projects.
Evidence suggests that of the information captured on projects only a very small percentage is stored
appropriately and even less converted to useful data to inform future projects.

Archiving Project Records

Once the project has been completed provision should be made to archive the files.
Project Data Base
Project information should be entered into an appropriate database. The establishment of
centralised databases is particularly important for technical projects as information about
the installation conditions in one technical area can seriously affect a project from another
technical area. Quick and easy access to data about installations is essential if disasters are
to be averted.
Human Resource Issues
Where personnel have been seconded to a large project for a period of time there can be a significant
adjustment period on return to their normal working environments. This can be due to the different
pace. Projects can create exciting and intense work environments. Alternatively it can be due to
anxiousness over the viability of returning to a previous position in the organisation and loss of
contact with former colleagues and with the department.
When personnel are seconded on a full-time basis to a large project from elsewhere in the
organisation it is important that they are permitted to maintain links with their functional unit, by
attending regular meetings and staff functions.

Commissioning
Commissioning the project is part of the Closure process and involves:

Identification of any training or familiarisation needs on the part of the end users of the
products of the project

Development of training manuals, training programs etc.

Identification of issues - including safety, environment compliance and comparative technology

evaluation

Identification of faults and making good any items

Handover
Project handover includes the following activities:

Finalisation of any contracted services - including any unresolved items.

Collection and handover of documents - 'as-built' drawings, specifications, maintenance

manuals, warrantees, etc.

Demonstration of the benefits of the project to the key stakeholders

One of the tasks most often left out of the handover procedure is a document, such
as the Handover Summary Report which demonstrates the benefits that the project
has delivered. It is the final important step in the management of stakeholders'
expectations.
The document reinforces and clarifies any changes to scope, budget, schedule or
quality, who agreed to the changes and why they were necessary.

Celebration with the project team and key stakeholders!

Often the delivery of projects on schedule and to the require standards requires
intense effort by all concerned. Their effort must be recognised and appreciated.
Also the project team members need a formal closure to the process. It has been
informally noted by senior project managers in some large companies, which have
been undergoing cost cutting measures, that the elimination of a celebration to
mark the end of a project has been a major contributing factor to declining morale
amongst project team members. Some senior project managers attribute so much
importance to the post-project celebration that they have financed the event
personally. (Anecdotal evidence collected by the author.)

Template:
A simple Handover Summary Report template is linked.

Evaluation
Effective evaluation of projects is rarely achieved. This is because of a mixture of factors:

The psychological need to move on the next project

Misuse of the evaluation process as a "blame shifting" exercise

Lack of formal post-project review

Lack of planning for evaluation - lessons learned are best captured at the time,
during the project when the issues are fresh

The evaluation process should involve the following:

Post project review - Review of the project outcomes against the project objectives. This
should take place as soon as the project is handed over. It can be conducted as a meeting with
stakeholders or as a formally facilitated workshop as the size of the project dictates. Lessons
learnt should be formally recorded for future use.

Business benefits review - review of the project outcomes in relation to the return to the
university. This should take place at some time, at least six months to a year after the project
has been delivered. It provides valuable information about the long-term viability of the
projects and informs future decision making with regard to similar projects.

Recommendations for future projects - often the necessity to adhere to budget or time
constraints has meant that sections of the project have been identified for delivery at a later
date. These elements should be formally developed as future projects.

Review of the contractor's performance - this can form part of the post-project review
and provides valuable knowledge to be applied to future projects.

Collection and collation of project records

Archiving of project records to a central project data base for use on later projects

Evaluation is the basis of knowledge management.

Template:
A simple Post Project Review template is linked along with a simple format for aProject Completion
Report.