PROJECT MANAGEMENT: CBU2216

1. INTRODUCTION TO PROJECT MANAGEMENT

(1) What is Project Management?

A project is “A temporary endeavor undertaken to create a unique product or service” (Project
Management Institute, 2001, cited in Meredith and Mantel, 2003, p.8). Lester (2007, p.1) define
it as “A unique set of coordinated activities, with starting and finishing points, undertaken by an
individual or organization to meet specific objectives within defined schedule, cost and
performance parameters”. Lester (2007, p.1) argues that project management is essentially
management of change, while running a functional or ongoing business is managing a continuum
or ‘business-as-usual’. It is not applicable when to running a factory making sausage pies but it
will be the right system when there is a requirement to relocate the factory, build an extension or
produce a different product requiring new machinery, skills, staff training and even marketing
techniques. Projects may be undertaken to generate revenue, such as introducing methods for
improving cash flow or be capital projects which require additional expenditure and resources to
introduce a change to the capital base of the organization.
Project organization Functional or ongoing concern
Building a house Manufacturing bricks
Designing a car Mass producing cars
Organizing a party Serving the drinks
Setting up a filing system Doing the filing
Setting up retail cash points Selling goods and operating tills
Building a process plant Producing sausages
Introducing a new computer system Operating credit control procedures
Unique (delivers change) Repetitive (keeps business running)
Temporal organizational structure Permanent organizational structure
Has start, middle and end. On going, no clear end.

From the definition above, it is clear that a project has a definite starting and finishing point and
must meet certain specified objectives. These objectives must meet three fundamental criteria:
(1) the project must be completed on time; (2) the project must be accomplished within the

1
budgeted cost; (3) the project must meet the prescribed quality requirements. In industries like
airlines, railways and mining, a fourth criterion, safety, is considered to be equally important.

Time-bound project
A scoreboard for a prestigious tennis tournament must be finished in time for the opening match,
even if costs more than anticipated and the display of some secondary information, such as the
speed of the service, has to be abandoned. Cost and performance are sacrificed to meet the
unalterable starting date of the tournament. E.g. SA world cup 2010; Brazil 2014.

Cost-bound project
A local authority housing development may have to reduce the number of housing units but the
project cost cannot be exceeded, because the housing grant allocated by central government for
this development has been frozen at a fixed sum. An alternative would be to reduce the
specification of the internal fittings instead of reducing the number of units.

Performance (Quality)-bound project

An armaments manufacturer has been contracted to design and manufacture a new type of rocket
launcher to meet the client’s performance specification in terms of range, accuracy and rate of
fire. Even if the delivery has to be delayed to carry out more tests and the cost has increased, the
specification must be met.

Safety-bound project
Not only must safe practices be built into every project, but constant monitoring is an essential
element of a safety policy. All projects are safety-bound since if it became evident after an
accident that safety was sacrificed for speed or profitability, some or the entire project

2
stakeholders could find themselves in real trouble, if not in jail. A serious accident which may
kill or injure people will not only cause anguish among relatives, but, while not necessarily
terminating the project, could very well destroy the company. Hence the ‘S’ symbol in the
middle of the project management triangle gives more emphasis of its importance. The 3 points
on the triangle are time, cost and quality performance (scope).

The outcome of a project is its performance. The expectations of the client are an inherent part of
the project specifications since the client specifies a desired outcome. Then the project team
designs and implements the project. Then the client views the result of the team’s ideas. In a
building project, for example, the building must meet the client’s expectations as well as those of
the builder, which may require more than slavish conformity to the builder’s blue-prints. There
are quality, safety, esthetic, and environmental dimensions to performance that cannot be
overlooked if the project is to meet its goals. The expectations of the client and project team
should be integrated throughout the entire project.

The Tower of Babel or the Egyptian pyramids were some of the first projects but modern project
management begun with the Manhattan Project. Noah must have managed one of the earliest
recorded projects in the Bible – the building of the ark. He may not have completed it to budget
but he certainly had to finish it by a specified time – before the flood and it must have met his
performance criteria, as it successfully accommodated a pair of all the animals. Project
management is defined as “The planning, monitoring and control of all aspects of a project and
the motivation of all those involved in it, in order to achieve the project objectives within agreed
criteria of time, cost and performance” (Lester, 2007, p.5). Key to project management success is
motivation – a project will not be successful unless most of the participants are not only
competent but also motivated to produce a satisfactory outcome.

Purpose of a project
A project is usually a one-time activity with a well-defined set of desired end results (Meredith
and Mantel, 2003, p.9). It can be divided into subtasks that must be accomplished in order to
achieve the project goals. The project is complex enough that the subtasks require careful
coordination and control in terms of timing, precedence, cost, and performance. The project is

3
often coordinated with other projects being carried out by the same parent organization. The
purpose is to deliver a quality product to the client.

Life Cycle
Projects have life cycles. From a slow beginning they progress to a buildup of size, then peak,
begin to decline, and finally must be terminated. Some projects end by being phased into the
normal, ongoing operations of the parent organization.
Task
Read and write notes on the different phases of a project life cycle.

Interdependencies
Projects often interact with other projects being carried out simultaneously by their parent
organization – they always interact with the parent organization’s standard, ongoing operations.
The interactions between an organization’s functional departments (marketing, finance,
manufacturing etc.) with projects tend to be changeable. Marketing may be involved at the
beginning and end of a project but not in the middle. Manufacturing may have major
involvement throughout. Finance is often involved at the beginning and accounting (the
controller) at the end as well as at periodic reporting times.

Uniqueness
Every project has some elements that are unique. No two projects are precisely alike. Projects
have some degree of customization.

Conflict
Project management lives in a world characterized by conflict. Projects compete with functional
departments for resources and personnel. With the growing proliferation of projects there is
project-versus-project conflict for resources within multi-project organizations. The members of
the project team are in almost constant conflict for the project’s resources and for leadership
roles in solving project problems.
Task
Read and write notes on features of a project.

4
(2) What is a Project Manager?
A project manager may be defined as “The individual who has the responsibility, authority and
accountability assigned to him or her achieve safely the project objectives within agreed time,
cost and performance/quality criteria” (Lester, 2007, p.6). Meredith and Mantel (2003, p.6) say
that the project manager is expected to integrate all aspects of the project, ensure that the proper
knowledge and resources are available when and where needed, and above all, ensure that the
expected results are produced in a timely, cost-effective manner. Some organizations complain
that the responsibility and accountability vested in the project manager is either severely
restricted or non-existent. The reasons for this may be reluctance of a department (usually one
responsible for the accounts) to relinquish financial control or it is perceived that the project
manager has not sufficient experience to handle certain tasks such as control of expenditure.
There may be good reasons for these restrictions but the project manager is supposed to be in
effect the managing director of the project and therefore should have control over costs and
expenditure, albeit within specified and agreed limits.

Apart from the conventional responsibilities for time, cost and performance/quality, the project
manager must ensure that all the safety requirements and safety procedures are complied with.
Hence the word safety has been inserted into the project management triangle to reflect the
importance of ensuring the many important health and safety requirements are met.

Some organizations issue a ‘Project Manager’s Charter’ which sets out the responsibilities and
limits of authority of the project manager. This makes it clear to the project manager what his
areas of accountability are and if this document is included in the project management plan, all
stakeholders will be fully aware of the role the project manager will have in this particular
project. It is project specific and will have to be amended for every manager and type, size or
complexity of project (Lester, 2007, p.6).

The project manager can be chosen and installed as soon as the project is selected for funding or
at any earlier point that seems desirable to senior management. In some cases the Project
Manager (PM) is chosen late in the project life cycle, usually to replace another PM who is

5
leaving the project for other work. A senior manager briefs the PM on the project so that the PM
can understand where it fits in the general scheme of things in the parent organization, and the
priority relative to other projects in the system. The PM’s first set of tasks is typically to prepare
a preliminary budget and schedule, to help select people to serve on the project team, to get to
know the client, to make sure that the proper facilities are available, to ensure that any supplies
required early in the project life are available when needed, and to take care of the routine details
necessary to get the project moving (Meredith and Mantel, 2003, p.118).

As people are added to the project, plans and schedules are refined. The details of managing the
project through its entire life cycle are spelt out, even to the point of planning for project
termination when the work is finally completed. Mechanisms are developed to facilitate
communication between the PM and top management, the functional areas, and the client. As
plans develop still further, the PM holds meetings and briefings to ensure that those who will
affect or be affected by the project are prepared in advance for the demands they will have to
meet as the project is implemented.

A PM starts his or her career as a specialist in some field who is informed by a senior manager
that he/she is being promoted to the position of PM. The PM must now metamorphose from
technical caterpillar into generalist butterfly. The PM, new or experienced, must oversee many
functional areas, each with its own specialists. Therefore he/she is required to have an ability to
put many pieces of a task together to form a coherent whole – must be more skilled at synthesis
whereas the functional manager must be more skilled at analysis. The functional manager uses
the analytic approach and the PM use the systems approach.

The analytic method focuses on breaking the components of a system into smaller and smaller
elements. The systems approach maintains that to understand a component we must understand
the system of which the component is a part. And to understand the system we must understand
the environment of which it is a part. Blaise Pascal (cited in Meredith and Mantel, 2003, p.121)
says “I find as impossible to know the parts without knowing the whole, as to know the whole
without specifically knowing the parts”. Adoption of the systems approach is crucial for the PM.
One cannot understand and, thus, cannot manage a project without understanding the

6
organizational program, of which the project is a part, and the organization in which the program
exists, as well as the environment of the organization. Consider the problem of managing a
project devoted to the development of software that will create and maintain a database, and to
undertake this task without knowing anything about the decision support system in which the
database will be used, or the operating system of the computers that will contain the DSS, or the
purposes for which the information in the database will be used etc.

The functional manager is a direct, technical supervisor. The PM is a facilitator and generalist.
But both require specialized technical knowledge. The functional manager’s knowledge must be
in the technology of the process being managed. The PM must be competent in the science of
project management and also have technical competence in some aspects of the work being
performed on the project. The PM is responsible for organizing, staffing, budgeting, directing,
planning, and controlling the project. The PM manages the project but the functional managers
may affect the choice of technology to be used by the project and the specific individuals who
will do the work. The PM may suffer from micromanagement – this is when the PM’s immediate
superior exercises extremely close supervision over every action the PM takes or actually tell the
PM precisely what to do. This stamps out any creativity or initiative from the PM or project
workers, frustrates almost everyone connected with the project and generally ensures mediocre
performance, if not failure. At the other end the relationship between the PM, the functional
managers, the project team, and the PM’s superior may be characterized as “collegial” and the
organization may be populated by talented people. Here conflict is minimized, cooperation is the
norm, no one is terribly concerned with who gets the credit, and the likelihood of success is high.
Effective teams tend to operate in a collegial mode (but success needs talent).

Project Responsibilities
The PM’s responsibilities fall into three separate areas: responsibility to the parent organization,
responsibility to the project and the client, and responsibility to the members of the project team.
Responsibilities to the firm include proper conservation of resources, timely and accurate project
communications, and the careful, competent management of the project. It is very important to
keep senior management of the parent organization fully informed about the project’s status,
cost, timing, and prospects. Senior managers should be warned about likely future problems.

7
Reports must be accurate and timely if the PM is to maintain credibility, protect the parent firm
from high risk, and allow senior management to intercede where needed. The PM must never
allow senior management to be surprised.

The PM’s responsibility to the project and client is met by ensuring that the integrity of the
project is preserved in spite of the conflicting demands made by the many parties who have
legitimate interests in the project. The manager must deal with the engineering department when
it resists a change advised by marketing, which is responding to a suggestion that emanated from
the client. Meanwhile contract administration says the client has no right to request changes
without the submission of a formal Request for Change order. Manufacturing says that the
argument is irrelevant because marketing’s suggestion cannot be incorporated into the project
without a complete redesign. The PM must sort out understanding from misunderstanding,
soothe ruffled feathers, balance petty rivalries, and cater to the demands of the client. Further, the
PM must keep the project on time, within budget, and up to specifications.

The PM’s responsibilities to members of the project team are dictated by the finite nature of the
project itself and the specialized nature of the team. Because the project is, by definition, a
temporary entity and must come to an end, the PM must be concerned with the future of the
people who serve on the team. If the PM does not get involved in helping project workers with
the transition back to their functional homes or to new projects, then as the project nears
completion, project workers will pay more attention to protecting their own future careers and
less to completing the project on time.
Task
The PM should have many skills in order to have a reasonable chance of success. These include
credibility, sensitivity, leadership and management style, ability to handle stress etc. Read and
write notes on these skills as they influence the success of a project manager.

(3)Merits and Demerits of Project Management.

The basic purpose for initiating a project is to accomplish specific goals. The reason for
organizing the task as a project is to focus the responsibility and authority for the attainment of
goals on an individual or small group. The project form of organization allows the manager to be

8
responsive to: (1) the client and the environment (2) identify and correct problems at an early
date (3) make timely decisions about trade-offs between conflicting project goals and (4) ensure
that managers of the separate tasks that comprise the project do not optimize the performance of
their individual tasks at the expense of the total project – that is, that they do not sub-optimize
(Meredith and Mantel, 2003, p.11).

Experience with project management indicates that the majority of organizations using it
experience better control and better customer relations (Davis, 1974 cited in Meredith and
Mantel, 2003, p.11) and probably an increase in their project’s return on investment (Ibbs and
Kwak, 1997 cited in Meredith and Mantel, 2003, p.11). A significant proportion of users also
report shorter development times, lower costs, higher quality and reliability, and higher profit
margins. Other reported advantages include a sharper orientation towards results, better
interdepartmental coordination, and higher worker morale.

Disadvantages – most organizations report that project management results in greater

organizational complexity. Many also report that project organization increases the likelihood
that organizational policy will be violated – not a surprising outcome, considering the degree of
autonomy required for the Project Manager. A few firms reported higher costs, more
management difficulties, and low personnel utilization. Another limitation is that the mere
creation of a project may be an admission that the parent company and its managers cannot
accomplish the desired outcomes through the functional organization. Further, conflict seems to
be a necessary side-effect.

Task
Identify and explain other project management merits and de-merits not given above.

9
2. PLANNING WORK BREAKDOWN STRUCTURES

(1) The Planning Phase Concept.

The primary purpose of planning is to establish a set of directions in sufficient detail to tell the
project team exactly what must be done, when it must be done, and what resources to use in
order to produce the deliverables (goods and/or services we promise to deliver to client at a
quality level that will meet client expectations) of the project successfully.

Initial Project Coordination

The project’s goals should be tied to the overall mission, goals and strategy of the organization.
Senior management should outline the scope of the project and describe how the project’s
desired results reinforce the organization’s goals. A senior manager should call and be present at
the project launch meeting – should define the scope of project. The success of this launch
meeting is dependent on the existence of a well-defined set of objectives. At planning meeting all
parties should have a clear understanding of precisely what it is the project is expected to deliver.
At this meeting, the project is discussed in sufficient detail that potential contributors develop a
general understanding of what is needed. The discussion can be short and routine if project is
similar to other projects but extensive if it’s unique.

It is useful to review the major risks facing the project at this stage. Known risks are likely to
focus on the market reaction to a new process/product, the potential feasibility of an innovation
etc. At the planning stage a risk management plan should develop. The initial meeting should not
make detailed plans so as to allow team members to add details in future meetings.

The outcome of the first meeting must be that: (1) technical scope is established (though not ‘cast
in concrete’); (2) basic areas of performance responsibility are accepted by the participants; (3)
some tentative overall schedules and budgets are spelled out; and (4) a risk management group is
created. Each individual/unit accepting responsibility for a portion of the project should agree to
deliver by the next project meeting, a preliminary but detailed plan about how that responsibility
will be accomplished. Plans should contain descriptions of the required tasks and estimates of the
budgets and schedules. The risk management group develops a risk management plan that

10
includes proposed methodologies for managing risk, the group’s budget, schedule, criteria for
dealing with risk, and required reports. The process of risk management is not a static process, it
is ongoing, with constant updating as more risks are identified and some vanish.

The various parts of the project plan, including the risk management plan, are then scrutinized by
the group and combined into a composite project plan. The composite plan is approved by each
participating group, by the project manager, and then by senior org. management. When the plan
is endorsed by senior management any further changes in the project’s scope must be made by
processing a formal change order. This written notice has to be approved by top management.
The PM takes responsibility for gathering the necessary approvals and assuring that any changes
incorporated into the plan at higher levels are communicated to, and approved by, the units that
have already signed off on the plan. Failure to communicate alterations is considered a betrayal
of trust. In one organization the anger was so great that two chief designers resigned and took
jobs with a competitor.

Hence any modifications of the plan by senior managers have to taken by the PM to the
contributing units for consideration and re-approval of the plan as modified. The final, approved
result of this procedure is the project plan or the master plan or the baseline plan or the project
charter. When the planning phase of the project is completed, it is valuable to hold one
additional meeting, a post-planning review (Martinez cited in Meredith and Mantel, 2003,
p.244). This meeting should be chaired by an experienced project manager who is not connected
with the project. The major purpose of the post-planning review is to make sure that all
necessary elements of the project plan have been properly developed and communicated.

Outside clients
When the project is to deliver a product/service to an outside client, the fundamental planning is
unchanged except that the specifications cannot be altered without the client’s permission. It is
important that marketing, manufacturing, engineering and all other key members of the project
team are involved in the planning process at the time the original proposal is made to the
potential client. However, marketing tends to object to early participation of engineering and
manufacturing since according to marketing, these two do not understand sales techniques and

11
are likely to be argumentative in the presence of the client. It is also very expensive to involve so
much technical talent so early in the process. However, it is appropriate to urge that anyone
meeting customers face to face should receive some training in the tactics of selling.

Project Plan Elements

The process of developing the project plan varies from organization to organization, but any
project plan must have the following elements:
 Overview – short summary of the objectives and scope of the project. It has a statement
of goals of the project, a brief explanation of their relationship to the firm’s objectives, a
description of the managerial structure that will be used for project, and a list of the major
milestones in the project schedule.
 Objectives – more detailed statement of the general goals noted in the overview section.
The statement should include profit and competitive aims as well as technical goals.
 General Approach – this describes both the managerial and technical approaches to the
work. The technical discussion describes the relationship of the project to available
technologies. E.g. it might note that this project is an extension of work done by the
company for an earlier project. The managerial approach takes note of any deviation from
routine procedure – for instance, the use of subcontractors for some parts of the work.
 Contractual Aspects – this section includes a complete list and description of all reporting
requirements, customer-supplied resources, liaison arrangements, advisory committees,
project review and cancellation procedures, proprietary requirements, any specific
management agreements (e.g. use of subcontractors) as well as the technical deliverables
and their specifications, delivery schedules, and a specific procedure for changing any of
the above.
 Schedules – outlines the various schedules and lists all milestone events. Each task is
listed and the estimated time for each task should be obtained from those who will do the
work. The project master schedule is constructed from these inputs.
 Resources – there are two aspects. First is the budget – both capital and expense
requirements are detailed by task, which makes this a project budget. One-time costs are
separated from recurring project costs. Second, cost monitoring and control procedures
are described. Monitoring and control procedures must be designed to cover special

12
 resource requirements for the project, such as special machines, test equipment,
laboratory usage or construction, logistics, field facilities, and special materials.
 Personnel – this lists the expected personnel requirements of the project. Special skills,
types of training needed, possible recruiting problems, legal or policy restrictions on
work force composition, and any other special requirements such as security clearances,
should be noted here (security – need to protect trade secrets and research targets from
competitors as well as need to protect national security). There is need to time-phase
personnel needs to the project schedule – makes it clear when various types of
contributors are needed and in what numbers.
 Evaluation Methods – every project should be evaluated against standards and by
methods established at the project’s inception. This section contains a brief description of
the procedure to be followed in monitoring, collecting, storing, and evaluating the history
of the project.
 Potential Problems – this is the province of risk management. Possible disasters include
subcontractor default, technical failure, strikes, bad weather, sudden required
breakthroughs, critical sequences of tasks, tight deadlines, resource limitations, complex
coordination requirements, insufficient authority in some areas, and new, complex, or
unfamiliar tasks are certain to occur. The only uncertainties are which ones will occur
and when. There are times, conditions, and events in the life of every project when
progress depends on subcontractors, or the weather, or coordination, or resource
availability, and plans to deal with unfavorable contingencies should be developed early
in the project’s life cycle. Some PMs avoid dealing with risk because “Trying to list
everything that can go wrong gets every in a negative state of mind. I want my people to
be positive!” (Meredith and Mantel, 2003, p.247). While it is true that no amount of
current planning can solve the current crisis but pre-planning may avert some.

These are the elements that constitute the project plan and are the basis for more detailed
planning of the budgets, schedules, work plan, and general management of the project. Once this
basic plan is fully developed and approved, it is disseminated to all interested parties. As noted
earlier this is the project charter. This formal planning is required for relatively large projects
that cannot be classified as routine for the organization.

13
Project Planning in Action
Project plans are usually constructed by listing the sequence of activities required to carry the
project from start to completion. It is a natural way to think about a project and helps the planner
decide the necessary sequence of things – a necessary consideration for determining the project
schedule and duration. Aaron and his colleagues (1993, cited in Meredith and Mantel, 2003,
p.249) describe the planning process used at a telecommunications firm. Using a planning
process oriented around the life-cycle events common for software and hardware product
developers, they divide the project into nine segments: concept evaluation; requirements
identification; design; implementation; test; integration; validation; customer test and evaluation;
and operations and maintenance.

Each segment is made up of activities and milestones (significant events). As project passes
through each of the segments, it is subjected to a series of “quality gates” that must be
successfully passed before proceeding to the next segment. E.g. the requirements identification
segment must meet the appropriate quality standards before the design segment can be started,
just as design must be approved before implementation can be commenced.

Systems Integration
This is sometimes called systems engineering or concurrent engineering. It is part of integration
management and plays a crucial role in the performance aspect of the project. It includes any
technical specialist in the science or art of the project who is capable of integrating the technical
disciplines to achieve the customer’s objectives. It is concerned with three major objectives.

1. Performance – this is what a system does. It includes system design, reliability, quality,
maintainability, and repairability. These are not separate, independent elements of the system but
are interrelated qualities. Any of these system performance characteristics are subject to
overdesign or under-design but must fall within the design parameters established by the client.
At times the aesthetic qualities of a system may be specified, typically through a requirement that
the appearance of the system must be acceptable to the client.

14
2. Effectiveness – the objective is to design the individual components of a system to achieve the
desired performance in an optimal manner. This is accomplished through the following
guidelines:
 Require no component performance specifications unless necessary to meet one or more
systems requirements.
 Every component requirement should be traceable to one or more systems requirements.
 Design components to optimize system performance, not the performance of subsystems.
It is possible for clients or project teams to violate any or all of these guidelines. Focus on the
total product rather than separate items.

3. Cost – systems integration considers cost to be a design parameter, and costs can be
accumulated in several areas. Added design cost may lead to decreased component cost, leaving
performance and effectiveness otherwise unchanged. Added design cost may yield decreased
production costs, and production cost may be traded off against unit cost for materials.

If a risky approach is taken by systems integration, it may delay the project. If the approach is
too conservative, we forego opportunities for enhanced project capabilities or advantageous
project economics. A good design will take all these trade-offs into account in the initial stages
of the technical approach. A good design will also avoid locking the project into a rigid solution
with little flexibility in case problems occur later or changes in the environment demand changes
in project performance or effectiveness.

Sorting out the project

Here we need to know exactly what is to be done, by whom, and when. All activities required to
complete the project must be precisely delineated and coordinated. The necessary resources must
be available when and where they are needed, and in the correct amounts. Some activities must
be done sequentially, but some may be done simultaneously. If a large project is to be completed
on time and within cost, a great many things must happen when and how they are supposed to
happen. Yet each of these details is uncertain and thus each must be subjected to risk
management. This section focuses on the hierarchical planning system (or even planning
process) – a method of constructing an action plan or WBS.

15
To accomplish any specific project, a number of major activities must be undertaken and
completed. Make a list of these activities in the general order in which they would occur. This is
Level 1. A reasonable number of activities at this level might be anywhere between 2 and 20 (20
is about the largest number of interrelated items that can be comfortably sorted and scheduled at
a given level of aggregation). Now break each of these Level 1 items into 2 to 20 tasks. This is
Level 2. In the same way, break each Level 2 task into 2 to 20 subtasks. This is Level 3. Proceed
in this way until the detailed tasks at a level are so well understood that there is no reason to
continue with the work breakdown.

It is important to be sure that all items in the list are at roughly the same level of task generality.
In writing a book, for example, the various chapters tend to be at the same level of generality, but
individual chapters are divided into finer detail still. It is difficult to overstate the significance of
this simple dictum. An artist explained: when creating a drawing, the artist sketches in the main
lines of a scene, and then builds up the detail little by little over the entire drawing. In this way,
the drawing has a “unity”. One cannot achieve this unity by drawing one part of the scene in high
detail, then moving to another part of the scene and detailing it.

Maintaining the “even planning” discipline will help keep the plan focused on the project’s
deliverables rather than on the work at a subsystem level. Sometimes some managers tend to
think of outcomes (events) when planning and others think of specific tasks (activities). Many
mix the two. In hierarchical planning the objectives are taken from the project plan. This aids the
planner in identifying the set of required activities for the objectives to be met, a critical part of
the action plan. Each activity has an outcome (event) associated with it, and these activities and
events are decomposed into sub-activities and sub-events, which in turn are subdivided again.

Activity and resource plans

A plan is a progressive statement of objectives, tactics and operations, needed to take the project
from start to its successful conclusion. These plans are more detailed than the project master
plan. Activity and resource plans show the order and methods by which the main activities will
be tackled and their resources provided.

16
Activity plans
Plans for complex or difficult activities will include:
 Activity description;
 Activity objective(s);
 Methods and processes to be used;
 Sequence and timing of tasks;
 Resources (for inclusion in the project budgets and resource plans);
 List of operations, sequence, workflow and coordination;
 Limitations on time for completion of the activity and time scale;
 Quality standards and requirements;
 Control, monitoring and progress reporting;
 Links to the resource plan showing provisioning arrangements.

Resource plans
Resources needed for the project administration and to complete each activity are specified,
costed and brought into a consolidated list showing both the detail of each requirement and the
total resource requirement.

The finance plan

All projects need finance: hence the need for a formal plan for finance. It will usually cover:
 Limits of available finance;
 Source and method of securing finance;
 Cost of finance;
 Project budget;
 Cash flow predictions covering the project;
 Procedures for controlling project costs;
 Procedures for authorization of payments and acquisition of funds;
 Accounting procedures.

17
Machinery and equipment plan
This will include:
 Machinery and equipment needs;
 Specifications and delivery dates;
 Costing;
 Method of acquisition e.g. loan, purchase, lease etc. and source of supply;
 Maintenance service and repairs;
 Operator and service training requirements;
 Power and fuel needs associated with major equipments;
 Disposal of machines and equipment on completion of the activity.

The manpower plan

The manpower plan may include:
 Human resource needs by categories, skills and abilities;
 When and for how long each number and category will be required;
 Method of acquisition – casual employment, contract, subcontract, team employment;
 Method of recruitment – availability register, international advertising, professional
society, consultant, employment agency, local advertising, local colleges & universities;
 Budgeted cost – salary, wages, budgeted overtime, bonus, allowances, incentive
payments, accommodation, insurance, gratuities, travel, subsistence etc.
 Job and recruitment specifications for key managers and specialist members of the
project team;
 Employment policies and selection methods e.g. screening processes, employment of
local people, equal opportunity;
 Special selection procedures;
 Occupational health, safety and welfare provisions.

Materials and merchandise plans

Plans for the provision of materials or purchased goods may include:

18
  Purchasing, tendering and contract policies and timeframes;
 Description, quantity and quality specifications;
 Transportation arrangements for bulk supplies;
 Penalty clauses for late delivery.
Task
1. Explain the need to check the plans and reporting procedures of a major project
contractor and what criteria might be appropriate for their evaluation.
2. Consider how build, operate and transfer (BOT) projects are planned and operated. Under
what circumstances may a BOT agreement be the best way of meeting project needs?

(2) Assigning Resources.

Efficiency in providing and managing resources is fundamental to project success. Each project
will demand a unique combination of type, quality and volume of resources = capital intensive or
rely heavily on technology, new processes, equipment or the application of specialized
knowledge and expertise. Resources are the lifeblood of a project and therefore must be
carefully chosen, accurately specified and their acquisition carefully planned.

Resources must be available where and when required and their use properly controlled. Over-
resourcing is wasteful and leads to diminished cost-effectiveness and, sometimes, delay in
project completion. Under-resourcing will strangle the project and a shortage of essentials may
lead to total failure (e.g. NUST campus library). Effective resource management entails
providing the project with all the essential items, even small items that are nonetheless vital to
the process. Project success (implementation) will depend on making all resource needs available
at the planning stage.

The seven resource groups

1. Money -- finance for the project (all projects).
2. Materials – raw and manufactured materials (most projects).
3. Merchandise --manufactured goods of various kinds, including food (many projects).

19
 4. Machinery – this includes equipment for use in the course of project work e.g.
infrastructure, construction, engineering and some technical projects.
5. Manpower – people with appropriate levels of skill to develop, design or perform
specified work.
6. Management, professionals and specialists – to manage the project, lead activities,
provide specialist expertise and advice or carry out work on sensitive or complex project
issues (all projects to varying degree).
7. Movement – transportation of people, machinery and equipment, materials, mail, and
other essentials, to and from the project site and within the project area – not commonly
included in business resource planning but important in project and resource planning.
Every project has its own needs. Any shortage or late delivery of key resources will usually
result in project delay or even failure.

Project Manager’s responsibility for resources

Resourcing and provisioning functions by project managers usually include:
 Determining needs, quantities and required delivery dates (what is needed and when);
 Defining and confirming technical and quality specifications;
 Determining the best source of supply, method and terms of purchase;
 Contracting and agreement, prices and terms;
 Arranging transport and storage;
 Confirming deliveries (quantities, quality, condition etc.);
 Pay authorization;
 Control in the use of stores, accounting and security;
 Disposal of surplus and used items no longer required.

The financial resource

The initial estimates of costs are done at feasibility study stage. When the project has been given
go-ahead, further planning will offer more and more detail on each main resource need. Details
of specification, quality, availability, required delivery time, transportation and storage will
become clear and can be accurately assessed, tenders invited and evaluated and contracts
negotiated.

20
This is time to review expense estimates and arrive at more accurate figures of resource costs,
and the total finance need, cash flow, interest charges or credits, customs duties, taxation (if
applicable) etc. A review of other aspects of the master plan, the project’s activities and the
methods to be used will help to confirm major expenses and finance estimates, details of which
will themselves form a major section of the master plan.

Concurrent resource planning

As we work through the plan and schedule each activity, its resource needs will be disclosed;
they can then be programmed and their cost estimated. So in planning of each activity, resource
lists, quantities, specifications and schedules are developed. Project stages and tentative dates
when each item will be required are established and lead times for order and delivery or
replenishing the resource can be estimated. An easy way is to endorse the master plan and
activity charts with estimated total costs of each activity.

The resource schedule

Having established the main resource needs, a schedule listing each item, its expected cost and
required delivery date can be drawn up. The schedule is updated as each item is requisitioned,
ordered, delivered and paid for.

Inventory control
This means knowing where, when and how to order so that the project always has enough but not
too much, of the right things, accounting for their use and maintaining security over them. Large
project inventories are difficult to control (subject to decisions by a range of people – locally
employed contractors or temporary project employees). Therefore, check and record receipts,
deliveries and storage details, and to control and record materials consumed. These records must
always be up to date for costing and accounting purposes, and to enable replenishments to be
ordered within the required lead time.

Inventory levels and lead times for orders need to be checked regularly. Loss of resources
(through theft or misuse) may delay completion of an important activity and disrupt the whole

21
timetable. Proper disbursement of funds is needed: so accounts of expenditures, issues, supply
movements and usage are essential safeguards against false allegations, fraud, loss, misuse and
non-availability of supplies. These accounts should be regularly checked and audited.

Cost of late delivery

Delay in delivery of equipment or materials is a common cause of cost escalation caused by
disruption of project time schedules. It is necessary to scrutinize suppliers of key resources for
reliability, financial capacity and performance capability. Late delivery may be a result of failure
to remit moneys when they are due, hence suppliers’ reluctance to provide good service. It is
important to check the supplier’s order cycle times, that is, supplier’s ability to meet delivery
dates and deadlines. Loss of customer goodwill; expediting costs; reduce company image;
replacement costs; reduced customer satisfaction etc.

Accuracy of specifications
It is important to specify:
 All key items – technical specifications, quality, delivery date, price and terms of
payment;
 All contract work – extent, quality, completion date and price;
 All technical support –nature, extent, quality and cost;
 All key posts – duration of work, responsibilities, capability, qualifications, experience,
remuneration;
 All training for project employees (including training to be provided by manufacturers as
part of a re-equipment programme) – number of trainees and the standards of competence
to be achieved;
 Standards of serviceability for leased or contract-serviced machinery and equipment;
 Minimum standards of maintenance to be provided for purchased machinery or
equipment.

Contracts for the supply of resources

Contracts for the supply of resources often follow an ‘Invitation’ or ‘Request to Quote’ or a
‘Request for Tender’. A contract is a legally binding agreement (Oxford Dictionary of Law). It is

22
“any agreement between two or more parties where one party agrees to provide certain deliveries
or services, and the other party agrees to pay for those deliveries or services”
(http://www.project-management-knowhow.com/contract_management.htm ). The law of
contract varies between legal systems. In many countries a contract must satisfy 6 criteria:
1. Manifestation of intent, that is, offer and acceptance, some form of agreement;
2. Consideration – some form of payment or reward;
3. Capacity to contract – legal capacity and authority;
4. Reality of intent – freedom of error, or duress;
5. Legality of purpose – the contract cannot be for an illegal act;
6. The agreement must comply with any formal legal requirements e.g. common law (in the
USA, the Statute of Frauds etc.).
The contract may have some form of penalty clauses written and may not make for project
success since they may be difficult to apply before the consequences of delay are felt. But
stringent penalty clauses may deter a good contractor from tendering or cause him to increase the
quote cost substantially as an insurance against unforeseen difficulty.

Fixed price incentive contracts = both parties agree on target cost and the contractor’s target
profit e.g. Target cost $500 million; Target profit $ 50 million and Ceiling cost $600 million. The
parties agree that, if the cost is less than $500 million the contractor is paid 30% of the saving
and costs in excess of $500 million will be 70% financed by the customer, 30% by the
contractor.
Cost-plus contracts reimburse the contractor for work done. Payment usually includes both
direct and indirect costs incurred and a margin of profit. To prevent price escalation, strict
monitoring procedures should be agreed between both parties and carefully observed. Terms of
payment should follow a legally approved form and be set out in the contract.

Provision of machinery and equipment

Decisions relating to combinations of machinery and labour costs call for information on:
1. Initial cost of equipment;
2. Length of useful life;
3. Estimated resale of value;

23
 4. Maintenance and repair costs;
5. Machine operating costs;
6. Labour costs for the activity;
7. Cost of special training related to the machine or method.
Decisions on whether to lease or buy project equipment will be based on:
1. Whether funds are available for purchase;
2. The cost of financing the purchase (interest on borrowed money or how much the funds
could earn if otherwise invested);
3. The useful life of the machine;
4. The cost of possible breakdown and , or maintenance (particularly when the leasing
contract provides for free replacement and /or maintenance);
5. In case where the project produces revenue, the earning potential of the asset and the
relative effects on taxation;
6. Present value of future payments;
7. Likely resale value of the asset when the project is completed.
When costly machinery or equipment is required for limited periods, leasing may be a sensitive
option.

Predicting manpower needs

The availability, quality and cost of manpower varies greatly within countries; therefore, the PM
should go for the best quality and smallest workforce able to accomplish the job within planned
time limits. Allow adequate lead time for recruitment, testing, selection and training because a
hastily recruited workforce may incur major difficulties. Planning and budgeting should take
care of the cost of special work conditions, limitations or restrictive practices.

As resource lists are made for each activity, overall manpower needs become apparent. For
projects located in a remote area (extreme weather conditions) recruitment incentive payments
may be necessary and extra time allowances made for travel or acclimatization. Savings can be
made by rescheduling labour – intensive activities so that tasks can be run consecutively. This
reduces need to dismiss satisfactory members of the workforce when one activity is completed,
only to employ and train similar people a short time later.

24
Some advantages may be found in prolonging tasks that are not on the critical path to reduce the
number of people needed. If this can be done without prejudice to the project completion date,
those employed may be able to move directly from one task to another, minimizing severance
and recruiting, familiarization and training costs and improving employee stability and
motivation.

Computer assistance in scheduling manpower

The process of listing manpower and other resource needs can be assisted by means of one of the
user-friendly software programmes that are readily available e.g. Microsoft Project which offers
a facility for resource scheduling linked to the activity list.
Task
For more details about manpower activity histograms see P.42 and 43.

(3) Project Tools.

Project management tools include “Critical Path Method” (CPM), “Programme Evaluation
Review Technique” (PERT) and the Gantt chart. Complex projects require a series of activities,
some of which must be performed sequentially and others can be performed in parallel with
other activities. This collection of series and parallel tasks can be modeled as a network. In 1957
the Critical Path Method (CPM) was developed (by DuPont, Inc.) as a network model for project
management. CPM is a deterministic method that uses a fixed time estimate for each activity.
While CPM is easy to use it does not consider the time variations that can have a great impact on
the completion time of a complex project. The Programme Evaluation Review Technique
(PERT) is a network model that allows for randomness in activity completion times. PERT was
developed by the US Navy in cooperation with Booz-Allen Hamilton and the Lockheed
Corporation for the Polaris missile/submarine project in 1958. It has the potential to reduce both
the time and cost required in completing a project. The PERT and CPM are quite similar and are
often combined for educational presentation.

The Network Diagram

25
In a project, an activity is a task that must be performed and an event is a milestone marking the
completion of one or more activities. For more definition of key terms see topic 3 (p.35).
Before an activity can begin, all of its predecessor activities must be completed. Project network
models represent activities and milestones by arcs and nodes. PERT originally was an activity on
arc network, in which the activities are represented on the lines and milestones represented on
the nodes. The current discussion follows this original form of activity on arc. The PERT chart
may have multiple pages with many sub tasks. The following is a very simple example of a
PERT diagram:

B D
A

C E

The milestones generally are numbered so that the ending node activity has a higher number than
the beginning node. Incrementing the numbers by ‘A’ allows for the new ones to be modified
without necessarily the numbering of the entire diagram. The activity in the above diagram is
labeled with letters along with expected time required to complete the activity.

PERT planning involves the following steps:

 Identify the specific activities and milestones;
 Determine the proper sequence of activities;
 Construct a network diagram;
 Estimate the time required for each activity;
 Determine the critical path;
 Update the PERT chart as the project progresses.

(a) Identify activities and milestones

26
Activities are tasks required to complete the project. The milestones are the events marking the
beginning and the end of one or more activities. It is helpful to list the tasks in a table that in later
steps can be expanded to include information on sequence and duration.

(b) Determine Activity Sequence

This step may be combined with the activity identification step since the activity sequence is
evident for some tasks. Other tasks may require more analysis to determine the exact order in
which they must be performed.
(c) Construct the Network Diagram
Using the activity sequence information, a network diagram can be drawn showing the sequence
of the serial and parallel activities. Activities are depicted by arrowed lines and milestones are
depicted by circles or “bubbles”. If done manually, several drafts may be required to correctly
portray the relationships among the activities. Software packages simply this step by
automatically converting tabular activity information into a network diagram.
(d) Estimate Activity Times
Weeks are commonly used unit of time for activity completion, but any consistent time can be
used. For each activity, the model usually includes three time estimates:
 Optimistic time – generally the shortest time in which the activity can be completed
(commonly three standard deviations from the mean – hence approximately a 1 percent
chance that the activity will be completed within the optimistic time);
 Most likely time – the completion time having the highest probability. It is not the
expected time.
 Pessimistic time – the longest time that an activity might require.
(e) Determine the Critical path
This critical path is determined by adding the times for the activities in each sequence and
determining the longest path in the project. It is the route with activities that take the longest
time to finish, thus giving the earliest possible time to finish the project. The critical path
determines the total calendar time required for the project. If the activities outside the critical
path speed up or slow down (within limits), the total project time does not change. The amount

27
of time that the non-critical path activity can be delayed without delaying the project is referred
to as slack time.

To determine the critical path four quantities may need to be determined: ES – Earliest Start
time; EF – Earliest Finish time; LS – Latest Start time and LF – latest Finish time. The times are
calculated using the time for the relevant activities. The earliest start and finish times each
activity are determined by working through the network and determining the earliest time at
which an activity can start and finish considering its predecessor activities. The latest start and
finish times are the latest times that an activity can start and finish without delaying the project.
LS and LF are found by working backward through the network. The difference in the latest and
earliest finish of each activity is that activity’s slack. The critical path then is the path through the
network in which none of the activities have slack.

Since the critical path determines the completion of the project, the project can be accelerated by
adding the resources required to decrease the time for the activities in the critical path. Such
shortening of the project sometimes is referred to as project crushing.
(f) Update as Project Progress
Make adjustments in the PERT chart as the project progresses. As the project unfolds, the
estimated times can be replaced by actual times. In cases where there are delays, additional
resources may be needed to stay on schedule and the PERT chart may be modified to reflect the
new situation.

Benefits of PERT
The tool is useful because it provides the following information:
 Expected project completion time;
 Probability of completion before a specified date;
 The critical path activities that impact directly on the completion time;
 The activities that have slack time and that can lend resources to the critical path;
 Start and end dates.
Limitations of PERT include:

28
  The activity time estimates are somewhat subjective and dependent on judgment. With
little experience they become guesswork.
 Even if the activity times are well –estimated, the actual completion time may still vary.
 PERT assumes that the probability of distribution of the project completion time is the
same as that of the critical path. Because other paths can become the critical path if their
associated activities are delayed, PERT consistently underestimates the expected project
completion time.
Critical Path Method (CPM)
The CPM is one of the several related techniques for doing project planning. CPM is for projects
that are made up of a number of individual “activities”. If some of the activities require other
activities to finish before they can start, then the project becomes a complex web of activities.

CPM can help you figure out:

 How long your complex project will take to complete;
 Which activities are “critical”, meaning that they have to be done on time or else the
whole project will take longer.
If you put information about cost of each activity, and how much it costs to speed up each
activity, CPM can help you figure out:
 Whether you should try to speed up the project, and if so,
 What is the least costly way to speed up the project?
CPM analysis steps are:
1. List the activities;
2. Draw the diagram;
3. Set up the CPM spreadsheet;
4. Use Path-find to get the paths;
5. Paste the path information into your spreadsheet;
6. Calculate the paths’ times;
7. Identify the critical path.
N.B. we shall use the manual approach but read more about how the spreadsheet method works.

29
Task:
The information below relates to the activities that have to be carried out to install a machine.
ACTIVITY DESCRIPTION DURATION DEPENDS ON
(DAYS)
A Determine machine specifications 8 -
B Design machine base and facilities 5 A
C Order machine 3 A
D Order materials for base and facilities 2 B
E Wait for machine delivery 12 C
F Wait for base materials, etc. 8 D
G Train machine operators 4 A
H Employ company to install base, etc. 3 B
I Install base and facilities 20 F and H
J Install machine 14 E, G and I

From the above information:

i) Draw the network diagram.
ii) Determine the critical path of the project.
iii) Determine the earliest possible time for finishing the project.
iv) Plot the above information on a Gantt chart.

The Gantt chart

Gantt chart is a type of a bar chart that is used for illustrating project schedules. Gantt charts can
be used in any projects that involve effort, resources, milestones and deliveries. At present, Gantt
charts have become the popular choice of project managers in every field. Gantt charts allow
project managers to track the progress of the entire project. Through Gantt charts, the project
manager can keep a track of the individual tasks as well as of the overall project progression. In
addition to tracking the progression of the tasks, Gantt charts can also be used for tracking the
utilization of the resources in the project. These resources can be human resources as well as
materials used.
Gantt chart was invented by a mechanical engineer named Henry Gantt in 1910. Since the
invention, Gantt chart has come a long way. By today, it takes different forms from simple paper
based charts to sophisticated software packages.

30
In order to use Gantt charts in a project, there are a few initial requirements fulfilled by the
project. First of all, the project should have a sufficiently detailed Work Breakdown Structure
(WBS). Secondly, the project should have identified its milestones and deliveries.
In some instances, project managers try to define the work break down structure while creating
Gantt chart. This is one of the frequently practiced errors in using Gantt charts. Gantt charts are
not designed to assist WBS process; rather Gantt charts are for task progress tracking.
Gantt charts can be successfully used in projects of any scale. When using Gantt charts for large
projects, there can be an increased complexity when tracking the tasks. This problem of
complexity can be successfully overcome by using computer software packages designed for
offering Gantt chart functionalities.
There are dozens of Gantt chart tools that can be used for successful project tracking. These tools
usually vary by the feature offered. The simplest kind of Gantt chart can be created using a
software tool such as Microsoft Excel. For that matter, any spreadsheet tool can be used to
design a Gantt chart template.
Task
Do the task given in the earlier task on project management tools.
Advantages & Disadvantages of the Gantt chart
The ability to grasp the overall status of a project and its tasks at once is the key advantage in
using a Gantt chart tool. Therefore, upper management or the sponsors of the project can make
informed decisions just by looking at the Gantt chart tool. The software-based Gantt charts are
able to show the task dependencies in a project schedule. This helps to identify and maintain the
critical path of a project schedule.
Gantt chart tools can be used as the single entity for managing small projects. For small projects,
no other documentation may be required; but for large projects, the Gantt chart tool should be
supported by other means of documentation. For large projects, the information displayed in
Gantt charts may not be sufficient for decision making.
Although Gantt charts accurately represent the cost, time and scope aspects of a project, it does
not elaborate on the project size or size of the work elements. Therefore, the magnitude of
constraints and issues can be easily misunderstood.

31
3. PROJECT SCHEDULING
(1) Baseline Projectors and Dates
The project’s baseline is used to measure how performance deviates from the plan. Your
performance measurement would only be meaningful if you had an accurate baseline. A project’s
baseline is defined as the original scope, cost and schedule. The project’s baseline must be
completely defined and documented before the project execution and control activities can begin.
Once the project starts execution, the project’s baseline is put under change control to help you
evaluate any further change and its impact on the project. No meaningful measurements can be
made if the scope, cost and schedule are not under strict change control disciplines.
If any change is approved then your new baseline is redefined as the original plan plus the
approved change. It is a good idea to keep records that show how the plan has progressed and
changed over time. Frequent requests for changes to the project requirements may indicate that

32
there was an incomplete initial requirements analysis or the lack of meaningful communication
with users and customers early in the project initiation phase.
A schedule is the conversion of a project plan into an operating timetable (allocating time among
tasks). It serves as the basis for monitoring and controlling project activity and, taken together
with the plan and budget, is probably the major tool for the management of the projects. In a
project environment, the scheduling function is more important than it would be in an ongoing
operation because projects lack the continuity of day-to-day operations and often present much
more complex problems of coordination. A detailed schedule is sometimes a customer-specified
requirement and can also serve as a key input in establishing the monitoring and control systems
for the project.
Not all project activities need to be scheduled at the same level of detail. In fact, there may be
several schedules (e.g. the master schedule, the development and testing schedule, the assembly
schedule). These schedules are based on the previously determined action plan and /or work
breakdown structure (WBS), and it is good practice to create a schedule for each major task level
in the WBS that will cover the work packages. But it is rarely necessary to list all work packages.
One can focus on those that need to be monitored for maintaining adequate control over the
project.
The basic approach of all scheduling is to form a network of activity and event relationships that
graphically portrays the sequential relations between the tasks in a project. Tasks that must
precede or follow other tasks are then clearly identified, in time as well as function. Such a
network is a powerful tool for planning and controlling a project, and has the following benefits:
 It is a consistent framework for planning, scheduling, monitoring, and controlling the
project.
 It illustrates the interdependence of all tasks, work packages, and work elements.
 It denotes the times when specific individuals and resources must be available for work
on a given task.
 It aids in ensuring that the proper communications take place between departments and
functions.
 It determines an expected project completion date.
 It identifies so-called critical activities that, if delayed, will delay the project completion
time.

33
  It also identifies activities with slack (activities that are not critical) that can be delayed
for specified periods without penalty, or from which resources may be temporarily
borrowed without harm.
 It determines the dates on which tasks may be started – or must be started if the project is
to stay on schedule.
 It illustrates which tasks must be coordinated to avoid resource or timing conflicts.
 It also illustrates which tasks may be run, or must be run, in parallel to achieve the
predetermined project completion date.
 It relieves some interpersonal conflict by clearly showing task dependencies.
 It may, depending on the information used, allow an estimate of the probability of project
completion by various dates, or the date corresponding to a particular a priori probability.

Network techniques: PERT and CPM

With the exception of Gantt charts, discussed in topic two, the most common approach to project
scheduling is the use of network techniques such as PERT and CPM. As indicated earlier the two
methods are quite similar, though PERT was originally oriented to the time element of projects
and used probabilistic activity time estimates to aid in determining the probability that a project
could be completed by some given date. CPM, on the other hand, used deterministic activity time
estimates and was designed to control both the time and cost aspects of a project, in particular,
time/cost trade-offs. In CPM, activities can be “crashed” (expedited) at extra cost to speed up the
completion time. Both techniques identified a project critical path with activities that could not
be delayed, and also indicated activities with slack (or float) that could be somewhat delayed
without lengthening the project completion time.
Task: Critically examine the differences between PERT and CPM in project management.
To understand networks a few definitions are needed.
Activity – a specific task or set of tasks that are required by the project, use up resources, and
take time to complete.
Event – this is the result of completing one or more activities. An event is an identifiable end
state occurring at a particular time. Events use no resources.

34
Network – the arrangement of all activities (and in some case events) in a project arrayed in their
logical sequence and represented by arcs and nodes. This arrangement (network) defines the
project and the activity precedence relationships. Networks are usually drawn starting on the left
and proceeding to the right. Arrowheads placed on the arcs are used to indicate the direction of
flow – that is, to show the proper precedence. Before an event can be realized/achieved all
activities that immediately precede it must be completed. These are called its predecessors.
Path – the series of connected activities (or intermediate events) between any two events in a
network.
Critical – activities, events, or paths which, if delayed, will delay the completion of the project.
A project’s critical path is understood to mean that sequence of critical activities (and critical
events) that connects the project’s start event to its finish event and which cannot be delayed
without delaying the project.To transform a project into a network, one must know what
activities comprise the project and, for each activity, what its predecessors (or successors) are.
An activity can be in any of these conditions: (1) it may have a successor(s) but no
predecessor(s); (2) it may have a predecessor(s) but no successor(s); and (3) it may have both
predecessor(s) and successor(s). The first of these is an activity that starts a network. The second
ends a network. The third is in the middle. These three types of activities can be shown in the
diagram below, where activities are represented by rectangles (one form of what in a network are
called “nodes”) with arrows to show the precedence relationships.

Type 1 Type3 Type 2

“Start” “Continue” “Finish”
In this activity-on-node (AON) notation, when there are multiple activities with no predecessors,
it usual to show them all emanating from a single node called “START”. Similarly, when
multiple activities have no successors, it is usual to show them connected to a node called
“END”, as shown below.

1a 3a 2a

1b 3b 2b
Start End
3d 2c
1c 35
 3c

2d
Another format of drawing networks is AOA (activity-on-arrow) as shown in the diagram below.

Activity network, AOA format, adapted from Meredith and Mantel, 2003, p.387.
Summary
The activity plans discussed in the previous topic form the basis of developing detailed schedules
for the project. The network approach to scheduling offers a number of specific advantages of
special value for projects. Network techniques can adopt either an activity-on-node or activity-
on-arc framework without significantly altering the analysis. Gantt charts, a monitoring
technique, are closely related to network diagrams, but are more easily understood and provide a
clearer picture of the current state of the project.
(2) Budgets and deliveries
A budget is a plan for allocating resources – it is the allocation of scarce resources to the various
endeavors of an organization. A budget is a control mechanism. It is a baseline from which to
measure the difference between the actual and planned uses of resources. As the manager directs
the deployment of resources to accomplish some desired objectives, resource usage should be
monitored carefully. This allows deviations from planned usage to be checked against the
progress of the project – it is sometimes possible to implement corrective actions. Budgets need
to be tied to achievement. If we cost the WBS, step by step, we develop a project budget and if

36
we cost project plans, we achieve the same end. Hence the budget is the project plan in another
form.
Estimating project budgets
To develop a budget, we must forecast what resources the project will require, the required
quantity of each, when they will be needed, and how much they will cost – including the effects
of potential price inflation. An experienced cost estimator can forecast the number of bricks that
will be used to construct a brick wall of known dimensions within 1 to 2 percent. The estimator
should know exact numbers and by adding a small allowance for broken bricks being delivered
to the job as well as broken during construction, he should provide a close estimate. But some
fields are difficult to accurately estimate. In many fields, cost-estimating methods are well
codified. Every business has its own rules of thumb for cost estimating. These usually distill the
collective experience gained by many estimators over many years. At times, the job of cost
estimation for entire complex projects may be relatively simple because experience has shown
that some formula gives a good first approximation of the project’s cost. It is important to note
that developing project budgets is much more difficult than developing budgets for more
permanent organizational activities. The influence of history is strong in the budget of an
ongoing activity – last’s figure plus X percent. For the project there is no tradition – no past
budgets to use as a base. Even past similar projects are just rough guides since all projects are
unique and all project budgets are based on forecasts of resource usage and the associated costs.
Thus, estimating the cost for any project involves risk.
The PM must be familiar with the organization’s accounting system. The PM must be aware of
both the resources requirements and the specific time pattern of resource usage. Every
expenditure (or receipt) must be identified with a specific project task (and with its associated
milestone).
Top-Down Budgeting
This strategy is based on collecting the judgments and experiences of top and middle managers,
and available past data concerning similar activities. These managers estimate overall project
costs as well as costs of major subprojects that comprise it. These cost estimates are then given to
lower-level managers, who continue to breakdown them into budget estimates for specific tasks
and work packages that comprise the subprojects. The process continues to the lowest level. The

37
budget, like the project, is broken down into successive finer detail, starting from top or most
aggregated level following the WBS.
Advantage of this process is that aggregate budgets can often be developed quite accurately.
Also budgets are stable as a percent of total allocation.
Bottom-Up Budgeting
In this method, elemental tasks, their schedules, and their individual budgets are constructed
following the WBS. The people doing the work are consulted regarding times and budgets for
the tasks to ensure the best level of accuracy. Initially, estimates are made in terms of resources
such as labour hours and materials. These are later converted to dollar equivalents. Differences
of opinion are resolved by the usual discussions between senior and junior managers. The PM
and some functional managers may enter the discussion in order to ensure the accuracy of the
estimates. The PM adds such indirect costs as general and administrative, possibly a project
reserve for contingencies, and then a profit figure to arrive at the final project budget. These
budget are more accurate in the detailed tasks. It is far more difficult to develop a complete list
of tasks when constructing that list from the bottom up than from the top down. Individuals
closer to the work are apt to have a more accurate idea of resource requirements than their
superiors or others not personally involved.
However, bottom-up budgets are rare – seen by senior managers as risky. Involvement of low-
level managers provides them with valuable experience in budget preparation as well as
knowledge of the operations required to generate a budget. The budget is most important tool for
control of organization – hence reluctant to hand over that control to subordinates whose
experience and motives are questionable.
Work Element Costing
The process of building a project budget tends to be straightforward but tedious process. Each
work element in the action plan or WBS is evaluated for its resource requirements, and the cost
of each resource is estimated.
Suppose a work element is estimated to require 25 hours of labour by a technician. The specific
technician assigned to this job is paid $17; 50/hr. Overhead charges to the project are 84 percent
of direct labour charges. The appropriate cost appears to be
25hr x $17, 50 x 1, 84 = $805, 00

38
But the accuracy of this calculation depends on the precise assumptions behind the 25 –hr
estimate. Industrial engineers have noted that during a normal eight hour day, no one actually
works for all eight hours. Workers need breaks called “personal time” – to visit the water cooler,
the toilet, having a cigarette, blowing one’s nose etc. A typical allowance for personal time is
12% of total work time. If personal time was not included in the 25 hr estimate made above, then
the calculation becomes
1, 12 x 25 hr x $17, 50 x 1, 84 = $901, 60
The uncertainty in labour cost estimate of hours to be expended. Not including personal time
ensures an underestimate.
Direct costs for resources and machinery are charged directly to the project and are not usually
subject to overhead charges. If a specific machine is needed by the project and is the property of
a functional department, the project may “pay” for it by transferring funds from the project
budget to the functional department’s budget. The charge for such machines will be an operating
cost ($/hr or $/operating cycle) plus a depreciation charge based on either time or number of
operating cycles. Use of general office equipment e.g. copy machines, drafting equipment, and
coffeemakers, is often included in the general overhead charge.
In addition to these charges, there is also the General and Administrative (G&A) charge. This is
composed of the cost of senior management, the various staff functions, and any other expenses
not included in overhead. G&A charges are a fixed percent of either the direct costs or the total
of all direct and indirect costs.
Thus, a fully costed work element would include direct costs (labour, resources, and special
machinery) plus overhead and G&A charges. The PM is advised to prepare two budgets, one
with overheads and G&A charges, and one without. The full cost budget is used by accounting to
estimate the profit earned by the project. The budget that contains direct costs gives the PM the
information required to manage the project without being confounded with costs over which the
PM has no control.
Task
Read and write notes on other approaches to project budgeting that have been used by
organizations.
Improving the process of cost estimation

39
The cooperation of several people is required to prepare cost estimates for a project. If an
organization is in a business that routinely requires bids to be submitted to its customers, it will
have “professional” (experienced) cost estimators on its staff. The major role of the estimators is
to reduce the level of uncertainty in cost estimations so that the firm’s bids can be made in the
light of expert information about its potential costs. With this approach the PM generates a
description of work to be done on the project in sufficient detail that the estimator can know
what cost data must be collected. Frequently the project will be too complex for the PM to
generate such a description without considerable help from experts in the functional areas. Two
methods may be used to manage risks associated with estimation. One way is to make an
allowance for contingencies –usually 5 or 10 percent of the estimated cost. The other way is for
the forecaster to select “most likely, optimistic, and pessimistic” estimates.
Task
1. What other methods can be used to improve the process of cost estimation?
2. Develop a form for gathering data on project resource needs by the PM.
4. RESOURCE AVAILABILITY AND TEAM BUILDING
(1) Resource histograms.
The resource histogram is a tool that is often used by the project management team and or as a
means of providing a visual representation to the team and to all of those interested parties.
Specifically speaking, the resource histogram is specifically a bar chart that is used for the
purposes of displaying the specific amounts of time that a particular resource is scheduled to be
worked on over a predetermined and specific time period. Resource histograms may also contain
the comparative feature of resource availability, used for comparison and for purposes of
contrast. Resource histograms are indeed handy tools to utilize for the project management team
and or the project management team leader because they allow a quick and easy single page view
of exactly what resources are available, what resources are being utilized at the present time (or
at whatever time the project management team and of project management team leader is seeking
information on), and how long those resources are expected to be tied up.
It can be inferred that the term histogram was used to differentiate the chart from the bar graph, a
similar analysis tool that was devised and introduced several years ahead. A bar graph merely
depicts the data by presenting different categories in separate bars. The bars of a histogram, on

40
the other hand, represent continuous data for a specific range that are measured in terms of
frequencies and intervals; thus, the bars are connected to each other. Its primary purpose is to
present a graphical depiction of the approximate distribution of the statistical data that was
gathered. As a visual aid it’s an excellent instrument for reducing large sets of data into bars that
show the peak levels or density of distribution.

A resource histogram is a chart that shows the number of resources assigned to a project over
time. It can be an effective tool for resource planning and coordinating project staff. In the table
below Project H requires the following staff over the next 5 days.
Staff
Required Day 1 Day 2 Day 3 Day 4 Day 5
Analysts 3 3 1 1 1
Programmers 0 2 3 2 1
Testers 0 0 0 2 2

Project Staff Requirement

6

4
Staff Required

Testers
3 Programmer
Analyst
2

0
Day 1 Day 2 Day 3 Day 4 Day 5
Days

(2) Resource loading and leveling.

Scheduling focuses on time rather than physical resources (i.e. types of labour, specific facilities,
kinds of materials, individual pieces of equipment and other discrete inputs). But note that time
cannot be inventoried or renewed. Schedules should be evaluated not merely in terms of meeting
project milestones but also in terms of the timing and use of scarce resources. A measure of

41
PM’s success in project management is the skill with which the trade-offs among performance,
time, and cost are managed.
Resource loading describes the amounts of individual resources an existing schedule requires
during specific time periods (or amount of resources of each kind that are to be devoted to a
specific activity in a certain time period). It gives a general understanding of the demands a
project or set of projects will make on a firm’s resources. It is an excellent guide for early, rough
project planning. It involves the personnel resources needed for each activity. It also shows the
total hours of work for each resource as demanded by the action plan of the project – this loading
is shown for each resource for each week or day or month of the project. An example could be a
scenario where two resources A and B could be used erratically over the duration of the project.
Resource A, used in tasks a, b, and c, has a high initial demand that drops through the middle of
the project and then climbs again. Resource B, on the other hand, has low initial use but
increases as the project develops. The PM must be aware of the ebbs and flows of usage for each
input resource throughout the life of the project. It is the PM’s responsibility to ensure that the
required resources, in the required amounts, are available when and where they are needed.
The above example shows that large fluctuations in the required loads for various resources are a
normal occurrence – and are undesirable from the PM’s point of view. Resource leveling aims
to minimize the period-by-period variations in resource loading by shifting tasks within their
slack allowances. The purpose is to create a smother distribution of resource usage. Resource
leveling therefore refers to approaches to even out the peaks and valleys of resource
requirements so that a fixed amount of resources can be employed over time.
Advantages to smoother resource usage include (1) much less hands-on management is required
if the use of a given resource is nearly constant over its period of use. The PM can arrange to
have the resource available when needed, can have the supplier furnish constant amounts, and
can arrange for a backup supplier if advisable. (2) if resource usage is level, the PM may be able
to use a “just-in-time” inventory policy without much worry that the quantity delivered will be
wrong. If the resource being leveled is people, leveling improves morale and results in fewer
problems in the personnel and pay-roll offices because of increasing and decreasing labour
levels. Further, when resources are leveled, associated costs also tend to be leveled. Leveling
employment throughout a project or task is meant to avoid hiring and layoff (which is
expensive). This is a procedure that can be used for almost all projects. If the network is not too

42
large and there are only a few resources, the leveling process can be done manually. For large
networks a number of computer programs can handle most leveling problems efficiently.
(3) Staffing models.
Success in project management may lie in turning a project group into a team. Building an
effective team begins on the first day of the team’s existence. Failure to begin the team-building
process may result in a team that is more like a group than a team. In a group, members may be
involved in but not committed to the activities of the majority. The problem of commitment is a
major one for both organizations and project teams. It is especially significant in matrix
organizations, in which members of the project team are actually members of functional groups
and have their own bosses but report to the project manager on a “dotted-line” basis.
A primary rule of planning is that those individuals who must implement the plan should
participate in preparing it. Therefore, in organizing a project team, do the initial plan and
determine staffing requirements to accomplish tasks identified in the plan and then recruit
members for the project team. Complete your plan with the participation of team members.
Project teams need to understand the organization’s mission, goals and objectives so that they
take the team to where the organization wants to go. If possible, the entire team should
participate in developing the team’s mission statement. This is a tremendous team-building
activity in itself.
Experience has shown that team members are most committed to a team when their individual
needs are being met. A manager should try to satisfy the needs of the organization, while
simultaneously helping individuals satisfy their own needs through participation in the project.
This entails the team leader helping individuals bring their personal objectives (hidden agendas)
into the open so that they can be helped to achieve them. When a person has a goal that runs
counter to the team’s goal that no reconciliation is possible (and team leader can discover what
the person’s goal is) that individual should be moved to another team in which his goal can be
reached (Heagney, 2012, p.159 – 160).
Once team members understand project goals, the next is to understand their roles. These must
be clearly defined. What is expected of each individual, and by when? In most cases team
members are asked if they are clear on their goals and roles, they respond negatively. The
problem is that managers fail to solicit feedback from team members in order to be sure that they
understood and also members are sometimes reluctant to admit that they haven’t understood.
43
Hence project leaders must establish a climate of open communication with the team in which no
one feels intimidated about speaking up. The best way is to comment on the problem and probe
team to be candid about not understanding. This also means that the leader also has to admit not
knowing something – avoid being seen as a demigod – a little human frailty goes a long way
towards breaking down barriers. It is this macho notion of infallibility that makes subordinates
fear to ask their bosses when they don’t understand– a team should periodically examine its
processes and see whether it could use better approaches. So-called personality conflicts are
often simply the result of people’s lack of good interpersonal skills. This lack of interpersonal
skills can be resolved through training. Friction occurs in nearly every interaction between
human beings. There are misunderstandings, conflicts, personality clashes, and petty jealousies.
PM must be prepared to deal with these. Relationships can sink a project eventually.
There are a number of models that describe the stages that teams go through on their way to
maturity. One of the more popular ones is Tuchman’s model with stages forming, storming,
norming and performing. In the forming stage, people are concerned with how they will fit in
and with who calls the shots, makes decisions, and so on. During this stage, they look to the
leader to give them some structure – give them a sense of direction and to help them get started.
A leader’s failure to do this may result in loss of the team to an informal leader. The storming
stage is frustrating for most people. When the team reaches this stage, people begin to question
their goals. Are they on the right track? Is the leader really leading them? They sometimes play
shoot the leader during this stage.
At the norming stage, they are beginning to resolve their conflicts and to settle down to work.
They have developed norms (unwritten rules) about how they will work together, and they feel
more comfortable with one another. Each individual has found her place in the team and knows
what to expect of the others. When the team reaches the performing stage, the leader’s job is
easier. Members generally work together now, enjoy doing so, and tend to produce high-quality
results (now can be called a team).
In the forming stage a directive style of leadership is called for. Members want to know one
another and want to understand the role each member will play on the team. The leader must
help team members get to know one another and help them become clear on goals, roles, and
responsibilities. Task oriented leaders just tell the team to “get to work”, without helping them
get to know one another. However people cannot become a team when some of the “players”

44
don’t know each other. A kickoff party or dinner could be a good way of getting team members
acquainted or some mechanism for letting people get to know each other.
At the storming stage members question the group’s goal: Are we doing what we’re supposed to
be doing? The leader must use influence or persuasion to assure them that they are indeed on
track. They need a lot of psychological support as well. They must be assured by the leader that
they are valued, that they are vital to the success of the team etc. Members need some stroking in
this stage. Pretending that conflict doesn’t exist is a mistake. The conflict must be managed so
that it does not become destructive, but it must not be avoided. If it is avoided, the team will keep
coming back to this stage to try to resolve the conflict and this will inhibit progress. Better pay
now and get it over with.
As the team enters stage 3, norming, it is becoming closer knit. Members are beginning to see
themselves as a team and take some sense of personal identity from membership in the group.
Members are now involved in the work, are becoming supportive of one another, and because of
their cooperation, can be said to be more of a team than a group at this point. The leader needs to
adopt a participative style in this stage and share decision making more than in stages 1 and 2.
By the time it reaches stage 4, performing, it is a real team. The leader can sit back and
concentrate on what-if analysis of team progress, planning future work etc. This is a delegative
style of leadership and is appropriate. The team is achieving results and members are usually
taking pride in their accomplishments. There should be signs of camaraderie, joking around, and
real enjoyment in working together. Note that no team stays in a single stage forever. If it
encounters obstacles, it may drop back to stage 3 and the leader can no longer be delegative but
must back up to the stage 3 management style, which is participative. When new members come
on board for a short time the team will fall back to stage1 and you will have to take it back
through the stages until it reaches maturity again. Help everyone to know the new member and
understand what his role will be in the team. This takes some time but it is essential if you want
the team to progress properly.
Developing commitment to a team– helping team members develop commitment to the project is
a major problem for project managers. Team members assigned to a project are usually the best
available people not because they are the best people for the job. As a result they may have no
commitment. March and Simon (cited in Heagney, 2012, p.166) present five rules for developing
commitment to a team. Those rules are:

45
 1. Have team members interact frequently so that they gain a sense of being a team.
2. Be sure that individual needs are being met through participation in the team.
3. Let all members know why the project is important. People don’t like working on a
“loser”.
4. Make sure all members share the goals of the team. One bad apple can spoil the
barrel.
5. Keep competition within the team to a minimum. Competition and cooperation are
opposites. Let members compete with people outside the team, not within it.
If members are scattered geographically then members can “meet” through
teleconferencing, videoconferencing and/or an Internet-based tool. If you want some
good models of how to work with teams, take a look at the best coaches and see how they
do it.
Task
Read and write notes on more strategies that can be used for team building in projects.

(4) Resource matrices.

Task
Read and write notes on resource matrices.

5. MONITORING AND CONTROL

Monitoring is the systematic and continuous collection and analysis of information
about the progress of a project or programme over time. It is useful for
identifying strengths and weaknesses in a project or programme and for providing
the responsible people with sufficient information to make the right decisions

46
at the right time in order to improve the quality of the project. Monitoring is
carried out along the three levels of results and hierarchy objective as stipulated
(1) Project Budget and risk management.
Project budget was covered in topic 3 and current focus will be on risk management which has
so far not been looked at. It is important to note that this topic focuses on monitoring and control
–we will return to these concepts later.
Project management begins early in the life cycle. A clear understanding of risks that face the
project must be established. Sources of project risk are almost limitless, emphasizing the need for
a well-thought-out, detailed plan. Examples include the loss of a key team member, weather
emergencies, technical failures, poor suppliers etc.
The PMBOK Guide (cited in Heagney, 2012, p.57) describes project risk management as “the
process of conducting risk management planning, identification, analysis, response planning, and
monitoring and control on a project”. The PMBOK (cited in Burke and Barron, 2007, p.352)
defines project risk management as “the processes concerned with identifying, analysing and
responding to uncertainty [throughout the project lifecycle]. It includes maximizing the
probability and consequences of positive events and minimizing the probability and
consequences of adverse events to the project objectives”. The focus is to optimize project
success by minimizing threats and maximizing opportunities.

The Six-Step Process

This is a practical approach to establishing the project risk plan. The process involves a great
deal of research and collaboration with the project team.
Step 1: Make a List
Making a list of potential risks to the project should be a formal brainstorming session, when all
ideas are captured. Step 2 and 3 allow for a vetting of these ideas. It is important that the entire
team get involved in identifying threats and highlighting what can go wrong. A PM who does
this process on their own is shortsighted and making a mistake. This initial step must be
collaborative and involve individuals who are expert at that portion of the project work for which
they are responsible. If one or more members are left out, it is likely that some risks will remain

47
unidentified and pose a threat to the project success. Note that a procurement specialist will not
be helpful in identifying potential software development problems, and vice versa. All types of
risks need to be identified and dealt with accordingly.
Steps 2 & 3: Determine the Probability of Risk Occurrence and Negative Impact
The two steps are combined because they are the prioritization factors. They assist in vetting the
list of risks. These steps allow you prioritize all identified threats to the project and help
determine how much time, effort, staff, and money should be devoted to preventing or mitigating
each. Again this must be accomplished with full input from team members and subject matter
experts.
How probable is it that each risk will become a reality? A High-Medium-Low (HML) scale is
applied to the list of brainstormed risks. H shows high probable; an M shows a medium
probability and L shows low probability. There is need for team collaboration or research and
analysis by the project manager.
If the risk becomes a reality, how badly will it damage the project? All aspects of the project
should be considered when rating the negative impact of any risk. If the risk becomes a reality,
how will it affect the budget, schedule, resource utilization, scope of work etc.? The output of
steps 2 and 3 results in a list of potential risks with corresponding values for probability and
negative impact: Risk Probability Impact
A M L
B M M
C L L
D H H
Given the assessment of risks A through D in the table, it is clear focus should be on mitigating
risk D and very little should be paid to risk C. While risk C may look harmless it still necessary
not to remove it from your list (radar screen).
Step 4: Prevent or Mitigate the Risk
Some risks can be prevented; others can only be mitigated. Earthquakes or the retirement of an
important stakeholder, for instance, cannot be prevented. Some can be prevented. Proactivity is
the project manager’s best friend. Kill the risk before it has a chance to grow and flourish and
you won’t have to deal with it again. E.g. if a supplier has had previous dealings with the

48
company and not impressed (deliveries frequently late and often rejected). If supplier is not only
choice, you can prevent the risk by finding an alternative supplier that is more reliable.
Those risks that cannot be prevented, an attempt should be made to mitigate or lessen the
probability of an impact occurring. Using the unreliable supplier you can create concrete steps to
pro-actively expedite the delivery of the material, thereby mitigating the impact of the risk.
Step 5: Consider Contingencies
Preventive measures are those steps taken before the risk becomes a reality. Contingencies
represent the specific actions that will be taken if the risk occurs. If the risk becomes a reality,
what do we do? E.g. if acceptance testing for a supplier’s widgets has been identified as medium
to high risk and a test failure occurs, an appropriate contingency might be to supply engineering
support at the supplier’s expense. Another contingency might to switch to another predetermined
vendor if he has widgets in stock.
If the risk is a high priority (high probability, high negative impact—check steps 2 & 3) you will
want to identify multiple contingencies. Since there is a good chance that the risk will occur and
that when it does, it will hurt the project, you want to be covered. If it falls in the middle range of
the prioritization scale, establish at least one contingency. Those in the lower level should not get
attention. Those in the very low probability, very high impact risk should be attended to because
they can and sometimes do bring projects down.
Step 6: Establish the Trigger Point
This is often the most important element of the project risk plan. The trigger point is the point
at which the risk becomes enough of a reality that the project manager needs to trigger the
contingency. It is a judgment call meant to maximize the value of the predetermined
contingency by implementing it at the optimal time. Trigger should not be too soon (spend time,
effort or money for no good reason) or tool late (little value added by implementing the
contingency).
Example: if a usually reliable supplier has experienced labor issues and has shut down because
of a strike, perhaps your contingency plan has identified suppliers B and C as alternatives. Each
has widgets in stock and has quoted a lead time of two weeks for prep and delivery. If the
required delivery date is February 15, your trigger should include the two-week lead time plus a
few days’ buffer. An appropriate trigger point here would be January 31. If the contingency

49
affects a task or tasks on the critical path, additional buffer days should be considered. The
trigger should be a specific point in time or a defined range of time.
Establishing Reserves
A comprehensive risk plan can be compromised if there is no time or means to take appropriate
action. Establishing reserves enables one to leverage the plan to its fullest potential. The best-laid
plans are impotent without the time and budget to allow for effective implementation. Hence,
need to establish contingency and management reserves.
Contingency reserves are designated amounts of time and /or budget to account for risks to the
project that have been identified and actively accepted. They are created to cover known risks to
the project. If your project team has identified the loss of a key team member to retirement as a
high-priority risk (probability and impact), contingency actions will require the hiring of a
replacement from outside the organization. The cost and schedule impact of the hiring process
and team member assimilation must be estimated and added to the contingency reserve.
Management reserves are designated amounts of time and /or budget included in one’s plan to
account for risks to the project that cannot be predicted. Management reserves are created to
cover unknown risks to the project. E.g. if the current project involves a high percentage of
research and development and an analysis of past similar projects using actuals (historical data)it
indicates an average budgetary overrun of 10 percent, this 10 percent is not attributed to any
particular risk event. However, it should trigger the need for a 10 percent increase to the overall
project budget as a management reserve.
Managing Multi-project Risks
The multi-project manager confronts unique issues not normally encountered when managing a
single project. In the multi-project world, many projects overlap or experience direct
dependencies with other projects.
Two perspectives here: first, focus on the individual project and the associated risks for each.
Then, assess your entire portfolio and determine the nature of the relationship of these projects.
Your portfolio is the sum of all projects under your purview. The relationship among these
projects may vary widely.
A program typically involves multiple projects working towards the completion of a single
deliverable. These projects must all be properly integrated towards this end. In the portfolio

50
environment identify where the projects coincide or overlap with regard to any project work.
Then determine what might go wrong in these areas where the projects “touch”.

Task
Read and write more notes on managing risks in projects.
(2) Estimating costs.
This was done in Project budgeting.
(3) Project standards, quality assurance and change management.
According to Roberts (2009, p.152) the project plan is composed of the quality plan;
deliverables; responsibilities; standards; planning assumptions; time schedule; resource plan and
risks.
The quality plan describes how the end product will be developed and delivered to an
acceptable standard, on time and to budget. Quality plan deliverables refer to the specified end
product such as a building, a computer system or a set of working practices, but also all other
deliverables that must be produced throughout the life of the project and that lead to the specified
end product. This is one way of describing the scope of the project and the product breakdown
structure. The end product need not to be a tangible product, it also covers services.
Each deliverable must be described so that those investing in the project can see what they will
get for their investment. This is best described through product descriptions. However, since
there may be many of them, they can be put in an appendix or better still, included in the main
document but tabulated to make them more palatable.
This section can also benefit from showing the order in which the deliverables must be produced.
Although this will not include a timescale, it will show the internal and external dependencies in
the project.
Quality plan responsibilities describe who will be responsible for which aspects of quality
management within the project. It is not a regurgitation of the roles and responsibilities section
but specifically identifies the things that named individuals must do to ensure that quality is:
 Specified;
 Planned;
 Built;

51
  Tested;
 Accepted.
Consequently, this section may contain statements such as the following:
 The project steering group will agree a set of success criteria from which all expressions
of quality will be derived.
 The sponsor will approve time, cost and benefit expectations throughout the project.
 The customer representative will approve the user requirements document on behalf of all
end users of the key deliverable.
 The development team representative will approve the solution design document on
behalf of the development team(s).
 The project manager will make sure that all key deliverables have been defined in a
product description.
 The project steering group will approve all product descriptions before development
work starts.
 The PM will co-ordinate activity according to the plan taking account of all quality
standards to be applied.
 The project manager will make sure that all key deliverables are tested against their
quality criteria and according to the method identified in the product description.
 The project steering group will approve all key deliverables once evidence of a
satisfactory quality review has been established.
 The customer and developer representatives will decide how many levels of testing are
desirable.
Quality plan standards – In any project, there may be prescribed standards that must be met.
These may include documentary or procedural standards for:
 Specifying the outcome;
 Designing the outcome;
 Building the outcome;
 Testing the outcome;
 Operating the outcome;
 Managing the project.
This section must describe the standards that must be met for this project.
52
Change management – should anyone consider a change to the baseline (project plan/master
plan) is needed; the matter will be subject to this change management process. Any item raised
in this way will be referred to as a change request. Problems that have arisen will be treated in
the same way. New and existing change requests will be reviewed at the weekly meetings
between the PM and team leaders.
These four steps will be taken, using the organization’s standard pro-forma for identification,
assessment, effect and conclusion:
 Change request identification – a change request may be identified by anyone inside or
outside the project.
 Change request analysis – the change request will be described fully by the person who
has raised it. If further supporting information is needed, this may be provided by a
developer, a customer and /or the project manager.
 Change request impact assessment – the change request will be measured against the
baseline to decide whether or not it represents a deviation. The contingency change
management fund will pay for the necessary assessment.
 Conclusion and decision – the conclusion must clearly and unequivocally state whether:
 The change request is a deviation from the baseline;
 Its conclusion would take the project outside the escalation conditions.
If the change is seen as worthy the PM can approve the change. Change that causes the project to
be completed outside the agreed escalation conditions can be approved by the project steering
group.
Project control
Control is linked with plans, schedules and reporting procedures. The PM is the helmsman who
has to chart progress, look ahead, and make allowance for current, crosswind and diversion to
navigate a safe and direct course towards project objectives. Although the bulk of the operational
control is exercised by way of on-the-spot decisions by experts, team and section leaders, to be
able to assess the effect of operational control it is essential the PM be fully informed of changes
and their results, so any significant issues must be reported.
Control of projects that involve simultaneous (concurrent) engineering techniques calls for a
particularly close team approach with micro-coordination of activities conducted in close

53
cooperation and centred on the mission objective. Control at manager level is usually occasioned
by one or more of the following:
 Unexpected difficulty or risk to the achievement of objectives;
 Control required by special circumstances e.g. cost overrun, budget deficit or delay;
 An activity situation in which further expense or effort would not be justified;
 Emergence of some new or unexpected opportunity to enhance project outcome;
 Periodic review or planning revision;
 Stakeholder change or alteration of strategy affecting objectives and plans.
To keep the project on schedule the PM usually has to make frequent assessments of the
programme, manipulating important considerations of time, quality and cost. Many control
situations that entail a sacrifice of some kind amounting to the manipulation of three key
variables:
 Time: less time = more cost;
 Cost: lower cost = more time or lower quality;
 Quality: better quality = higher cost or more time.
For purposes of cost control, limits can be set above or below which actual costs may not exceed
budgeted figures. When level moves beyond predetermined limits, the PM is alerted to action,
either by cost limitation or a revision of budget estimates. Lower than expected costs, after
reviewing cumulative expenditure, may lead to a timely reallocation of funds.
Controlling project contractors
Effective communication and good leadership are the ingredients of day-to-day operational
control involving project personnel but control of activity provided by contractor or the work of
consultants is often more difficult. The contractor may have different communication and
reporting systems that may not fit project needs. It may have differing priorities and will not
come under the PM’s direct control.
In setting up a communication and control system, provision should be made for an information
and reporting procedure that will enable the PM to monitor contractor’s progress and coordinate
the efforts of all contributors. Contractual agreements should stipulate minimum reporting
requirement for monitoring and provide PM with authority to demand timely action in default of
a contractor’s commitment. Time scales for research and development are notoriously difficult to

54
predict and when several aspects of development are involved, frequent reappraisal and
adjustment may be needed. A control and coordination plan to which all contractors respond
with routine information and on attaining agreed milestones or progress stages should be
enforced.
Project Cycle Management Technical Guide by SEAGA
Checklist for Project Monitoring
(i) Are the activities taking place as scheduled?
(ii) Are the outputs being achieved as expected?
(iii) How are the beneficiaries responding to the project?
(iv) Identify possible causes of differences between actual and target performance.
Were the original targets realistic?
(v) Have any unexpected outputs arisen? Should they be included in a revised logical
framework?
(vi) Are the assumptions identified in the logical framework relevant? Have any killer
assumptions emerged? Have any new risks appeared?
(vii) What is the likely achievement of the project purpose?
(viii) Recommend corrective action that would improve the implementation of the
existing project.

Checklist for Mid Term Evaluation

(i) What did the project set out to achieve? Was the problem correctly identified?
Were the project activities appropriate? Were the targets realistic?
(ii) What were the expected linkages between outputs and purpose?
(iii) What is the likelihood that the project purpose will be fulfilled? What would have
happened in the absence of the project?
(iv) Is the project purpose still relevant? Are there other ways in which the same
purpose could be achieved? Would they be more appropriate? Would they be
more cost effective?
(v) What are the indications about the likely achievement of the project goal? Are the
project benefits sustainable?
(vi) Who were the intended beneficiaries of the project? How were they to benefit?
Did the project address practical or strategic gender needs?
(vii) Were there any unexpected outputs or beneficiaries?
(viii) Were the assumptions identified in the logical framework relevant? Have any killer
assumptions emerged? Have any new risks appeared?
(ix) Identify the lessons learnt for the future design of similar projects.

55
6. PROJECT CLOSE
(1) Creating a post implementation review.
The termination stage has a great deal to do with residual attitudes towards the project – the
“taste left in the mouth” of the client, senior management, and the project team. It’s also to do
with learning about the things that lead to success or failure. Problems have been solved,
bypassed, lived with, or ignored. Implementation plans have been carried out. The client is
delighted, angry, or reasonably satisfied. In construction-type projects where the project cadre
remains intact, the termination issue is eased because the team moves on to another challenge.
For nonrecurring projects, the issue is far more akin to the breakup of a family. While the
members of the family may be on the best of terms, they must now separate, go their individual
ways, divide or dispose of the family property, and make plans for individual survival. The
change is stressful – creates a situation where there are few or no sympathetic colleagues with
whom to share the anxieties associated with transfer to a new project or back to a functional
group. There are four different ways to close out a project: extinction, addition, integration, and
starvation.
Termination by Extinction
The project is stopped. It may end because it has been successful and achieved its goals: the new
product has been developed and handed over to the client; the building has been completed and
accepted by the purchaser; or the software has been installed and is running.
The project may also be stopped because it is unsuccessful or has been superseded: the new drug
failed its efficacy tests; the yield of the chemical reaction was too low; there are
better/faster/cheaper/prettier alternatives available; or it will cost too much and take too long to
get the desired performance. Changes in the external environment can kill projects too e.g. the

56
explosion of the Challenger stopped a number of space shuttle projects overnight. There is also
“termination by murder” – range from political assassination to accidental projecticide. When
senior executives vie for promotion, projects for which the loser is champion are apt to suffer.
Corporate mergers often make certain projects redundant. NCR was forced to cancel several
projects following its merger into AT&T.
When a project is terminated, arrangements must be made for the orderly release of project team
members and their reassignment to other activities if they are to remain in the parent
organization. The property, equipment, and materials belonging to the project must be disbursed
according to the dictates of the project contract or established procedures of the parent
organization. Finally the Project Final Report or project history must be prepared.
Termination by Addition
Some projects are “in-house”, that is, carried out by the project team for use in the parent
organization. If a project is a major success it may be terminated by institutionalizing it as a
formal part of the parent organization. NCR Corporation (prior to its merger and demerger with
AT&T), for example, used this method of transforming a project into a division of the firm and
then, if real economic stability seems assured, into an independent subsidiary.
Project personnel, property, and equipment are often simply transferred from the dying project to
the newly born division. The metamorphosis from project to division (or department/subsidiary)
is accompanied by budgets and administrative practices that conform to standard procedure in
the parent firm, by demands for contributing profits, greater exposure to all the usual stresses and
strains of regular, routine, day-to-day operations. Some adventurous members of the project team
may request transfers to other projects or seek the chance to start new projects.
Termination by Integration
This is the most common way of dealing with successful projects. The property, equipment,
material, personnel, and functions of the project are distributed among the existing elements of
the parent organization. The output of the project becomes a standard part of the operating
systems of the parent or client. Most of the problems of termination by addition are also present
when the project is integrated. The project may not be viewed as a competitive interloper but the
project personnel being moved into established units of the parent organization will be so
viewed. Also, the project, which flourished so well in its protected existence as a project, may

57
not be quite so healthy in the chill atmosphere of the “real world”. Individuals who nurtured the
project may have returned to their respective organizational divisions, and may have new
responsibilities. They tend to lose interest in the “old” project.
Task
What other issues related to termination by integration may need to be considered when the
project functions are distributed?
Termination by Starvation
This is “slow starvation by budget decrement” (Meredith and Mantel, 2003, p.648). Budget cuts
or decrements are not rare. Because they are common, they are sometimes used to mask a project
termination. In some firms it is dangerous to admit that one has championed a failure, and
terminating a project that has not accomplished its goals is an admission of failure. In such a
case, the project budget might receive a deep cut – large enough to prevent further progress on
the project and to force the reassignment of many project members. In effect, the project is
terminated but still exists as a legal entity complete with sufficient staff to maintain some sort of
presence such as a secretary who issues a project “no-progress” report each year.
(2) Role of the Project Manager.
Task
Read and write notes on the role of the Project Manager after the implementation of the project is
complete.

58
REFEFERENCES
Burke, R. and Barron, S. (2007) Project Management Leadership: building creative teams.
Everbest, HK (China): Burke Publishing. (HD 69.P75 BUR)

Heagney, J. (2012) Fundamentals of Project Management. 4th ed. New York: American
Management Association. (HD 69 HEA)

Kerzner, H. (2009) Project Management Case Studies. 3rd Ed. New York: John Wiley & Sons,
Inc.

Meredith, J. R. and Mantel, S. J. Jr. (2003) Project Management; a Managerial Approach. 5th
Ed. New York: John Wiley & Sons, Inc.

Roberts, P. (2009) Guide to Project Management: Achieving lasting benefit through effective
change. London: Profile Books ltd.

59