PRM MBA v5 e F PDF

Contact details:
Regenesys Business School

Tel: (011) 669-5000
Fax: (011) 669-5001
Email: info@regenesys.co.za
www.regenesys.co.za
MASTER OF BUSINESS
ADMINISTRATION

Project Management

Version Control: 5_e_f
Date of Publication: August 2013
Publisher: Regenesys Management

Document Change History

Date Version Initials Description of Change
13 August
2013
5_e_f FVS Re-versioned
Updating page numbers
Formatting

This workbook offers foundational information on the subject. It is offered as a guide to students who
have limited background in the subject matter so that they can place the information into a larger
contextual framework. Please consult additional literature.

Copyright Regenesys, 2013

All rights reserved. No part of this publication may be reproduced, stored in or introduced into a
retrieval system, or transmitted, in any form, or by any means (electronic, mechanical, photocopying,
recording or otherwise) without written permission of the publisher. Any person who does any
unauthorised act in relation to this publication may be liable for criminal prosecution and civil claims
for damages.

CONTENTS

1. WELCOME TO REGENESYS ............................................................................................................... 1
1.1 TEACHING AND LEARNING METHODOLOGY ........................................................................... 2
1.2 ALIGNING ORGANISATIONAL, TEAM AND INDIVIDUAL OBJECTIVES .................................... 2
2. INTRODUCTION ................................................................................................................................... 3
3. ICONS USED IN THIS STUDY GUIDE ................................................................................................. 4
4. STUDY MATERIAL FOR THE MODULE .............................................................................................. 5
5. RECOMMENDED RESOURCES .......................................................................................................... 5
5.1 RECOMMENDED ARTICLES ........................................................................................................ 6
5.2 RECOMMENDED BOOKS ............................................................................................................. 7
5.3 RECOMMENDED MULTIMEDIA ................................................................................................... 8
5.4 ADDITIONAL SOURCES TO CONSULT ....................................................................................... 8
6. LEARNING OUTCOMES ..................................................................................................................... 10
7. CONTENT SCOPE AND LEARNING GUIDANCE.............................................................................. 11
7.1 PROJECT MANAGEMENT FUNDAMENTALS ........................................................................... 12
7.1.1 DEFINING THE CONCEPTS ............................................................................................... 12
7.1.2 PROJECT MANAGEMENT TRIANGLE .............................................................................. 14
7.1.3 PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK
) ..................................... 15
7.1.4 PROJECT MANAGEMENT LIFE CYCLE ............................................................................ 18
7.1.5 TYPES OF PROJECTS ....................................................................................................... 20
7.1.6 THE ROLE OF THE PROJECT MANAGER ........................................................................ 21
7.1.7 STRATEGIC PROJECT MANAGEMENT ............................................................................ 21
7.1.8 AN OVERVIEW OF THE PROJECT MANAGEMENT PROCESS ...................................... 22
7.1.9 PROJECT MANAGEMENT SUCCESS FACTORS ............................................................. 28
7.1.10 AGILE PROJECT MANAGEMENT ...................................................................................... 29
7.1.11 CONCLUSION ..................................................................................................................... 31
7.2 PROJECT INITIATION ................................................................................................................. 34
7.2.1 THE PROJECT TEAM ......................................................................................................... 34
7.2.2 VIRTUAL PROJECT TEAMS ............................................................................................... 36
7.2.3 STAKEHOLDER MANAGEMENT ....................................................................................... 37
7.2.4 TENDER MANAGEMENT ................................................................................................... 41
7.2.5 CONCLUSION ..................................................................................................................... 46
7.3 PROJECT PLANNING ................................................................................................................. 47
7.3.1 PROJECT SCOPE MANAGEMENT .................................................................................... 48
7.3.2 CALCULATE RETURN ON INVESTMENT ......................................................................... 51
7.3.3 CONTRACT MANAGEMENT .............................................................................................. 52
7.3.4 WORK BREAKDOWN STRUCTURE (WBS) ...................................................................... 58
7.3.5 SCOPE CHANGE CONTROL PROCESS ........................................................................... 61
7.3.6 PROJECT TIME MANAGEMENT ........................................................................................ 63
7.3.7 PROJECT COST MANAGEMENT ...................................................................................... 78
7.3.8 PROJECT RISK MANAGEMENT ........................................................................................ 84
7.3.9 CONCLUSION ..................................................................................................................... 97
7.4 PROJECT EXECUTION AND EVALUATION .............................................................................. 99
7.4.1 PROJECT TEAM DEVELOPMENT ..................................................................................... 99
7.4.2 PROJECT MONITORING .................................................................................................. 101
7.4.3 PROJECT QUALITY CONTROL ....................................................................................... 108
7.4.4 PROJECT EVALUATION .................................................................................................. 111
7.4.5 CONCLUSION ................................................................................................................... 118
7.5 PROJECT CLOSURE ................................................................................................................ 119
7.5.1 PROJECT CLOSURE / TERMINATION ............................................................................ 119
7.5.2 PROJECT BASED LEARNING .......................................................................................... 120

7.5.3 CONCLUSION ................................................................................................................... 121
8. REFERENCES .................................................................................................................................. 123

List of Tables

FIGURE 1: PROJECT MANAGEMENT TRIANGLE .................................................................................. 14
FIGURE 2: DIAMOND APPROACH TO PROJECT MANAGEMENT ....................................................... 15
FIGURE 3: PMBOK
NINE PROJECT MANAGEMENT AREAS .............................................................. 16

FIGURE 4: PROJECT LIFE CYCLE OF A COMPLEX PROJECT ............................................................ 19
FIGURE 5: PROJECT MANAGEMENT TYPOLOGY ................................................................................ 20
FIGURE 6: INTEGRATED PROJECT MANAGEMENT KNOWLEDGE AREAS ....................................... 23
FIGURE 7: WATERFALL MODEL ............................................................................................................. 29
FIGURE 8: PROJECT SUCCESS RATINGS ............................................................................................ 30
FIGURE 9: EXAMPLES OF PROJECT STAKEHOLDERS ....................................................................... 38
FIGURE 10: STAKEHOLDER MANAGEMENT PROCESS ...................................................................... 39
FIGURE 11: POWER/INTEREST GRID .................................................................................................... 40
FIGURE 12: TIME, COST AND QUALITY CONTINUUM .......................................................................... 49
FIGURE 13: LOGICAL SEQUENCING ...................................................................................................... 60
FIGURE 14: SCHEDULING STAGES ....................................................................................................... 65
FIGURE 15: SEQUENCING THE CRITICAL PATH IN A GANTT CHART ............................................... 66
FIGURE 16: EXAMPLE OF A GANTT CHART FROM MS PROJECT ..................................................... 67
FIGURE 17: ACTIVITY-ON-ARC NETWORK DIAGRAM ......................................................................... 68
FIGURE 18: DUMMY TASKS .................................................................................................................. 68
FIGURE 19: ACTIVITY ON NODE NETWORK DIAGRAMS ..................................................................... 70
FIGURE 20: AON RELATIONSHIPS ......................................................................................................... 70
FIGURE 21: PRECEDENCE/NETWORK DIAGRAM OF IT REFIT PROJECT ........................................ 71
FIGURE 22: PRECEDENCE/NETWORK DIAGRAM WITH ACTIVITY DURATIONS .............................. 71
FIGURE 23: PRECEDENCE/NETWORK DIAGRAM WITH EETS ........................................................... 72
FIGURE 24: PRECEDENCE/NETWORK DIAGRAM WITH EETS AND LETS ......................................... 73
FIGURE 25: CRITICAL RESOURCE PATHING........................................................................................ 76
FIGURE 26: RISK RATING........................................................................................................................ 92
FIGURE 27: RISK ANALYSIS.................................................................................................................... 94
FIGURE 28: NUMERICAL RISK SCALE ................................................................................................... 94
FIGURE 29: LIKELIHOOD OF RISK ......................................................................................................... 95
FIGURE 30: TEAM DEVELOPMENT STAGES....................................................................................... 100
FIGURE 31: QUALITY CONTROL PROCESS ........................................................................................ 109

List of Figures

FIGURE 1: PROJECT MANAGEMENT TRIANGLE .................................................................................. 14
FIGURE 2: DIAMOND APPROACH TO PROJECT MANAGEMENT ....................................................... 15
FIGURE 3: PMBOK
NINE PROJECT MANAGEMENT AREAS .............................................................. 16

FIGURE 4: PROJECT LIFE CYCLE OF A COMPLEX PROJECT ............................................................ 19
FIGURE 5: PROJECT MANAGEMENT TYPOLOGY ................................................................................ 20
FIGURE 6: INTEGRATED PROJECT MANAGEMENT KNOWLEDGE AREAS ....................................... 23
FIGURE 7: WATERFALL MODEL ............................................................................................................. 29
FIGURE 8: PROJECT SUCCESS RATINGS ............................................................................................ 30
FIGURE 9: EXAMPLES OF PROJECT STAKEHOLDERS ....................................................................... 38
FIGURE 10: STAKEHOLDER MANAGEMENT PROCESS ...................................................................... 39
FIGURE 11: POWER/INTEREST GRID .................................................................................................... 40
FIGURE 12: TIME, COST AND QUALITY CONTINUUM .......................................................................... 49
FIGURE 13: LOGICAL SEQUENCING ...................................................................................................... 60
FIGURE 14: SCHEDULING STAGES ....................................................................................................... 65
FIGURE 15: SEQUENCING THE CRITICAL PATH IN A GANTT CHART ............................................... 66
FIGURE 16: EXAMPLE OF A GANTT CHART FROM MS PROJECT ..................................................... 67
FIGURE 17: ACTIVITY-ON-ARC NETWORK DIAGRAM ......................................................................... 68
FIGURE 18: DUMMY TASKS .................................................................................................................. 68
FIGURE 19: ACTIVITY ON NODE NETWORK DIAGRAMS ..................................................................... 70
FIGURE 20: AON RELATIONSHIPS ......................................................................................................... 70
FIGURE 21: PRECEDENCE/NETWORK DIAGRAM OF IT REFIT PROJECT ........................................ 71
FIGURE 22: PRECEDENCE/NETWORK DIAGRAM WITH ACTIVITY DURATIONS .............................. 71
FIGURE 23: PRECEDENCE/NETWORK DIAGRAM WITH EETS ........................................................... 72
FIGURE 24: PRECEDENCE/NETWORK DIAGRAM WITH EETS AND LETS ......................................... 73
FIGURE 25: CRITICAL RESOURCE PATHING........................................................................................ 76
FIGURE 26: RISK RATING........................................................................................................................ 92
FIGURE 27: RISK ANALYSIS.................................................................................................................... 94
FIGURE 28: NUMERICAL RISK SCALE ................................................................................................... 94
FIGURE 29: LIKELIHOOD OF RISK ......................................................................................................... 95
FIGURE 30: TEAM DEVELOPMENT STAGES....................................................................................... 100
FIGURE 31: QUALITY CONTROL PROCESS ........................................................................................ 109

1

1 WELCOME TO REGENESYS
At Regenesys, we assist individuals and organisations to achieve their personal and organisational
goals, by enhancing their management and leadership potential. We approach education and
development holistically, considering every interaction not only from an intellectual perspective but
also in terms of emotion and spirituality. Our learning programmes are designed to transform and
inspire your mind, heart and soul, and thus allow you to develop the positive values, attitudes and
behaviours which are required for success.

Having educated over 70 000 students based in highly reputable local and international
corporations across over 40 countries in the past 14 years, Regenesys is now one of the fastest-
growing and leading institutions of management and leadership development in the world.

Regenesys ISO 9001:2008 accreditation bears testimony to our quality management systems
meeting international standards. Regenesys is accredited with the Council on Higher Education.
Our work is rooted in the realities of a rapidly changing world and we provide our clients with the
knowledge, skills and values required for success in the 21st century.

At Regenesys, you will be treated with respect, care and professionalism. You will be taught by
business experts, entrepreneurs and academics inspired by their passion for human development.
You will be at a place where business and government leaders meet, network, share their
experiences and knowledge, learn from each other, and develop business relationships. You will
have access to a campus, in the heart of Sandton, with the tranquillity of a Zen garden, gym and
meditation room.

We encourage you to embark on a journey of personal development with Regenesys. We will help
you to awaken your potential and to realise that everything you need to succeed is within you. We
will be with you every step of the way. We will work hard with you and, at the end, we will celebrate
your success with you.

Areas of Expertise

Have a vision. Think big. Dream, persevere and your
vision will become a reality. Awaken your potential
knowing that everything you need is within you.
- Dr. Marko Saravanja.

2

1.1 TEACHING AND LEARNING METHODOLOGY
Regenesys uses an interactive teaching and learning methodology that encourages self-reflection
and promotes independent and critical thinking. Key to the approach utilised is an understanding of
adult learning principles, which recognise the maturity and experience of participants, and the way
that adult students need to learn.

At the core of this is the integration of new knowledge and skills into existing knowledge structures,
as well as the importance of seeing the relevance of all learning via immediate application in the
workplace.

Practical exercises are used to create a simulated management experience to ensure that the
conceptual knowledge and practical skills acquired can be directly applied within the work
environment of the participants. The activities may include scenarios, case studies, self-reflection,
problem solving and planning tasks.

Training manuals are developed to cover all essential aspects of the training comprehensively, in a
user-friendly and interactive format. Our facilitators have extensive experience in management
education, training and development.
1.2 ALIGNING ORGANISATIONAL, TEAM AND INDIVIDUAL OBJECTIVES
This course will draw on a model developed by Regenesys Management, which demonstrates how
the external environment, the levels of an organisation, the team and the components of an
individual are interrelated in a dynamic and systemic way. The success of an individual depends
on his/her self-awareness, knowledge, and ability to manage successfully these interdependent
forces, stakeholders, and processes.

The degree of synergy and alignment between the goals and objectives of the organisation, the
team and the individual determines the success or failure of an organisation. It is therefore
imperative that each organisation ensures that team and individual goals and objectives are
aligned with the organisations strategies (vision, mission, goals and objectives, etc.); structure
(organogram, decision-making structure, etc.); systems (HR, finance, communication,
administration, information, etc.); culture (values, level of openness, democracy, caring, etc.).
Hence, an effective work environment should be characterised by the alignment of organisational
systems, strategies, structures and culture, and by people who operate synergistically.

3

Regenesys Integrated Management Model
2 INTRODUCTION
Welcome to the module of Project Management (PRM). This module concentrates on a managerial
approach to Advanced Project Management. It is divided into six sections.

The first section introduces the fundamental concepts of project management. The section focuses
on terminology and basic project management responsibilities. It reviews the nine project
management knowledge areas supported by the Project Management Body of Knowledge
(PMBOK). You will spend time studying project management success and failure factors as well
as an analysis of the role of the project manager.

Section two discusses the management of team members. Time is spent on exploring the project
team and team development is reviewed. A part of section two is devoted to virtual teams as the
reality of the global village is essential for project managers.

Sections three to five focuses on the five process groups of project management. These sections
discuss project management process and techniques. It allows students to review project
management and also introduces new concepts. In section five project based learning is discussed
which will allow project managers to reflect on the lessons learnt from projects completed. The last
section of the workbook discusses tender and contract management.

4

3 ICONS USED IN THIS STUDY GUIDE
Icons are added to the workbook to enhance the usability of it. Certain illustrations were used to
indicate different important aspects in the workbook to help the learner to use it more effectively as
a reference guide in future. The icons in this workbook were used as follows:

Definition
The definitions provide an academic perspective on given terminology. They are used to give
students a frame-of-reference from which to define a term using their own words.

Interesting source to consult
The source icon is used to indicate text sources, from the Internet or resource centre, which add to
the content of the topic being discussed.

Self-reflection
Self-reflection is an action, which the students need to complete on their own time. It requires
students to think further about an issue raised in class or in the learning materials. In certain
instances, students may be required to add their views to their assignments.

Examples
The example icon is used to indicate an extra/additional text that illustrates the content under
discussion. These include templates, simple calculation, problem solution, etc.

Calculations
This icon indicates mathematical or linguistic formulae and calculations.

Tasks
The task icon indicates work activities that contact students must complete during class time.
These tasks will be discussed in class and reflected upon by students and facilitators. E-learning
students can use these tasks simply to reinforce their knowledge.

In a nutshell
This icon indicates a summary of the content of a section in the workbook and to emphasise an
important issue.
Please read through this study guide carefully, as it will influence your understanding of the subject
matter and the successful planning and completion of your studies.
5

Video clip or Presentation
This icon indicates a URL link to a video clip or presentation on the subject matter for discussion.
It is recommended that students follow the link and listen/read the required sources.

Note
This icon indicates important information of which to take note.
4 STUDY MATERIAL FOR THE MODULE
You have received material that includes the following:

Study guide;
Recommended reading;
Assignment.

These resources provide you with a starting point from which to study the contents of this module.
In addition to these, other resources to assist you in completing this module will be provided online
via the link to this module. Guidance on how to access the material is provided in the Academic
Handbook which you received when you registered for this qualification.

Additional resources that will be provided include:

List of recommended books and articles;
Feedback letters.

The aim of providing additional material is to broaden your understanding of, and interest in the
subject. Additional feedback letters serve to provide feedback on the assignments and guidelines
for studying towards the examination. These feedback letters form an integral part of the module
and must also be studied.
5 RECOMMENDED RESOURCES
A number of recommended resources have been identified to assist you in successfully completing
this module.
6

5.1 RECOMMENDED ARTICLES
Baccarini, D., and Archer, R. (2001) The risk ranking of projects: a methodology. International Journal of
Project Management. 19, pp. 139-145.
Dey, P. (2002) Project Risk management: a combined analytic hierarchy process and decision tree approach.
Cost Engineering. 44(3), pp. 13-26.
Duncan, W.R. (1996) A guide to the Project Management Body of Knowledge. viewed 5 September 2012,
<http://www.unipi.gr/akad_tmhm/biom_dioik_tech/files/pmbok.pdf>.
Eloranta, E., Hameri, A,P., and Lahti, M. (2001) Improved project management through improved document
management. Computers in industry. 45, pp. 231-243.
Evaristo, R., van Fenema, P.C. (1999). A typology of project management: emergence and evolution of new
forms. International Journal of Project Management. 17(5), pp. 275-281.
Furst, S.A. Reeves, M., Rosen. B., and Blackburn, R.S. (2004) Managing the life cycle of virtual teams.
Academy of Management Executive. 18(2), pp. 6-20.
Green, S. (2005) Strategic project Management. viewed 06 September 2012,
<http://www.projectscenter.com/projectmanagementsoftware/documents/strategicprojectmanagement.pdf>.
Hazen, G.B. (2004) Writing effective project reports. Department of Industrial Engineering and Management
Sciences: Northwestern University.
Jackson, B. (2000) Designing projects and project evaluations using the logical framework approach viewed
08 November 2012, <http://www.infra.kth.se/courses/1H1146/Files/logicalframeworkapproach.pdf>.
Jugdev, K., and Mller, R. (2005) A retrospective look at our evolving understanding of project success,
Project Management Journal. 36(4), pp. 19-31.
Karlsen, J.T. (2002) Project stakeholder management. Engineering Management Journal. 14(4), pp. 19-24.
Kwak, Y.H., and Ibbs, C.W. (2002) Project Management Process maturity (PM)
2
model. Journal of
management in engineering. July 2002.
Love, P.E.D., and Irani, Z. (2002) A project management quality cost information system for the construction
industry. Information & Management. 40, pp. 649-661.
Munns, A.K., Bjeirmi, B.F. (1996) The role of project management in achieving project success. International
Journal of Project Management. 14(2), pp. 81-87.
Murphy, K.E., Simon, S.J. (2001) Using Cost Benefit analysis for Enterprise Resource Planning Project
Evaluation: a case for including intangibles. viewed 08 November 2010,
<http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=927131>.
7

Neal, S., Cole, J., Linington, P.F., Milosevic, Z., Gibson, S., and Kulkarni, S. (n.d) Identifying requirements for
business contract language: a monitoring perspective. viewed 8 November 2010,
<http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1233837>.
Rad, P.F., and Cioffi, D.F. (2000) Work and Resource Breakdown Structures for formalized bottom-up
estimating. viewed 8 November 2012, <http://www.betsaonline.com/articles/WRBS.pdf>.
Raz, T., and Michael, E. (2001) Use and benefits of tools for project risk management. International Journal of
Project Management. 19, pp. 9-17.
Rickards, T., and Moger, S. (2000) Creative Leadership processes in project team development: an
alternative to Tuckmans stage model. British Journal of Management. 11, pp. 273-283.
Scarbrough, H., Swan, J., Laurent, S., Bresnen, M., Edelman, L., and Newell S. (2004) Project-based learning
and the role of learning boundaries. Organization Studies. 25(9), pp. 1579-1600.
Shendar, A.J., Dvir, D., Levy, O., Maltz, A.C. (2001) Project success: a multidimensional strategic concept.
Long Range Planning. 34, pp. 699-725.
Stock tools. (2006) How to calculate your return on investment. Viewed 23 September 2012,
<http://www.fatpitchfinancials.com/392/how-to-calculate-your-return-on-investment/>.
White, D., and Fortune, J. (2002) Current practice in project management an empirical study. International
Journal of Project management. 20, pp. 1-11.
Wilson, J.M. (2003) Gantt charts: A centenary appreciation. European journal of operational research. 149,
pp. 430-437.
Wruck, K.H., and Jensen, M.C. (1994) Science, specific knowledge, and total quality management. Journal of
Accounting and Economics. 18, pp. 247-287.

Additional articles that may prompt discussions and further assist you in completing this course
will be saved on Regenesys Online under the relevant course. Please visit the site regularly to
access these additional sources.
5.2 RECOMMENDED BOOKS
The following books are highly recommended for this module:

Laufer, A. (2012) Mastering the leadership role in project management: practices that deliver remarkable
results. Pearson Education: South Africa.

Please ensure that you order your textbook well in advance to ensure that you do not delay the
commencement of your studies for this module. It is highly recommended that you order and
purchase all your textbooks at the beginning of the year, immediately after registration.
8

5.3 RECOMMENDED MULTIMEDIA
Challenges with cross-functional teams. (2011) viewed 5 September 2012,
<http://www.youtube.com/watch?v=3C-vSl7P3X4>.
Laurie, J. (2003) Why projects fail: a university accounting system. viewed 23 September 2012,
<http://www.jiscinfonet.ac.uk/InfoKits/infokit-related-files/project-failure-university-accounting-system>.
Lecture 10 Basic scheduling with A-O-N networks. viewed 6 September 2012,
<http://www.youtube.com/watch?v=yXj2AEVgs0U&feature=related>.
Petersen, T. (2009) Case study: Risk Management in Health Case Construction projects. viewed 23
September 2012, <http://ohsonline.com/articles/2009/01/01/case-study-risk-management-in-health-care.aspx>.
Project management quick tips Lesson 3. viewed 6 September 2012,
<http://www.youtube.com/watch?v=R_cokZf7p_k>.
Projectsmart.co.uk. (2011) Agile: an introduction. viewed 23 September 2012, <
http://www.youtube.com/watch?v=OJflDE6OaSc&feature=player_embedded#!>.
Quality planning vs quality assurance vs quality control project quality control. (2012) viewed 6 September
2012, <http://www.youtube.com/watch?v=iCgzbYi_Iw8>.
Ruopp, T. (2010) Agile project management 1 Top 5 ideas. viewed 23 September 2012,
<http://www.youtube.com/watch?v=_PQCTaVEhm8>.
Wideman, R.M. (2002) Project Management Case study: the custom woodworking company Woody 2000
project viewed 23 September 2012, <http://www.maxwideman.com/papers/woody2000/woody2000.pdf>.
5.4 ADDITIONAL SOURCES TO CONSULT
As a higher education student, you are responsible for sourcing additional information that will
assist you in completing this module successfully. Below is a list of sources that you can consult to
obtain additional information on the topics to be discussed in this module:

EBSCOhost: This is an online database containing journal articles that are relevant to your modules.
Please refer to the attached EBSCOhost manual to assist you to download required
articles. Information on how to access EBSCOhost is provided to you in your Academic
Handbook. You will receive access to the database once you register as a learner.
NetMBA: This is one of several web addresses that provide a selection of MBA constructs and
discussion. It is one of the better of these addresses. http://www.netmba.com/
MindTools: MindTools.com is a very useful source of ideas, constructs, management models, etc. with
even more useful commentary and description. http://www.mindtools.com/
Brunel Open Learning
Archive:
A Brunel University support-site that provides an easily accessible library of ideas,
concepts, constructs techniques, tools, models, etc. http://www.brunel.ac.uk/

9

ProvenModels: ProvenModels' Digital Model Book presents digitalised management models categorised in
a clear, consistent and standardised information structure to improve the usability and
reusability of management literature. Management models are important generalisations of
business situations when applied in context and are powerful tools for solving business
issues. http://www.provenmodels.com/
12manage.com: This is a website on which one can access numerous models as well as global comments
on the models and principles. This could also serve as a place where you could voice your
ideas and get feedback from all over the world. http://www.12manage.com/
Alliance Online: The Alliance for Non-profit Management's general introduction to strategic planning is built
around 15 questions that cover just about all aspects in brief. (Click on Strategic
Planning)
http://www.allianceonline.org/faqs.html
The Free Management
Library:
The Free Management Library can be used to improve your organisation, and for your own
personal, professional and organisational development. This is by far the most
comprehensive overview of all aspects of strategic planning covering all stages of the
process.
http://www.managementhelp.org/np_progs/sp_mod/str_plan.htm
The Charity Village: A series of twelve very short articles, by Ron Robinson, an independent Canadian
consultant, appeared on Charity Village between November 2001 and October 2002.
These articles are refreshing in that they do not advocate a one best way for all types of
non-profit organisations. They discuss various way of approaching the strategic planning
process.
http://www.charityvillage.com/cv/research/rstrat.html

There are many more sites and articles available that can help you to successfully complete this
module. You are encouraged to post the website addresses or URLs of any additional interesting
sites that you come across on the Regenesys Learning Platform. In this way, you can assist other
learners to access the same wonderful information that you have discovered.

A word of caution not all information available on the Internet is necessarily of a high academic
standard. It is therefore recommended that you always compare information that you obtain with
that contained in accredited sources such as articles that were published in accredited journals.

10

6 LEARNING OUTCOMES
Upon completing this course, participants should:

Critically explain strategic and project management terminology, concepts, and definitions
Interrogate the link between strategic management, programme management and project
management
Evaluate key project success and failure factors within their workplace
Examine the skills and processes to manage group dynamics and project teams effectively
Successfully analyse problems, develop a feasible project strategy, plan, implement,
monitor and evaluate a project
Identify, understand and involve appropriate stakeholders in the project management
process
Be able to apply key project management tools and formulate a Gantt chart, project
structure, budget, PERT, Logical Framework, Work Breakdown Schedule
Manage time more effectively and efficiently
Identify processes and apply key skills to manage human resources
Evaluate project risks and develop a proactive risk management strategy
Identify, critique and manage the quality aspect of a project
Critically review key issues related to outsourcing, and effective contract and tender
management
Be able to apply project management software as a project management tool
Be able to compose professional project documents, reports and proposals

11

7 CONTENT SCOPE AND LEARNING GUIDANCE
A number of topics will be covered to assist you in successfully achieving the learning outcomes of
this module. It is important to study each of these sections to ensure that you expand your
knowledge in the subject and are able to complete the required assessments.

The sections that will be dealt with include:

Section 1 Project Management Fundamentals
Section 2 Project Initiation
Section 3 Project Planning
Section 4 Project Execution and Evaluation
Section 5 Project Closure

A more detailed framework of what is required for each of these topics follows under each section
heading. A number of questions to probe discussion and guide you towards comprehension and
insight are also provided.

The timetable under each section heading provides guidance on the time to be spent to study each
section. It is recommended that you follow the given timetable to ensure that you spend the
appropriate amount of time on each section. Following the timetable will ensure that you have
covered the required sections relevant to each assignment and have appropriate time to prepare
for the examination.

12

7.1 PROJECT MANAGEMENT FUNDAMENTALS
Timeframe: 8 hours
Learning Outcome:
Critically explain strategic and project management terminology, concepts, and definitions
Interrogate the link between strategic management, programme management and project
management
Recommended
reading:
A guide to the Project Management Body of Knowledge. (Duncan, (1996),
http://www.unipi.gr/akad_tmhm/biom_dioik_tech/files/pmbok.pdf
A retrospective look at our evolving understanding of project success, (Jugdev, and Mller,
2005)
A typology of project management: emergence and evolution of new forms. International
Journal of Project Management. (Evaristo, and van Fenema, 1999).
Project Management Process maturity (PM)
2
model. (Kwak, and Ibbs, 2002)
Project success: a multidimensional strategic concept. (Shendar, Dvir, Levy, Maltz, 2001)
Strategic project Management. (Green, 2005)
http://www.projectscenter.com/projectmanagementsoftware/documents/strategicprojectman
agement.pdf
The role of project management in achieving project success. (Munns, A.K., Bjeirmi, B.F.,
1996)
Multimedia
Agile project management 1 Top 5 ideas. (Ruopp, 2010),
http://www.youtube.com/watch?v=_PQCTaVEhm8
Agile: an introduction. (Projectsmart.co.uk. 2011)
http://www.youtube.com/watch?v=OJflDE6OaSc&feature=player_embedded#!
Project Management Case study: the custom woodworking company Woody 2000 project
(Wideman, 2002) http://www.maxwideman.com/papers/woody2000/woody2000.pdf
Section overview
In this section, we will be looking at project management fundamentals, those issues concerning
project management that each manager should know, whether you manage projects or not. The
first section is spent on defining the concepts. Thereafter, time is allocated to discuss the project
management life cycle. Types of projects are discussed and the role of a project manager. This
section is concluded by discussing strategic project management and project success and failure
factors.
7.1.1 Defining the concepts
Project management has been used for many years to handle from simple to difficult activities in
an organisation. Project management techniques are used to enhance the decision-making
process, which allows critical success through making the right choices. It effects the organisation
as a whole the processes, procedures, employees and managers.
Project
The term Project can be interpreted in many ways. Ask any school going teenager and they will
frown when you use the term, as project to them means a task / assignment which they need to
complete for their portfolios. In the business world, projects are related to tasks as well tasks
13

that have deadlines, constraints and problems. Therefore, it is important to develop a common
understanding of the word project that can be understood by all during this module. Lets have a
look at definitions for the word project:

A project is a temporary endeavour undertaken to achieve a particular aim. Every project has a
definite beginning and a definite end. While projects are similar to operations in that both are
performed by people, both are generally constrained by limited resources, and both are planned,
executed and controlled, projects differ from operations in that operations are on-going and repetitive
while projects are temporary and unique (Project Management Body of Knowledge, 2004:5).

... a temporary endeavour undertaken to create a unique product or service where temporary
implies that every project has a definite end, and unique focuses on the fact that the product or
service is different in some distinguishing way from all similar products or services. (Burke, 2004:2).

... something that is contemplated, devised, or planned; plan; scheme (Dictionary.com, 2012).

a large or major undertaking, esp. one involving considerable money, personnel, and equipment
(dictionary.reference.com, 2012).

Project Management
Munns (1996) claims that project management is: the process of controlling the achievement of
the project objectives. Below are some alternative definitions for project management:

The process of integrating everything that needs to be done as the project evolves through its life
cycle in order to meet the projects objectives (Burke, 2004:3).

The application of knowledge, skills, tools, and techniques to project activities in order to meet or
exceed stakeholder needs and expectations from a project (Project Management Body of
Knowledge, 2004:8).

Read the following article for further information:

The role of project management in achieving project success. (Munns, A.K., Bjeirmi, B.F., 1996)

As a preamble to this Study Guide, read through the case study (URL link below) which describes
the praxis of project management.

Project Management Case study: the custom woodworking company Woody 2000 project
(Wideman, 2002) http://www.maxwideman.com/papers/woody2000/woody2000.pdf

14

Make sure that you understand the definitions of project and project management as the rest of the
guide continues with the presumption that you do.
7.1.2 Project Management Triangle
The project management triangle, lists the constraints of project management as time, cost and
performance. Time represents the timeframe in which a project needs to be completed. Cost
indicates the budgeting involved in project management. Performance is representative of the task
specification of project management. Meredith and Mantel (2012:3) argues that a forth dimensions
should be introduced: the expectations of the client. Figure 1 illustrates the principles.

Figure 1: Project Management triangle

(Source: Meredith and Mantel, 2012:3)

More recently, a new model for project management has emerged. This model is called the
Diamond approach and was developed by Aaron Shenhar and Dvir Dov from Harvard Business
School in their book Reinventing project management: The Diamond approach to successful
growth and innovation (published in 2007 and distributed by Harvard Business School Press).

The diamond approach to project management has four vertices and customer expectations are
the central factor. The model is presented in Figure 2 (Haughey, 2011).

Performance
Cost Time
15

Figure 2: Diamond approach to project management

(Haughey, 2011)
7.1.3 Project Management Body of Knowledge (PMBOK
)
The Project Management Institute developed the Project Management Body of Knowledge as a
guide to project managers. It is seen as the sum of knowledge within the profession of project
management (Duncan, 1996). PMBOK
organises the knowledge needed for project management

in nine areas. These are described in Table 1.

Table 1: PMBOK
nine project management areas

1 Project Integration Management:
The processes and activities that integrate the various elements of
project management.
2 Project Scope Management:
The processes involved in ascertaining that the project includes all the
work required, and only the work required, to complete the project
successfully.
3 Project Time Management: The processes concerning the timely completion of the project.
4 Project Cost Management:
The processes involved in planning, estimating, budgeting, and
controlling costs so that the project is completed within the approved
budget.
5 Project Quality Management:
The processes involved in assuring that the project will satisfy the
objectives for which it was undertaken.
6
Project Human Resource
Management:
The processes that organize and manage the project team.
Expectations
Cost
Time
Scope
Quality
16

7
Project Communications
Management:
The processes concerning the timely and appropriate generation,
collection, dissemination, storage and ultimate disposition of project
information.
8 Project Risk Management:
The processes concerned with conducting risk management on a
project.
9 Project Procurement Management:
The processes that purchase or acquire products, services or results, as
well as contract management processes.

These areas are represented diagrammatically on the following pages in Figure 3 (Duncan,
1996:7):

Figure 3: PMBOK
nine project management areas

Project
integration
management
Project plan
development
Project plan
execution
Overall
change
control
Project Scope
management
Initiation
Scope
Planning
Scope
definition
Scope
verification
Scope change
control
Project time
management
Activity
definition
Activity
duration
estimating
Activity
sequencing
Schedule
development
Schedule
control
17

(Source: Duncan, 1996:7)

Project cost
management
Resource
planning
Cost estimating
Cost budgeting
Cost control
Project quality
management
Quality
planning
Quality
assurance
Quality control
Project human
resource
management
Organisational
planning
Staff
acquisition
Team
development
Project
communications
management
Communications
planning
Information
distribution
Performance
reporting
Administrative
closure
Project risk
management
Risk
identification
Risk
quantification
Risk response
development
Risk response
control
Project
Procurement
management
Procurement
planning
Solicitation
planning
Solicitation
Source selection
Contract
administration
Contract close-
out
18

These aspects form the content of the manual hyperlinked below. Click on the URL to access the
manual.

A guide to the Project Management Body of Knowledge. (Duncan, 1996),
http://www.unipi.gr/akad_tmhm/biom_dioik_tech/files/pmbok.pdf
7.1.4 Project management life cycle
Project management, like any discipline, has stages from initiation to completion. The project
management life cycle is usually divided into five phases which is described in Table 2.

Table 2: Project management life cycle phases
Project origination
This phase initiates the development of a project proposal or the evaluation of
project proposal. Organisations will identify the selection criteria for selecting
projects and notifying project sponsors.
Project initiation
Project initiation includes the development of a project charter, defining the project
scope, identifying the quality standards and establishing the project budget. This
stage also includes risk identification and documentation and the development of
the project plan. The project initiation phase also includes the signing of contracts
and approval of project plans.
Project planning
This phase involves orientation of team members, review of project materials and
the refinement of the project scope, schedule, quality standards, project plan and
budget. A complete risk assessment will be performed in this phase.
Confirmation of the plans will be signed in the approval form provided by the
project manager
Project execution and control
During this phase the project is implemented. It includes the management of the
project scope, schedule, quality control and project budget. The phase includes
the monitoring and evaluation of the project outcomes and risks. It includes
project change control, communication plan control and managing the project
team. Project progress reporting is included in the phase.
Project closure
This phase includes the post-implementation review and reporting. Project
managers will be expected to provide feedback on the performance of the project
issues.
(Source: NYS Project Management Guidebook, n.d)

Figure 4 provides an example of a more complex project. It incorporates greater detail so that the
project management team have a more comprehensive understanding of the elements contained
in each phase.

19

Figure 4: Project life cycle of a complex project

TOTAL PROJECT LIFE CYCLE

PLAN ACCOMPLISH

(Adapted from: Burke 2004: 32)
PHASE 1
CONCEPT
Conceive
Gather data
Identify need /
problem analysis
Establish: Goals and
objectives, Stakeholders,
Risk level, Strategy, Potential
team
Estimate of resources
Review alternatives
Present proposal
Obtain approval for
next phase
PHASE 2
DEVELOPMENT
Develop
Appoint key team
members
Conduct studies
Develop scope
Establish: Master plan,
budget, cash flow, WBS,
policies and procedures
Assess risk
Present project brief
Obtain approaval to
proceed
PHASE 3
IMPLEMENTATION
Execute
Set up: structures,
communications
Motivate team
Provide detailed
technical
requirements
Establish: schedules,
information control
systems
Procure goods and
services
Execute work
according to
schedules
Direct/monitor/ forecast and
control: scope, quality, time,
cost
Resolve problems
PHASE 4
TERMINATION
Finish
Finalise project
deliverables
Review and accept
Hand over
Evaluate project
Document results
Release / redirect
resources
Reassign project team
Accumulative Effort
20

We can see the project life cycle is the primary tool used to plan and coordinate a project.
7.1.5 Types of projects
You need to consult the following article to relate to this section:

A typology of project management: emergence and evolution of new forms. International Journal
of Project Management. (Evaristo, and van Fenema, 1999).

The development of categorising project types emerged from the trends in which projects are
organised and managed. Evaristo and van Fenema (1999) differentiated between (a) single versus
multiple projects and the (b) number of sites that these projects encompass. The writers claim that
their differentiation will enhance problem solving through understanding the type of project one will
be dealing with. They create Project Management typology is described in Figure 5 below:

Figure 5: Project Management typology

(Source: Evaristo & van Fenema, 1999:277)
21

Make sure you understand the different cells within the diagram in order to evaluate projects
according to their differentiation.
7.1.6 The role of the project manager
This section covers the PMBOK
knowledge area 6: Human resource management. The project

manager is the person who needs to be accountable for the project planning, implementing and
completion. Meredith and Mantel (2012:108 118) highlights the following as special demands on
the project manager:

Acquiring adequate resources;
Acquiring and motivating personnel;
Dealing with obstacles;
Making project goal trade-offs;
Failure and the risk and fear of failure;
Breadth of communication; and
Negotiation.
7.1.7 Strategic project management
Strategic project management is defined as:

... the management of projects in such a way as to develop competencies and capabilities, which
contribute to the firms sustainable competitive advantage (Green, 2005).

... the project perspective, direction and guidelines on what to do and how to do it, to achieve the
highest competitive advantage and the best project results (Shedar et al, n.d.).

Shedar et. al (n.d.) suggests that strategic project management focuses on the business results of
projects and how this will influence the position of the organisation in the market place.

Shedar et al. (n.d) identifies the role of strategy in project management. They identify a missing
link between the project plan and the organisational strategy. As projects are run in a competitive
arena, the project strategy needs to focus on the overall business strategy of the organisation.
The project strategy will enhance the organisational strategy and therefore the organisational
competitive edge.

The project strategy framework developed by Shedar et al. (n.d) distinguishes between four
elements of project strategy:

Product definition and competitive advantage;
Business perspective;
Project scope; and
Strategic focus.
22

Read the articles indicated below for a greater understanding of Strategic Project Management.

Strategic project Management. (Green, 2005)
http://www.projectscenter.com/projectmanagementsoftware/documents/strategicprojectmanagemen
t.pdf
Project success: a multidimensional strategic concept. (Shendar, Dvir, Levy, Maltz, 2001)
7.1.8 An Overview of the Project Management Process
The overall process for managing projects can be divided into related sub-processes, or process
groups. Managing these groups can enable you to finish projects on time, within budget, with
reduced risk, and with reasonably predictable results.

Project Management Process is the theory of project management processes. Each process can
only be separated theoretically, because in practice the processes overlap. Each specific task that
has to be completed within a project is called a project objective, and these need to be clearly
stated and determined. The objectives that need to be accomplished are based on complexity;
risk; size; timeframe; project teams experience; access to resources; amount of historical
information; the organisations project management maturity and the industry and application area
(PMBOK
2004:39). These objectives only serve as guides to which project management

knowledge and skills need to be applied during the life cycle of a project.

It is important for the project management process to continually check that it adheres to a plan-
do-study-act cycle. This cycle is commonly referred to as the PDSA cycle and was developed by
Walter Shewhart (1939). It is sometimes referred to as the Deming Cycle. In the context of project
management this implies:
Plan: Determine scope of project as well as interval of initial iteration
Do: Execute - small steps in controlled circumstances
Study: Gather empirical evidence, involve the customer if possible
Act: Take action to improve or standardize the plan or process
Within the context of PMBOK
the integrated processes are seen as being more complex than the
PDSA cycle (PMBOK
2004:40):
Plan: The Planning Process Group
Do: The Executing Process Group
Check and Act: The Monitoring and Controlling Group
In addition, the life span of a project is limited and so the initiating Process Group starts the project
and the Closing Process Group ends them. The Monitoring and Controlling Group also have
interaction with every aspect of the Process Group.

23

The five Process Groups within PMBOK
are:

1. Initiating Process Group;
2. Planning Process Group;
3. Executing Process Group;
4. Monitoring and Controlling Process Group; and
5. Closing Process Group.

Kwak (2002:151) integrates the project management knowledge areas and project process
grouping as follows. They also explain this integration through modelling which is illustrated in
Figure 6.
Figure 6: Integrated project management knowledge areas

(Source: Kwak, 2002:151)
Initiating
Integration
Scope
Time
Cost
Quality
Communication
Human
Resources
Risk
Procurement
Planning
Integration
Scope
Time
Cost
Quality
Communication
Human
Resources
Risk
Procurement
Executing
Integration
Scope
Time
Cost
Quality
Communication
Human
Resources
Risk
Procurement
Controlling
Integration
Scope
Time
Cost
Quality
Communication
Human
Resources
Risk
Procurement
Closing
Integration
Scope
Time
Cost
Quality
Communication
Human
Resources
Risk
Procurement
24

A brief discussion of project group processing follows.
Initiating process group
This group defines and authorises the project or the project phase in the case of multiphase
projects. Their outputs include the project charter and the preliminary project scope statement.
The initialising of a project often takes place externally to the projects scope of control. It is
important therefore that before starting the Initiating process that the group has a clear
understanding of why the project was requested; an understanding of the project objectives; and a
clear description of why the project is the best solution to satisfy the project requirements
(PMBOK
, 2004:43).

The outputs of the Initiating Process Group are (Table 3). These outputs will be discussed later in
this section.
Table 3: Project initiation
The Project Charter: States why the project is needed and who authorised it.
The Preliminary Project Scope
Statement:
States the what what work needs to be accomplished and the deliverables
that need to be produced.

Planning process group
This group defines and then refines the project objectives and then plans the course of action
required to reach these objectives and scope that the project has undertaken to address. This
group identifies; defines and matures the project scope, project cost and schedules the project
activities that occur within the project. As new project information is received it integrates this
information and resolves discrepancies. Stakeholders should also be involved within the Project
Process Group as they may have knowledge and leverage important to the execution of the
project.

This group provides leverage across multiple processes and it normally provides (PMBOK
2004:
48-55) the outputs described in Table 4:

25

Table 4: Project planning
Project Management Plan:
Says how the work will be performed and includes subsidiary management plans
such as scope; schedules; cost; quality; staff; communication; risk and procurement.
Scope Planning:
Documents how the project scope will be defined, verified and controlled and how
work breakdown structure will be controlled and verified.
Scope Definition:
Developing of a detailed project scope statement as the basis for future project
decisions.
Create Work Breakdown
Structure (WBS):
Process for subdividing major project deliverables and work into smaller, more
manageable components.
Activity Definition:
Identifies the specific activities that need to be performed to produce various project
deliverables.
Activity Sequencing: Identifies and documents dependencies among scheduled activities.
Activity Resource
Estimating:
Process for estimating the type and quantities of resources required to perform each
scheduled activity.
Activity Duration Estimating:
Process of estimating the number of work periods that will be needed to complete
individual schedule activities.
Schedule Development:
Process for analysing the activity sequences, durations, resource requirements and
schedule constraints to create the project schedule.
Cost Estimating:
Process for developing an approximation of the costs of the resources needed to
complete project activities.
Cost Budgeting:
Process for aggregating the estimated costs of individual activities or work packages
to establish a cost baseline.
Quality Planning;
The processes of identifying which quality standards are relevant to the project and
determining how to satisfy them.
Human Resource Planning:
Process of identifying and documenting project roles and responsibilities and
reporting relationships, as well as creating a staffing management plan.
Communications Planning:
Process for determining the information and communication needs of project
stakeholders.
Risk Management Planning:
Process for deciding how to approach, plan, and execute the risk management
activities for a project.
Risk Identification:
Process for determining which risks might affect the project and documenting their
characteristics.
Qualitative Risk Analysis:
Process for prioritising risks for subsequent further analysis or action by assessing
and combining their probability of occurrence and impact.
Quantitative Risk Analysis:
Process for numerically analysing the effect on overall project objectives of identified
risks.
Risk Response Planning:
Process for developing options and actions to enhance opportunities and to reduce
threats to project objectives.
Plan Purchases and
Acquisitions:
Process for determining what to purchase or acquire, and determining when and
how.
Plan Contracting:
Process for documenting products, services and results requirements and identifying
potential sellers.

26

Executive process group
This process integrates people and other resources to carry out the project management plan for
the project. It is responsible for producing the project deliverables and updating the Project
Management Plan by addressing the scope statements and then implementing any approved
changes. Normal execution variances such as increased risks, duration or resource availability
may cause some re-planning, they may affect the project management plan. Most of a projects
budget is spent during this stage and may include the project management processes (PMBOK

2004: 56-58) described in Table 5:

Table 5: Project execution
Direct and Manage Execution:
Process for directing technical and organisational interfaces that exist in the
project to execute the work as defined in the project management plan. The
deliverables are produced as outputs from the processes performed as defined in
the project management plan. Information on the completion status of the
deliverables and what work has been accomplished are collected as part of
project execution and input to the performance reporting process.
Perform Quality Assurance:
Process of applying the planned and systematic quality activities to ensure that
the project employs all the processes required to meet requirements.
Project Team: Process for obtaining the human resources needed to complete the project.
Develop Project Team:
Process for improving the competencies and interaction of team members to
enhance project performance.
Information Distribution: Process for making information available to project stakeholders timeously.
Request Seller Responses: Process for obtaining information, quotations, bids, offers or proposals.
Select Sellers:
Process for reviewing offers, choosing from among potential sellers, and
negotiating a written contract with the seller.

Monitoring and controlling process group
This group regularly measures and monitors the progress of a project to identify variances from the
project management plan so that corrective action can be taken if and when necessary to meet the
project objectives. It provides the team insight into the health of the project. In multiphase projects
this group also provides feedback between the different phases and in so doing may implement
corrective or preventative actions that may need to be taken. When variances do occur that may
jeopardise the project management plan then they may revisit the PDSA cycle in the Planning
Process Group.

The Monitoring and Controlling Group includes the following management processes (PMBOK

2004:61-65) (Table 6):

27

Table 6: Project monitoring and controlling
Monitor and Control Project
Work:
Process for collecting, measuring, and disseminating performance information. It
also assesses tends to effect process improvements. The process has to include
risk monitoring so that risks may be identified early and appropriate action taken.
Performance reports need to include information on the projects performance with
regard to scope, schedule, cost, resources, quality and risk.
Integrated Change Control:
Process for controlling factors that create changes to make sure that the changes
are beneficial, determining whether a change has occurred and managing the
approved changes throughout the project from its initiation to its closure.
Scope Verification:
Process for formalising the acceptance of the completed project deliverables.
Scope Control:
Process for controlling changes to the project scope.
Schedule Control:
Process for controlling changes to the project schedule.
Cost Control:
Process of influencing the factors that create variances, and controlling changes to
the project budget.
Perform Quality Control:
Process for monitoring specific project results to determine if they comply with the
predetermined quality standards and determining ways in which to eliminate the
causes of unsatisfactory performance.
Manage Project Team:
Process for tracking team member performance, providing feedback, resolving
issues and coordinating changes to enhance project performance.
Performance Reporting:
Process of collecting and distributing performance information such as status
reporting; progress measurement and forecasting.
Manage Stakeholders:
Process for managing communications to satisfy and resolve issues with relevant
stakeholders.
Risk Management Control:
Process for tracking identified risks, monitoring residual risks, identifying new risk,
executing risk response plans, and evaluating their effectiveness throughout the
project life cycle.
Contract Administration:
Process for managing the contract and the relationship between buyer and seller,
reviewing and documenting how a seller is performing. If it is appropriate the
process may mange the contractual relationship with the outside buyer of the
project.
Closing process group
This group formalises the acceptance of the product, service or result and brings the project or
project phase to an orderly end. It verifies that all the defined processes are completed. It includes
the management processes described in Table 7 (PMBOK
2004: 66-67):

28

Table 7: Project closure
Close Project:
Process to finalise all activities across the Process Groups to formally close a
project or project phase.
Contract Closure:
Process for completing and settling each contract, including the resolution of any
open items, closing each contract applicable to the project or a project phase.

Read the article to enhance your understanding.

Project Management Process maturity (PM)
2
model. (Kwak, and Ibbs, 2002)
7.1.9 Project management success factors
Kerzner (1995:6) states that project success was defined in the past as:

... the completion of an activity within the constraints of time, cost and performance.

Kerzner (ibid.) points out that changing circumstances, have resulted in a change to the
understanding of what a successful project is, therefore the definition has changed as follows a
successful project is one which is completed:

within the allocated time period;
within the budgeted cost;
at the proper performance or specification level;
with acceptance by the customer/user;
with minimum or mutually agreed upon scope changes;
without disturbing the main work flow of the organisation; and
without changing the corporate culture.

Research in the USA has shown that the most successful projects had these factors in common:

Adequate and suitable organisational structures are in place.
Adequate planning and suitable control mechanisms are in place.

In the United Kingdom, common factors recognised in successful projects include:

Commitment by the parent organisation, client and the project manager to:
o Establish activity schedules and control procedures;
o Establish budgets and control of expenditure;
o Technical goals and milestones are linked to time and cost;
Organisation structures suited to the nature of the project;
Team participation in planning and determining methods, schedules and budgets;
29

Absence of legal encumbrances;
Minimise the number of bureaucratic public or government agencies involved; and
Enthusiastic public support.

For more information, the following article should be considered:

A retrospective look at our evolving understanding of project success, (Jugdev, and Mller, 2005)
7.1.10 Agile project management
Traditionally, project management assumes that all projects follow the life cycle phases and that
the phases of a project are easily recognisable. This assumes further that projects are predictable
and occur in an orderly sequence. It further assumes that once a phase in the project life cycle is
complete the project will not return to this phase. A traditional approach to project management
model is compared to a waterfall. This is illustrated in Figure 7 below (Hass, 2007).
Figure 7: Waterfall model

(Source: Hass, 2007)
Business
Requirements
System
Requirements
Design
Construction
Test
Deliver
Operations
and
Maintenance
30

Business has become more complex in being able to address the changing nature of new and
evolving business systems.

According to Hass (2007) the 2006 CHAOS survey indicated the following success record of
projects (Figure 8).
Figure 8: Project success ratings

Improving the almost 50% over budget and over time aspect of a project, an alternative approach
to project management has been developed. This alternative approach, Agile Project
Management, is used when (Hass, 2007):

When the project value is clear
The customer participates throughout the project
The customer, designers and developers are co-located;
Feature-driven development is possible;
Visual documentation is acceptable.

Hass (2007) further identifies key elements, which provide the basis for Agile Project Management.
These are discussed in Table 8.

Succeeded: 35%
Failed: 19%

Over time or budget:
46%
31

Table 8: Agile Management Components
Visual control
This approach relates to how teams organise the work of the project. The features of
the project are designed using colour which are visible at a glance. This method
ensures that all team members view the project in the same way
Co-located high-performing
teams
All team members are located in the same room. Communication and Co-ordination is
improved.
Test-driven development This requires that once requirements of a project are defined, test plans are developed.
Adapted control
Everyone on the team is constantly adapting. The project manager should therefore be
a leader. This method requires teams continuous review of their inputs in order to
improve outputs.
Collaborative development
Constant feedback and improvement is one of the strengths of this approach. The
initial planning is done by the project manager and the business analyst defines and
prioritises the solution features with all other stakeholders.
Feature-driven development
This requires that teams are focussed on one thing at a time which reduces complexity.
The project manager and analyst focus on the next priority. The core component and
high risk components are built first and the other priorities are then based on this.
Leadership and
collaboration
The project manager is focussed on collaborating and leading and not on commanding
and controlling. S/he is responsible to remove barriers to ensure efficient teams.
Revenue focussed
The business analyst should ensure that team members are not investing too much
into the development of the solution of the project.
Lessons learned
The team members holds lessons learned session after each cycle to evaluate what
could be done to adapt the implementation of the next cycle.
(Source: Hass, 2007)

For more information on Agile Project Management, watch the clip hyperlinked below:

Agile project management 1 Top 5 ideas. (Ruopp, 2010),
http://www.youtube.com/watch?v=_PQCTaVEhm8
Agile: an introduction. (Projectsmart.co.uk. 2011)
http://www.youtube.com/watch?v=OJflDE6OaSc&feature=player_embedded#!
7.1.11 Conclusion
In this section we discussed the concepts of project management. We laid out the project
management life cycle and types of projects. The project manager and her/his roles were
identified. We also provided an overview of the project management process. Project success
and failure factors were discussed and strategic project management were argued. The next
section will be devoted to project team development.

32

Recap Questions

Read the case study below.

Churchill as a project manager

Winston Churchill is widely regarded as one of the greatest leaders of the 20
th
century. But as he became British Prime
Minister in May 1940, in a period of calamitous change during World War II, what did he actually do? How did he
transform his organisation to turn his perilous situation around? Both Churchill in 1940 and business people today
grapple with an unprecedented level of change adversely impacting their organisations at the enterprise, business unit,
or project level.

A project manager needs experience in projects relative to their selection, initiation, definition, planning, risk
management, resource management, budgeting, communication, tracking issues and status, and evaluating
performance. Churchill had experience with large scale projects in abundance. His experience included preparing the
Navy for war, to planning the Gallipoli campaign, to coordinating the economy for the production of war materials and
tanks, to running the finances of the country.

As well as experience, project managers require strong traits in business, technology, and behaviour, and of course
leadership skills. In Churchills situation:

1. He understood the challenges the country faced better than anyone. He had learned many lessons from the
First World War which guided his priorities in May 1940. Foremost on his agenda was overcoming the lack of a
central policy, which undermined resource coordination and prolonged Britains response.
2. He was very aware of technology and could see its application providing a clear advantage. For example, in
1915 even though he was the Lord of Admiralty he sponsored the initial tank design. In 1938 he supported the
development of Radar, although he would be involved in technical discussions, he would leave decisions to
trusted Lieutenants people he knew could do the job
3. He was very savvy at understanding human behaviour and motivating teams around him. Communication
management was a cornerstone of his strategy in 1940, communicating in all direction (cabinet, government,
people) to avoid any surprises.

When Churchill became PM at the age of 65 in 1940, he had to find the strength to lead his nation out of the darkest and
most dangerous of times, towards the defeat of a tenacious enemy. But Churchill was ready for this and he had always
believed he had a date with destiny that would require him to lead his nation.

When he took over as Prime Minister, he had a very good idea of what he was undertaking, with the background he had,
and could draw from him experience in tough international negotiations and fierce political battles. In many ways, he
was so well prepared that he wasted little time in taking action.

During the Second World War, Churchill, as a historian, understood early on what was happening and he was astute
enough to maximise the impact of valuable information he had collected, and build up his case. He recognised that one
of the chief goals of a project manager was to rally people to a cause, and to do this required considerable credibility
gained through self-belief, steadfastness, courage, and integrity to the cause.

Organisations today need to pay close attention to events and changes in the business environment, and prepare for
worst case situations. Techniques like future scenario planning, better prepare potential options available to
organisations which then have the ability to react and respond through a project if a series of events take a turn for the
33

worse. In todays world, changing events initiate projects. But the response needs to be very rapid ad so he project,
vision, and scope need to be thought through, already in place, and well understood in relations to the planned response
scenarios. This also requires a project team in position to enact thee project according to available options. Churchill
was viewed as someone with moral conviction who could pick up a cause and stay true to it, and his stature grew as he
provided leadership to a project he inherited.
(Mark Kozak-Holland, Churchill as Project Manager in PM world today, Vol VIII in Meredith and Mantel, 2012)

1. Evaluate the categories of skills required to be a project manager.
2. Examine the different definitions of project management and project and explain what you understand project
management is.
3. Critically evaluate the importance of project management.
4. Explain how project management can be a powerful strategic weapon.
5. Explain project success under the following headings:
a. Project efficiency
b. Impact on the customer
c. Business and direct success
d. Preparing for the future

34

7.2 PROJECT INITIATION
Timeframe: 8 hours
Learning Outcome:
Examine the skills and processes to manage group dynamics and project teams effectively
Identify, understand and involve appropriate stakeholders in the project management
process
Critically review key issues related to outsourcing, and effective contract and tender
management
Recommended
reading:
Managing the life cycle of virtual teams. (Furst, Reeves, Rosen. and Blackburn, 2004)
Project stakeholder management. (Karlsen, 2002)
Multimedia:
Challenges with cross-functional teams. (2011) http://www.youtube.com/watch?v=3C-
vSl7P3X4
Section overview
Project human resource management focuses on the effective use of people involved in a
project (Duncan, 1996:93). This section is devoted to analysing the management of human
resources in the project life cycle. It is divided into team identification, team development and
stakeholder management. A section of this chapter introduces the ideas of virtual teams.
7.2.1 The Project Team
The project teams can be described as the individuals who plan, implement and execute a project.
As teams change with different projects, the roles team members play will change as well. The
focus of the project team needs to be a successful completion of a project. Cobb (2006:86-92)
suggests that project teams structure needs to compose of the following aspects (Table 9):

Table 9: Project team structure
Team size:
Team size will depend on the size of the project. If, for example, the project is planning a year-
end function the team size will considerably differ from the project team for building a bridge in
Johannesburg City Centre.
Team
composition:
Team composition refers to the members in the team. This will also depend on the project as a
project team will not always need, for example, an engineer.
Team
Governance:
Team governance refers to the amount of control a team has over the project. The team will have
a project leader yet, the project leader does not always have control over the complete project.
Team identity:
Teams need to have an identity to be effective. The team identity will promote team effectiveness
and commitment as the team members will see themselves as distinct from other employees.
Team interaction:
Teams need specific communication methods to interact with one another. Teams have to work
together in order to complete a project successfully. In the world today, not all team members are
located in the same area, sometimes not even in the same country. These teams are called
virtual teams.
Team ideology
Teams need to be motivated by values. These values need to be communicated and accepted
by each team member. Think, for example, of the team members who built the soccer stadiums
for the Soccer World Cup 2010. These members felt motivated by contributing to an historic
35

event.

Team effectiveness characteristics
Given the highly complex nature of many projects, it is not feasible to assign a task to one person
or a highly specialised team. Project management requires a wide range of skills, including highly
specialised skills, generalist skills, and also those with an overall understanding of how the system
operates and how the component parts fit together. This complexity alone requires a team
approach, and yet within it, are the seeds of misunderstanding and conflict. An effective project
manager will have to be able to juggle these varying characteristics and mould a group of people
of differing interests, expertise and personality into a cohesive and effective team. The
characteristics of an effective project team are discussed in Table 10.
Table 10: Effective project teams
A clear understanding of the
project objective:
Scope, quality, budget and schedule need to be clearly defined, and each project
team member needs to have the same vision of the project outcomes.
Clear expectations of each
team members role and
responsibilities:
Team members need to know how their work is linked together by participation in
the development of project plans and by committing to their section of the project.
A results orientation:
Each project team member needs to be committed to achieving the project
outcomes or objectives.
A high degree of co-operation
and collaboration:
Open, honest and timely communication should be the norm. Team members
should be prepared to share information and ideas. They should act as resources
for each other beyond their duties, and assist other members to succeed in their
tasks where possible.
A high level of trust:
Team members need to comprehend their interdependency and to accept that
everyone is needed for the project to be a success. Conflict should be resolved
through constructive feedback and positive contributions on issues. Team
members should accept their differences, and differences of opinion should be
encouraged, expressed and respected.
(Source: Knipe and Van der Waldt, 2002: 204-5)
Selecting team members
Knipe, van der Waldt et al (2002:184) emphasise the role of human resource processes in building
healthy, high-functioning teams.

Staffing requirements decide what type of skills is needed from what types of individuals or groups,
and in what time frames (Project Management Institute, 1996:95). In order to identify the people
resources needed for a project, the types of personnel (such as job descriptions) must be decided
on, as well as how many personnel from each job category are needed, and when these personnel
will be required. (Kerzner, 1998:186).

In other words, team members need the appropriate skills and knowledge to undertake the tasks in
question, and this means the project manager must ensure that team members are selected
according to the requirements of the project.
36

Team roles and responsibilities
Staff members can be assigned or appointed only once the initial planning has been
accomplished. The project manager has a vital role here, although s/he may not have free choice
as to staff availability with the range of competencies that are required.

The closer the match, the more chance there is of the project attaining success. Project managers
can, of course, if the budget allows and processes are flexible enough, call in expert help if and
when required. But this also requires careful planning. Knipe and Van der Waldt (2002:186)
points out that:

... the project manager must ensure that all project team members understand the project roles
(who does what) and responsibilities (who decides what) that are assigned.

The first step in recruiting an effective project team is to look for a balance in skills needed for the
project. The skills needed are discussed in Table 11.

Table 11: Skills needed for project teams
Functional skills:
These skills develop because of years of study or experience. Every project will
need some form of these skills and the project manager will draw up a skills list,
giving priority to those essential functional skills required.
Management skills:
Managerial skills mean the hands-on skills related to the everyday working of the
project.
Interpersonal skills:
Team members with strong functional skills but little in the way of interpersonal skills
will need to be balanced with those with interpersonal skills.

For more information about project teams, view the clip below:

Challenges with cross-functional teams. (2011) http://www.youtube.com/watch?v=3C-vSl7P3X4
7.2.2 Virtual Project Teams
Furst (2004:6) describes a virtual project team as:

Individuals who are geographically dispersed and interact primarily through telecommunications
and information technologies to accomplish specific objectives within specified timeframes.

37

Virtual teams allow project managers to appoint employees for their specific talents relating to the
project. Managers can therefore appoint the best of the best to complete their projects. Although
this is very exciting, virtual teams pose specific challenges to project managers. Read the article
below:

Managing the life cycle of virtual teams. (Furst, Reeves, Rosen. and Blackburn, 2004)

It is argued that, without efficient management, virtual teams can become less effective than face-
to-face teams (Furts, 2004:6). Furst (ibid.) examines the development of virtual teams by using the
Tuckman team development model and the Gersicks Punctuated equilibrium model. She
described the challenges associated with Virtual Team development in a table on pages 8 - 9 in
the article.

Furst (ibid.) suggests that challenges experienced can be avoided if project managers are actively
involved at each stage of team development. She summarises interventions for managers on p.
15.
7.2.3 Stakeholder Management
Stakeholder management comprises of two phases, namely stakeholder analysis and stakeholder
planning. We will briefly look at Stakeholder Analysis, which is the technique we use to identify the
key people whose support we have to gain. Stakeholder planning, which entails building the
support that helps you to succeed, will then be discussed. Stakeholder planning includes the
compilation of a stakeholder relationship management plan based on observation of the attitudes
and needs of the stakeholders, the implementation of the plan and an evaluation of the
involvement of the stakeholders. These aspects are not the focus of this manual for more
information, you may read the following:

Project stakeholder management. (Karlsen, 2002)

A stakeholder is defined as follows on the web:

Stakeholders are the specific people or groups who have a stake, or an interest, in the outcome of
the project (Unknown Author, n.d.).

Stakeholders are an integral part of a project. They are the end-users or clients, the people from
whom requirements will be drawn, the people who will influence the design and, ultimately, the
people who will reap the benefits of your completed project (Unknown Author, 2010).

A stakeholder is anybody who is affected by the project. They can be internal or external and they
can be at senior or junior levels. Stakeholders are crucial to the success of your project. Neglect
them and they will actively work against you. Manage them well and they will actively promote you
and your project (Morphy, 2008).
38

Based on the definitions we can conclude that stakeholders in projects are:

all entities within or outside the organisation that sponsor a project;
all parties that who an interest or will gain in some way in the successful completion of the
project; and
People/institutions who may have a positive or negative effect on the successful completion
of the project.

Karlsen (2002) provides the following as examples of project stakeholders:

Project stakeholders can include clients, end users, contractors, consultants, labour unions, line
organization, public authorities, financial institutions, insurance companies, controlling
organizations, media, third parties, and competitors.

Diagrammatically it is represented as follows (Figure 9):
Figure 9: Examples of project stakeholders

Project
Financial
institution
s
End users
Competitors
Suppliers /
contractors
Controlling
organisations
Consultants
/ advisers
Third
parties
Labour
unions
Insurance
companies
Line
organisation
Public
authorities
Press /
media
Client /
customers
39

Stakeholder management is defined by Projectsmart.co.uk (2010) as follows:

... is the process of managing the expectation of anyone that has an interest in a project or will be
effected by its deliverable or outputs.

It is not really possible to manage stakeholders in the traditional sense, but you can manage the
projects relationship with them in a systematic way.

The successful management of stakeholder participation includes:

Identification of all internal and external stakeholders;
Prioritisation of key stakeholders;
Analysis of their needs, interests and power base; and
Deciding on a tactic to involve them constructively.

Karlsen (2002:23) suggests the following project stakeholder management process (Figure 10):

Figure 10: Stakeholder management process

Plan Step 1
Identify Step 2
Analyze Step 3
Communicate Step 4
Act Step 5
Follow up Step 6
40

Determine impact of stakeholders on the success of the project
Once you have determined what the interests of your stakeholders are, and have recorded it, the
time has come to prioritise the stakeholders in order of importance to your project. There are
different ways to analyse the importance of stakeholders to your project. The most popular method
used for this analysis is the Power/Interest Grid (Mindtools, 2010). An example of such a grid is
given below. By using such a grid you can classify your stakeholders according to their influence
and impact on the project you are managing. For example, your boss is likely to have high power
and influence over your project and high interest in it. Your family may have high interest, but are
unlikely to have power over it. This grid is illustrated in Figure 11.

Figure 11: Power/Interest Grid

Influence / power
of stakeholders

Interest of stakeholders

Stakeholders, who have a lot of power over the successful completion of the project, will have a
high interest. They will be placed in the top right hand side of the grid.

The stakeholders who might have high power over the success of your project, but do not have a
high interest in the project will be placed on the left top quadrant of the grid.

The stakeholders who do not have much influence over your project and who will not be influenced
by the outcome of the project should be, placed in the left bottom quadrant.

People/organisations for whom your project is important, but they dont have much influence on it,
are placed in the right bottom quadrant.
High influence
Low interest
High influence
High interest
Low influence
Low interest
Low influence
High interest
41

Once you have mapped your stakeholders, you can focus your efforts on the highest priority
groups while providing sufficient information to keep the less influential groups happy. The
stakeholders position on the grid will guide you in terms of the actions you have to take with them
(Table 12):
Table 12: Power/Interest Grid
High power, interested people: These are the people you must fully engage with, and make the greatest
efforts to satisfy.
High power, less interested people: Put enough work in with these people to keep them satisfied, but not so
much that they become bored with your message.
Low power, interested people: Keep these people adequately informed, and talk to them to ensure that no
major issues are arising. These people can often be very helpful with the
detail of your project.
Low power, less interested people: Again, monitor these people, but do not bore them with excessive
communication.

Develop a stakeholder relationship management plan
After you have identified and analysed your stakeholders, it is time to plan and to engage with your
key stakeholders. Once your key stakeholders are identified, the next step is to compile a
stakeholder management plan. One of the most critical issues in project management is the
participation or involvement of key project stakeholders. If the key stakeholders are not involved
from the beginning of the project, they may sabotage the implementation of the project or they may
not support it. However, too much stakeholder participation may also become frustrating, time
wasting, and destructive. Therefore, project managers must have a carefully designed plan in
order to manage them successfully.

The key to managing stakeholders is a good understanding of their current circumstances and
which factors influence them over others. This then allows you to tailor your approach involve them
constructively and to achieve maximum benefit. Communication and feedback channels are
crucial as this allows you to use specific management techniques, dependant on the feedback that
you receive.
7.2.4 Tender Management
This is probably one of the stressful processes that project managers have to go through.
Opportunities do not appear magically. Project managers must be very alert of suitable business
opportunities. One way of identifying suitable business is through tenders that come out every now
and then.

Every opportunity to do business must be carefully screened and evaluated. This is where an
assessment is made as whether the product and/ or service have the returns needed for the
needed resources. It involves looking at the creation and length of the opportunity, its real and
perceived value, its risks and returns, its industry and if it fits the organisation. Below is a template
that you can use to assess the need as discussed above:
42

FACTOR ASPECT COMPETITIVE CAPABILITIES
Type of need:
Continuing
Declining
Emerging
Future

Timing of need:
Duration
Frequency
Demand cycle
Position in life cycle

Competing ways to satisfy need:
Doing without
Using present way
Modifying present way

Perceived benefits / risks:
Utility customer
Appeal characteristics
Customer tastes and
preferences
Buying motives
Consumption habits

Price versus performance
features:
Price-quantity relationship
Demand elasticity
Stability of price
Stability of market

Market size and potential:
Market growth
Market trends
Market development
requirements
Threats to market

Availability to customer funds:
General economic conditions
Economic trends
Customer income
Financing opportunities

(Source: Hisrisch, 2004)

43

Tender advertisement
Tenders for national government contracts are advertised in the following places:

The South African Government Information website's Tenders Page.
The Department of Trade and Industry's Government Tender Bulletins page.
The Government Tender Bulletin, which comes out on Fridays. You can subscribe to the
Bulletin by contacting the Government Printer on 012 334 4735 / 012 334 4736 / 012 334
4737.

Other places where you can access tenders online are the following:

www.onlinetenders.co.za
www.seda.org.za
www.dailytenders.co.za
www.tenderscan.co.za
www.satender.co.za
Analyse tender documents
Tender documents should be analysed to determine the viability of new venture possibilities. The
following information explains critical factors to consider when analysing a tender document:
Tender documentation
Each tender or bid advert indicates where you can collect the documents you will need to fill in to
submit your tender, and where they should be submitted. The advert also indicates a closing date.
This is a very firm deadline, which has to be strictly adhered to - no late tenders are accepted.

Tenders or bids have to be in writing. Each tender has a number of associated forms, which must
accompany the tender to be submitted. The specific forms you require for your tender should be
listed in the tender documentation. You should consider very carefully how you fill in these forms.

Once you have all the forms completed and signed, place your tender in an envelope with the
tender number on it and deliver it before the closing time to the place specified when the tender
was advertised (satender.co.za, 2009).

It is important to note that to submit a tender there are tender forms or bid forms that have to be
completed and be sent along with the tender when you submit.

44

How the bid will be awarded
The document called SBD 6.1 explains how tenders are awarded. According to this document the
following happens:

The bidder obtaining the highest number of points will be awarded the contract.
Preference points shall be calculated after prices have been brought to a comparative basis.
Points scored will be rounded off to 2 decimal places.
In the event of equal points scored, the bid will be awarded to the bidder scoring the highest
number of points for specified goals.

What this means in practice, is the following. After the closing date, an elementary check is done
on all the tenders submitted to see if they comply with the formal requirements. For example, if you
have not indicated a price, your tender will be disqualified.

Tenderers otherwise known as vendors need to be careful of the mistakes and omissions that may
lead to them being disqualified from the tender process. However, some minor mistakes may not
necessarily lead to being disqualified. In most cases it is up to the official checking the tender to
decide whether the mistake or omission warrants disqualification.

After the tender documents have been checked and found to be in line with the requirements, the
next phase looks at the compliance of the product or service with the specifications and price. At
this stage those products / services and prices that do not comply with the specifications are
removed from the process. The ones that comply with the specifications are then listed in order of
price. Those falling in the lowest price group are then considered in a lowest price tender list.

It is in this phase that the preference points come into play. All the preference points claimed by
those on the list of lowest price tenders are first verified. Then the formula is applied to determine
who of those on the lowest price list with verifiable points come out with the best result on points,
and therefore who should be awarded the contract.

In other words, preference points only come into play after the most expensive tenders have first
been excluded. This is to ensure that the most expensive options do not win solely on points, and
also to speed up the process, as only those on the lowest price list have their preference points
verified. The Tender Bulletin shows who has won previous tenders, listing the price and other
factors taken into account in awarding the tender.
Securing the bid
Tender documentation
Usually a tender submission requires the inclusion of the documents discussed in Table 13.

45

Table 13: Tender documentation
The Bid (SBD1)
In this document you are agreeing to be bound by the tender or bid terms and
conditions.
Tax Clearance Requirements
(SBD2)
Your taxes must be in order to be successful with your tender or bid. This document
has an 'Application for tax clearance certificate' form attached to it. You have to
complete this form and hand it in at your nearest South African Revenue Services
(SARS) office, to get a tax clearance certificate. You must then attach the original tax
clearance certificate that you get from SARS, to the tender or bid documents. This
certificate serves as proof that you are not in arrears with your tax payments.
Price and motivation SBD 3.1,
3.2 and 3.3
A choice between these forms is determined by the subject of the tender. In this form,
you motivate your price, by describing the product you will supply or the experience
of the person who will perform the service. This form is often amended for the
particular tender, so check which one you need to complete carefully.
Declaration of Interest (SBD4)
This is the document in which you declare whether or not you have a relationship
(friend, family, business) with anyone who works for government. This is so that
those people are not involved in awarding the tender in any way, to avoid corruption.
Industrial Participation
Programme (SBD5)
Any contract having an imported content equivalent to or exceeding R10 million has
an industrial participation (IP) obligation, which must be addressed in the tender.
Preference certificate (SBD-
6.1)
You must fill in the SBD 6.1 form for provincial tenders even if you are not claiming
any of the preference points. If you are claiming preference points, you need to fill in
those of 12 documents SBD /WCBD 6.1-6.12 which relate to kinds of points you are
claiming (national and provincial) as explained above.
Contract form (SBD 7.1 or 7.2
or 7.3)
This is the contract that binds the parties should the ender be successful. There is a
different form for purchases (7.1, services 7.2 or sales 7.3)

There may be other specific forms to fill in for a specific tender or bid. Nevertheless, a typical
package will most likely have the following documents:

SBD 1 - WCBD 1
SBD 2 - WCBD 2 (Tax Certificate)
SBD 3.1 - WCBD 3.1 (Firm pricing: purchases)
SBD 3.3 - WCBD 3.3 (Pricing schedule: Professional services)
SBD 4 - WCBD 4 (Declaration of interest)
SBD 6.1 - WCBD 6.1 (Preferential procurement points)
SBD 6.10 - WCBD 6.10 (Preferential points- local area)
SBD 6.3 - WCBD 6.3 (Preferential points - SMME)
SBD 6.4 - WCBD 6.4 (Preferential points - local content)
SBD 7.1 - WCBD 7.1 (Contract purchase)
SBD 7.2 - WCBD 7.2 (Contract services)

46

7.2.5 Conclusion
In this section, we discussed the importance of the individual when practising project management.
We focused on successful teams and the development of project teams. One of the most recent
project management issues, virtual teams, were discussed in order to enhance project leaders with
the most recent technological advances in project management. You were introduced to the
process of tendering. This will enhance the project manager to secure business for the
organisation as s/he can procure tenders which s/he knows the organisation is capable of doing

In the section that follows we will look at project management processes and techniques. This
section examines of project planning, implementation, monitoring and evaluation.

Recap Questions

1. If you have to appoint a virtual team in your working environment today, what resources will you need to purchase in
order to make the team effective?
2. Read the case study below and answer the questions that follow:

A project management office success for the transportation security administration

The Transportations Security Administration (TSA) had only 3 months and $20 million to build a 13,500 square foot
coordination centre, involving the coordination of up to 300 tradespeople working simultaneously on various aspects of
the centre. A strong Project Management Office (PMO) was crucial to making the effort a success. The PMO
accelerated the procurement and approval process, cutting times in half in some cases. They engaged a team leader, a
master scheduler, a master financial manager, a procurement specialist, a civil engineer, and other specialists to
manage the multiple facets of the construction project, finishing the entire project in 97 days and on budget, receiving an
award from the National Association of Industrial and Office Properties for the quality of its project management and
overall facility.
(Project management institute, PMO speeds success for transportation facility. PM Network, Vol 18. In Meredith and
Mantel, 2012:193)

3. Explain the concept of stakeholder management.
4. Use a power/interest grid to identify the importance of the stakeholders involved in the project.
5. Differentiate between stakeholder analysis and stakeholder influence.
6. Argue the importance of efficient stakeholder management in the successful completion of a project.

47

7.3 PROJECT PLANNING
Timeframe: 20 hours
Learning Outcome:
Successfully analyse problems, develop a feasible project strategy, plan, implement,
monitor and evaluate a project
Be able to apply key project management tools and formulate a Gantt chart, project
structure, budget, PERT, Logical Framework, Work Breakdown Schedule
Be able to apply project management software as a project management tool
Manage time more effectively and efficiently
Evaluate project risks and develop a proactive risk management strategy
Recommended
reading:
Current practice in project management an empirical study. (White and Fortune,
2002)
Gantt charts: A centenary appreciation. (Wilson, 2003)
How to calculate your return on investment. (Stock tools, 2006),
http://www.fatpitchfinancials.com/392/how-to-calculate-your-return-on-investment/
Identifying requirements for business contract language: a monitoring perspective.
(Neal, Cole, Linington, Milosevic, Gibson, and Kulkarni, n.d),
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1233837
Project Risk management: a combined analytic hierarchy process and decision tree
approach. (Dey, 2002)
The risk ranking of projects: a methodology. (Baccarini and Archer, 2001)
Use and benefits of tools for project risk management. (Raz and Michael, 2001)
Work and Resource Breakdown Structures for formalized bottom-up estimating. (Rad
and Cioffi, 2000) http://www.betsaonline.com/articles/WRBS.pdf
Multimedia:
Case study: Risk Management in Health Case Construction projects. (Petersen,
2009) http://ohsonline.com/articles/2009/01/01/case-study-risk-management-in-health-
care.aspx
Lecture 10 Basic scheduling with A-O-N networks.
http://www.youtube.com/watch?v=yXj2AEVgs0U&feature=related
Project management quick tips Lesson 3.
http://www.youtube.com/watch?v=R_cokZf7p_k
Why projects fail: a university accounting system. (Laurie, 2003)
http://www.jiscinfonet.ac.uk/InfoKits/infokit-related-files/project-failure-university-
accounting-system
Section overview
In this section of the Study Guide we will be discussing the project management process.
Different project management tools are discussed within the framework of project initiation
and planning. Project time management is discussed and tools used for scheduling is
provided.

48

7.3.1 Project Scope Management
Scoping is incredibly important as it allows the project manager to:
Determine the cost and timeframes of the project.
Establish quality expectations.
Measure outputs against indicators at the end of the project, thereby ensuring that only the
work that is required by the project is actually completed.

The key to an understanding of project scope is a comprehension of the interrelationship between
the three factors of time, cost and quality.
The time / cost / quality continuum
When projects are undertaken the project team undertakes to complete the scope of work
according to the criteria of cost, time and specifications. In essence, this is a form of contract,
whether it is seen in the light of an internal contract (internal to the organisation or department) or
if the project is for an external client/stakeholder. This has been discussed in the first chapter of
this manual.

It will be impossible to honour commitments made in terms of time, cost and quality if these are not
carefully calculated, and in fact this is why faulty scoping can be seen as one of the greatest
causes of project failure. If you develop a project scope that promises exceptional quality in an
incredibly short period and at a very low cost, it is highly unlikely that the team will be able to
deliver what has been promised, because the factors of time, cost and quality are interdependent,
as shown in Figure 12. The higher the level of quality, the higher the requirements will be in terms
of time and cost. If quality must be high but time must be short, the cost will increase even more.

49

Figure 12: Time, cost and quality continuum

Note: Position is plotted by drawing a line perpendicular with the axis of each element.

Define project scope
Project scope management includes all the necessary processes to ensure that the project
includes all the work required (and only the work required) to complete the project successfully
on time, to the required quality and within budget.

P
r
o
j
e
c
t

S
c
o
p
e

A

This project scope
allows for
relatively low cost
and little time,
therefore the
quality achieved
will also be
relatively low
P
r
o
j
e
c
t

S
c
o
p
e

B

This project scope
allows just as little
time, but by
greatly increasing
cost manages to
achieve a high
level of quality
P
r
o
j
e
c
t

S
c
o
p
e

C

This project scope
achieves the same
high level of
quality at a much
lower cost by
increasing the
timeline for the
project
50

Scope is the sum of the products, services, and results to be provided as a project (PMBOK
,
2004).

Table 14 provides an overview of the major scope management processes (PMBOK
2004:105).

Table 14: Overview of scope management processes
Scope planning: Developing a written scope statement as the basis for future project decisions.
Scope definition:
Subdividing the major project deliverables into smaller, more manageable
components.
Creating WBS:
Subdividing the major project deliverables and project work into smaller, more
manageable components.
Scope verification: Formalising acceptance of the project scope.
Scope change control: Controlling changes to the project scope.

Scope planning
Scope planning is defined as the process of creating a project scope management plan
(PMBOK
, 2004). The scope planning forms the basis for future decisions and establishes the
criteria for the completion of the project activity or phase. The scope statement is often revised to
accommodate changes in the project scope.

Scope planning:

defines the boundary of the project as agreed by the stakeholders;
outlines the project objectives and major deliverables as agreed by the client and contractor;
and
determines whether the project is implemented according to the required condition and
Informs the change control process.
Scope definition
Scope definition: is the process of developing a detailed project scope statement as the basis for
future project decisions (PMBOK
, 2004). The scope definition outlines the project content,

approach, and how it will solve the clients needs or problem.

Scope definition uses a method to identify the work to be implemented. The build method outlines
how the project will be built or implemented. The work breakdown structure is the tool that assists
to divide the scope of work
51

Scope verification
Scope verification is the process of formularising acceptance of the completed project
deliverables (PMBOK
, 2004). The scope of work is formally approved at the end of each project
phase. This step ensures that the project is implemented according to the required conditions and
assesses whether the project has been implemented according to the required conditions.
Scope change and control
Scope change control is:

influencing the factors which create scope changes to ensure that changes are beneficial;
determining that a scope has occurred; and
managing the actual changes when and if they occur.

This step ensures that the project is refined or adjusted if changes occur. A management system
should be developed that outlines the following areas:

a change control system that outlines the steps by which the official project documents can
be changed;
lists the people who have the authority to make changes to the scope of work;
a framework to monitor, evaluate and update the scope baseline to accommodate scope
changes;
automatic approval for emergency situations; and
a record of all approved changes.
7.3.2 Calculate return on investment
Before a project contract is finalised, the project manager should calculate the return on
investment. Return on investment could be defined as:

A performance measure used to evaluate the efficiency of an investment or to compare the
efficiency of a number of different investments (investopedia.com, 2012).

To calculate the return on investment, the following formula could be used:

ROI = (Gain from Investment Cost of Investment)
Cost of Investment

The project manager should calculate whether taking on the project is worth the time, effort and
money it will cost.

52

To practice calculating the return on investment, you could follow the link below:

How to calculate your return on investment. (Stock tools, 2006),
http://www.fatpitchfinancials.com/392/how-to-calculate-your-return-on-investment/
7.3.3 Contract management
According to Kerr (1989:3) in contracts the legal bond is formed by the parties themselves and
within the limits laid down by law. The nature of the obligation is determinable by those parties.
Contracts are further defined by Kopel (1996:16), as a lawful agreement entered into by two or
more parties within the limits of their contractual capacity, with serious intention, each to the other
without vagueness and being of the same mind as to the subject matter to perform positive or
negative acts that are possible of performance.

In this section, we are going to relate to the legal rule that relate to the validity of various contracts.
As will be discussed further a valid contract is that which complies with certain requirements
recognised by the law (Fouche, 1990). Again, we are going to look at and discuss the legal
requirements of a valid contract.
The requirements of a contract
Let us first look at the concept of valid contract. A valid contract is not different from a contract, its
just a synonym. Therefore, in this section these terms may be used interchangeable because they
mean one and the same thing. As mentioned before, in order for a contract to be a contract it has
to meet some requirements and they are as follows:

Serious intention to conclude a contract;
Consensus;
Contractual capacity;
Lawfulness;
Formalities; and
Possibility of certain or ascertainable performance i.e. it must be physically capable of being;
execute.
Serious intensions to conclude a contract
We have already hinted on the importance of the intentions of the parties entering into a contract.
This is very critical for the importance of the conclusion of the contract. As stated by Fouche (1990)
the legal system in South Africa the serious intention to conclude a contract is required as a
fundamental requirement for the existence of a contract. It is a requirement for the parties entering
into the transaction to be serious and deliberate. Where this intention is lacking even when the
parties are serious there is no contract (Kerr, 1989).
53

Consensus
We have already mentioned that a contract has to display a degree of consensus. Consensus can
be seen as the cornerstone of any contract. When this is reached between the parties then an
agreement exists between the involved parties. A consensus is reached during the negotiations. It
is defined by Fouche (1990) as the meeting of minds regarding all the terms of the contract. This is
achieved by offer and acceptance. Furthermore, in order to be valid, the offer needs to be clear,
complete, communicated to the offered party(s) and intended to serve as an offer. It must be noted
that an offer lapses through rejection, counter offer, by the passing of time, death or lack of mental
capacity (insanity) of one of the parties before acceptance.

In order to be valid the acceptance need to be very clear and without conditions. Some further
argue that a consensus can be reached only if (Havenga et al., 2001):

Every one of the parties has a serious intention to be bound by such contract.
The parties have a common intention, so that they must have in their minds the same
commitment.
Every party makes his or her intention known to every other party by means of a
declaration.
Contractual capacity
Contractual capacity is the capacity, which the law grants persons to perform valid legal acts.
Capacity to act must be distinguished from legal capacity. According to South African law every
person (natural or juristic) legally has capacity to be the bearer of the rights and duties. However,
not every person who has legal capacity has capacity to act (Havenga et al. 1992). The term
capacity to act refers to the capacity to perform juristic acts. Only a natural person has the
capacity to perform juristic acts. Therefore, a contract has to be entered into on behalf of a legal
person by a natural person. Nevertheless, not all natural persons have capacity to act. Normally
the unmarried person who has reached the age of majority has full capacity to act. According to
the Age of majority Act 57 of 1972 a person becomes a major once they are 21 years old (unless
he or her independence is flawed by his or her marriage or mental deficiency). The same Act also
stipulates that any unmarried individual who is 18 years old may apply to the Supreme Court for an
order to be declared a major. If this is successful, the individual then gains capacity to perform
juristic acts.
Lawfulness
It is also one of the requirements of a valid contract that it needs to be by all means lawful.
According to Fouche (1990) a contract is lawful when it has been concluded in accordance to
common law. It must be noted that a contract contradicts common law if it is against public policy
or against good morals. A contract which is not expressly prohibited by statute or common law may
be concluded.

In sum, a contract is only lawful if it is in line with statutory and common law. If a contract
contradicts the above it is unlawful and void. A restraint of trade is against public policy and thus
not a valid contract. Nevertheless, if it is reasonable it will be permissible and valid as a contract.
54

Formalities

Formalities are one of the many factors to be considered in looking at whether a valid contract
exists or not. The general rule is that no formalities are prescribed for the validity of a contract.
Parties do not have to announce their intentions to enter into a contract in any formal manner. The
contract may be concluded verbally and still be a perfect valid contract (Fouche, 1990). However,
legislation has since created an exception to that general rule. Contracts have to comply with
certain formalities in order for them to be valid contracts. This is more relevant to complicated
contracts to be mentioned below. These requirements are aimed at preventing fraud, reducing
uncertainties and evidential problems (Havenga et al., 2001).

The contract must be rendered in writing. Contracting parties may agree to set their contract down
in writing and then the contract will only be valid only once it is put down in writing. This should
ensure that all the contents of the contract are contained in the document. Any changes such as
additions, omission and amendments are also to be in writing. There are specific contracts that
have to be in writing. We are not going to go into details of these contracts. The examples are the
following:

Contracts for the alienation of land;
Contracts of suretyship; and
Contracts of donation in terms of which performance is due in the future.

The contract has to be notarially executed. This entails the conclusion of a contract in the presence
of a notary public. An example here would be the antenuptial contract as well lease of mineral
rights.

Finally, the contract must registered. Registering involves making an entry in the registers of the
state. This is done with an intention to publicise the contents of the particular contract.

Ascertainability

The contract will be void if the performance to be undertaken by parties is not vaguely defined.
Parties need to know exactly what their obligations entail and that needs to be clearly stated in the
terms of the contract.

Also, we need to consider the element of being realistic before entering into a contract. This refers
to the possibility of performance itself. It is a general rule that if the performance of a contract is not
possible than the contract is to be deemed to be void (Havenga et al. 2001). Now the question you
must be asking yourself is how to ascertain whether this general rule is applicable?

To answer this question we need to assess the following:

The nature of the contract
The relationship between the parties
The circumstances of the case
The nature of the impossibility

55

The criterion in terms of which the possibility or impossibility of performance measured is a
commercial one. For instance, according to Havenga et. al (2001:83). performance is impossible if
the thing which has to be delivered no longer exists or never existed, is incapable of being traded,
or already belonged to the purchaser when the contract of sale was concluded. The example here
would be that of a house which was to be given for occupation and has been raised to the ground.
Here you can clearly see that performance is physically impossible to undertake. In addition to this,
you must know that the impossibility referred to here is an objective impossibility. This means that
any reasonable person must not be able to perform under similar circumstances. A subjective
impossibility would be if you purchase a house for R300 000.00 in 2005 and due to interest rate
adjustments you are unable to pay bond instalments. The reality is that you are not able to pay (it
is impossible for you), but this is a subjective impossibility because someone else might be able to
pay for the same amount. This does not affect the validity of the contract.

Let us now discuss the concept of breach of contract. This discussion will focus on the explanation
of the concept breach of contract. We are also going to look at some types examples of breach of
contract.
Breach of contract
The primary aim when concluding a contract is its fulfilment or discharge by due and proper
performance. However, if this result is not achieved due to the acts of omissions of one of the
parties this constitutes breach of contract (Fouche, 1990; Havenga et al., 2001).

There are five different forms of breach of contract, but in this workbook we are going to focus on
three. The five forms of breach of contract are:

Default by the debtor;
Default by the creditor;
Repudiation;
Positive mal-performance; and
Rendering performance impossible.
Default by the debtor (mora debitoris)
Default by the debtor can be defined as the failure of the debtor to perform on time. This has
nothing to do with the case of impossibility of performance as discussed earlier, but is simple a
case of late performance. Here the delay leading to late performance is due to no one else but the
debtor. For example, the debtor must pay the purchase price on or before a specified date. If the
debtor does not pay on the specified date he or she is referred to as mora meaning the debtor is
late in terms of payment (Fouche, 1990; Havenga et al., 2001).

Certain requirements have to be present though in order for the debtor to be said to have
committed a mora debitoris or default by the debtor. There are two requirements required and they
are:

56

A date for the performance will have to be stated, and only when the debtor has failed to
perform will he or she be mora.
The delay must be due to the debtors fault. If the delay is not due to the debtors fault he or
she will not be guilty of mora. Some have recently argued that in addition to these two
requirements another requirement must be added, and that is the debt must be due. Mora
cannot exist is the date for performance has not yet occurred.
(Fouche, 1990; Havenga et al., 2001)

Remedies to the above would be for the creditor not to cancel the contract. Cancellation of contract
will be at his disposal only where the contract makes for such provision (Fouche, 1990). Damages
may be claimed for financial losses suffered by the creditor as a result of the failure of the debtor to
perform on time.
Default by the creditor (mora creditoris)
This occurs where the creditor causes the debtors performance to be delayed. The example here
would be where person X and Y contract that Y will lay carpeting in Xs house and where X
therefore has to co-operate in allowing Ys workmen access to the house.

The requirements for this kind of breach of contract are as follows:

The performance must be dischargeable. The performance owing to the creditor must be
dischargeable in terms of an existing and valid obligation and must be physically and legally
capable of being discharged. To put it simply, when the day has been agreed of the
performance and the debtor performs on that day, but the creditor does not accept this
performance, the creditor will be in mora. The creditor will be in mora when he refuses entry
to the debtor when the debtor has come to tender performance.
The time for performance must have arrived. The creditor will therefore not be in mora should
he refuse to accept performance before the time agreed upon in the contract.
The debtor must tender proper performance. Where performance is not proper, the creditor
may refuse to accept it without being in mora.
The failure to receive performance must be due to the default of the creditor
(Fouche, 1990; Havenga et al., 2001)

Remedies to default by the creditor are the same as for the default by the debtor. For example, in
the case where the debtor is innocent, he has the usual remedies for breach of contract at his
disposal. Cancellation of contract is possible only where time is of the essence to the contract or
where the contract states that the aggrieved party will have the right to cancel the contract in the
case of breach of contract being committed. Obviously, damages can be claimed if the failure of
the creditor has caused the debtor to suffer damages.

57

Repudiation
Repudiation means the notice given by the debtor that he will not comply or continue to comply
with his obligations. It can be further defined as any behaviour by a party to a contract indicating
that he does not intend to honour his obligations. The example here would be the denial of
obligation. This is also another form of breach of contract. Note that the debtor here tries to get out
of or withdraw from the contract obligations without any justification. The debtor does not
necessarily have to withdraw from his entire obligation to be considered to be in breach of contract
(Fouche, 1990; Havenga et al., 2001).

The requirements for repudiation are:

The debtor must give notice that he will not comply or continue to comply with his obligations. In
this case a positive refusal to perform is required. In other words the debtor must give notice in one
way or another that he will not comply. This may be affected expressly or tacitly. Therefore, mere
failure to perform is not repudiation.
Terms and conditions of a contract
Terms
A term in a contract is a provision which imposes on a contracting party one or more contractual
obligation. Therefore, the terms of a contract determine the results or the consequences of the
contract (Havenga et al, 2001). Terms define the contractual obligations to which the parties bind
themselves and which they can enforce against one another. To add more, it stipulates the time
when or the circumstances in which the obligations either become enforceable or are terminated
(Ibid.:91). In contracts, terms are statements made seriously and deliberately with the intention that
they should be enforceable in law. This should be distinguishable from say for instance a sales talk
which has no legal consequences, but is merely excessive praise of performance.
Expressly
Terms may be incorporated by means of articulated declarations of intent. A term is articulated if it
expressed in so many words, whether in writing or orally (Havenga et al, 2001).
Tacitly
A tacit term is that which has not been expressed in words, but is based on the parties honest
intentions. This is based on the parties true, but unexpressed intention where it had been
considered during negotiations but had seemed so self-evident so as not to necessitate an express
provision (Havenga et al, 2001).
Implied terms
This term too is that which has not been expressed in words and can be incorporated into a
contract. Implied terms are also known as natural consequences of a contract. For example, if the
58

contract is a contract of sale, a guarantee against latent defects is included in the contract.
Therefore guarantee against later defects forms part of every contract of sale unless the parties
specifically exclude or change it (Havenga et al, 2001).
The condition
The words terms and conditions are usually used as if they mean the same thing. The use of
these terms as synonyms is incorrect. The word condition has a special legal meaning. In law a
condition is an additional term which may be added to the terms of the contract by the parties. A
condition is a qualification which is added to the agreement rendering the operation of the contract
dependent on the taking place, or not taking place, of an uncertain future event. Conditions refer to
the uncertain, future events. The contract is concluded and is binding from the moment that
consensus is reached and not when the condition is fulfilled (Havenga et al, 2001).

There are different types of conditions namely:

Suspensive condition; and
Resolutive condition.

A suspensive condition postpones the consequences of the contract until the condition has been
fulfilled.

On the other hand, a resolutive condition has the effect that the consequences of the contract take
effect immediately, but cancelled depending upon the fulfilment or not of the condition.

For more information on Project contract management, read the following:

Identifying requirements for business contract language: a monitoring perspective.
(Neal, Cole, Linington, Milosevic, Gibson, and Kulkarni, n.d),
7.3.4 Work breakdown structure (WBS)
The WBS is a hierarchical breakdown of the way in which the project will deliver work tasks to
complete the project. It subdivides the project into smaller, more manageable pieces of work. It has
been found that frequently an organisation can develop its WBS from a standard template because
the work structures are often similar (Meredith and Mantel, 2012:234).

The scope of the project determines its objectives, and dictates the sequencing and time frame
within which they must be completed. It is necessary to gain a complete understanding of the
project deliverables to ensure that the project deliverables can be completed in time and to the
appropriate quality. This understanding must be achieved before scheduling and budgeting can
take place that is, before we become concerned with time and cost planning.

59

However, considering the size and scope of certain projects, it is necessary to break them down
into smaller, more manageable components.

Deconstructing tasks in this way helps to:

Improve the accuracy of cost, time and resource estimates;
Define a baseline for performance measurement and control;
Identify clear and achievable tasks and responsibilities; and
Meet the overall project objectives.

The work breakdown structure is a way of depicting large tasks in terms of smaller sub-tasks.
Having separated projects into their building-block sub-tasks, the project manager then calculates
the time, cost and quality objectives of the major task by adding those of all the minor tasks
together.
Levels of Definition
WBSs are broken down into a variety of levels usually about six depending on the size and
nature of the task. Levels could include:

Level 1: The programme;
Level 2: The project;
Level 3: The element;
Level 4: The sub-element;
Level 5: The work package; and
Level 6: The work package component.

The number of levels increases according to the size and complexity of the project. Whereas
preparing a press release may require only two or three layers, launching an IT system for an
entire government structure could require six or more levels. High-risk activities should be broken
down further in order to ensure that thorough plans for mitigation of those risks can be made
(Meredith and Mantel, 2012:234-236).
WBS Numbering
Tasks within the WBS structure should be logically coded using a numbering system. This is
particularly necessary where cost accounting code systems are in use, defining the cost centres to
which different costs are allocated. Identifying codes should therefore speak to any existing cost
code system that is already in place (Meredith and Mantel, 2012:234-236).
Structuring the WBS
A WBS can be structured in various ways, including by:
Work type;
Responsibility;
Location; and
Project phase. (Meredith and Mantel, 2012:234-236)
60

Shortcuts and pitfalls
It may be tempting to take shortcuts by reducing the number of levels in a work breakdown
structure, but it must be remembered that the actual scope of work cannot be established without
breaking down every work package and task.
Project Logic Evaluation (PLE)
The next step after identifying the tasks and subtasks implied by the total project scope is to
sequence the activities as they will be carried out. This is done through a project logic evaluation
(PLE). This is important for time, cost and quality planning, as discussed in Table 15:

Table 15: Project logic evaluation
Time:
The project manager must know when each WBS activity is going to start and
finish, and, by extension, when the project as a whole will be complete.
Cost:
In terms of budgeting, the project manager needs to indicate when expenditure will
start and end for each activity.
Quality:
The PLE defines the work windows for each task and work package, which will
determine the scheduling of any necessary testing.
(Meredith and Mantel, 2012:234-237)
Deciding on the most logical sequence
Activities may run sequentially or in parallel. This depends on which activities must be done before
others, and which ones can be done at the same time. The example of one of the smallest projects
imaginable making a cup of tea is illustrated in Figure 13.

Figure 13: Logical sequencing

Start
Put
water
in the
kettle
Boil
the
kettle
Put tea
in a
teapot
Pour
tea in a
cup
61

7.3.5 Scope change control process
There is a natural discovery process in all projects due to factors such as omissions, mistakes,
creativity, misunderstandings, and external influences that normally creates pressure to expand or
change aspects of the scope of the project. The purpose of a scope management process is to
constructively manage that pressure.
Reasons for re-planning
Table 16 describes reasons for re-planning, some are beyond the project managers control, but
others can be managed.

Table 16: Reasons for re-planning
Internal (optional) change
Even the most careful planning and design of projects cannot cover absolutely every
aspect of a project. Post-design changes are often enacted to correct this kind of
omission. Where a client or third party is involved, changes may be introduced after the
original planning has been completed. Here, major changes will require substantial
investment in re-planning.
External (imposed) change
An example of externally imposed change is where a supplier or subcontractors
business fails and a replacement must be found. This can be difficult, because
subcontracts can have long lead times which threaten to disrupt the project. This is
where cost contingencies and time reserves become important in the design process,
but even these have their limits.
Sequential disruption
Sequential disruption occurs when resources are shuffled from one project to another
more urgent one. For example, if one important project is falling behind, human
resources and time might be shifted from a longer-term project into the delayed project
in order to address the delay. While this may be effective in the short-term, there are
clear resonances further down the sequence of work, where the longer term project will
also find itself delayed.
Miscalculation
When project planners miscalculate the time and resources that will be required for
particular work packages, there can be major cost and time implications. If insufficient
time is allocated, sequential disruption may result, whereas if a work package is
completed early there may be a need to re-plan in order not to waste idle resources.

Scope expansion is acceptable as long as:

users agree that the new requirements are justified;
impact on the project is analysed and understood; and
resulting changes to the project (i.e. cost, timing, quality, and human resources) are
approved and properly implemented.
62

Implications of re-planning
When considering changes to the project it should once again be emphasised that a change in any
of the variables of time, cost or quality have an impact on the remaining variables.

Scope change control is important because it is through this process that the project manager
analyses and reports on the implications of any scope change on the other variables in the project.
Often, those demanding a change in scope for example, the shortening of the project timeline
assume that the project parameters, costs and deliverables will remain the same despite the scope
change. If the project manager does not make the necessary amendments to any contract in place
for instance, amending the budget to reflect the cost of additional contractors or staff assigned in
order to speed up completion of the project s/he will find that the indicators for success remain
the same despite a decrease in time resources. S/he will be expected to complete the project more
quickly within the constraints of the original budget.

The time-cost-quality continuum becomes useful again when considering the implications of a
scope change for the remaining variables in the project.
Scope change tools
The main tools a project manager uses to manage scope changes are the project scope statement
and the change request register. Change requests are created to document any subsequent
changes to these and are tracked using the change request register.

Throughout the project, proposed changes are documented and screened by the project manager.
S/he determines which suggested changes might be necessary, and these are investigated to
determine the impact of accepting or rejecting them. When the investigation is complete, the
change is either approved and the project management plan is adjusted to reflect this decision, or
the change is rejected. At any point in time, the current project scope is determined by the initial
agreed project scope statement plus all the approved change requests.
Procedural flow of a change request
An attempt should be made, as soon as practical, to resolve change requests. This attempt at
resolution should be performed at each step in the process. First, the change is identified and
entered into a change request register. The change may require clarification prior to investigation
and resolution. In other situations, it may be assigned for investigation immediately. After
investigation, a recommendation is made, reviewed, and resolved. As part of the resolution, the
change request may be accepted, deferred, or rejected. Once the final resolution is approved, the
change request is closed.
The problem of scope creep
Changes need to be managed on even the simplest projects, because of the cumulative effects
created by many small changes to a project. Creeping scope refers to the way in which a number
of minor changes may have major effects on the outcome of a project.
63

7.3.6 Project Time Management
The WBS and PLE precede any other form of scheduling; they are the first steps of the planning
process. However, having dealt with these first steps, we can look at the specific techniques of
time, cost and quality planning.
Time management
Managing time in the project management context is a challenging task as it involves the co-
ordination of a range of different factors, many external to the project itself, and others are reliant
on the commitment, skills and competence of, say team members. This unenviable task falls to
the project manager, who must, of course, begin with him or herself and set a good example of
efficient and effective time management.

Knipe and van der Waldt (2002:139) describe project time management as follows:

Project time management involves determining the time needed to complete the project, and
scheduling the various activities to meet that time. It is the complex co-ordination of a project to
ensure that critical deliverables are met and project completion is reached, both in a timely manner.
This aspect of project management is crucial to the success of a project for, without careful
scheduling and planning, a project is subject to greater risk and thus a greater chance of failure. In
short, time management is the art of estimating, scheduling and tracking project progress. It
includes:

Activity definition
Activity sequencing
Activity duration estimating
Schedule development
Schedule control.
Activity Scheduling
Project managers are increasingly searching for new and easier techniques to control and manage
project complexities, information, and time deadlines. The scheduling of projects needs to align
with the project scope document and needs to be logically sequenced with the proper precedence
relationships and leads and lags to support and achievable project schedule. In the last few
decades, scheduling techniques have continuously improved. We have seen emergence of bar-
charts, milestone charts, network diagrams such as PERT (Program Evaluation and Review
Technique), CPM (Critical Path Method) and so on.

Bar-charts are the most common way of presenting project information. They are simple to
understand and easy to modify. The most widely used bar-chart in project management is the
Gantt Chart. A simple version of the Gantt chart lists the project activities against time. The more
complex versions of the Gantt chart may include the following project elements/activities:
responsibilities, events, milestones, projected versus completed activities, critical path analysis,
parallel activities, etc.

64

Scheduling comprises of the following steps: activity listing, resource allocation, sequencing, and
taking corrective action. The questions to be asked in scheduling are discussed in Table 17:

Table 17: Scheduling steps
Activity listing
What specific activities must be carried out or things must be done, and how must they be
carried out / done, to achieve the project objectives?
Resource allocation
Who will carry out each activity listed, and what other resources will they need to carry out
the activities i.e. money, equipment, advice etc.?
Sequencing
How long should each activity take? What other activities must be completed before this
activity takes place? When must this activity start and by when must it be completed?
What is the best sequence for activities to take place?
Taking corrective
action:
Which activities have been completed and which activities have not been completed that
should have been completed? Why have they not been completed and what must be done
to get them back on schedule? What resources have been used? Has too much of any
resource been used e.g. money? Why has too much been used and what must be done to
get planned resource utilisation back on track?

Draft Master Schedules (DMS)
Once the Project Logic Evaluation (PLE) has been completed, networking and scheduling follow.

Networking

Networking and scheduling builds on the logical PLE sequence by assigning specific durations to
different project activities and determining the start and end points for each activity in order to
arrive at an overall project completion date. This is generally done quickly and easily by computer
programmes. Though this course will not examine software in any great detail, the principles of
networking will be explained in order to provide participants with an appreciation of the main
procedures and applications (Meredith and Mantel, 2012:334).

A Draft Master Schedule (DMS) is the end result of the scheduling process. It is a complete
network analysis of the project, showing the start and finish times of each activity. The DMS
determines the critical path of the project, which is the path of activities that determines the
projects final completion date.

The DMS is a crucial tool to:

identify an overall completion date;
identify order and delivery dates for suppliers;
identify notification and start dates for contractors;
Identify key completion dates for progress planning;
create a basis for implementation of risk management;
identify logical anomalies;
cross-check against contractor schedules;
65

check contract compatibility;
create a basis for re-planning and trade-off analysis;
establish data to determine the possible consequences of delay;
establish data for earned value analysis;
establish data for resource levelling if necessary.

Scheduling therefore entails the stages indicated in Figure 14:

Figure 14: Scheduling stages

Assigning Activity Durations

Durations are assigned to activities using either the Critical Path Method (CPM) or the Programme
Evaluation and Review Technique (PERT).

Activity periods can be calculated with relative accuracy. For example, given the same set of
standard tools it may always take you the same amount of time to change a tyre, allowing you to
make a relatively accurate estimate of the time you will need.

PERT: Used where activity durations cannot be accurately calculated. For example, changing a
tyre where you are not certain whether or not a jack is available, or whether or not your spare tyre
is flat. In this case, you might make informal calculations about the minimum, maximum and most
likely time the activity will take.

Assign durations to each activity
Identify the start and finish window for each activity
Identify activities with no critical path
Re-plan as necessary
Rationalise resources
Formuolate a draft master schedule
Refine the draft to produce a Project Master Schedule (PMS)
66

Project Network/Planning Techniques
Gantt Charts

The oldest and simplest form of project plan is the Gantt Chart, with which many participants will
be familiar.

Limitations of the Gantt Chart

When it comes to large and complex projects, Gantt Charts have disadvantages. These include
the fact that they:

Dont show the underlying links and interdependencies between activities;
Show mainly finish-to-start relationships;
Cant show complex resource requirements in printed form; and
Make re-planning difficult.

Figure 15 is a graphical representation of sequencing the critical path into a Gantt chart.

Figure 15: Sequencing the critical path in a Gantt chart

(Source: Visitask.com, n.d)

The next page provides an example of a Gantt chart for MS Project (Figure 16).
67

Figure 16: Example of a Gantt Chart from MS Project

(Source: Gantt-chart.biz, n.d)

68

To view an explanation of critical pathing in MS Project, click on the link below:

Project management quick tips Lesson 3. http://www.youtube.com/watch?v=R_cokZf7p_k

Network Diagrams

A network diagram is like a precedence diagram with activity durations added to it. Network
diagrams achieve what Gantt Charts do not: they show the dependency relationships
between project activities.

There are two main types of network diagrams: activity-on-arc (AoA) and activity-on-node
(AoN) diagrams (Meredith and Mantel, 2012: 334-336).

Activity-on-Arc Network Diagrams

In the AoA diagram, the arrows (arcs) denote tasks and the circles (nodes) represent events.
For example, node 10 represents the start of the project. Node 20 denotes the end of activity
A and the start of activities B and C, etc.

Figure 17: Activity-on-Arc Network Diagram

Activities can occur in series or in parallel. In the above example, activities A and C occur in
series, while activities B and C occur in parallel (Meredith and Mantel, 2012: 334-336).

Of course, networks can become more complicated and sometimes require the use of
dummy tasks represented by dashed lines. These lines do not represent an actual task. For
example, in Figure 18, activity D cannot start until both B and C are complete. The dummy
task line shows this logic. The network diagram in Figure 18 also shows activity durations.

Figure 18: Dummy tasks
Activity Description
A Procure office space
B Install communications lines
C Furnish office space
Activity Description
69

A logic table explaining the relationships in the network diagram could then be set up to aid
interpretation, as follows:

Activity Description Dependency Duration
A Procure office space - 2 days
B Install communications lines A 3 days
C Furnish office space A 1 day
D Transfer staff to new offices B & C 1 day
E Install computer hardware at desks C 2 days
(Meredith and Mantel, 2012: 334-336)
Activity on Node Network Diagrams
AoN network diagrams are much the same as their AoA counterparts, but this time the node
boxes represent activities and the arrows only represent the dependency relationships
between activities. For this reason, there is no need for dummy lines. All arrow lines
represent dependencies. Various project management software programmes generate these
AoN diagrams (Meredith and Mantel, 2012: 337-338).

A Procure office space
B Install
communications
lines
C Furnish office space
D Transfer staff to new
offices
E Install computer
hardware at desks
70

Figure 19: Activity on Node network diagrams

In AoN diagrams it is necessary to define the relationships between activities rather carefully
(Meredith and Mantel, 2012: 337-338). For this reason, there are various conventions for
representing different kinds of relationships, as follows (Figure 20):

Figure 20: AoN relationships

Critical Path Method
The most popular method of producing a draft master schedule (DMS) from a precedence
diagram or network is the critical path method. The term critical path refers to the longest
path in any network diagram in other words, the expected duration of the project.

71

In exploring network diagrams we have already covered the first step in the critical path
method drawing up the precedence diagram or network. The next steps follow.
Assigning Activity Durations
The two important event times necessary for each activity are the Earliest Start Time (EST)
and the Latest event Time (LET). These are generated by forward and backward passes
respectively (explained later).

Figure 21: Precedence/Network Diagram of IT Refit Project

In the above precedence diagram for replacing the server and PC systems in an office, we
would add activity durations to determine the critical path.
Figure 22: Precedence/Network Diagram with Activity Durations
72

Backward and Forward Passes
Then we would enter the forward pass stage, where we would calculate the earliest event
time (EET) in other words, the earliest time that an event can start. For example the EET
of activity E-F above would be the latest finish time of either B-E or C-E, since both of these
must be complete before E-F can begin. It is possible to split EET into earliest start time
(EST) and earliest finish time (EFT).
Figure 23: Precedence/Network Diagram with EETs

Next, we would enter the backward pass stage to calculate the critical path. Working back
from latest end of the diagram, we would calculate the latest event times of each activity.
That is, the latest time at which each activity could finish without affecting the starting time of
the next activity.

73

Figure 24: Precedence/Network Diagram with EETs and LETs

We can see that this project can be completed in no less than 45 days. Wherever there is no
difference between the EET and the LET, there is no float or slack time for an activity. For
example, activity C must finish on day 6. If not, it will delay the entire project. However,
where there is a difference, a float of time is available. For example, activity D could be
finished by day 14, but there are 4 days to play with if necessary.

To view an example of drawing a network diagram, click on the link below:

Lecture 10 Basic scheduling with A-O-N networks.
http://www.youtube.com/watch?v=yXj2AEVgs0U&feature=related
Programme Evaluation and Review Technique (PERT)
The PERT technique works on the assumption that it is not a simple matter to decide on an
activity duration. Therefore, this is an appropriate method to use when there is uncertainty
about the duration of project activities. When using PERT, one must assign three durations
to each activity an optimistic, most likely, and pessimistic duration. The expected time
taken by each activity is then calculated as the average of these three figures.

So in the following example a project manager may plan an activity. If all goes well and
resources are delivered on time, he may complete the project in 5 weeks. It is most likely
that the project will take 10 weeks, and in the worst case scenario it may be 15 weeks.

To calculate the mean (estimated) duration for each activity:

74

Average time = (optimistic time + (4 x most likely time) + pessimistic time) 6
= (a+4m+b)/6

Calculating average activity time

Optimistic time (a): 5 weeks
Most likely time (m): 10 weeks (also called the mode in this calculation)
Pessimistic time (b): 15 weeks

So: Average time = (a+4m+b)/6
= (5 + 4 (10) + 15) /6
= 60/6
= 10 weeks

The average (mean) time that the project would take to complete is 6 weeks.

To calculate the standard deviation for each activity:

Standard deviation = (pessimistic time optimistic time) 6

Calculating activity standard deviation

Optimistic time (a): 5 weeks
Most likely time (m): 10 weeks
Pessimistic time (b): 15 weeks

So: Standard deviation = (b - a)/6
= (15 5)/6
= 10/6
= 1. 6

The standard deviation is 1.6

In the PERT approach, forward and backward passes are also performed in exactly the
same way as used in the CPM method, as is the calculation of the critical path through the
PERT network.

Next, the project mean duration and standard deviation are calculated:
To calculate the project mean duration:

Project mean duration = (all individual critical path activity mean durations)

Calculating project mean duration

For example: There are five project activities to be completed with the following means for each
activity: 14 weeks, 5 weeks, 10 weeks, 11 weeks and 25 weeks.

Project mean duration = (all individual critical path activity mean durations)
= 14 + 5 + 10 + 11 + 25
= 65 weeks

75

To calculate the project standard deviation:

Project standard deviation = (all individual critical path activity standard deviations)
2

If there is pressure or a demand to complete the project in less than the project mean
duration, statistical calculations can help the project manager to calculate the likelihood of
being able to complete the project within the specified time.

Calculating project standard deviation

For example in the five project activities above the standard deviations may be:
(The standard deviations are estimates as a, b and m were not accurately calculated for this
example)

2.3; 1.1; 1.6; 1.5; 4.2

Project standard deviation = (all individual critical path activity standard deviations)
2

= 2.3 + 1.1 + 1.6 + 1.5 + 4.2
= 10.7

As with Gantt Charts, Critical Path Analysis and PERT methodology helps you to plan all
tasks that must be completed as part of a project. They act as the basis both for preparation
of a schedule and resource planning. During management of a project, they allow you to
monitor achievement of project goals. They help you to see where remedial actions need to
be taken to get a project back on course.

For more information concerning project time management techniques read the following:

Work and Resource Breakdown Structures for formalized bottom-up estimating. (Rad
and Cioffi, 2000) http://www.betsaonline.com/articles/WRBS.pdf
Current practice in project management an empirical study. (White and Fortune,
2002)
Gantt charts: A centenary appreciation. (Wilson, 2003)
Project re-planning
Crash Analysis

You may find that you need to complete a project earlier than your Critical Path Analysis
says is possible. In this case you need to take action to reduce the length of time spent on
project stages. This is referred to as crashing.

You could pile resources into each and every project activity (critical and parallel running) to
bring down time spent on each. This would probably consume huge additional resources. A
76

more efficient way would be to look only at the activities on the critical path and increase
resources on this path after all, non-critical activities will not provide a time saving. This
would shorten the overall project time providing there is still enough float time to complete
the parallel activities.
Figure 25: Critical resource pathing

Crash analysis process
1. Begin with a list of the critical activities those without float.

2. Calculate the cost of crashing each activity.

3. Calculate the cost of crashing per unit time.

This will allow you to see the relative cost and time saving of crashing each activity. This
will prevent you from spending too much on crashing an activity that will not significantly
reduce the length of the critical path. You may also choose to prioritise the crash
sequence by cheapest cost.

For example, some of the main activities on the network diagram above can be analysed
as follows, with crash cost per day calculated as crash cost divided by number of days
saved:

77

Activity
Normal
Duration
Crash
Duration
Normal Cost Crash Cost
Crash
Increase
Crash Cost
per Day
Saved
A-B 4 1 R8 000 R20 000 R12 000 R4 000
B-E 4 1 R8 000 R20 000 R12 000 R4 000
E-F 16 5 R20 000 R70 000 R50 000 R4 545.45
F-G 4 2 R18 000 R36 000 R18 000 R9 000
G-H 4 2 R18 000 R36 000 R18 000 R9 000

4. Calculate the crash sequence.

Usually, this will start with the cheapest unit-crash-cost item and end with the most
expensive.

5. Check the critical path

As the items in the crash sequence are crashed, the critical path will reduce. In the
example shown above, if you only need to shorten the project time by three days, you
may be able to stop crashing after the first crash of A-B. If you need to condense the
project into the shortest amount of time possible, you will need to crash the network up to
the crash limit that is, crashing the entire crash sequence.
78

Trade-off analysis

Crash analysis is one aspect of trade-off analysis. In the example above, we examined a
trade-off between time and cost. However, trade-offs between time and performance, or
between cost and performance, are also possible. Trade-offs may be required if project
objectives change, if errors occur or if unexpected problems arise. It is at this point that one
must weigh up different solutions in terms of their impact on overall time, cost and quality of
the project.
Translate the WBS into an operational plan
When there are a significant number of activities a thorough account of timeframes and
budget allocations is advisable. The following is a generic example of a project planning
matrix for operational use. The information is derived from the work breakdown structures,
project logic evaluation and calculation of activity durations using the DMS.

In the matrix below we see that specific team members have been assigned responsibility
for particular tasks. Time frames have also been assigned, indicating that a project logic
evaluation has been carried out to ascertain the best sequence for activities and the likely
durations of each.

Delegation must be carried out with a view to the team members skills, knowledge and
experience, as well as an awareness of any time constraints they may experience due to
involvement in other projects occurring simultaneously. Ensure clear communication about
the nature of the tasks and elicit information on each team members other commitments to
ensure that the team is equipped with the appropriate resources from time to knowledge
and training to successfully commit to their assigned tasks.
7.3.7 Project Cost Management
Project cost management revolves around three areas of knowledge, according to PMBOK

(2004: 157) (Table 18).

Table 18: Project cost management
Cost Estimating
Developing an approximate schedule of the costs of the resources needed to complete
project activities.
Cost Budgeting
Aggregating the estimated costs of individual activities or work packages to establish a
cost baseline.
Cost Control
Influencing the factors that create cost variances and controlling changes to the project
budget.

The first two of the above activities fall into the planning category, preceding implementation,
and the third into the monitoring category which unfolds with implementation.
79

Cost estimating
Cost estimating involves developing an approximation (estimate) of the costs of the
resources needed to complete project activities. Project cost estimating is usually performed
by adding estimates for individual project elements into a project total. The pieces can vary
in size and number from a few large chunks of a project with known costs, to hundreds or
thousands of discrete tasks or individual work packages. The estimate of a project is
prepared as a measure against which to control expenditure on the project, and is known as
the benchmark or baseline.

Level of Detail

Depending on the level of cost detail required for a specific project, estimates will vary in the
level of detail they include. There are three phases of estimation described in Table 19
(Source: Roberts & Wallace, 2002).

Table 19: Phases of cost estimation
Order-of-Magnitude
Estimation
This is done without any precise data, based on past experience of similar work,
or on published output or cost information. The typical level of accuracy is about
25 %, merely to get an idea of the magnitude of the cost for example R1 000
or R10 000. Therefore, generous contingency funds are provided.
Indicative Estimation:
The indicative estimate is based on known information and published data such
as electronic databases or prices indexes. These are generally accurate to
plus/minus 10 to 15 percent.
Definitive Estimation
A definitive estimate is produced from supplier quotes, contractor-supplied prices
and so on. In other words, it is based on the most realistic and current costs
obtainable. No measurement can be completely accurate, but definitive estimates
should be within 5 percent of an accurate estimate of costs.
(Source: Roberts & Wallace, 2002)

Top down costing

Here the cost of a previous, similar project is used. Care must be exercised as costs that
seem analogous may actually vary because of differing specifications.

80

Activity based costing (ABC)

This is based on the consumption of resources. It is not exact and involves many value
judgements. The cost of an activity for a project is defined as the average cost of the activity
multiplied by the number of times the activity is required for that project.

Bottom up estimating

A detailed WBS is prepared and each activity that goes into a project is estimated. The
technique of bottom-up estimating involves estimating the cost of individual work items, then
summarising or rolling-up the individual estimates to obtain a project total. If the work
process is well understood, this can be a very accurate way of estimating costs.
Supporting details
Cost estimates should include:

A description of the scope of work estimated (using WBS).
A description of the basis for the estimate (i.e. how was it done?).
A record of any assumptions made (e.g. exchange rate, fuel price, etc.).
Cost budgeting
The Role of the Project Budget

The project budget is a management, planning and decision-making tool. It can be used to
(Roberts & Wallace 2002: 6/50-51):

Establish the overall budget baseline for the project, against which changes and
expenditure will in future be measured;
Develop, alongside the project schedule, the projected cost curve for each aspect and
work package;
Establish a reference point for variance analysis, allowing the performance of
individual elements and tasks to be assessed through the duration of the project;
Moderate the spending of those in charge of individual elements of the project;
Generate the basic data for scenario analysis in calculating trade-offs; and
Estimate the likely effects of change notices and variation orders

81

Preparing a Budget

Preparing an initial budget involves (Roberts & Wallace 2002: 6/50-51):

Assigning an accurate cost to each objective, ensuring that you include any possible
hidden costs. Costs often run over budget when possible costs are not properly
thought through, and this often means having to abandon one of the minor objectives
in order to make up for the decreased budget.
Estimating the expected income for the project. Dont be too optimistic, as projects
often cost more than expected.
Comparing income and expenditure. The costs will often exceed the income, in which
case expenditure must be re-evaluated with a view to saving on costs. Build in a safety
or contingency element if you are concerned that you may have underestimated costs.

The final budget that results from the above steps is not in fact final. It must be changed
and re-evaluated whenever unexpected changes occur in the project.

It is necessary to consider a lot of detail when drawing up a budget. It is critical to draw up a
budget that is based on real costs. Most importantly if the project is for a two year period the
budget should factor in inflation.

Costs and Allowances

A variety of different types of costs may be incurred during the life of a project (listed in
Table 20). Knowing the range of costs that may be incurred will assist you in thoroughly
evaluating the possible costs of each project objective (Roberts & Wallace 2002: 6/50-51).

Table 20: List of costs and allowances
Fixed and Variable Costs
Fixed costs are those that occur independently from the exact activities of
a project. For example, the cost of an internet connection, office space,
insurance and administrative salaries. These often form the main part of a
projects indirect costs. Variable costs, on the other hand, fluctuate in a
manner that depends on project activities. For example, if staff has to be
transported and accommodated in the course of a project, this would be a
variable cost. Variables costs are usually direct.
Direct and Indirect Costs
Direct costs, as suggested above, are costs directly related to the project
task at hand. Indirect costs are those that exist independent of project
activities they are the overheads related to facilities, services and
personnel costs. Often, these costs are recovered across organisational
projects.
Measured Works
Individual prices assigned for carrying out individual pieces of work.
Contingencies and Reserve
A reserve of money designated for unexpected contingencies that emerge
during the project. Large, complex projects will often run over budget if
they do not allow in this way for unforeseen additional costs that result
82

from the unpredictable nature of projects.
Cost Fluctuations
When contractors are brought on board for a long-term project, the
contract will usually allow for cost escalation. When the economy is stable,
it is easier to predict increases in the cost of labour, materials and
equipment.
Provisional Sums
Provisional sums are estimated to cover work that is foreseen but not
clearly defined at the start. For example if the purchase of school furniture
in a province were dependent on an audit of the existing furniture so that
the current furniture could be reused wherever possible, a provisional sum
might be used because there is no way of knowing prior to the audit how
much of the existing furniture is still usable.
Bonds and Warranties
Projects involving public finance may include bond cover of perhaps 10
percent of the contract total. Guarantee and warranty amounts may also
be required.
Exchange Rate and Currency
Fluctuations
Should foreign companies be involved in a project, for example the
structural engineers for the building of Nelson Mandela Bridge, it is
preferable to pay the contractor in a stable currency such as US dollars,
Euros, Pounds or Swiss Francs. A contingency amount should be included
to cover shortfalls due to currency fluctuation.
Insurance
Many types of contracts will require the parties to take out insurance for
fire, flood, lightning or radiation.
(Source: Roberts & Wallace, 2002: 6/16-6/20)
Cost control
Requirements of a Cost Control System

We have already established that no part of a project works in isolation from the other
components, and it is no different when it comes to cost control. In fact, your ability to control
cost will depend on an accurate budget plan, which itself is dependent for accuracy upon the
quality of information used to compile it. So in a sense, cost control begins right at the start
of the cost planning journey. If you do not collect and compile your budget data with the
need for accurate cost control in mind, you will be undermining your chances of success
from the outset.

Cost control systems, like most financial planning and management systems, generally
incorporate an electronic system. It is important to understand the principles that such a
system should embody, to ensure that any software used for this purpose is appropriate.
These are discussed in Table 21 (Adapted from: Roberts & Wallace 2002: 6/6 - 6/9).

83

Table 21: Prerequisites for a Cost Control System
An accurate
project schedule
Budgets cant be prepared accurately if every work input to each work package has not been
carefully explored. To reliably predict the resources and costs for a project, all the relevant
information must be taken into account. Every aspect of a task that is overlooked will mean
extra, unplanned cost at the end of the day.
A reliable
estimating system
A cost control system can only perform within the limits imposed by the estimating process that
has been used to prepare it. Estimates cannot be rough guesses; they must be based on
detailed calculations and established data wither price books or estimation software or
estimates taken from recent cost history.
A clear project
scope
To budget accurately it is essential that the parameters of the project and its sub-tasks are
clearly and unambiguously defined. If they are not, it becomes easy for work to be duplicated or
omitted. Two contractors tasked with different aspects of a single work package may quote for
scopes that cover some of the same ground. Alternatively, in internal projects several workers
might overlook a certain task all making the assumption that someone else is responsible for
that aspect. The consequent delay when the oversight is finally noticed will have cost
implications.
Realistic budgets
Nothing must be missed in the budgeting process, as this will lead to an unrealistic budget that is
bound to be overrun. While it may be tempting to present a smaller budget, the short-term kudos
this may earn could be reversed later on when you are unable to control costs within an
unrealistic budget and thus overrun the budget significantly.
A clear
authorisation
system
Clearly, it will be difficult to control expenditure against budgets if the authorisation system is
tangled, confusing and open to abuse. The designation of one or two individuals as the sole
authorising parties increases accountability and acts as an additional check. Alternatively,
different parties can be assigned different levels of authorisation over R10 000, up to R100
000, over R100 000, etc.
A flexible and
responsive
system
Projects change, and with them, costs vary. Therefore, a cost control system must be able to
respond to changing requirements for example through variation orders or change notices
used to amend contract specifications. As each change notice is authorised, the cost estimates
for the project must be updated accordingly.
A reliable
approach to cost-
tracking and
variance analysis
A cost control system must be able to perform rapid and frequent analyses of project data,
because the frequency of analysis is a key to accurate output. Computer software, which allows
project managers to compare the baseline cost plan with the latest version and again compare
these to actual expenditure across multiple work packages, is increasingly used to achieve this.
A time-dependent
variance detection
system
Any system designed to track variance should incorporate a mechanism to lower the
acceptability of cost variance as the project continues it is common for variances to occur early
on during the time of intensive re-planning, but in the later stages of a project there should be
little or no variance.
A flexible
approach to
reserves and
contingencies
Most projects should include a contingency fund of around five percent of the project value and
provisional sums of up to 10 percent of the total value. Project managers should be empowered
to use these sums within the appropriate authorisation structures in order to correct cost
variances on affected work packages.

(Adapted from: Roberts & Wallace 2002: 6/6 - 6/9)
Read the following case study. It describes the consequences of poor quality cost control.

84

Why projects fail: a university accounting system. (Laurie, 2003)
http://www.jiscinfonet.ac.uk/InfoKits/infokit-related-files/project-failure-university-accounting-
system
7.3.8 Project Risk Management
Defining risk
The concept of risk has proven to be somewhat challenging to define. Risk indicates the
existence of the expectation that the actual outcome of a decision may differ from the
outcome originally expected. The terms, risk and uncertainty are often regarded as having
similar meaning. But they are actually very different. Uncertainty implies that no probability
can be attached to any possible outcome identified, whilst risk implies that there is a
possibility of associating probabilities to expected outcomes.
Risk can be defined as:

Risk management is the identification and evaluation of actual and potential areas of risk as
they pertain to an organisation, followed by a procedure of termination, transfer, and
acceptance or mitigating of each risk.

It is a continuous process of identifying, evaluating and managing risk
(SAICA, 2009).

If we look at the above mentioned definition you will find that it all refers to results and
consequences and it also talks about future actions. One can therefore say that Risk
Management is the proactive approach to avoiding or minimising the severity of potential
hazardous actions.
Risk categories
The main categories to group individual risk exposures are discussed in Table 22:

85

Table 22: Risk categories
Risk type Risk category Description
I
n
t
e
r
n
a
l

Human resources
Risks that relate to human resources of an institution. These risks can
have an effect on an institutions human capital with regard to:
Integrity and honesty;
Recruitment;
Skills and competence;
Employee wellness;
Employee relations;
Retention; and
Occupational health and safety.
Knowledge and
Information
management
Risks relating to an institutions management of knowledge and
information. In identifying the risks consider the following aspects
related to knowledge management:
Availability of information;
Stability of the information;
Integrity of information data;
Relevance of the information;
Retention; and
Safeguarding.
Litigation
Risks that the institution might suffer losses due to litigation and
lawsuits against it. Losses from litigation can possibly emanate from:
Claims by employees, the public, service providers and other third
party; and
Failure by an institution to exercise certain right that are to its
advantage.
Loss / theft of assets
Risks that an institution might suffer losses due to either theft or loss of
an asset of the institution.
Material resources
(procurement risk)
Risks relating to an institutions material resources. Possible aspects
to consider include:
Availability of material;
Costs and means of acquiring \ procuring resources; and
The wastage of material resources
Service delivery
Every institution exists to provide value for its stakeholders. The risk
will arise if the appropriate quality of service is not delivered to the
citizens.
Information Technology
The risks relating specifically to the institutions IT objectives,
infrastructure requirement, etc. Possible considerations could include
the following when identifying applicable risks:
86

Security concerns;
Technology availability (uptime);
Applicability of IT infrastructure;
Integration / interface of the systems;
Effectiveness of technology; and
Obsolescence of technology.
Third party performance
Risks related to an institutions dependence on the performance of a
third party. Risk in this regard could be that there is the likelihood that
a service provider might not perform according to the service level
agreement entered into with an institution. Non-performance could
include:
Outright failure to perform;
Not rendering the required service in time;
Not rendering the correct service; and
Inadequate / poor quality of performance.
Health & Safety
Risks from occupational health and safety issues e.g. injury on duty;
outbreak of disease within the institution.
Disaster recovery /
business continuity
Risks related to an institutions preparedness or absence thereto to
disasters that could impact the normal functioning of the institution e.g.
natural disasters, act of terrorism etc. This would lead to the disruption
of processes and service delivery and could include the possible
disruption of operations at the onset of a crisis to the resumption of
critical activities. Factors to consider include:
Disaster management procedures; and
Contingency planning.
Compliance / Regulatory
Risks related to the compliance requirements that an institution has to
meet. Aspects to consider in this regard are:
Failure to monitor or enforce compliance;
Monitoring and enforcement mechanisms;
Consequences of noncompliance; and
Fines and penalties paid.
Fraud and corruption
These risks relate to illegal or improper acts by employees resulting in
a loss of the institutions assets or resources.

87

Financial
Risks encompassing the entire scope of general financial
management. Potential factors to consider include:
Cash flow adequacy and management thereof;
Financial losses;
Wasteful expenditure;
Budget allocations;
Financial statement integrity;
Revenue collection; and
Increasing operational expenditure.
Cultural
Risks relating to an institutions overall culture and control
environment. The various factors related to organisational culture
include:
Communication channels and the effectiveness;
Cultural integration;
Entrenchment of ethics and values;
Goal alignment; and
Management style.
Reputation
Factors that could result in the tarnishing of an institutions reputation,
public perception and image.
E
x
t
e
r
n
a
l

Economic Environment
Risks related to the institutions economic environment. Factors to
consider include:
Inflation;
Foreign exchange fluctuations; and
Interest rates.
Political environment
Risks emanating from political factors and decisions that have an
impact on the institutions mandate and operations. Possible factors to
consider include:
Political unrest;
Local, Provincial and National elections; and
Changes in office bearers.
Social environment
Risks related to the institutions social environment. Possible factors to
consider include:
Unemployment; and
Migration of workers.

88

Natural environment
Risks relating to the institutions natural environment and its impact on
normal operations. Consider factors such as:
Depletion of natural resources;
Environmental degradation;
Spillage; and
Pollution.
Technological
environment
Risks emanating from the effects of advancements and changes in
technology.
Legislative environment
Risks related to the institutions legislative environment e.g. changes in
legislation, conflicting legislation.
(Source: nsw.gov.au, 2012)
Risk identification
Risk identification is a deliberate and systematic effort to understand and document all of the
key risks facing the institution.

Risk identification starts with understanding the institutional objectives, both implicit and
explicit. Risks are those things that will affect the institution form achieving these objectives.
The risks in question do not only relate to fraud, finance or safety but encompasses the
whole spectrum of risk that can affect the achievement of objectives.

When identifying risks, it is also important to bear in mind that risk also has an opportunity
component (refer to the definition of risk as adopted in the risk management framework).
This means there must also be deliberate attention to identifying potential opportunities that
could be exploited to improve institutional performance.

Internal and external events and/or factors affecting achievements of the organisations
objectives must be identified, distinguished between those with negative and positive
impact. Events or factors with a positive impact must be channelled back to management
strategy or objective setting processes. During this identification phase, all financial and
non-financial factors that may influence the organisations policy and management agenda
must be identified.

The organisations risk identification methodology shall comprise a combination of
techniques and supporting tools. Risk identification techniques shall look to both the past
and the future.

89

An organisation can make use of the following questions to identify and control risks:

What, when, where, why and how risks are likely to occur, and who might be involved?
What is the source of each risk?
What are the consequences of each risk?
What controls presently exist to mitigate each risk?
To what extent are controls effective?
What alternative, appropriate controls are available?
What are the department obligations external and internal?
What is the need for research into specific risks?
What is the scope of this research, and what resources are required?
What is the reliability of the information?
Is there scope for benchmarking with peer organisations?
Identify potential risk
Risks can be avoided, or at least planned for, if we stay constantly aware of triggers, causes,
effects and owners. These aspects are briefly discussed below.

Triggers are early warning signs of risks. Jiscinfornet (2009) cites the scenario where your
most casually dressed employee comes to work in a suit and asks for the afternoon off, as a
classic example of a project risk trigger scenario. If you are alert and sensitive to triggers,
you can put plans in place for when things go wrong, or you may even be able to prevent it.

Causes are circumstances or events that lead to events that may jeopardise the project or
objectives. It is therefore extremely important to keep track of causes in order to address
current problems and to avoid similar occurrences in the future.

When we talk about effects, we are concerned with the impact that the risk will have on the
project or unit if it actually occurs.

The owner can be described as someone who will 'own' the risk. This person will be
responsible for monitoring the situation and ensuring that necessary management actions
are carried out. In a project situation the owner is typically someone within the project team
who will be impacted by the risk and who has a vested interest in addressing it.

Management know what risks the organisation is exposed to but, they do not always
formally record those risks. The aim of completing a risk identification exercise is to identify,
discuss and document the risks facing the organisation. These risks are supposed to be
recorded in the risk register.

90

This register is used as:
A source of information to report the key risks throughout the department, as well as to
key stakeholders.
A tool to help managers focus on the priorities.
A tool to assist the auditors to focus their plans on the departments top risks.
Qualitative assessment
Qualitative assessment is applied when the risk does not lend itself to numeric
quantification. In such cases more subjective means are used, the most important of which
is the expert judgement of management.

Risk assessment considerations

The risk assessment tables need to be consistently applied for all key risks in the institution.
Certain disciplines, for example, IT and Health and Safety, may use assessment
methodologies that are informed by their professional norms and standards. In such
circumstances, it would be prudent for the sake of the operational efficiency of these
disciplines to allow them to use their preferred methodology. However, in order to maintain
consistency at the institutional level the same risks should be re-assessed in terms of the
institution-wide risk assessment tables (National Treasury, 2008).

The assessment of likelihood of risk often imposes a challenge to management. In this
respect guidance can be obtained from the historical experience of the institution, as well as
the experience of similar institutions. The assessments must be considered together with the
departments risk appetite to ascertain whether the risk is acceptable or not. This in turn will
inform whether additional interventions will be required.

Below we are going to have a look at risk rating tables as part of risk assessment tools in the
process. Remember we have already touched on this before in our discussion of risk
management framework.

Risk Rating Tables

Risk rating tables can be used to assess the potential impact of risks (Unknown author,
2012). Departments customise these tables to suit their preferred department style. The risk
assessment process includes the following 4 steps:

Step 1

Quantifying the parameters (scoring system) of impact and likelihood before the actual
assessment (Table 23).

Table 23: Risk Rating Table

IMPACT (CONSEQUENCE)
91

Score Rating Description
5 Catastrophic
Loss of ability to sustain on-going operations.
Leads to termination of the project
4 Major
Significant impact on achievements of strategic objectives and targets relating to the
organisational plan.
Cost increase > 20%
3 Moderate
Disruption of normal operations with limited effect on achievement of strategic
objectives or target relating to the organisational plan
Cost increase > 10%
2 Minor
No material impact on achievement of the organisations strategic objectives
Cost increase < 10%
1 Insignificant
Negligible impact
Minimal or no impact on cost
LIKELIHOOD ( FREQUENCY, PROBABILITY)
Score Rating Description
5 Common
The risk is almost certain to occur more than once within the next 12 months/ almost every
time (Probability = 100% p.a)
4 Likely
The risk is almost certain to occur once within the next 12 months (Probability = 50 100%
p.a)
3 Moderate The risk could occur at least once in the next 2-10 years (Probability = 10-50% p.a)
2 Unlikely The risk could occur at least once in the next 10-100 years. (Probability = 1-10% p.a)
1 Rare The risk will probably not occur less than once in 100 years. (Probability = 0-1%)

Step 2

Applying the parameters to the risk matrix to indicate what areas of the risk matrix would be
regarded as high, medium or low risk (Table 24):
Table 24: Risk index = impact x likelihood
I 5 5 10 15 20 25 Risk index Risk Magnitude
M 4 4 8 12 16 20 20 - 25 Maximum
P 3 3 6 9 12 15

15 - 19 High risk
A 2 2 4 6 8 10 10 - 14 Medium risk
C 1 1 2 3 4 5 5 - 9 Low risk
T 1 2 3 4 5 1 - 4 Minimum risk
LIKELIHOOD
Step 3

Determining the risk acceptance criteria by identifying what risks will not be tolerated (Table
25):

Table 25: Risk acceptance criteria
92

Step 4

Determine risk acceptability and what action will be proposed to reduce the risk (Table 26).

Table 26: Risk acceptability

Risk index Risk magnitude Risk
acceptability
Proposed actions
20-25 Maximum risk Unacceptable Take action to reduce risk with highest
priority, accounting officer and executive
authority attention.
15-19 High risk Unacceptable
10-14 Medium risk Unacceptable
Take action to reduce risk, inform senior
management.
5-9 Low risk Acceptable
No risk reduction - control, monitor, inform
management.
1-4 Minimum risk Acceptable
No risk reduction - control,
Monitor, inform management.

Likelihood represents the possibility that a given event will occur, while impact represents its
effect should it occur.

The rating of the risks is conducted through a voting system. Risk has to be rated both on
inherent and residual basis. Residual risk represents risks after considering the
effectiveness of existing control. See Figure 26 below.

Figure 26: Risk rating

4 8
3 6 9
2 4 6 8
1 2 3 4 5
15 20 25
12 16 20
12 15
10
Unacceptable risks
Acceptable risks
5
10
93

Risk analysis (Qualitative and Quantitative)
Once you have identified the risks, your next step would be to decide on the probability that
it may actually occur, its possible frequency and the impact that it will have on the
organisation if it happens (Figure 27).

94

Figure 27: Risk analysis

(Source: Department of Justice, 2008)

Since there is quite some subjectivity and guess work involved in this decision making, it is
important to brainstorm with all the stakeholders and to reach resolutions which the majority
of involved parties will feel comfortable with. Take for instance a risk such as a terrorist
attack or a natural disaster such as the Tsunami. The likelihood that it could happen is not
really great, but if it does happen, the impact will be such that it can ruin an organisation.

A numerical scale such as the one given in Figure 28, it helps to grade a risk as:

High Risk (1);
Medium Risk(2);
Medium Risk(3); or
Low Risk (4).
Figure 28: Numerical risk scale

(Source: Department of Justice, 2008)

After grading the likelihood and impact of the risks, you and the stakeholders have to decide
what your attitude towards each risk will be. You may be tempted to do nothing about a low-
Risk
assessment
Identify Analyse Prioritise
95

probability risk, e.g. one graded as a 2. However, you should remember that it can still be
highly damaging to your business if it occurred. A remote chance of a catastrophe warrants
more attention than a high chance of a hiccup.

To determine the possible impact of a crisis on your business, you should brainstorm and
think of some of the worst possible scenarios and how they might prove debilitating for the
business. For example, how could you access data on your customers and suppliers if
computer equipment was stolen or damaged by a flood? Where would the business operate
from if your premises were destroyed by fire?

The measurement or analysis of risk is important for the following reasons:

To identify the potential operational risk exposure of the organisation;
To serve as a platform for the calculation of the cost of the operational risk;
To serve as a basis for cost-effective decisions by management; and
To ensure that the cost of risk does not exceed the benefits stemming from the actual
management thereof.

Figure 29 can be used to determine the likelihood of risk occurring.
Figure 29: Likelihood of risk

This means that all the risks need to be prioritised in order of importance and then it focused
on or addressed.
Risk response planning
This process is about the determination of how the institution will mitigate the risks it is faced
with, through consideration of alternatives such as risk avoidance, reduction, risk sharing or
acceptance.

Risk management response plan or treatment options are classified under the following
broad categories:
96

Risk Avoidance

Risk avoidance is a decision not to be involved with a risk or in a risk situation. The decision
will be not to proceed with a particular activity or project because upon assessment, the
activity represents such a great risk that there is limited ability to control the risk and that
there is little benefit in pursuing the activity.

Risk Control

Is the pro-active control of adverse consequences of a risk by implementing preventative
measures. It is the risk, which is cost effective to control or treat.

Risk Transfer/sharing

It is the risk that upon assessment shall be considered cost effective to transfer to third
parties or otherwise sharing a portion of the risk with the third party.
Risk Retention
It is the risk that upon assessment shall be considered cost effective to be accepted or
tolerated due to its limited impact on the Department.

The response plan shall be developed once the risk assessment has been completed and
shall include all the intervention to minimise the identified risks.

Control activities

This is about putting in place policies and appropriate procedures such as approvals,
authorisations, segregation of duties, reconciliations and physical safeguards to ensure that
the chosen risk responses are implemented.
Concept of risk evaluation
Risk evaluation is the assessment of the identified risk exposures with the aim of managing
and controlling the risks that could negatively influence the business strategy. If you want to
manage risk effectively it is fundamental that you measure or test the risk exposure. This is
not an easy task as it is difficult to attach a value to some of the operational factors for
examples the impact of virus attacks to our system. Operational risk is evaluated in
quantitative and qualitative terms and therefore it entails the following two approaches:

The quantitative approach aims to quantify the risk in numerical terms and determine
the potential impact on the organisation. It is an analysis of loss exposure.
The qualitative assessment of risk aims to evaluate the risk exposure that cannot be
numerically calculated. These risks are analysed in terms of rating scales to determine
the possible impact and likelihood of risk events.
97

Read the following text to enhance your understanding of project risk management:

Use and benefits of tools for project risk management. (Raz, and Michael, 2001)
Project Risk management: a combined analytic hierarchy process and decision tree
approach. (Dey, 2002)
The risk ranking of projects: a methodology. (Baccarini, and Archer, 2001)

Access the following case study to study the implementation of project risk management:

Case study: Risk Management in Health Case Construction projects. (Petersen, 2009)
http://ohsonline.com/articles/2009/01/01/case-study-risk-management-in-health-care.aspx

7.3.9 Conclusion
The success of a project relies on efficient project initiation and planning. It lays the
foundation for project execution as it provides the project manager with a map as to how to
manage the project. Project managers need to understand that sufficient planning prepares
the project manager for project execution and contributes to achieving the project team
purpose and goals. In the next section, project execution, risk management and project
quality control will be discussed.

98

Recap Questions

1. On the time-cost-quality continuum, try to plot a scope that allows for top quality. What would this require in
terms of cost and time?
2. Now try to plot a scope that provides high quality with low cost and low time resources.
3. Define a contract.
4. Think of any contract you have once entered into and review it critically. What where your intentions of
entering into this contract?
5. Discuss the formalities of a contract.
6. Discuss the concept of a void contract in relation to ascertainability.
7. What is meant by capacity to contract, discuss briefly?
8. Distinguish between a suspensive condition and a resolute condition.
9. Discuss ways and procedures in which contracts can be terminated.
10. How would a work breakdown structure look if constructed for the current project you are involved in? How
many levels would it have?
11. Explain the advantages of bottom-up budgeting.
12. Explain how budgeting techniques can undermine the successful completion of a project.
13. Critically evaluate the necessity of a Gantt chart.
14. Summarise how a network is drawn.
15. Discuss the importance of a critical chain.
16. Argue the reasons why risk analysis should be done during the initiation phase of project management.
17. Read the case study below and critically argue whether the child support system software was a victim of
scope creep. Ensure that you explain the concept of project creep in your response.

Child support software a victim of scope creep

In March 2003, the United Kingdoms Child Support Agency (CSA) started using their new 456 million software
system for receiving and disbursing child support payments. However, by the end of 2004 only about 12 percent
of all applications had received payments, and even those took about three times longer than normal to process.
CSA thus threatened to scrap the entire system and withhold 1 million per month in service payments to
software vendor. The problem was thought to be due to both scope creep and the lack of a risk management
strategy. The vendor claimed that the project was disrupted constantly by CSAs 2,500 change requests, while
CSA maintained there were only 50, but the contract did not include a scope management plan to help define
what constituted a scope change request. And the lack of a risk management strategy resulted in no
contingency or fall back plans in case of trouble, so when project delays surfaced and inadequate training
became apparent, there was no way to recover.

(Project Management Institute, Lack of Support. PM Network. Vol. 19 in Meredith and Mantel, 2012:325))

99

7.4 PROJECT EXECUTION AND EVALUATION
Timeframe: 4 hours
Learning Outcome:
Identify, critique and manage the quality aspect of a project
Examine the skills and processes to manage group dynamics and project teams
effectively
Recommended
reading:
Creative Leadership processes in project team development: an alternative to
Tuckmans stage model. (Rickards, and Moger, 2000)
Writing effective project reports. (Hazen, 2004)
A project management quality cost information system for the construction industry.
(Love and Irani, 2002).
Science, specific knowledge, and total quality management. (Wruck and Jensen,
1994)
Using Cost Benefit analysis for Enterprise Resource Planning Project Evaluation: a
case for including intangibles. (Murphy and Simon, 2001)
Designing projects and project evaluations using the logical framework approach
(Jackson, 2000)
http://www.infra.kth.se/courses/1H1146/Files/logicalframeworkapproach.pdf
Multimedia:
Quality planning vs. quality assurance vs. quality control project quality control. (2012)
http://www.youtube.com/watch?v=iCgzbYi_Iw8
Section overview
In this section of the study guide, you will spend time on project execution and project
evaluation. You are introduced to project monitoring and control. Time is spent and
project reporting and the importance of project documentation is discussed. Project
quality control is evaluated. An overview is provided for the evaluation of information to
assist you with project evaluation and project auditing.

7.4.1 Project Team Development
Tuckman and Jenson (1965 in Rickards and Moger, 2000) developed a team development
model comprising of five stages (Figure 30):

100

Figure 30: Team development stages

Rickards and Moger (2000:273) suggest that this model ignores contingency effects and
might be too prescriptive. They suggest creative leadership as a method of problem-solving.
The writers focus on two critical questions to enhance team development modelling:

Forming
Newly formed teams
Avoidance of serious issues as individuals focus on the desire to be accepted
Team forms project purpose and goals
Sets ground rules for team behaviour
Storming
Problems starts surfacing and confrontation starts
Uncertainties are communicated and team members might become distracted

Norming
Emotional struggles becomes less
Struggles are sorted and team can focus on their purpose
The team's working process is sorted out and team members understand one
another more
Performing
The team performs according to the project purpose and goals
Members work well together and tasks are completed on time and with
enthusiasm
Adjourning
Team achieved the project purpose and goals and breaks up.
101

What mechanisms are at play when a team fails to achieve expected performance?
What mechanisms lead to outstanding performance?
(Rickards and Moger, 2000:277)

The writers argue that team leaders need to encourage team openness which is linked to
the transformational leadership style (if you cannot remember the transformational
leadership style assumptions, revisit your Leadership, Emotional and Spiritual Intelligence
module). They suggest seven team factors that might influence team development.
Rickards and Moger (2000) suggest that their proposals needs further study as they
identified barriers which can be breached by effective leadership involvement. Furthermore,
the study focuses on problem-solving which lack a multi-level model which may offer an
alternative to the Tuckman-Jensen model.

For more information concerning project team development, read the article indicated below:

Creative Leadership processes in project team development: an alternative to Tuckmans
stage model.
(Rickards, and Moger, 2000)
7.4.2 Project Monitoring
Project monitoring is an internal process required during project implementation to ensure
success. Project monitoring is essentially about measuring actual progress against the
project plan or indicators, detecting variance, and taking corrective action. It is mainly
concerned with the following project elements:

Measurement of physical and financial resources;
Time management;
Information management;
Quality control;
Human Resources performance; and
Achievement of project objectives.
Key Project Monitoring Questions and Time Frames
Project monitoring is an integral part of day-to-day management. It provides information by
which management can identify and solve implementation problems and assess progress.
The questions in Table 23 should be asked regularly by the project manager and the project
team:

Table 27: Monitoring questions
Weekly Which activities are underway and what progress has been made?
102

Monthly At what rate are resources being used and costs incurred in relation to implementation?
Quarterly Are the desired results being achieved?
Half yearly To what extent are these results furthering the project purpose?
Half yearly What changes have occurred in the project environment?

Reporting on Progress
Progress review meetings

These should be used to review progress against the plan. The questions above should be
used as a guideline for the meetings. Reflection, review, and problem-solving should be the
norm, not blaming and destructive conflict.

Project progress reports

These are an important source of information. They should refer to the indicators milestones
and targets developed earlier. The following framework is useful and encourages
interrogation:

Data about intended achievements, which is compared to
Data on actual achievements, to identify
Significant deviations from the plan, as a basis for
Identification of problems and opportunities, to identify
Corrective action and alternatives.

For more information on writing project reports, read the following article:

Writing effective project reports. (Hazen, 2004)

Project Planning and Control Tools
Project monitoring is an integral process of the project management cycle and as such it
utilises various project planning and control tools:

Bar-charts
Project documents and reports: work plans, project specifications, networks,
schedules, progress reports, budgets and cash-flow statements, quality plan, etc.

Integration change control means that as the various elements of the project as described
above, alter, encounter problems, find solutions and so on, the project team and the project
103

manager need to keep a flow of information so that all involved are properly informed and
that both macro and micro planning can be adjusted accordingly. Care must be taken that if
one part of a project over-runs time or budget, this does not impact too negatively on tasks
that flow from the delayed task.
Management Information Systems
A management information system is defined as:

A formal method of making available to management the accurate and timely information
necessary to facilitate the decision-making process and enable the organisations planning,
control, and operational functions to be carried out effectively. The system provides
information about the past, present, and projected future and about relevant events inside
and outside of the organisation.

A management information system must be able to satisfy the information needs of all
stakeholders. Moreover, information collected should assist to inform strategic and
operational decisions of the respective stakeholders. This in turn informs the type and
nature of programmes and projects that should be delivered.

Key problems with Management Information Systems (Shortell and Kaluzny, 1993):

Do not collect the right information.
Do not store the right information.
Are not computerised. Lack sufficient computer hardware and software to provide
adequate retrieval and analysis information.
Are not integrated with other systems (e.g. human resources, finances, planning, etc.).
Do not analyse the information.
Do not use the information in decision making processes.
Monitoring Human Resources
The key resource in any organisation and particularly in a project situation is the human
resources. Without the support, skills and knowledge of the project team members, projects
will most likely fail. Project managers therefore have to be equipped with essential hard and
soft human resource skills to manage project team members effectively. Some of the hard
skills refer to performance management, meeting management, planning and scheduling,
delegation, written communication, etc. Some of the soft skills entail: effective verbal and
non-verbal communication, conflict resolution, management of group dynamics, motivating
and inspiring of members, etc. As projects nowadays are invariably complex, project
managers are not charged with managing individuals, but with managing teams.

Setting Performance Indicators

Performance indicators can be defined as quantifiable indicators of performance. These are
used to assess the extent to which projects are meeting their aims while using the assigned
104

and available resources (people, time, money, equipment, etc.) efficiently. Performance
indicators should be derived from, and linked to, each activity listed in the WBS.

Performance is affected by a number of factors (Knipe, van der Waldt et al 2002:228-9):

Personal factors: the project team members skill, confidence, motivation and
commitment
Leadership factors: the quality of encouragement, guidance and support provided by
project managers;
Team factors: the quality of support provided by team members to the project;
System factors: the system of processes, resources and facilities provided by the
organisation to the project; and
Contextual (situational) factors: internal and external environmental pressures and
changes on the project.

Team Monitoring: Conflict Management

Conflict is a process that begins when one party perceives that another party has negatively
affected, or is about to negatively effect, something that the first party cares about. Conflict is
not an aberration something that is abnormal. It occurs in all organisations and teams,
unless there is a culture of compliance, which means that little questioning occurs. Project
team managers need to be able to manage conflict and harness it so that it becomes a
creative, and not a destructive, force.

105

The following list of causes of conflict and conflict escalators are worth reflecting on:

1. Poor communication inappropriate communication channels and too little attention
given to efficient and effective communication.
2. Unreasonable workloads/short staffed high concern for task and low concern for
people.
3. Power plays inappropriate use of power.
4. Interest parties sharing different interests. This is often strongly associated with
power.
5. Understanding sharing a different understanding about the same situation.
6. Value placing a different value on the issue and/or applying a different set of
values.
7. Style different ways of doing something.
8. Opinion holding a different view on the issue.
9. Scarce or limited resources limitations in human or financial resources can cause
intra-organisational conflict.
10. Divisions and specialisation each division concentrates on its own concerns and
co-operation ma become problematic.
11. The interdependent nature of work activities fluctuations in performance in one
area which is dependent on another, especially if linked to reward systems.
12. Role conflict at times our roles may appear conflicting and if these tensions are not
recognised complex conflict can arise (e.g. role as a line manager at conflict with role
as team member or project leader).
13. Inequitable treatment perceived and actual unfairness can lead to friction and
conflict.
14. Violation of territory people tend to become attached to their own work territories
(work station, place in the staff room, personal clients etc.). Resentment arises out
of disturbing this comfort zone or perceived inequity in territorial rights (e.g. amount
of office space, additional staff, and perceived benefits).
15. Environmental change uncertainty can give rise to overt resistance (e.g. blocking
proposed changes, making implementation difficult).

Make use of the problem analysis tools already covered to surface the root cause(s) so that
these can be resolved.
Variance Analysis and Earned Value
On tasks that are 100% complete, the earned value equals the original budget (Roberts &
Wallace 2002: 6/66). Therefore, if Task B has been completed, we can say that it has
earned the value of the planned budget even though it has overspent. Similarly, if Task A is
complete, it has achieved an earned value of R5 200 despite the fact that less was actually
spent. Let us present this visually for the project we are considering. Table 28 below
(sourced from Roberts & Wallace 2002) will provide a better idea of the progress of this
project towards its goals.

106

Table 28: Project progress
Variance Analysis
1 2 3 4 5 6 7 8
Actual
Expenditure
at end of
Month 3
Budgeted
Expenditure
at end of
Month 3
Variance (3
2)
Forecast
cost to
complete
task
Forecast
cost of
task
(2+5)
Original
Budget
Forecast
overrun/
under run
(7-6)
A 5 100 5 200 +100 250 5 350 5 200 -150
B 4 600 4 400 -200 1 500 6 100 6 600 500
C 2 100 2 000 -100 1 700 3 900 4 200 300
D 0 0 0 1 000 1 000 1 000 0
E 1 750 1 500 -250 2 150 4 000 3 900 -100
F 1 000 1 000 0 6 500 7 500 7 800 300
G 250 0 -250 8 000 8 250 8 100 -150
H 0 0 0 3 200 3 200 3 200 0
I 0 0 0 1 200 1 200 1 200 0
14 800 14 100 -700 25 500 40 500 41 200 700

The variance analysis shows quite a positive position for the project. The project manager
will concentrate on minimise the forecast overruns in Task A, E and G (although in this case
the overruns are very small and in some projects would be seen as insignificant).

The principles demonstrated in the last variance analysis table underlie the earned value
method, which analyses the following variables (Roberts & Wallace 2002) (Table 29):

107

Table 29: Variance analysis
Actual cost of the works
performed (ACWP)
Payments or legally committed expenditure incurred to get the project to
its current level of completion. This includes both fixed and variable
costs.
Budgeted cost of the works
performed (BCWP)
This is also known as the actual earned value, and it represents the
budgeted cost that should have been required in order to get the project
to its current level of completion.
Budgeted cost of the works
scheduled (BCWS)
Also known as planned earned value, this represents the budgeted cost
that should have been required in order to get the project to any
specified level of completion.
Scheduled time for work
performed (STWP)
The estimated time required to perform a defined amount of work.
Actual time for work performed
(ATWP)
The actual time taken to perform a defined amount of work.
Cost variance (CV) The budgeted cost of work (BCWP) minus the actual cost (ACWP).
Schedule variance (SV)
The difference between budgeted cost of work performed and budgeted
cost of work scheduled (CV=BCWP-BCWS). In other words, this
measures the performance of project tasks in relation to budgeted costs.

For example:
Total work package budgeted cost = R 1 000 000
Actual cost to date = R750 000
ACWP = R 750 000
BCWP = R700 000
BCWS = R600 000
CV = BCWP ACWP = R700 000 R750 000 = -R50 000
SV = BCWP BCWS = R700 000 R600 000 = + R100 000

In other words, this work package is over cost but ahead of schedule.
Budget at completion (BAC)
This is the sum of all the individual budgets (BCWS) that make up the
whole project sometimes known as the project baseline. It is the total
that the project should cost to achieve final completion.
Estimate at completion (EAC)
This is the estimated total cost of the project the sum of all direct and
indirect costs to date plus the estimated cost of work remaining. The
formula would be EAC = ACWP + estimate to complete (ETC).
Variance at completion (VAC)
The difference between what the project should have cost (BAC) and
what it is expected to actually cost (EAC).

Earned value analysis is generally associated with profit driven business
models, but it is clear that its basic principles offer an excellent model for
continual cost monitoring and control.
108

7.4.3 Project quality control
Quality is a perceptual, conditional and subjective attribute and may be understood
differently by different people. In the context of business, customers might focus on specific
attributes of a product or service and how it matches with the competitors.

Let us look at some common definitions of quality:

A trait or characteristic used to measure the degree of excellence of a product or service.
Meeting customers needs. It can also be said to be the degree to which a set of inherent
characteristics of a product fulfils customer requirements (Metaglossary.com, 2012).

The totality of features and other characteristics of a product or service that bear on its ability
to satisfy stated or implied needs (ISSCO, n.d.).

Duncan (1996:82) divides project quality management into three sections:

Quality planning;
Quality assurance; and
Quality control.
Quality assurance
Quality assurance can be described as:

Quality assurance is all those planned or systematic actions necessary to provide adequate
confidence that a product or service will satisfy given requirements for quality

(Storey et al., 2000)

Objectives of quality assurance

As shown in the definitions above, quality assurance is the process of verifying or
determining whether products or services meet or exceed customer expectations. It is a
process-driven approach with specific steps to help define each goals. This process takes
into account the design, development, production and service.

109

The main objectives of quality assurance include among others:

To maintain an effective Quality Assurance System complying with international quality
systems;
To achieve and maintain a level of quality which enhances the reputation of the
organisation with customers; and
To ensure compliance with statutory and safety requirements.
The process required to control quality
The process can be best explained through a quality control loop. It may be pertinent to
mention here that the word control has many different meanings, some of which have
undesirable overtones. It can spark an immediately hostile and resistant response in many
people. Some find it offensive and feel that only inanimate items like material resources,
expenditure and events can be controlled.

You may wish to substitute this word with progress. The control loop shown below visually
represents the process that a manager uses to monitor and measure what is actually
happening. They then compare this with what is supposed to be happening and if all is well
they need merely to continue monitoring. If things are not going according to plan, they
must take corrective action to bring them back on course. In certain circumstances it might
be necessary to revise the standards, to set new objectives, or to change other aspects of
the quality plan. This process is illustrated in Figure 31.

Figure 31: Quality control process
Take action to correct
performance
Revise the standards
Continue unchanged
if corrective action is
not needed
Measure
performance
Compare performance with
agreed standards and decide
whether corrective action is
needed
Agree
standards
(targets /
SMART
objectives ect.)
START
Either
Or
Or

110

Plan-do-check-act
The quality assurance cycle consists of at least four steps which are:

Plan;
Do;
Check; and
Act.

It may happen that you do not know why you have been unable to achieve the required
quality criteria and you need to use a problem solving technique. The Plan-Do-Check-Act
process provides you with a structure to manage this process.

The Plan-Do-Check-Act is an effective method for monitoring quality assurance. It analyses
existing conditions and methods used to provide the product or service to customers. The
goal of this process is to ensure that excellence is part of every component of the process.

Quality assurance also helps determine whether the steps used to provide the product or
services are appropriate for the time and conditions. If the PDCA cycle is repeated
throughout the lifetime of the product or service, it helps improve internal company
efficiency.

Quality assurance demands a degree of detail in order to be fully implemented at every step.
Let us use the example of planning. Planning could include investigation into the quality of
the materials used in the manufacturing of the product, the actual assembly, or the
inspection processes. The Checking step could include customer feedback, surveys, or
other marketing tools to determine if customer needs are being exceeded and if not explain
the reasons for that. The Acting step could mean a total revision in the manufacturing
process with the aim of correcting a technical or any other flaw in the product. See Table 30
for an overview of the process.
Table 30: Plan-do-check-act
PLAN
Step 1: Identify and analyse
the Problem
Select the problem to be analysed
Clearly define the problem and establish a precise problem statement
Set a measurable goal for the problem solving effort
Establish a process for coordinating with and gaining approval from the
project manager
Identify the processes that impacted on or lead to the problem
List the steps on the process as it currently exists (map or draw out)
Check the process with the respective stakeholders (validate)
Identify the potential root cause(s) of the problem
Collect additional data if necessary to verify the root cause(s).
111

DO
Step 2: Develop and
implement the solutions
Establish criteria to be met by the solution
Generate (brainstorm) potential solutions that will address the root cause(s)
of the problem
Select a solution
Gain approval and support for the chosen solution
Plan the solution
Implement the solution (may need to be done on a trial or pilot basis)
CHECK
Step 3: Evaluate the results
Gather data on the solution
Analyse the data on the solution
ACT
Step 4: Standardise the
solution
Identify systemic changes and training needs for full implementation
Adopt the solution
Plan ongoing monitoring of the solution
Continue to look for incremental improvements to refine the solution
Look for another improvement opportunity

For more information on Project quality control, and techniques used, read the following
articles:

A project management quality cost information system for the construction industry.
(Love and Irani, 2002).
Science, specific knowledge, and total quality management.
(Wruck and Jensen, 1994)

Watch the following click to differentiate between quality planning, quality assurance and
quality control:

Quality planning vs quality assurance vs quality control project quality control. (2012)
http://www.youtube.com/watch?v=iCgzbYi_Iw8
7.4.4 Project Evaluation
When evaluating a project, the following questions are pertinent:

Why is the evaluation being done?
Who are the audiences for the information from the evaluation?
What kinds of information are needed to make the decisions that the audience would
approve of? (Usually information to understand the process of the product or
programme, its inputs, activities and outputs, the customers or clients who experience
the product or program, strengths and weaknesses of the product or programme,
benefits to customers or clients (outcomes), how the product or program failed and
why.
112

From what sources should the information be collected, e.g., employees, customers,
clients, groups of customers or clients and employees together, programme
documentation.
How can that information are collected in a reasonable fashion, e.g., questionnaires,
interviews, examining documentation, observing customers or employees, conducting
focus groups among customers or employees.
When is the information needed (so, by when must it be collected)?
What resources are available to collect the information?
Usually, the farther your evaluation information gets down the list, the more useful is your
evaluation. Unfortunately, it is quite difficult to reliably get information about effectiveness.
Still, information about learning and skills is quite useful.
Methods of project evaluation
The following types of evaluation are commonly used. It is important however to choose a
method of evaluation by the key considerations for doing the evaluation rather that the
method type though. McNamara (2007) provides us with some insights into methods for
programme evaluation.
Goal-based evaluation
Often programmes are established to meet one or more specific goals. These goals are
often described in the original program plans. Goal-based evaluations evaluate the extent to
which programs are meeting predetermined goals or objectives. Questions to ask yourself
when designing an evaluation to see if you reached your goals are:

How were the programme goals (and objectives, is applicable) established? Was the
process effective?
What is the status of the programmes progress toward achieving the goals?
Will the goals be achieved according to the timelines specified in the programme
implementation or operations plan? If not, then why?
Do personnel have adequate resources (money, equipment, facilities, training, etc.) to
achieve the goals?
How should priorities be changed to put more focus on achieving the goals?
(Depending on the context, this question might be viewed as a programme
management decision, more than an evaluation question.)
How should timelines be changed (be careful about making these changes know
why efforts are behind schedule before timelines are changed)?
How should goals be changed (be careful about making these changes know why
efforts are not achieving the goals before changing the goals)? Should any goals be
added or removed? Why?
How should goals be established in the future?
113

Process-based evaluations
Process-based evaluations are geared to fully understanding how a programme works
how does it produce that results that it does. These evaluations are useful if programmes
are long-standing and have changed over the years, employees or customers report a large
number of complaints about the programme, there appear to be large inefficiencies in
delivering programme services and they are also useful for accurately portraying to outside
parties how a programme truly operates (e.g. for replication elsewhere).
There are numerous questions that might be addressed in a process evaluation. These
questions can be selected by carefully considering what is important to know about the
program. Examples of questions to ask when designing an evaluation to understand and/or
closely examine the processes in projects are:
On what basis do employees and/or the customers decide that products or services
are needed?
What is required of employees in order to deliver the product or services?
How are employees trained about how to deliver the product or services?
How do customers or clients come into the programme?
What is required of customers or client?
How do employees select which products or services will be provided to the customer
or client?
What is the general process that customers or clients go through with the product or
program?
What do customers or clients consider being strengths of the programme?
What do staff consider to be strengths of the product or programme?
What typical complaints are heard from employees and/or customers?
What do employees and/or customers recommend improving the product or
programme?
On what basis do behaviour and/or the customer decide that the product or services
are no longer needed?
Analysing and interpreting information
Analysing quantitative and qualitative data is often the topic of advanced research and
evaluation methods. There are certain basics which can help to make sense of reams of
data.
Always start with your evaluation goals
Before analysing data that is collected from questionnaires, interviews, focus groups, and so
on, question why the evaluation undertaken in the first place. This will help you organise
your data and focus your analysis. For example, if you wanted to fully understand how your
programme works, you could organise data in chronological order in which clients go
through your programme.
114

If you are conducting an outcomes-based evaluation, you can categorise data according to
the indicators for each outcome. McNamara (2007) provides us with guidelines on analysing
data:
Basic analysis of quantitative information
For information other than commentary, e.g. ratings, rankings, yess, nos, etc.:
Make copies of your data and store the master copy away. Use the copy for making
edits, cutting and pasting, etc.
Tabulate the information, i.e. add up the number of ratings, rankings, yess, and nos
for each question.
For ratings and rankings, consider computing a mean, or average, for each question.
For example, For question #1, the average ranking was 2.4. This is more meaningful
than indicating, e.g. how many respondents ranked 1, 2, or 3.
Consider conveying the range of answers, e.g. 20 people ranked 1, 30 ranked 2,
and 20 people ranked 3.
Basic analysis of qualitative information
Respondents verbal answers in interviews focus groups, or written commentary on
questionnaires:
Read through all the data.
Organise comments into similar categories, e.g. concerns, suggestions, strengths,
weaknesses, similar experiences, program inputs, recommendations, outputs,
outcome indicators, etc.
Label the categories or themes, e.g. concerns, suggestions, etc.
Attempt to identify patterns, or associations and causal relationships in the themes,
e.g., all people who attended programs in the evening had similar concerns, most
people came from the same geographic area, most people were in the same salary
range, what processes or events respondents experience during the program, etc.
Keep all commentary for several years after completion in case needed for future
reference.
Interpreting Information
Attempt to put the information in perspective, e.g. compare results to what you
expected, promised results; management or program staff; any common standards for
your services; original program goals (especially if youre conducting a programme
evaluation); indications of accomplishing outcomes (especially if youre conducting an
outcomes evaluation); description of the programs experiences, strengths,
weaknesses, etc. (especially if youre conducting a process evaluation).
Consider recommendations to help program staff improve the program, conclusions
about program operations or meeting goals, etc.
115

Record conclusions and recommendations in a report document, and associate
interpretations to justify your conclusions or recommendations.
Pitfalls to Avoid
Dont balk at evaluation because it seems far too scientific. Its not. Usually the first
20% of effort will generate the first 80% of the plan, and this is far better than nothing.
There is no perfect evaluation design. Dont worry about the plan being perfect. Its
far more important to do something, than to wait until every last detail has been tested.
Work hard to include some interviews in your evaluation methods. Questionnaires
dont capture the story, and the story is usually the most powerful depiction of the
benefits of your services.
Dont interview just the successes. Youll learn a great deal about the programme by
understanding its failures, dropouts, etc.
Dont throw away evaluation results once a report has been generated. Results dont
take up much room, and they can provide precious information later when trying to
understand changes in the programme.
Overview of Methods to Collect Information
Table 31 provides an overview of the major methods used for collecting data during
evaluations (McNamara 2007:8).
Table 31: Methods for collecting data
Method Overall Purpose Advantages Challenges
Questionnaires,
surveys,
Checklists
When need to quickly
and/or easily get lots of
information from people
in a non-threatening way
Can complete
anonymously
Inexpensive to
administer
Easy to compare and
analyse
Administer to many
people
Can get lots of data
Many sample
questionnaires already
exist
Might not get careful
feedback
Wording can bias
clients responses
Are impersonal
In surveys, may need
sampling expert
Doesnt get full story

116

Interviews
When want to fully
understand someones
impressions or
experiences, or learn
more about their answers
to questionnaires
Get full range and
depth of information
Develops relationship
with client
Can be flexible with
client
Can take much time
Can be hard to
analyse and compare
Can be costly
Interviewer can bias
clients responses
Documentation review
When want impression of
how programme operates
without interrupting the
programme; is from
review of applications,
finances, memos,
minutes, etc.
Get comprehensive and
historical information
Doesnt interrupt
programme or clients
routine in program
Information already
exists
Few biases about
information
Often takes much time
Info may be
incomplete
Need to be quite clear
about what looking for
Not flexible means to
get data; data
restricted to what
already exists
Observation
To gather accurate
information about how a
program actually
operates, particularly
about processes
View operations of a
program as they are
actually occurring
Can adapt to events as
they occur
Can be difficult to
interpret seen
behaviours
Can be complex to
categorise
observations
Can influence
behaviours of program
participants
Can be expensive
Focus groups
Explore a topic in depth
through group discussion,
e.g. about reactions to an
experience or suggestion,
understanding common
complaints, etc.; useful in
evaluation and marketing
Quickly and reliably get
common impressions
Can be efficient way to
get much range and
depth of information in
short time
Can convey key
information about
programmes
Can be hard to
analyse responses
Need good facilitator
for safety and closure
Difficult to schedule 6-
8 people together
Case studies
To fully understand or
depict clients
experiences in a program,
and conduct
comprehensive
examination through
cross comparison of
cases
Fully depicts clients
experience in
programme input,
process and results
Powerful means to
portray programme to
outsiders
Usually quite time
consuming to collect,
organise and describe
Represents depth of
information, rather
than breadth

(Adapted From McNamara 2007:8)
117

Ethics for collecting data
It is important to note that when conducting an evaluation programme there may be a need
to collect personal and confidential information. It is vital that that the people who provide
this information are confident of their protection, and so it important to get them to sign an
information release form. They also participate on a voluntary basis and must be assured
that they may pull out of the research programme at any time.
Selecting which methods to use
The overall goal in selecting evaluation method or methods is to get the most useful
information to key decision makers in the most cost-effective and realistic fashion. Consider
the following questions when deciding on data collection methods:

What information is needed to make current decisions about a product or programme?
Of this information, how much can be collected and analysed in a low-cost and
practical manner, e.g. using questionnaires, surveys and checklists?
How accurate will the information be?
Will the methods get all of the needed information?
What additional methods should and could be used if additional information is needed?
Will the information appear as credible to decision makers?
Will the nature of the audience conform to the methods? Will they fill out
questionnaires carefully, engage in interviews or focus groups, let you examine their
documentation?
Who can administer the methods now or is training required?
How can the information be analysed?

Ideally, the evaluator should use a combination of methods. They may use a questionnaire
to quickly collect a great deal of information from a lot of people, and then interviews to get
more in-depth information from certain respondents to the questionnaires. Perhaps case
studies could also be used for more in-depth analysis of unique and notable cases.

For more information on Project Evaluation, read the following articles:

Using Cost Benefit analysis for Enterprise Resource Planning Project Evaluation: a case
for including intangibles. (Murphy and Simon, 2001)
Designing projects and project evaluations using the logical framework approach
(Jackson, 2000)
http://www.infra.kth.se/courses/1H1146/Files/logicalframeworkapproach.pdf

118

7.4.5 Conclusion
This section allowed you, the student, to focus on project execution and evaluation. Project
quality control was discussed. In the next section, we will look at project closure and project
based learning.

Recap Questions

1. Identify project team characteristics that will enhance project team development.
2. Explain the importance of project team development.
3. Analyse and explain the importance of leadership in project team development.
4. As a project manager, what action can you take to control the risk to the project if you are unable to source
sufficiently skilled staff for the project team? What action can you take to better equip the organisation for
the future once you notice a skills gap?
5. What is your understanding of a management information system?
6. What kind of information does your institution collect?
7. Why is it necessary to collect this information?
8. How is this information collected?
9. How is this information utilised for management improvement purposes?
10. Describe the concept of project monitoring and control.
11. What is earned value?
12. Compile an outline for a project progress report.
13. Why is it important to archive project documents?
14. What is a project audit?

119

7.5 PROJECT CLOSURE
Timeframe: 3 hours
Learning Outcome:
Recommended
reading:
1. Improved project management through improved document management. (Eloranta,
Hameri, and Lahti, 2001)
2. Project-based learning and the role of learning boundaries. (Scarbrough, Swan,
Laurent, Bresnen, Edelman, and Newell, 2004)
Section overview
This section concludes the project management process. We discuss project termination
and the process involved with project closure. A brief discussion follows concerning
project final reporting. Project based learning is introduced and a model for project
based learning is introduced.
7.5.1 Project closure / termination
Project closure / termination are divided into four fundamental:

Closure by extinction;
Closure by addition;
Closure by integration; and
Closure by starvation.

Knowing when to terminate the project is also very important to the project management
process.
Project closure process
Meredith and Mantel (2012:551) differentiates between two phases in the project closure
process: the decision process and the implementation process. The decision process
determines whether the project is ready for closure or whether the project manager needs to
risk increased cost to complete the project in relevance to the project status and expected
outcome. The implementation process concludes the process of closure. It focuses on the
tasks involved in closing a project.

Read the following article describing improved project management:

Improved project management through improved document management. (Eloranta,
Hameri, and Lahti, 2001)
120

Writing the final report
Report writing skills are not the focus of this study, yet it is important to indicate the essential
elements needed for a final project report. Meredith and Mantel (2012:565) indicates the
following subjects to be discussed in the final report.

Project performance
Administrative performance
Organisational structure
Project and administrative teams
Techniques of project management
7.5.2 Project based learning
You will need to consult the following article for this section:

Project-based learning and the role of learning boundaries.

(Scarbrough, Swan, Laurent, Bresnen, Edelman, and Newell, 2004)

The experience of managing projects often lies within learning from previous project
mistakes or successes. The article provided distinguishes between:

The practice-based nature of knowledge and learning in organisations;
The relative autonomy of projects within the organisational context; and
The integration of knowledge within projects.

The writers suggest a model for project based learning. This model is summarised in Table
28 (Scarbrough, 2004:1584).

121

Table 32: Project based learning

(Source: Scarbrough, 2004:1584)

The value of allowing learning to take place at all aspects of the project management
process is endless. Learning inevitably encourages development and development is
fundamental for growth.
7.5.3 Conclusion
This section was devoted to project closure and project based learning. Project
management, like any managerial process, needs to be terminated methodically. This
completes the project life cycle.

122

Recap Questions
Read the case study below and answer the questions that follow:

Project Termination practices in Indian industry

Project termination phase, the last phase of the project life cycle, plays a vital role in successful completion of a
project. The process of project termination is not an easy task. It has to be planned, budgeted and scheduled
like any other phase of the project life cycle. Sometimes special termination managers are put to complete the
termination process. Though project termination constitutes a significant part in the total project it is often
overlooked by project managers. A case study was conducted to analyse the problems faced by project
managers while terminating projects in India.

The case study revealed that project managers loosen their grip of monitoring the time-bound projects as soon
as the installed plants or services start functioning. The last few defects continue to get rectified for long periods
in the process of handing over the projects to clients. By the time these defects are rectified, new problems drop
up which require further time to stabilize. It has been observed that plants are formally handed over with
preliminary acceptance certificate, pending rectification of last few problems. This becomes a vicious cycle
before obtaining the final acceptance certificate form the client. Due to non-realisation of the last contractual
amount, project organisations face shortage of funds, particularly when they are engaged in multiple projects.
For example, a company manufacturing material handling equipment ran a coal-handling plant for a power
project of a leading power generating firm for almost 10 years before it could successfully terminate the project
due to the project managers inability to meet the performance guarantee tests. Another difficult aspect is the
identification of the beginning of the termination phase of a project. Project managers use their perception and
judgement to identify the starting of termination phase after completion of execution, commissioning, and testing
activities.

An analysis of the case study data revealed that the following problems are considered most significant by Indian
industry during the project termination phase:
Negotiating claims with clients
Compliance of statutory requirements
Receipt of the final instalment of payment
Performance guarantee tests
Handling claim of suppliers.
(De, P.K. Project termination practices in Indian industry: a statistical review. International journal of Project
Management. Volume 19 (2):119-126. In. Meredith and Mantel, 2012:550)

1. Evaluate the mistakes indicated in the case study made by project managers during the project closure
phase. Suggest activities to ensure that these mistakes are not repeated in projects you are running / part of
in your organisation.
2. Critically discuss the ways in which projects are terminated.
3. Relate managing information systems to project closure.
4. Discuss the importance of project-based learning.
123

8 REFERENCES
Burke, R. (2004) Project management: Planning and control techniques. 4
th
Edition. Cape
Town: PROMATEC International.

Cobb, A.T. (2006) Leading project teams: an introduction to the basics of project
management and project team leadership. viewed 09 November 2012,
<http://books.google.co.za/books?id=0-
5SE6Nw0poC&printsec=frontcover&dq='project+teams'&source=bl&ots=YhgaQTSihx&sig=Z
LEImsb9RkrUUK7VZ8Px3OMvqyA&hl=en&ei=M_TbTIvMMsPFswaSmq2iBA&sa=X&oi=boo
k_result&ct=result&resnum=12&ved=0CEQQ6AEwCw#v=onepage&q&f=false>

Department of Justice. (2008) Legal risk management in the department of justice
formative evaluation. Final report. viewed 6 September 2012,
<http://www.justice.gc.ca/eng/pi/eval/rep-rap/08/lrm-grj/lrm_evaluation_eng.pdf>

Dictionary.com (2012) Project. Viewed 25 September 2021,
http://dictionary.reference.com/browse/re+project>

Dictionary.reference.com. (2012) Project. Viewed 3 September 2012,
<http://dictionary.reference.com/browse/project>

Duncan, W.R. (1996) A guide to the Project Management Body of Knowledge. viewed 3
September 2012, <http://www.unipi.gr/akad_tmhm/biom_dioik_tech/files/pmbok.pdf>

Evaristo, R., and van Fenema, P.C. (1999) A typology of project management: emergence
and evolution of new forms. International Journal of Project Management. 17(5), pp. 275-
281.

Fouche, M. A. (1990) Legal principles of contracts and negotiable instruments. Pretoria:
DIGMA

Furst, S.A. Reeves, M., Rosen. B., and Blackburn, R.S. (2004) Managing the life cycle of
virtual teams. Academy of Management Executive. 18(2), pp. 6-20.

Gantt-chart.biz. (n.d) Project editor. Viewed 23 September 2012, <http://www.gantt-
chart.biz/gcImages/Gantt_Chart.gif>

Green, S. (2005) Strategic project Management. viewed 6 September 2012,
<http://www.projectscenter.com/projectmanagementsoftware/documents/strategicprojectma
nagement.pdf>

Hass, K. (2007) The blending of traditional and Agile project management. viewed 23
September 2012, <http://www.projectsmart.co.uk/the-blending-of-traditional-and-agile-
project-management.html>

124

Haughey, D. (2011) An Introduction to Project Management. viewed 17 September 2012,
<http://www.projectsmart.co.uk/introduction-to-project-management.html>

Havenga, P. ; Garbers, C. ; Havenga, M. ; Schulze, W. ; Van Der Linde, K. ; Van Der Merwe,
T. (2001) General Principles of Commercial Law. ( 4
th
Edition.). Cape Town: Juta

Havenga, P. Havenga, M., van der Linde, K.,and van Kerken, E. (1992) General Principles
of Commercial Law. Cape Town: Juta

Hisrich, R. D. (2004) Small business solutions. McGraw-Hill Professional, viewed 22 May
2009,
<http://books.google.co.za/books?id=lpMTftc5XCEC&dq=business+venture+resources&sour
ce=gbs_summary_s&cad=0>

Investopedia.com, (2012) Definition of Return on investment ROI. Viewed 23 September
2012, <http://www.investopedia.com/terms/r/returnoninvestment.asp#axzz27KkzgQIs>

ISSCO. (n.d.) Terminology. viewed 6 September 2012,
<http://www.issco.unige.ch/en/research/projects/ewg95//node69.html>

Jiscinfonet. (2009) Risk Management. viewed 9 April 2009,
<http://www.jiscinfonet.ac.uk/InfoKits/risk-management/risk-log>

Karlsen, J.T. (2002) Project stakeholder management. Engineering Management Journal.
14(4), pp.19-24

Kerr, A. J. (1989) The Principles of the Law of Contract. 4
th
Edition. Durban: Butterworths

Kerzner, H. (1998) Project management: A systems approach to planning, scheduling and
controlling. 6
th
Edition. Danwers: John Willey & Sons.

Knipe, A., Van der Walt, G. (2001) Project management for strategic change and upliftment.
Cape Town: Oxford University Press.

Knipe, A., Van der Waldt, G. (2002) Project management for success. Sandown:
Heinemann.

Kopel, S. (1996) Student Guide to Business Law. Johannesburg: International Thomson
Publishing.

Kwak, Y.H. and Ibbs, C.W. (2002) Project Management Process maturity (PM)
2
model.
Journal of management in engineering. July 2002.

McNamara, C. (2007) Basic guide to programme evaluation. viewed 10 November 2010,
<http://managementhelp.org/evaluatn/fnl_eval.htm>

Meredith, J.R., Mantel, S.J. (2012) Project management: a managerial approach. New
Jersey: John Wiley & Sons, Inc.
125

Metaclossary.com. (2012) Quality. viewed 6 September 2012,
<http://www.metaglossary.com/meanings/406936/>

Mindtools.com, (2010) Stakeholder analysis. viewed 09 November 2010,
<http://www.mindtools.com/pages/article/newPPM_07.htm>

Morphy, T. (2008) Stakeholders not happy? Cant get people to work together? Use four
simple steps and our proven templates to map your stakeholders. viewed 9 November
2010, <http://www.stakeholdermap.com/index.html>

Munns, A.K., Bjeirmi, B.F. (1996) The role of project management in achieving project
success. International Journal of Project Management. 14(2), pp. 81-87.

National Treasury. (2008) Guidebook: Risk Assessment. National Treasury publication

Nsw.gov.au. (2012) Categories of risk. viewed 6 September 2012,
<http://www.smallbiz.nsw.gov.au/start/legalcompliance/riskmanagement/categories/Pages/d
efault.aspx>

NYS Project Management Guidebook. (n.d.) Section 1: Project Management Lifecycle.
viewed 5 September 2012, <http://www.its.ny.gov/pmmp/guidebook2/Origination.pdf>

Project management body of knowledge. (2004). 3
rd
Edition. Pennsylvania: Project
Management Institute. Inc.

Projectsmart.co.uk. (2010) Stakeholder management viewed 09 November 2010,
<http://www.projectsmart.co.uk/stakeholder-management.html>

Rickards, T. and Moger, S. (2000) Creative Leadership processes in project team
development: an alternative to Tuckmans stage model. British Journal of Management.
11, pp. 273-283.

Roberts, A., Wallace, W. (2002) Project Management. Pearson Education: Essex

SAICA. (2009) Summary of Report on Governance for South Africa (King III). viewed 20
August 2012, <http://www.auditor.co.za/Portals/23/king%20111%20saica.pdf>

satender.co.za. (n.d.) Tenders. viewed 21 May 2009, <www.satender.co.za>

Shendar, A.J., Dvir, D., Levy, O., and Maltz, A.C. (2001) Project success: a
multidimensional strategic concept. Long Range Planning. 34, pp. 699-725

Shortell, S.M., Kaluzny, A.D. (1993) Health care management: organisation design and
behaviour Albany: Delmar.

Storey, A., Briggs, R., Jones, H., Russell, R. (2000) Chapter 4: quality assurance. viewed
6 September 2012, <http://www.who.int/water_sanitation_health/bathing/bathwatchap4.pdf>
126

Unknown Author, (2010) Stakeholder definition. viewed 09 November 2010,
<http://www.mariosalexandrou.com/definition/stakeholder.asp>

Unknown Author. (2012) Risk assessment tables. viewed 6 September 2012,
<http://hr.mq.edu.au/HealthAndSafety/PoliciesFormsGuidelines/Docs/Forms/RiskAssessme
ntMatrix.pdf>

Unknown Author, (n.d.) Stakeholder. viewed 09 November 2010,
<http://www.visitask.com/stakeholder-g.asp>

Visitask.com. (n.d). PERT sequence diagram. Viewed 23 September 2012,
<http://www.visitask.com/img/sample-gantt-chart.jpg>

PRM MBA v5 e F PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PRM MBA v5 e F PDF

Uploaded by

Copyright:

Available Formats

Contact details:

Regenesys Business School

NINE PROJECT MANAGEMENT AREAS .............................................................. 16

NINE PROJECT MANAGEMENT AREAS .............................................................. 16

organises the knowledge needed for project management

nine project management areas

nine project management areas

knowledge area 6: Human resource management. The project

2004:39). These objectives only serve as guides to which project management

, 2004). The scope definition outlines the project content,

You might also like