tmp13C TMP

The Guerrilla
Principle
- Winning Tactics for Global Project Managers -
Jacques Magliolo
Author of the bestselling
Corporate Mechanic
Become Your Own Stockbroker
Richer than Buffett
Jacques Magliolo, 2007
The Guerrilla Principle: Winning Tactics for Global Project Managers
Definitions
Guerrilla tactics are the unconventional use of closely knit
small teams, with a sole leader, to combat less mobile
formal entities through discipline, dedication and complete
focus.
New Project Management is the discipline of organising
and managing resources in such a way that the project
team is small, efficient and led by an independent project
manager, who will deliver a defined project within time and
cost constraints.
And, to do this in a hostile global environment.
Page 2 of 283
By the Same Author

Share Analysis and Company Forecasting
The Business Plan: A Manual for South African Entrepreneurs
The Millionaire Portfolio
Jungle Tactics: Global Research, Investment & Portfolio Strategies
A Guide to AltX: Listing on SAs Alternative Stock Exchange
Become Your Own Stockbroker
The Corporate Mechanic: The Analytical Strategists Guide
Richer Than Buffett: Day Trading to Ultra-Wealth
Page 3 of 283
Dedication
To my daughter Alexandra Pasqual Magliolo
Page 4 of 283
CONTENTS
INTRODUCTION
PREFACE: SETTING THE SCENE
Lessons Learned: General
ABOUT THE AUTHOR
PRE-PROJECT PREPARATION
GUERRILLA PRINCIPLES & THE CASE STUDY
STAGE 1: UNDERSTANDING THE BASICS & PROJECT INITIATION
Common Mistakes: Getting Started
CHAPTER 1: PROJECT DEFINITION & AGREEMENTS
CHAPTER 2: DEFINING KEY ROLES
CHAPTER 3: PREREQUISITES FOR SUCCESS
CHAPTER 4: DEVELOPING PROJECT STAGES
CHAPTER 5: ASSESSING PROJECT VIABILITY
CHAPTER 6: INITIATION & SCHEDULES
Case Study Commentary: Stage 1
STAGE 2: PROJECT PLANNING
Lessons Learned: Planning
CHAPTER 7: PLANNING A PROJECT
CHAPTER 8: PRIORITISING OBJECTIVES
CHAPTER 9: A PHASED APPROACH
CHAPTER 10: ASSESSING CONSTRAINTS
CHAPTER 11: THE TASK LIST
CHAPTER 12: COMMITTING & MANAGING RESOURCES
CHAPTER 13: ORDER & CRITICAL PATH ANALYSIS
CHAPTER 14: SETTING DEADLINES
CHAPTER 15: VALIDATING THE PLAN
Page 5 of 283
STAGE 3: PROJECT EXECUTION, CONTROL & MONITORING
Lessons Learned: Project Execution
CHAPTER 16: ROLE PLAYERS & TEAM BUILDING
CHAPTER 17: THE FIRST MEETING
CHAPTER 18: LEADING EFFECTIVELY
CHAPTER 19: MAKING TEAM DECISIONS
CHAPTER 20: MANAGING INFORMATION, COSTS & PROFITS
CHAPTER 21: COMMUNICATION, HEALTH CHECKS & PROJECT SUPPORT
CHAPTER 22: PROJECT PROGRESS SCHEDULING, TRACKING & CONTROLLING
CHAPTER 23: HOLDING REVIEW MEETINGS
CHAPTER 24: THE CASE METHOD OF DECISION MAKING
CHAPTER 25: RISK MANAGEMENT
CHAPTER 26: DEALING WITH CHANGE
STAGE 4: PROJECT COMPLETION & POST-MORTEM
Lessons Learned: Project Closure
CHAPTER 27: QUALITY, SPEED & CLOSURE
CHAPTER 28: FINALISATION & THE POST-MORTEM
CHAPTER 29: : SELF ASSESSMENT FOR PROJECT MANAGERS
FINAL WORD
APPENDICES
Appendix 1: Project Management Rules
Appendix 2: Project Definitions: Essential information
Appendix 3: Project Scope Template
Appendix 4: Project Initiation Template
Appendix 5: Risk Checklist - Small Projects
Appendix 6: Risk Checklist - Large Projects
Appendix 7: Change Request Sample Form
Page 6 of 283
Appendix 8: SWOT Analysis Template
Appendix 9: Reasons for Potential Project Failures & Successes
Appendix 10: Project Management Associations
Appendix 11: Due Diligence Questions
Appendix 12: Main Board & AltX: Differences
Appendix 13: Benefits Of Listing On The JSE Ltd
Appendix 14: Case Study Phase Two: Agenda
GLOSSARY
REFERENCES
INDEX
Page 7 of 283
INTRODUCTION
Looks impressive, doesnt it?

Now imagine if you had to take the above diagram and add due diligence, business plans, regulatory
issues and accounting forensics? On top of that, imagine trading in a global environment with a multitude
of cultures, languages, ethics (or lack thereof), corporate governance, time differences, currency risk
profiles and conglomerates, which rule the global corporate environment with a staggering hostility and
ruthlessness that is backed by billions of dollars.
To the point, in fact, that entrepreneurs around the world have had to rethink their entire way of running
projects. Do they have the requisite level of understanding of the economics, business, socio-political
nuances and technological know-how to undertake ventures in the future? Are the old, tried and tested
project management theories enough to survive and prosper under such conditions?
Do entrepreneurs need to rethink strategy? Do they need to take a step back and assess how they will
continue to operate and achieve requisite levels of profit? The authors experience suggests that there
isnt really need to panic. The problem, however, is that entrepreneurs need to do things right the first
time. There simply is no short cut to prospering in a global marketplace.
Too many business owners spend too much time trying to resolve every problem that occurs within a
firm and are thus not prepared for the rapidly changing business condition within which they trade. For
instance, in South Africa the need to spread shareholder wealth through empowerment initiatives meant
Page 8 of 283
that companies had to find partners and shareholders within previously economically disadvantaged
communities.
As a corporate consultant, the author has been repeatedly approached to resolve such issues for local
entrepreneurs. So, at the first meeting, the authors first question is always the same: Do you want to
give away shares in your business or do you want to sell these shares?
This may seem like an obvious question and the answer is always the same, and said in a less than
consolatory tone. Why should I give away a percentage of my business .?
The second question, then, should also be basic and absolutely obvious; the answer, however, seldom
is. Here is the main issue if you need to have a new partner and shareholder, then you need to transfer
shares to that person or organisation. That is simply logic. If you want to get paid for those shares, then
the only issue is to work out the cost of those shares.
The obvious second question: What is the value of your business? The answer is usually stunned
silence.
Stated again - entrepreneurs often find themselves trying to handle all problems within their firm and
refuse to delegate. Often, to the point that few entrepreneurs keep to their planned strategies or targets,
even fewer have active and updated business plans. Seldom do company owners have a renewed
valuation for their businesses, nor do they have internationally accepted valuation methodologies, which
they can use to update the value of their companies. A full valuation methodology is outlined in the
authors 2007 university MBA textbook on strategy, called The Corporate Mechanic.
These issues may seem obvious and not pertinent to conglomerates. Or are they?
In 2002, the author was commissioned by PricewaterhouseCoopers the South African branch of the
international accounting house to assess why one of their clients was effectively going bankrupt,
despite controlling 85% of the fertilizer market in South Africa. In this case, lack of research of the
international related markets had resulted in the company paying more for raw materials than they
needed. In fact, research immediately highlighted that the company was the subject of price collusion in
South Africa. Understand that the main element to produce fertiliser is, in fact, ammonia, which is a byproduct obtained from a conversion process; details are not necessary here.
The following graph explains the whole story: the South African companies selling ammonia had kept
prices high after the global price had dropped.
An in-depth research document, followed by due diligence, business plan and corporate re-engineering
and strategy resolved their cash flow problems, led to new structures and a planned expansion
Page 9 of 283
programme. Simultaneously, the company used the research document to take these sellers to the
South African Competition Board and won.
The obvious is not always easy to see. This is the main reason why the author has - during the past
seven years since leaving stockbroking and after launching his own corporate strategy firm Business
Consultants International developed a four phase approach to corporate finance. The methodology has
enables the corporate advisor to initiate, plan and take control of a project and to deliver project
completion within a predetermined timeframe. To date, the author has produced over 30 major projects
and countless smaller ones, all on budget and at the scheduled time. All these are familiar to project
managers around the world and certainly fulfil recognised international theory on the subject.
What, then, is the author proposing that is different to the obvious?
The aim is to keep the client informed, while manoeuvring the project within the global environment and
only after potential problems have been sorted through due diligence and strategy; these statements will
become clear in later text See Guerrilla Principle & The Case Study.
Just two issues that have to be understood at this stage:
Any new project must be undertaken with an understanding as to its influence on the company as a
whole.
Any new project must be undertaken with analysis of the global, regional and local markets. Such
analysis must include political, economic, business and technological trends.
Projects around the world

Today, organisations around the world make billion dollar investments in all spheres of business.
Thousands of projects are carried out, from starting a small school tuck shop to implementing new
employee incentive schemes to launching new aviation conglomerates. Surely, these projects must be
undertaken with some form of in-depth plan in place.
At least, many entrepreneurs assume that such projects have a logical and well thought out process.
They would be surprised to hear, then, that most projects fail to achieve predetermined objectives due to
the simplest of causes. You dont have to be a genius to deliver a project on time, nor do you have to be
steeped in a mystical project management methodology to be a project manager.
To be successful in today's hostile and extremely ruthless competitive business world, managers must
deliver results on time and within budget. Yet, there is no point in doing just that (time and budgets) if the
project ultimately exposes the company to structural weaknesses, potential corporate takeovers or loss
of market share due to the project causing balance sheet weakness, earnings strain and falling profit
margins. By applying basic project management processes, tools and techniques shown in this book, the
consultant can maximise performance and ensure optimum (and safer) results for the company.
Without proper planning and structure, projects tend to quickly deteriorate and always:
Take longer than expected to be completed.
Cost substantially more than originally planned.
Seldom produce the expected result.

Does this sound familiar?
This book has been developed as a guide for project managers, corporate consultants, entrepreneurs
and students to help them to plan projects and to maintain control of that project until the company
owners have signed off and the project has been completed. While there is never a guarantee of project
success, experience does highlight that planning and knowledge (company, market and general trends)
do significantly increase the chances of success.
Page 10 of 283
The main reason for writing this book has been a perceived widening gap between current project
management theory and practice and the dire need for global strategy, knowledge and co-ordinated
planning when undertaking any project, whatever the size or cost.
The theories and case studies set out in this book are, therefore, based on observations and conclusions
made in over 400 projects completed since the author left stockbroking in July 2000. These reflect
experiences over a wide range of successful projects, from setting up a chicken farm in the Nigerian
province of Akwa Ibom, fertilizer in Kwazulu-Natal, platinum mining, research on semi-conductors for the
University of Potchefstrooms department of Nuclear Physics, to aviation projects in Singapore and
corporate finance required to list a number of companies on South African stock exchanges.
It is not offered as a prescriptive approach to project management, nor is it
claimed to be 100% complete a book of this nature is wide ranging and must
be used as a guide only; use what is appropriate to your specific
requirements.
This project management guide is, therefore, set out to provide you with a carefully planned and
organised methodology to accomplish specific tasks within broader stages of project management effort.
Project management includes developing a project plan, which includes defining project goals and
objectives, specifying tasks or how goals will be achieved, what resources are needed to set out budgets
and timelines for completion. It also includes implementing the project plan, along with careful controls to
stay on the "critical path"; that is, to ensure the plan is being managed according to pre-determined
objectives. Project management usually follows major stages with various titles for these stages, as set
out hereunder.
BOOK LAYOUT
The book consists of a series of practical and easy to understand sections that set out the theory and
practical aspects of project management.
Three sections
Four Stages
Supporting information
Introduction
Preface
Pre-Project Preparation
The theory behind Magliolos Guerrilla Principle
In-depth Case Study
The four elements that make up project management
(initiation, planning, execution and completion) are set
out in four Stages, which reflect these elements.
Templates
Additional information
Glossary
References
Index
After the introduction, a preface sets the tone of the book, followed by basic tools that will be useful in
the pursuit of becoming a project manager. A more lengthy discussion follows on the theory of what the
author terms Guerrilla Principles; a set of guidelines that he has used successfully to complete many
major projects on time. The practical side of such theories is set out in an actual recent case study,
which is, therefore, used throughout this book.
The book is then broken up into four parts or stages, which mirror the stages of project management.
The four Stages of the book start with understanding the basics and the required steps to initiate a
project. In stage two, the methods of project planning are set out, followed by project execution in stage
three. In the final stage, completion and a post-mortem is carried out on the project.
Page 11 of 283
Each Stage consists of a number of pertinent information:
Starts with a list of common mistakes, which acts as warning signals for the project manager to avoid
straying from objectives.
A brief description of the Stage.
An explanation explains what the project manager intends to achieve during that specific Stage.
How does the project manager go about achieving the targets set out in the Stage?
Explanations relating to the Stage are set out.
The activities within the Stage are explained.
The Stage ends with a checklist, which ensures that all relevant targets have been achieved during
the Stage; to be completed before proceeding to the next Stage.
In addition, throughout the book:
Templates are set out to help expedite the process of undertaking project management.
Step-by-step guides are used throughout the book to make it easier to understand, in many
instances, conflicting theory of project management.
Where possible, a sample (or explanations) of what is produced by the Stage has been provided;
using the Case Study as the basis for explanation.
Learner Notes are set out throughout the chapters and are the basis for the questionnaire; set
out in the Appendices.
Organisations that employ professional project managers have well-worn project management
procedures, templates, questionnaires and surveys. These organisations have the skill and accumulated
in-house experience to undertake projects in an efficient and methodical manner. Yet, there are other
firms, whose primary business is not project-based, but still need to undertake projects.
You will find that many of the latter form of businesses will employ professional people, from IT
Specialists, to accountants and lawyers to even medical doctors, to manage projects. After all, these are
qualified and experienced people?
They may be qualified and experience in their specific fields of expertise, but they are not first, and
foremost, project managers. Yet, they are expected to manage projects - even ones that will determine
the organisation's future - in an environment that may be hostile. Some project management books and
methodologies start from the presumption that the project team is available and all team members will
work full time on the project.
In the authors experience, the norm is that an idea is brainstormed by management, who take a
decision to pursue that idea. They then call in a professional project manager, who is given a broad brief;
without specifics, pertinent details, budgets or analysis on the influencing effect of the project on the
company as a whole.
It is up to the project manger to take control of the proposed idea and to take that idea and to place it
through a thoroughly logically and systematically filter to determine whether the idea is feasible. If it isnt
viable, dump it and eliminate any further costs. If the idea is feasible, then a coherent plan must be
drafted to benefit the company.
Page 12 of 283
The worst case scenario is, of course, to have a brilliant idea that is feasible, potentially highly
profitable and technologically easy to implement but the company doesnt pursue it.
EXAMPLE:
In 2006, a highly brilliant colleague contacted the author and told about an idea that he had conceived,
assessed and planned. After his discussion, the authors immediate thought was that his colleague was
correct. The idea was to set up a cellular insurance-based text messaging service for the South African
taxi industry. For the cost of R25, the subscriber would receive insurance for a week.
The violence that plagues that industry, together with the aggressive manner in which taxi drivers
operate their vehicles, meant that the idea had a market, potentially high volume of text messages and
an easy sell to the taxi using public.
He abandoned the idea after the first hurdle. The major cellular networks simply asked for a business
plan. He felt that they were not interested and moved on to other projects. Guess what happened?
Within three months after he had dropped the idea, the same cellular company announced that they
were about to launch the same project. Estimated annual net profit: R100 million after the first year.
You will find that sometimes ideas are wonderful in
exist. Many books overlook some of the major
undertaking tasks that they should never do, such
that some senior managers may feel threatened by
and project managers the support they need.
theory, while in practice the technology may not yet

challenges that project managers face, including
as forensic auditing. Another prominent problem is
new projects and thus may not always give projects
This book is also a flexible resource pack for project managers and their teams. The contents can be
used for any sized project and any management style or methods. Remember that, although the
principles of project management apply to all projects, each project is unique. Particular ways of working
do not fit all projects. The project management needs of each project should be assessed to determine
the approach most suited to the particular needs of that project. The checklists and templates in this
handbook are intended to be selected, amended and adapted to suit the needs of a particular
organisation or project.
Not all documents suggested are required for all projects. Some documents will vary in their level of
detail depending on the needs of the project. In some cases, more than one example of a template for a
particular document is provided. Only the one which best suits the particular project needs should be
used.
Many of the resources referred to in this handbook are available online, using the web addresses
provided in the Appendices. This book does outline some theory of project management, to place the
practical aspects of the case study in perspective. There are also references to online information and a
range of project management resources, including:
Project management guidance.

Project resources and other useful tools.
Before we start
The following basic axioms need to be repeated:
Axiom 1: When is an idea an opportunity? An idea is an opportunity when it is timely, attractive,

achievable, durable, fills a need and provides value to the buyer. An idea is an opportunity only if
there is reason to believe the market will validate the idea and the management team has the ability
to execute the idea. Only proper strategic due diligence can determine such factors with pin point
accuracy. Therefore, undertaking a project without proper due diligence is simply guess work.
Page 13 of 283
Axiom 2: To be a true opportunity, a business idea must have a demonstrated need, ready market
and ability to provide a solid return on investment.
Axiom 3. Business ideas are a dime a dozen. What really matters is the planning and execution and
the quality of the team. It is not merely the idea. It is the people, and their ability to execute, that
matters. Once you have the people and the execution, then the idea has the potential to become a
true opportunity.
Axiom 4: With a positive mental attitude, a desire to succeed, a determined mindset and enthusiasm
you can find, create and take advantage of any possibility and any opportunity that you can dream. If
you can conceive it and you can believe it, you can achieve whatever you set your sights on.
Axiom 5: Opportunity-focused entrepreneurs start with the customer and the market in mind. They
analyse the market to determine industry issues, market structure, market size, growth rate, market
capacity, attainable market share, cost structure, the core economics, exit strategy issues, time to
breakeven, opportunity costs and barriers to entry.
Axiom 6. If you are not ready for an opportunity, it will pass you by. You must make personal
development a priority, so that you will be prepared to take advantage of the opportunities.
Axiom 7: YOU and YOU ALONE as project manager - is responsible for the ENTIRE project.
Therefore, only take on projects that you believe in.
As you work through the book, you will begin to use the supplied reusable and customisable project
templates. Make them your own and, that way, turn opportunities into real ventures. The secret is to act
quickly, but methodically, to manage risk and continually changing environmental issues.
Enjoy and contact me if you have any question, whether theoretical or practical.
Jacques Magliolo
bci@magliolo.com
www.magliolo.com
2008
Page 14 of 283
PREFACE: SETTING THE SCENE

This book is the culmination of an idea, which the author has had many years ago, for a way to more
effectively mentor entrepreneurs and, at the same time, teach students and private clients. The aim was
to write a number of books to cover the elements that make up sound corporate finance; from the basics
of investments through to setting up a strategy to list on a stock exchange; if that was the ultimate aim of
the entrepreneur. The author felt that, after seeing hundreds of companies with poor financial structures,
and even worse management controls, there must be an easy way to help struggling entrepreneurs and
investors.
The process started in 1992, after the author had written a 10 part column for the Johannesburg-based
newspaper The Star. The series was titled Share Analysis and Accurate Forecasting and the response
from readers surprised the author. More pertinent were the comments made by South African
entrepreneurs about the lack of understanding of how stock market analysts assess companies, financial
results and valuations.
If my board simply knew what factors analysts look at when evaluating listed companies, then we could
all improve performance, investor perception and ultimately our share price. This was the verbatim
comment by an extremely high powered South African businessman, and lead to the author writing his
first book, Share Analysis and Company Forecasting; published in 1995.
However, more importantly, it led to the authors entre into the world of corporate finance and a host of
takeover and merger projects. Its quite simple logic that, if companies are well managed, but have poor
structures, then they become takeover targets. In addition, during this time the author began to realise
that many companies also do not have strategy, proper organisational structures and, in fact, do not
even have active business plans.
The Business Plan: A Manual for South African Entrepreneurs was published in 1996.
The next three corporate finance books looked at issues that make up trading in a global and emerging
market environment; including strategy, emergence of small capitalisation stock exchanges, like the UKs
AIM (Alternative Investment Market) and the South African Alternative Exchange (AltX) and the
similarities between standard portfolio theory and entrepreneurial methodologies. In 2003, Jungle
Tactics: Global Research, Investment & Portfolio Strategy covered factors that influence businesses
and portfolio investments in a global market, A Guide to AltX (2004) outlined the methodologies of how
to prepare for listing on a small cap market and Corporate Mechanic: The Analytical Strategists
Guide (2007) set out methods to restructure a company to become efficient, profitable and protected
from the hostilities of international corporate raiders.
More importantly, The Corporate Mechanic outlines valuation methods and sets out corporate trouble
shooting techniques to find and eliminate corporate problems. It also outlines a strategy called The War
Room, which is also explained in this book.
This Project Management book moves the contents of the previously published books to the field of
micro-planning and management. It is, therefore, far more specific in layout and application.
When you work on a project, you will be able to apply the lessons learned from prior projects and,
hopefully, some of those prior projects may come from this book. The successful project manager must
simultaneously manage the four basic elements of any project, whether it is the creation of a company to
run from home, services or product related or a multi-billion dollar firm operating in the international
petroleum industry. These elements of resources, time, money, and more importantly, scope are
interrelated and each must be managed effectively and together if the project, and the project manager,
is to be successful
To re-iterate:
Page 15 of 283
Resources: People, equipment and raw material/services.

Time: Expected task duration, potential changes and critical path.
Money: Costs, contingencies, profit (actual vs. forecast).
Scope: Project size, targets and requirements.
Most literature on project management concentrates on the need to manage and balance people, time,
and money. However, in the authors experience there is a fourth factor that seems to be completely
ignored by many project managers.
The need to assess every aspect of a project (including the four elements
above) in relation to the environment within which the project is been applied.
TWO CRUCIAL INITIALS STEPS

Before you even start down the road of costly project management, you need to complete two basic, but
crucial, mandates.
MANDATE 1: THE PROJECT SCOPE

The project scope, also called The Project Brief, is the definition of what the project is supposed to
accomplish and the budget (of time and money) that has been created to achieve these objectives. It is
absolutely imperative, that any change to the scope of a project, must have a matching change in
budget, either time or resources. For instance, if the project scope is to build a residential complex of 40
homes at a cost of R10 million, then any change must be met with a re-calculated time and budget. If the
budget is not adjusted, the smart project manager will avoid the change in scope. Under the Guerrilla
Principle, the scope is written down and signed by the sponsor and project manager no changes will
even be contemplated.
Usually, scope changes occur in the form of "scope creep," which is an incremental change over time
that may, on its own, seem insignificant, but in aggregate can be major. For instance, in the above
residential complex project, the owner wants all door frames to be changed to a better type of wood.
Each new frame may only cost an additional R800 per frame and, independently, is minor. However, if
Page 16 of 283
there are eight doors per home and their are 40 homes in the complex, the additional cost is over
R250,000.
Imagine if the same owner then requests that the carport is converted into a garage at only an extra
R10,000 per home. That would be an additional R400,000 to the project cost. Later, eventually, the client
asks for a security camera for every home at a cost of R2,500 per home (R100,000 total cost). By now,
the minor changes have become a major addition to both time and, of course, cost. The extra R750,000
must be included in the project scope. Make sure any requested change, no matter how small, is
accompanied by approval for a change in budget or schedule or both.
You cannot effectively manage the resources, time and money in a project unless you actively
manage the project scope.
When you have the project scope clearly identified and associated to the timeline and budget, you can
begin to manage the project resources. These include the people, equipment and raw materials needed
to complete the project.
The Scope is a key document or product in its own right.
It provides a description of what the project is to do and is a precursor to the project mandate. It is the
basis of the project and outlines issues that will form the contract between the project management team
and the promoter. Any changes that are made in the project Scope will need to be referred back to the
promoters.
See Appendices for Project Scope Template.
The following notes can be used to help entrepreneurs finalise a Project Scope. Remember that the
promoter of the project has to agree with the Project Scope before you can draft a Contract or Mandate to
proceed with the project.
Notes:
Project Title: Working title of the proposed project. Remember that the title should give the reader
an idea of what the subject is.
Background to the Proposed Work: Describe the potential change, idea and problem. Why it
should be done now and what are the implications of not doing it.
Objectives/Targets: This is a summary of what you want the project to achieve when it has been
completed. Strong statements starting with, Completion of this project will result in." should also
be specific, measurable, achievable, timely, fair and realistic. It is also suggested that managers
avoid vague words like improve, optimise, clarify, help etc.
Scope: Also called Brief this section must describe the boundaries of the project, areas of work to
be included and what does not form part of the scope. Most projects can be divided into the four
Stages set out in this book, so each section should be outlined.
Deliverables: These are the main component parts of the potential project that have to be produced
in order to achieve the objectives. Each deliverable item should be outlined.
Business Benefits: Will the promoter benefit from the proposed work; either tangibly or intangibly. It
will also be necessary at the next stage of the project to produce a more detailed Business Case.
Assumptions: remember that all assumption must be based on fair and realistic research. There is
no point in telling a promoter that his revenue will climb by 20% if international research shows that
the proposed changes to the promoters business usually yields only an additional 2% to revenue.
Page 17 of 283
Constraints: Comprehensively set out the factors that you will have to take into account during the
course of the projects. These may include regulatory or fiscal issues, such as exchange controls,
company legislation or cultural, social or time-based issues.
Risks: From your current knowledge what things could happen to disrupt or stop the project? These
become more complex the further out the project manager moves from a level of comfort, i.e. both
form a business or regional issue.
Other Areas of Business Affected: as a starter, who/where are these potential areas and do they
need to be involved right from the start.
Dependencies: Are there any events that are either dependent on the outcome of this project or that
the project will depend on.
Customers: Who are the persons that you consider will have a major interest in the work and will
want some input into it.
Resources: Set out the proposed team, what sort of experience they should have and how you
would go about getting the right people. At this point, you could research if you need external
suppliers and carry out some initial work on availability, costs etc.
Outline estimates of time and cost: Use available analytical methods to best determine timeframes
and cost factors?
MANDATE 2: THE CONTRACT TO PROCEED

A legal contract must be drafted and should include remuneration if the project succeeds and
remuneration if the project fails.
Remuneration on the project succeeding:

o If the project succeeds on time and within budget, the norm is for the following to be paid:
A percentage of capital raised, if that is the nature of the project. The international
norm is 2.5%, but it is contingent on performance.
If the company is to list on an exchange, the percentage capital may be increased to

6% and payable in shares or cash or both.
A successful listing bonus - contingent on listing. This is usually an amount of

R1 million.
Professional fees, which have to be paid as agreed to the project manager and his or
her team. The norm is 50% upfront and the remainder on the promoter signing off on
the project. These fees can also be paid before and at the end of each Stage.
Remuneration on the project not succeeding:

o
If the project is not completed on time and within budget, there may be penalties; these have
to be sorted prior to the go-ahead contract being signed. If no penalties are to be
implemented, state that in the contract.
Make sure that professional fee due are paid before the final documents are handed over.
While that may sound like there is no trust between the project sponsor and project manager,
it is simply too true that many project managers do not or struggle get that final payment.
Page 18 of 283
Never move ahead with the next phase of a project until deposits and amounts due are meet.
Make sure that time constraints stipulate such conditions.
Note: you can make the four stages of project management as per this book the criteria for payment:
Insist on a deposit prior to starting the Stage.

Insist on payment due at the end of the stage as condition to starting the next stage.
Again, insist on a deposit before starting the next stage etc.
Make the time constraints for the project dependent on receiving the deposit. For instance, you
state that all four phases will take a month each to complete. Make it a condition that the month
period starts when you receive the deposit, instead of stating that the full four Stages will take
four months. You would be tying yourself down to that period irrespective of whether you
received payment.
BE WARNED: SUCCESS & PITFALLS

Project managers must simultaneously focus on a multitude of issues, but ultimately all can be handled if
planning is correctly and logically completed. All plans need to be continually reviewed in relation to the
project and the environment within which the company operates. Of the over 600 odd books reviewed
prior to completing this book, one issue always surfaced:
The single most important activity that project managers engage in is planning; detailed
and systematic plans form the foundation for project success.
In the real-world, events will overtake a planned project, so a method must be included
to enable the project manager to change the plan to reflect the changes. So planning
and re-planning must be a way of life for project managers.
Project managers must always be in control and transmit to their team members a sense of urgency.
Remember that projects are defined by time, money and other available resources, so they must be kept
moving toward completion. Since most team members have lots of other priorities, it's up to the project
manager to keep their attention on project deliverables and deadlines. Regular status checks, meetings,
and reminders are, therefore, essential.
You will see in the main body of the book that the author always proposes that teams are made up of
independent professionals working to specific contracts; The Guerrilla Principle. The incentive is to
complete the project on time and on budget to garner success fees, which the entire team must share.
There has to be more than professional fees to entice the team to work 18 hour days to complete the
project.
Significant money incentives (in the form of bonuses) are always well received.
Successful projects tend to use time-tested, proven project life cycle. Corporate consultants around the
world know what works and, more importantly, what doesnt. Best practices must thus always be built
into project plans. Not only do models support quality, they help to prevent re-doing work. When the time
comes and it will when budget or time pressures encourage consultants to take short cuts, the
recommendation is NOT to do so. As a consultant to the project - whether financial, legal or corporate
you will simply have to re-do the task. That is time that the consultant could have used in another project.
While it may be up to the project manager to identify and defend the best project life cycle for the job, it is
the consultants professional duty to deliver best practice tasks and documentation.
Page 19 of 283
All project deliverables and all project activities must be visualised and communicated in vivid detail. In
short, the project manager and project team must early on create a tangible picture of the finished
deliverables in the minds of everyone involved, so that all effort is focused in the same direction. Avoid
vague descriptions at all costs; spell it out, picture it and make sure everyone agrees to it.
Deliverables must evolve gradually, in successive phases or stages. It simply costs too much and risks
too much time spent in re-work to jump in with both feet and begin building all project deliverables. Build
a little at a time, obtain incremental reviews and approvals and maintain a controlled evolution.
Projects require clear approvals and sign-off by sponsors. Clear approval points, accompanied by formal
sign-off by sponsors and clients, should be demarcation points in the evolution of project deliverables,
i.e. as stated above in working to Stages and payment for each. It's this simple: anyone who has the
power to reject or to demand revision of deliverables after they are complete must be required to
examine and approve them as they are being built.
Project success is correlated with thorough analyses of the need for project deliverables. Research has
shown that, when a project results in deliverables that are designed to meet a thoroughly documented
need, then there is a greater likelihood of project success. So managers should insist that there is a
documented business need for the project, before they agree to consume organisational resources in
completing it.
Project managers must fight for time to do things right and right the first time. The author often
hears consultants say that they wish they had taken the time to do it right in the first place. The common
scenario goes like this: it takes between three months and a year to complete documentation required to
present a company for listing to the board of a South African stock exchange. If the project manager
rushes these documents and the stock exchange board rejects the proposal, due to lack of appropriate
research or due diligence, it will take another three months before the exchange can see the company
again, for a second presentation.
And everyone knows excellent first impressions are crucial to getting a companys image right as
a listed company. Now, if the consultant had done the task correctly the first time and over a six month
period then the company would list, first impressions would be supreme and investor sentiment
towards the companys share not tarnished. Remember that investors, clients and competitors will hear
about the project very quickly and it is thus crucial that you get the project underway rapidly to keep your
competitive advantage.
Project manager responsibility must be matched by equivalent authority. It's not enough to be held
responsible for project outcomes; project managers must ask for and obtain enough authority to execute
their responsibilities. Specifically, managers must have the authority to acquire and co-ordinate
resources, request and receive co-operation, and make appropriate, binding decisions that have an
impact on the success of the project.
Project sponsors and client must be active and not passive participants. Most project sponsors
and clients rightfully demand the authority to approve project deliverables, either wholly or in part. Along
with this authority comes the responsibility to be an active participant in the early stages of the project
(helping to define deliverables), to complete reviews of interim deliverables in a timely fashion (keeping
the project moving), and to help expedite the project manager's access to members of the target
audience and essential documentation.
Projects typically must be sold, and resold. There are times when the project manager must function
as salesperson to maintain the commitment of Client and sponsor. With will be highlighted in the Case
Study, which is used throughout this book. With project plans in hand, project managers may need to
periodically remind people about the business need that is being met and that their contributions are
essential to help meet this need.
Page 20 of 283
Project managers must acquire the best people they can and then do whatever it takes to keep these
consultants delivering contracted tasks. In heading projects the author always ask the team members
(individually): How long will it take to deliver the required task? in trying to get the contract, consultants
will often specify time frames that are too tight. For instance, to undertake a thorough financial due
diligence on a company should take about a month. The consultant will state that it will be done in three
weeks. In the contract, the author states the following: The financial due diligence will be done in three
weeks, but an additional week is provided for contingencies. The consultant is bound by his or her own
folly and enthusiasm. Giving them that extra week will come across as being a fair and reasonable
person and doe place additional pressure on them to complete the wok on time. The extra week can also
be used to make all required corrections prior to the completion date.
By acquiring the best people -- the most skilled, the most experienced, the best qualified -- the project
manager can often compensate for too little time or money or other project constraints. Project managers
should serve as an advocate for these valuable team members, helping to protect them from outside
interruptions and helping them acquire the tools and working conditions necessary to apply their talents.
Top management must actively set priorities. Too often, company owners will state: Do your best,
as a brief. Ultimately, such a brief is inadequate and too vague. The author was once asked to assist in a
hostile takeover of a car hire company. Before the meeting, the author asked for a brief: price are you
willing to pay for the firm?
As low as possible. An answer like that is a no win situation, because no matter how low a price you
get, it is guaranteed that the client will say that you could have gone lower. The author persisted,
refusing to go into the meeting before the client gave him an answer. Eventually, he said: get at least
60% of the company and limit the cost to R10 million. He was to attend the meeting, but complete
authority had been signed over to the author in a formal contract.
Less than 30 minutes later, the author had secured 85% of the company for a mere R2 million; an option
for the remaining 15% to be transferred to his client if certain warrantees were achieved within a
predetermined timeframe. The clients comment after the presentation: Why only 85%?
Secure all issues in contract and insist that they are dated and signed before undertaking any project.
Axioms for Success
Before we plough straight into the theory and strategy for project management in a global market, Lets
look at those traits that improves the potential for success:
Know your goal: It may sound obvious, but if you dont have an end-point in mind youll never get
there. You should be able to clearly state the goal of your project in a single sentence. If you can't,
your chance of achieving it is slim.
Know your team: Your team is the most important resource you have available and their
enthusiastic contribution will make or break the project. Look after them, whether they operate as as
a unit or as a collection of independent consultants. Invest time in ensuring that everyone knows
what they have to contribute to the bigger picture.
Know your clients: Spend time with the clients, who either contribute expert knowledge or offer
political or commercial endorsement, which will be essential to success.
Spend time on planning and design: A traditional mistake is to leap before you are ready. When
youre under pressure to deliver, the temptation is to succumb to the clients request to start
immediately. Remember that it is difficult to change its direction once the project gets moving. So
spend some time deciding exactly how to proceed in the most efficient and methodical manner.
Contractually set out delivery promises. Make them reasonable, but deliver true expectations:
By understating goals and delivering more than promised you:
Page 21 of 283
o
o
o
o
o
o
Build confidence in yourself, the project and the team.

Build knowledge in various industries.
Build a reputation as someone that gets the job done, on time and within budget.
Buy yourself contingency in the event that something goes wrong.
Generate a positive and receptive atmosphere.
Consider:
If everything goes right you will finish early everyone will be happy. Remember that,
given human nature, if you finish too early the client will become suspicious and will
wonder whether he or she paid too little for the work, whether the tasks were
performed to the required specifications or whether the quality of the work is high.
If something goes wrong you might still finish on time.
If things goes really badly you might still not deliver what you anticipated, but it will still
be better than if you over-promised.
Have methods to sort out problems: Serious project will generally require some kind of
methodology to resolve and solve problems. Without a systematic approach, the project manager
ends up with a multitude of potential solutions, instead of just one correct solution.
Be ruthless about timing. Project managers need to work methodically towards the goal and
provide leadership (make decisions). This applies whether youre a senior project manager with a
team of 20 or youre a lone web developer. Learn to use tools like schedules and budgets to stay on
track. Consistency is what separates professionals from amateurs.
Manage change: As the project progresses, the temptation to deviate from the plan will become
irresistible. Clients will come up with new and interesting ideas, the team will identify potential risks
initially not identified and the original goal will change if the project manager lets it. Scope creep or
drift is a major source of project failure and it is crucial to manage and control changes if success if to
be achieved. This doesnt imply that there should be single, immutable plan which is written down
and all other ideas must be stifled. You need to build a flexible approach that absorbs changes as
they arise.
Discipline: Projects involve creative disciplines burdened with assumptions and mistakes.
Continually test and check that assumptions and conclusions are logical and accurate. This is the
way to find and eliminate errors; as set out in The Corporate Mechanic (Juta, 2007).
Be flexible: The desired outcome is the delivery of the finished project to a client, who is satisfied
with the result. Focus on delivering the project and use all the tools and people available. Deliver the
finished product, promote its use, celebrate success and then move on to the next project.
Axioms that Ensure Failure
Not aligning a specific project to the overall strategy of the company.
Encourage sponsors and key customers to take a passive role on the project team
Continually changing project leadership committees or meetings.
Keep changing consultants tasks.
Change the focus of the project after it has already been in progress for some stage.
Undertake projects without signed briefs or mandates.
All the above have a common element that ultimately results in project failure: each takes on a less than
serious discipline to achieve stipulated and pre-determined goals.
Page 22 of 283
LESSONS LEARNED: GENERAL

These lessons will be displayed prior to every Stage of this book and throughout the
chapters.
There is nothing worse in business than making common and simple errors that could have been
avoided if lessons learnt from documented (or personal) past experiences. These documents
should include good and bad experiences, how these were successfully managed as well as
lessons deriving from problems and issues.
In Richer than Buffett (Zebra Press, 2007) the author stressed that day traders should keep a
journal of every single trade they make. In that manner, day traders can learn from poor trading
decisions and from trading strategies that work. It is suggested that a project journal is kept and all
decisions made noted.
The journal can also be useful to review the lessons at key stages in a new project. There are a
number of activities that should be done as part of getting started, while managing the process and
at project closure.
The following are some examples of lessons learned through the experience of project
management:
Ensure there is adequate full-time dedicated resource in the project team. Essentially, ensure
that enough funds have been placed in trust to pay the consultants, other professionals and,
among others, travel expenses.
Dont dilute the project team's attentions by other responsibilities. These are professions, who
earn a living from producing work on time and at stipulated budgets.
Appoint a full-time professional project manager.
Focus on early planning, group strategy, identification of issues, objectives and targets for each
Stage of activity:
Page 23 of 283
Identify necessary skills. The project manager must identify the peculiarities of
the project. For instance, if the project is the expansion of a shopping mall, then
a geologist on the team would be meaningless. Some companies may also
insists that time be set aside for training of junior staff, which could be added to
the fee structure.
Define respective roles and responsibilities for each consultant. While there may
be overlaps, these should be kept to a minimum.
Establish clear channels of communication and contact points.
All relevant key authorities should be continually informed. Remember that the
more people involved in a decision process, the longer it will take to get things
done. Insist on a single contact. This will expedite the laborious process of
decision making.
If consultants are employed, ensure that time is built in to allow effective

knowledge transfer.
Have regular risk reviews.
ABOUT THE AUTHOR

Jacques Magliolo, managing director of corporate finance and research firm Business Consultants
International, is well versed in taking entrepreneurs through the paces of project management. Since
leaving stockbroking in July 2000, Magliolo has been involved in more than 400 projects, personally
running everyone of them.
Some projects took him to scientific fields, such as researching semi-conductors for the University of
Potchefstoom. That project was presented to the scientific community of South Africa at the university,
and the audience included the chancellor. After six hours of discussing the proposed semi-conductor,
Magliolo received a standing ovation, which should have been for the team that assisted in delivering the
project. Yet another scientific project took Magliolo to the realms of tobacco farming, where the project
management plan was to assist the client to determine new growth plans in a market limited by quotas.
Less technical projects included mergers and acquisitions, hostile takeovers and an innumerable number
of corporate re-engineering. The latter is taking a company that has a host of unknown problems,
funding out what these are, fixing them according to best practice solutions and then to proceed with
projects to restart the companys future.
He is the author of eight other financial books, including university textbooks on strategy, portfolio
management and listing on the global trend of new small stock exchanges.
Magliolo has been an investment and corporate strategist since 1987. His experience includes
stockbroking, business development and corporate strategy. Before setting up his own consultancy he
was director, strategist and head of research for South African stockbrokers Global Capital Securities. As
team leader, he provided institutions and private clients with industry, market and listed company
research, analysis, presentations and reports.
His responsibilities involved strategic analysis of global market trends, regional political and economic
assessments (including company valuations and capital raising), industrial company analysis, identifying
arbitrage opportunities in warrants and equities and structuring client portfolios. The strategic analysis of
global trends was used to determine which sectors (and thereby companies) would be best suited for
clients asset allocations. It is this experience that drew Magliolo to writing South Africas MBA text book,
Jungle Tactics (Heinemann, 2003).
Magliolo concentrates on assisting entrepreneurs in the two worlds of consulting, working directly with
multiple clients at all levels, where he managed programmes and projects of all types and sizes, in a
variety of industries and one a personal one-on-one basis.
Currently, Magliolo helps entrepreneurs to restructure their firms to become more efficient and ultimately
more profitable. He has developed a four phase approach to corporate intelligence, which includes
market research and analysis, due diligence, business plans, corporate profiles and implementation
strategies. These are amply outlined in this book. Magliolos clients are from both listed and private firms
and advice to clients is on long-term basis helping them through the entire process to achieve business
goals.
In addition to owning and running BCI, Magliolo has associations with a number of stockbroking firms,
including Manhattan Equities, Arcay Moela and London Capital. Moroccan born Magliolo immigrated to
South Africa in 1969 and today lives in Johannesburg with his wife Susan and three children.
Page 24 of 283
PRE-PROJECT PREPARATION
For many people, working on a project is simply a frustrating experience. Team members cant
agree on what should be done or how to do it. No-one seems to have control and deadlines are
often missed. The result: the clients is unhappy. Morale is often poor, yet It doesnt have to be
this way. Projects can be both successful and profitable, if an effective method is used to work
through the Stages of any project.
The only way to understand these concepts is to use an in-depth Case Study, so that this book
becomes a simple, easy-to-use method for managing any project.
This section, therefore, looks at three issues:
Tools and Checklists
Information needed before meeting the client.
The Case Study: the merger and listing of two companies
The Guerrilla Principle Project Management Methodology
TOOLS & CHECKLISTS

Before starting on the Case Study, it is important to spend time getting a better feel for the size
and nature of the task ahead. In addition, lists of questions have to be asked and assessed even
before a project is taken on. After all, there is absolutely no point in taking on a project that has
no possibility of succeeding.
Questions to be asked prior to meeting a client:
What is the vision, aim and objective of the project?
Who is the client/owner of the Project?
Is there a business case?
Will travel be required?
Define the scope: where are the boundaries of the Project?
Resources: who is funding the project and do they have the resources needed to complete the entire
project?
Are Risks associated with such a project low, medium or high?
Can the project manager build the required team?
Do you want to work with the owner?
Do you want to work in the proposed industry?
Using the right project tools can go a long way in ensuring a projects success. The best project
managers also access helpful project management resources when they need them.
Page 25 of 283
Project Management Tools and Resources: Conservative estimates consistently put project failure
rates above 50%. In South Africa, statistics are closer to 66% failure in the first year and an additional
50% in the second year of a company starting operations. In addition, more than half of projects started
fail to meet the organisation's objectives. Project Managers can certainly do with some assistance. From
the outset, the project manager must adopt a committed vision and work ethic to overcome
organisational roadblocks. However, without an equally committed client, the project manager will have
an uphill battle to get the team motivated and the project completed.
Find out who the projects owners are and communicate with them regularly, which should prevent errors
and misunderstanding from propagating throughout the project. Decide the project Stages for the
proposed project and the key go/no go decision points. Are there any deal breakers? Identifying these
early on helps to eliminate projects that have little chance of success.
In order to clarify business owner and other project interested party expectations, the project manager
will have defined the measures of success of the project even before your project began. Every project is
a valuable learning experience for everyone involved in the project. Successful project managers work
hard to get feedback from project team members. From this, they discover what went well and what did
not go so well. These lessons can then be applied to the next project.
In addition, the project manager must have the right project documents for the right purpose. Have these
ready even before meeting the client; set out throughout this book. Whether the manager is running a
large-, medium- or small-sized project, he or she must decide from the start which project documents the
project needs.
PRE-MEETING CLIENT INFORMATION

Fact Finding: prior to a project being commissioned
The project manager must make a list of people, who will have information he or she will need and
the type of information they're likely to possess. There are definite
Continue to gather information until there is relative certainty to the project's purpose, potential
outcome, possible problems, budgets and the deadline.
Always have a number of consultants that could be available for a project, i.e. the professional
project manager should have more than one forensic auditors, legal and corporate advisors who
could join in as part of a team. Once the potential team is selected, the team can be involved from
the early planning stages of the project.
Develop draft goal & milestone sequences as early as possible to focus project team input.
Prepare project charts that reveal enough detail so you can effectively spot potential trouble and
proactively manage key dependencies.
Prepare a scheduling planner with all key activities and outcome dates.
The project manager must find out about the potential audience's expectations, interests, familiarity
with the project and their opinions of the project before preparing for the first meeting with the client..
Prepare a presentation goal first, then write enabling points that support the goal.
Select facts, evidence and/or expert opinion that support each enabling point.
Be sure to use the presentation for interaction - not core dumping.
Page 26 of 283
Identify your participant's team maturity level - do they identify with the project and each other?, are
they motivated to learn and achieve? Do they trust each other and you? Do they communicate about
the project frequently, meaningfully and/or productively?
Step 1: Define the client

There are two types of clients that need to be considered in every project:
The end user, i.e. the companys customer.

The project client, i.e. the professional managing director or owner.
Typically the client is the person who will receive the final deliverable from the project, while the end user
is the person who will use/buy the product. Ultimately, the project manager really does have to worry
about the end users requirements, because even if the client is happy with the project and the product
doesnt sell there will be recriminations. End user requirements should be gathered before the project
begins, as part of a market research effort or the product concept definition.
If the customer requirements are not defined before the project begins, then the project manager will
need to gather them before he or she hands over the final deliverable. Often these requirements can be
assessed in more depth during the execution phase. In some instances, however, the manger will need
to go out and collect these requirements during planning:
When the end user requirements have not been assessed at all.
When the project client does not have a clear understanding of the end user requirements.
When the end user requirements may differ significantly from the project client requirements.
The processes by which requirements are collected, either for the end user or for the client, are very
similar. Therefore, If you need to collect end user requirements, use the process described for the
project client.
Step 2: Identify the clients need

The first thing that has to be validated is the clients need, which is the problem the project manager is
trying to solve. The best way to do this is to visit the client and actually experience the problem he or she
is facing. The reason you explore the need is to make sure you understand the root cause/s of the
problem that has led the client requesting the project in the first place. Note that this will only provide the
manager with the clients perception of the solution to his or her problem. Clients often state what they
perceive the problem to be, without assessing if the problem could be caused by something else. The
professional project manager must determine if there is an alternative solution that could work better
than the proposed project. By exploring the need, the manager can get beyond the stated solutions to
the real problem.
The methodologies to find and resolve problems is amply outlined in The Corporate Mechanic, so it is
sufficient to state that the following questions can be asked:
What effect does this problem have on the business?

Why do you think this problem exists?
If we deliver the solution you have requested, what problems would go away?
What youre really doing is probing the clients assumptions about the solution or final deliverable that he
or she has requested.
When the manager validates the clients need, he or she makes sure the assumptions that are held by
the client are true or the best approximation of the truth available at the time.
A question the author often gets asked: Is it really that urgent to understanding the clients needs?
Page 27 of 283
My answer: it is always better to get to the root problem before getting too far down the road. Imagine
completing the project and discovering that the original problem, which you were not aware of, has not
been solved?
Step 3: Determine whether the project will work

Once youve assessed the clients need, youre in a position to validate what has to be delivered to the
client. Is the final deliverable the best possible solution to the project clients problems? If not, you need
to go back to the client and discuss options. The project manager can propose an alternative solution
that would better address the problem, but ultimately his or her only responsibility is to deliver the project
that satisfies the client. However, if you havent at least alleviated the clients problem, then the likelihood
that the client will be satisfied with the final deliverable, even if its exactly what they asked for, is not very
high.
Therefore, take the time to define the problem and make sure the final deliverable will help the client to
resolve that problem. Then you can move on to the next step of defining how the client will determine
their level of satisfaction with the final deliverable after they receive it.
Satisfying the client is, after all, the aim of any project.
How do you know what the clients criteria for acceptance of the final deliverable is? You ask the client.
Step 4: Define the clients acceptance criteria

Sign-off is the act of stating that the client accepts and is satisfied with the delivered project. Usually, a
client will have a set of criteria, which the he or she will use to evaluate whether they are satisfied with
the final project. As the purpose of the project is to satisfy the client, its important to know their criteria
for satisfaction.
Effectively, this sign-off criteria becomes the managers target for the project. If you hit the target, the
client will be satisfied. Without them, you dont have an absolutely clear end goal for the delivery of the
project.
If the client claims that he or she does n ot have a set of criteria, the project manager should set one up
via a set of questions. That must be followed with the client signing the list.
Step 5: Determine the clients requirements

While interviewing the client about the sign off, the project manager can also validate and expand on the
clients requirements for the final deliverable, including any physical delivery aspects of the project. Ask
the client to describe all the features they require and every function they are interested in and capture
each one in typed written form and group these into items of crucial, important and low priority.
Check to make sure that all the items in Crucial list are aligned with the Sign Off. Next check the
important category to decide which of these, if any, can be included in the final deliverable. Remember
that these lists will drive the resource requirements for the project. Ultimately, this list will be converted to
technical specifications, as you get ready to actually develop an accurate plan that sets realistic
expectations about what will be produced.
Page 28 of 283
GUERRILLA PRINCIPLES & THE CASE

STUDY
At the outset, let me state two important issues. Firstly, I am not interested in war or, for
that matter, anything remotely related to war. So, Guerrilla Principles are not aimed at
subterfuge or war plans. Rather, it is a methodology for project managers to keep firm
control of the four complex and risk prone Stages of project management; as outlined in
this book.
The second issue is that I abhor writing in the first person. It always sounds
presumptuous and, in all honesty, not professional. I have thus decided to write this
Case Study in the first person, seeing as it is about strategy and a project that I managed
in 2007. The rest of the book will be in the third person.
While the principles of Guerrilla tactics are outline in this book, these will be restricted to a single project
case study. The relevant case study issues will be outlined throughout the book, but highlighted in a
double lined box; relating to project management issues being discussed in that section of the book, as
follows:
Note: the only part of this book that discusses Guerrilla Principles is in this case
study part of the book, as these methodologies are inextricably linked to the project
undertaken and outlined in this section of the book.
TWO ASPECTS DISCUSSED

ASPECT 1: THE GUERRILLA PROJECT MANAGEMENT METHODOLOGY
An Overview
While many brilliant books and articles have been written on efficient and proficient project management
(see the references section to see a good selection), there is little attention paid to all the in-house
politics and problems caused by interfering owners during the project management process. In many
respects, the project manager is merely the business development office (a clerk), who follows direct
instructions to carry out tasks, which are not really part of the project management process. These inhouse managers are not trained enough to successfully carry out complex projects, as project
management requires a host of skills which are not normally found within the boundaries of companies
staff.
In fact, in many respects, these project managers/clerks take on the appearance of managing a project,
without the burden of actually doing it. Ultimately, projects take longer and cost more to complete. A
possibly worse situation is when companies actually do appoint a project manager who is an outsider.
They then set unrealistic boundaries, forcing his or her to use in-house staff as team members. You can
see immediately that this cannot possibly work, as the project manager does not have the authority to
instruct these staff members to do anything. In addition, the project manager does not know who these
people are, their strengths, weaknesses, ability to perform under stressful conditions and whether there
are any incentives for them to complete the project on time budget.
The project manager is effectively handcuffed.
Page 29 of 283
So, what is the answer? In a globalised world, where you can find a professional for every, and any,
aspect of business, there is room for a project manager, who ha his or her own appointed team. It is
immediately obvious how this type of structure can be more efficient. For instance, there is no need to
worry whether team members are professional, as they are appointed for their skills and experiences.
There is no need to wonder if they are working on scheduled tasks, or whether they have worked the
required amount of hours. These members get professional fees, so they get paid on completion of the
project. That is their incentive.
In addition, there are benefits when it comes to managing communications with the sponsor and client.
Here, the project manager has his or her own office, which is used as a war room (see Corporate
Mechanic). As it is not at the companys premises, there is less chance of inaccurate reporting (or
misunderstandings) from staff to client.
In effect, there is better control, more security and drive to complete a project on time and budget.
Brief Summary of Guerrilla Principles Methodology
The War Room: Establish a Project War Room to have meetings away from the company, to have
project reviews, brainstorming sessions, discussions relating to Stage Gates, end-Stage discussions,
team performance, and lack of cooperation from client or confusion over current objectives and more.
Always get everything in contract: The project manager gets a letter of appointment, and he gives
a letter of appointment to the team members. However, the Guerrilla Methodology works as follows:
o
Before the project manager makes his or her presentation to the client, he or she has already
appointed a provisional team of experts, with skills that would depend on the project being
tendered.
This is done At Risk which means that the provisional team would only get appointed if the
project manager gets appointed. The benefits of securing such contracts are massive, as
these would be international business projects, involving millions of rands.
The aim is to arm him or herself with in-depth knowledge about the company, the
environment within which that company operates and how changes to the business would
affect the business. In other words, the structure is two fold:
Page 30 of 283
Corporate Finance: This is the left hand side of the diagram, whereby the structure is
used for corporate finance work, such troubleshooting, restructuring, listing a company
etc.
Project management: This is the right hand side of the diagram, whereby a new
project is being assessed and planned to be launched, i.e. new product or service.
Combined: as a combined business process, it places the corporate advisor/project

manager is a position to analytically determine whether the proposed project will
benefit the client before he or she presents their qualifications to the client.
This structure is laborious, as it undertakes major industry analysis, before the project
is commissioned. However, from experience it is noted that once the client signs for
the project to go ahead, he or she doesnt know that the average three months of
research becomes the project managers contingency time saved.

The Guerrilla Principle Project Management Methodology
Therefore, as per the above flow chart, a project has two parallel, but interlinked, flows. On
the left hand side, the project manager undertake due diligence and research before seeing
the client.
All work is carried out At Risk.
If the client accepts and appoints the project manager, the manager in turn appoints the team.
Under Option Determination discussions are held between the project manager and team,
as to the best method of tackling the project. This is translated into an Initiation Document
(Stage 1) for the sponsor.
Once initiation had been completed, the manager has effectively re-written the companys
business plan, which is the overall plan for the business. The project aspect of the plan is
taken from the business plan and provided to the client (Stage 2) as planning for the project.
In effect, the project manager and his or her team has already assessed whether the final
deliverable will benefit the company and how.
Implementation is simply the carrying out of tasks and schedules as set out in the project
plan. However, under the Guerrilla Principle, the execution of the plan is monitored relative to
the overall company itself, i.e. not just the original Project Plan.
Under Completion the project is handed to the sponsor and client and the project manager
gets paid for his or her professional fees. He or she in turn pays the team members.
The incentive mentioned earlier goes beyond professional fees. In international markets, it is
the norm for a project manager to get a bonus if he or her achieves the deliverable on time
and on budget. This bonus can be made up of shares in a company that is being listed on an
exchange or cash or a combination of both.
Page 31 of 283
This usually adds up to millions of Rands or US Dollars and is shared between project
manger and team in an agreed percentage.
One person contact: As stated before, all projects start with a contract and end with a sign-off letter.
Here is another recommendation: ensure that only one person is responsible for the project at the
company and all communication must then be between that person and project manager.
o
This speeds things up and avoids confusing messages being delivered between parties.
Some more Tactics
The natural enemy of the project manager is split into three classes:
o The Client.
o The sponsor.
o The companys in-house staff; no matter how senior.
The customer is a means to an end: The customer is often referred to as the counterpart of the
project manager. This is not correct.
o
The customer is only a minor figure in the project management process. Remember that the
project manager has already determined that the project will be beneficial to the company;
that suggests that the customer will be happy. After all, there are few global companies that
have only a handful of customers.
In principle, it doesn't matter whether the customer is satisfied or not, whether he or she is
happy or not, or what opinions or feelings he or she has about the project manager.
The only significance the customer has at all, is in his or her impact on the client; if the
customer is friendly with the sponsor, he or she could cause problems.
Under the Guerrilla Principle, this does not matter too much, as he or she is the appointed
contracted manager to see a project through to completion. The sponsors ability to interfere
has been handcuffed. Unless there is gross misconduct, the project tasks are late or above
budget, the sponsor cannot interfere.
Never involve the sponsor too early, ie. The Planning Stage. Too many issues can go wrong
during this stage, so it is better to start the review meetings with the sponsor at the Execution Stage.
By then, most problems and risk factors will have been sorted out.
Plan most tasks to be finished just before the last milestone: Too many people can read Gantt
charts. Task end dates are like mini-checkpoints and the very last thing you need are umpteen
checkpoints, on which anyone can argue and comment. Combining most of these checkpoints with
the unavoidable last milestone gives you the much needed degree of freedom to interpret the
progress during the project.
Add contingency at all levels: Contingency is your little friend and helper. However, you must be
aware that removing contingency is the only contribution of higher-level management to project
planning. Therefore, it is essential to add plenty of contingency in many different forms, so that you
will have enough after the removal.
o
You have to ask the professional consultants to add contingency in their estimates, which
later you refer to as "raw figures". Participate in all estimation meetings in order to increase
the figures. Then add contingency both in percentages and as extra activity at task, module
and project level. Finally, you add risk premiums at the various levels.
The key skill here is creativity in naming, as you cannot expect any mercy from higher-level
management when they recognise contingency as such.
Page 32 of 283
Requirements are not required: Incomplete and ambiguous requirements by the sponsor must be
dealt with quickly. Remove these from the schedule and notify the sponsor that these are not
required and will not add any value or benefit to the promised deliverable. Among global players,
these are often said to be the most common obstacle to project success.
Keep reports clean: Status reports are a project managers appraisal sheets, and it comes in handy,
particularly when there is an argument that something, for instance, was not done. These act as
lesson sheets (at the end of the project) but also as proof that the project manager is on track with all
schedules etc.
It would be a pity not to use that to its full advantage. Besides the obvious acclamation of any real or
plausible sounding achievements, the project manager must follow a few simple rules:
o
Never report delays if it will stop the project: This is one of the basic principles for
successful project managers. Nobody stops a project that is 80% completed, because of a
30% budget overrun. That's quite different in the first half of the project. Fortunately, this
principle is easy to follow, as it just requires not doing something. Fill the time in the steering
meetings with success stories and complaints about the customer. That should be sufficient
to convince higher-level management that these meetings need to be short.
In progress reports, only report actual and planned totals: Project tracking is comparing
actual data with plans. However, when plans change, you must compare actual data with the
changed plan, not the original plan.
The changes to the original plan were approved by the sponsor, so there is no need
to compared actual data with originals, as it is bound to look like the p[roject amanger
is off budget and schedules.
Milestones are fixed: Just like a week is a week, no matter what happens, a project Stage has to
end as scheduled. This cannot seldom happen with normal project manager and team (from the
company), as the company will expect the project manager to be training juniors along the way. The
Guerrilla Principle use of professionals means that work and tasks are delivered on time and on
schedule. The professionals may have their own in-house problems, but that is not the concern of the
project manager.
Your project team is not your electorate: Never mention the project team in communication with
sponsor. Talk about yourself, or talk about "the project". The team is just a tool to accomplish
designated tasks. Project managers have often complained to the author that they are always
running around chasing their team to achieved targets. To make matters worse, some teams start to
argue and the project falls apart. How, then, can project managers avoid the complexities that go
with potentially large teams, such as backstabbing, office politics, absenteeism and general problems
associated with teams?
o
The answer is simple: have one project manager, who chooses a team on a contractual
basis.
Note:
The Broad of Directors, under instructions from the shareholders, appoints a sponsor, who in turn
appoints a project manager.
I re-iterate: the sponsor is the sole contact point for the project manager, which eliminates confusion
and scope creep.
The project manager appoints his or her own team.
Page 33 of 283
These are professionals, who get paid for their expertise.
These include:
Researchers.
Corporate advisors (business plans, swot analysis, due diligence).
Experts on valuation (Discounted Cash Flow).
Capital funders (if needed).
Stockbrokers.
Forensic accountants.
Corporate Lawyers.
Skills professionals in specific fields, such as geologists, retail experts,
engineers or scientists.
o
o
They report directly to the project manager, who also co-ordinates all tasks.
The team members produce tasks according to time frames and budgets.
They charge for their services and get paid:

A deposit and remainder on completion.
Some consultants will prefer shares in the project; if the project is the listing of a
company on an exchange.
The consultant sets the timeframe; often longer than needed.
All the consultants sign a separate mandate.
Different teams are signed up for different projects. For instance, a project involving film making
would be different to one involving a water treatment plant.
Project Manager Sponsor structure
The scope or brief of the project will define the type of team that the project manager will need to
assemble. Planning the scope sets the stage for everything else that happens in the project, so
its important to do it right. Learn how to recognise the different types of client (sponsor) and to
define their need appropriately. At the conclusion of the initiation phase, the sponsor approves
the brief, which outlines what the project should accomplish and what resources will be
available.
Don't be popular within the project team: A project manager is not being paid for making the
project team happy. Unlike the normal methodologies, where project managers are encouraged to
communicate and make the team own the project in the Guerrilla Principle, the project manager has
layers of professionals he or she can choose from. There is thus no need to squeeze the last bit of
productivity out of the team, as they have their reputations to uphold and, of course, wont get paid if
Page 34 of 283
they dont deliver. They will also not participate in the bonus attained if the project is on time and in
budget.
o
I recommend that the following is contractually negotiated:
If the project is on time and budget: a bonus of 6% of the value of the project is paid to
the project manager.
If the project is one week late in delivery: the bonus falls to 4%.
If the project is later than a week: no bonus.
All good things must come to an end: Project end dates must be treated like other milestones, as
of course bonuses hinge on achieving deadlines.
The issue of resources: under normal circumstances, the project manager has to agree to all sorts
of issues that affect costs of a budget, including staff costs, training, whether computers have to be
acquired etc.
o
Under Guerrilla Principles, most of those resources fall outside the cost of the project. The
project manager has a contract to deliver a project, which states that he or she will use his or
her offices, equipment, teams and thus all other costs, such as training are up to the
company to cover. It makes this all easier to manager, as time sheets for staff do not have tp
be kept.
It may sound harsh to take (and keep) control of the entire project, but often it is the only way to
get the Stages completed on time and within budget.
ASPECT 2: THE CASE STUDY

THE MERGER & LISTING OF CARVERTEL CONSULTANTS
FULL CASE STUDY DOCUMENTATION CAN BE DOWNLOADED FOR FREE FROM: www.magliolo.com
There is, however, a case study commentary at the end of each Stage; as set out in this book.
About the case study:
The names of the companies have, of course, being changed. There is still confidentiality and
non-disclosure agreements in place.
Nature and background to the project:

In 2003, I was approached by a Johannesburg-based Mechanical Engineering Consultancy (lets call it
Carver B Consultants), who wished to restructure his business to list on a renown stock exchange. The
company owner (lets call him Steve), wanted a long term plan and strategy to become more efficient
and profitable.
The companys focus was brilliant and Steves skills and experience in this automotive research was
unsurpassed. However, due diligence and research suggested a number of issues had to be resolved
before he could list his business.
In fact, the company did not meet listing criteria for a number of reasons. The main problem, however,
was that Steve used the business as his private account, not paying himself a salary and so on. This is
no different to many small companies around the world, which leaves the owners frustrated when they
are told that the company cannot be accurately valued. Another problem was that the companys client
Page 35 of 283
was in another town, which left the business open to interference from smaller competitors ased in that
region.
The maim advice was to restructure the business to keep proper accounts, relocated to the Cape Town
region to better service the client and, finally, to acquire or merge with a similar sized company to
increase capacity, profitability and improve chances to list on an exchange.
Now, four years later, Carver B Consultants, have restructured, relocated to Cape Town and wished to
review the potential of listing on a small cap exchange. Simultaneously, the JSE had launched an
exchange for that very purpose, called The Alterative Exchange (AltX). The requirements are strict, but
aimed at the entrepreneur who wishes to increase capacity, growth and profitability.
So, the consultancy had taken advice and was now ready to appoint a project manager to assist them to
list on the AltX. Despite four years of growth, however, the problem of a lack of capacity still existed. The
answer: to merge with a company (Lets call it ProKomTol) that complimented each other in skills and
product/service ranges.
APPOINTMENT:
Confirmed and signed by both companies.

Confidentialities and non-circumvention agreements signed
Contact person (sponsor): Steve.
Brief outline of the contract:
Deliverables (purpose of contracts):
CONTRACT ONE:
o Assess Carver B Consultants and ProKomTol to determine merger viability.
o Merge the two companies.
CONTRACT TWO: List the new company, to be called CarverTel Consultants, on the AltX.
Aim of the merger and listing

o
Enhance the profile and credibility of both their companies, within a merged company.
Raise awareness of both companies and in the new company in its target markets and more
generally with investors and members of the general public.
Position the new company to attract and retain key human resources by means of the
implementation of a share incentive scheme in the foreseeable future.
Obtain the necessary spread of shareholders to enable the new company to be listed on the
JSE; specifically, the AltX.
Increase its capital base in order to take advantage of future growth opportunities; as
specified in the research section of the document.
Provide management, staff, selected black economic empowerment investors, financial

institutions and associates the opportunity to participate directly in the equity of the new
merged company.
Raise the necessary funding to allow the company to fund future acquisitions.
Page 36 of 283
Time frames:
o According to Guerrilla Principle, place the responsibility of time schedules on the company.
For instance, if it takes four weeks to complete each of the four phases, state that the phase
starts once the company has provided all the required data.
o
The proceeds of a private placing would be utilised to defray the expenses of the private
placing and the listing, and the excess will be utilised to fund expansion.
The four phases would take three months to the point where AltX would grant or deny the
listing. If the exchange accepted the listing, it would take an additional two to three months to
list.
Costs:
o According to the Guerrilla Principle, I would charge the company and pay my consultants (the
project management team).
Cost: R250,000 per phase: total = R1 million.

Payable: 50% on starting the phase and remainder on closing the phase.
Bonus: 6% of the ordinary shares of the company at listing. Estimated value on
listing is R12 million.
Payable to the consultant: details would be different for different projects.
Consultants required:
o The project required the following:
Research and analysis of industry trends: I, as project manager, would undertake
this task. I would also conduct all corporate finance due diligence issues.
Forensic auditors: A small accounting firm based in Port Elizabeth was chosen for
the ability to undertake in-depth assessment and conduct discounted cash flows with
the four week time schedule.
Legal work: the merger would need an attorney to draft shareholders agreements etc.
The consultant used is an advocate, who is also a stock exchange listing
requirements expert.
IT: new websites and co-ordinated e-commerce systems would have to be developed
and integrated. A systems analyst was chosen, due to her ability to complete complex
tasks within tight deadlines.
The process would be to undertake each phase as follows:
PHASE 1: RESEARCH & DUE DILIGENCE

[List of questions submitted to management is set out in the appendices]
The aim was to undertake in-depth research into each company; individually and as a merged entity.
Research would include global regional and South African markets of mechanical engineering; in a
drill down approach, as follows:
Page 37 of 283
Note:
o
o
Research included analysis if environmental factors (See Jungle Tactics).

Industry analysis included scenario planning and assessment.
Simultaneously, the accounting and legal firms would assess the companies as per their respective
tasks, the potential merger and the option of listing.
Part of the analysis, despite not being part of the Scope of the project, was to assess the benefits of
listing on the JSEs Main Board, rather than the AltX market.
o
While it may seem like a waste of time to do something that is not contractually required,
this was carried out, as one of the listing conditions of AltX is that the exchange would
have to determine whether a Main Board listing would not be better for the company; the
differences are set out in the Appendices.
In addition, while a listing was Scoped, one of the directors was not certain and a
document to help him understand the advantages was drafted to set his mind at rest; a
summarised version is set out in the Appendices.
PHASE 2: STRATEGY & OPTION DETERMINATION

Through workshops, I would:
o
o
o
Discuss all the relevant issues with the consultants, independently and as a group.
Outline a plan for the merger of the two companies, with the directors of the two
companies.
By the end of the two day workshops, the directors had agreed on all the issues relating
to the full agenda, including:
Shareholders agreements
Listing on AltX
New company name etc.
The full agenda is set out in the Appendices.
These workshops also lead to determining which options are available to the client; can such current
options change if corporate restructuring takes place?
Strategic decisions are made and outlined in the next phase.
Page 38 of 283
PHASE 3: THE BUSINESS PLAN & VALUATION
Set out a plan to include strategy, valuation and objectives.
The plan is written on the assumption that phase two decisions have been carried out.
PHASE 4: FINAL DOCUMENTATION AND IMPLEMENTATION

Carry out required legal, accounting and corporate work to raise capital or to list.
Once the above tasks are completed, the work of the corporate advisor/project manager is over,
unless the company lists then a new listing advisory mandate will be signed.
An advisory and strategic mandate can be discussed at such a time.
Remember the essence of the case study is outlined at the end of each chapter of this book.
For assistance in setting up project management rules for your company, whether standard rules or
based on the Guerrilla Principles, contact me on mentor@magliolo.com
Page 39 of 283
STAGE 1:
UNDERSTANDING THE
BASICS & PROJECT
INITIATION
Project management provides structure, focus, flexibility and control in the pursuit of desired
and targeted results.
Learn the basic characteristics of a project and how projects differ from the normal way that
work gets done. Discover why project managers should be using the new global approach to
project management instead of the old approach. Explore the types of people who typically work
on projects and what the role of each should be.
Finally, learn the four phases of any project and whats required in each phase if success is to be
achieved.
Page 40 of 283
COMMON MISTAKES: GETTING STARTED

As the project manager prepares to start a project, he or she should build in key activities around the
management of the project.
This should include building lessons learned reviews into the project plan at key times in the life of the
project.
Suitable times might be:
At the end of each Stage.
If the project is subject to review periods, at the end of the review.
At key milestones.
If the project is straightforward and there are no obvious Stages, it can still be useful to conduct a
mid-project review.
The manager should always build in a lessons learned reviews to form part of the structured project
closure so that other projects of a similar type may benefit. Experience highlights that many projects
are very similar.
Page 41 of 283
CHAPTER 1: PROJECT DEFINITION &

AGREEMENTS
The aim of this first chapter is to establish some basic principles and, hopefully, take a quick
look into the world of the project manager, which is often completely misconstrued. Some
students once painted a picture of project managers as high powered individuals, who have large
teams in expensive high rise offices, travel around the world and conclude multi-million rand
deals. The professional manager is mostly an independent professional who does travel, but has
few staff (if any), and works long hours to complete projects on time and on budget.
A STARTING POINT
The career of project management is not always as glamorous or exciting as it may seem on the surface.
Project management takes dedication, discipline and a combination of skilled leadership and experience.
Logic is yet another important trait, which is largely underemphasised.
What, then, is a project? Usually, it is a once-off activity with a clear start and a clear end. It has full or
part-time resources clearly assigned to a manager by the owners and it sets out to deliver something,
whether a new telecoms system, product, business process, listing on an exchange or merger.
The above can, therefore, be summarise as having four main characteristics:
Finite time
Involves people
Clear and concise roles and responsibilities
Delivery of a final product
When stated in such clear and unambiguously terms, it is a wonder that project managers have anything
to complain about. Yet projects often run out of time, employ the wrong professionals or have too much
to accomplish with too few resources.
If characteristics are well documented, why do many project managers feel overwhelming pressure? In
effect, it usually boils down to poor planning. People start projects without properly defining or planning
them, then some 25% of the way through the project they begin to realise what it's really all about and
the panic starts. Sometimes the end date is thrust upon them arbitrarily, but sometimes project
managers voluntarily commit themselves to dates, costs and deliverables without troubling to define and
plan the project properly, which is akin to lunacy.
While a bit of pressure is good for the soul, too much causes endless problems, including inaccurate
valuations, costing, budgets and delivery timing.
Another popular definition of a project is: the way change is achieved. Left to their own devices many
things gradually improve, but to bring about significant change, say to a business process, a project is
needed. However, to this definition it would be prudent to add the word predictable: projects are a way
of bringing about predictable change. That is, cost, end date, deliverables and quality should be
predicted at the beginning of a project.
How do we make projects predictable? A clear scope/brief, clear roles, clear plans, clear control
mechanisms... in other words project management.
Page 42 of 283
CONSIDER THE FOLLOWING:

If you take the total cost of a project expressed in man hours, what percentage should be
spent on planning, controlling, team meetings, reporting, etc?
The answer is: it depends. Imagine a simple project being done by a few experts who've done
many similar projects before. They may need hardly any control - perhaps only 5% of the cost
will go on managing the project. But by contrast imagine a large, complex project spread
across many locations, staffed largely by novices who only spend part of their time on the
project would constitute more than 35% of the cost on managing the endeavour.
One of the many skills of the project manager is knowing almost instinctively how much control to bring
to bear so that small projects are not smothered by unnecessary bureaucracy, but enough control is
applied to large projects to keep them on the straight and narrow.
EXAMPLE: A project manager is asked to manage a project that consists of five sub-projects:
Business re-engineering
Software development
Hardware installation
Training
Implementation
To make matters worse, the project manager discovers that each of these five groups use different ways
of running, valuating and implementing projects. Would you have a problem in running the project?
Sense suggests that any project manager would. Logic dictates that the divisions, sub-projects et al
should be co-ordinated and structured so that all tasks flow to a central control point. This is the essence
of this book, taking it step further: project management in a global market must include a centralised
control point that is structured to account for operations in different countries with radically varying
cultures, languages and time zones!
Process vs. Project Oriented
Choosing the right people for the project starts with knowing what the extremes are: in many companies
there are, at the extremes, people who are either process- or project-oriented. For example, bank clerks
perform the same tasks all day; each task is independent of every other task done that day, but forms
the basis for that clerks job. People who work in factories or the construction industry have a different
experience. Each brick is a unit of material, but together can only be used effectively if there is a project
plan. The basis for success is to make the right choices quickly and, hopefully, at the outset. The next
logical step is to ask: How does the project manager get from an idea or business need to a properly
defined and planned project with an approved business case?
These are discussed in the four Stages of project management, as defined in this book. It is thus
sufficient to state that there are many ways to set out the process from idea to completion. The following
is merely one such example:
Page 43 of 283
IDEA: Define and produce a plan for the project definition stage.
EVALUATE: Is there a market (demand) need for this project.
DECIDE ON BEST ACTION: Find the best solution for the project.
RELATE ACTION TO POTENTIAL COSTS & RISKS: Investigate cost to benefit of undertaking
the project.
CREATE A PLAN: Estimate and plan the first stage in detail, later stages in outline.
DECIDE: Proceed or not.
Killing Creativity
Another question that often gets asked: do you really need formal steps to project management? Surely
creative corporate people do not need systems and templates? Surely such systems just produce
mediocre results?
Yes. Project management systems with their checklists and templates, processes and procedures do
reek of rigidity and bureaucracy. Often, project management systems clearly reflect senior managers
desire to keep control of projects and success is assumed to be sacrosanct if staff use approved
templates and follow set procedures.
Successful projects depend on good ideas, a genuine connection with user need, passion, dynamism,
and competent people. To succeed, a successful project needs much more than a cookbook approach,
particularly where innovation is required. Yet sound techniques are needed even in the most creative
project. Project management methods provide useful tools and techniques that represent accumulated
best practice.
Leaner Notes: How project managers choose to apply tools is up to them, but they are too useful
to ignore.
Projects are, more than ever, a fact of life for organisations across the globe. Changing patterns and
costs of funding, in addition to the multitude of funding options can have significant influences on the
companys profit. It is becoming increasingly common for companies to outsource develop of new
projects to secure funding. Simultaneously, capital providers are asking for details of how projects will be
managed, with some beginning to expect companies to use one or another established project
management system.
Against this background, there is a clear need for project management expertise, yet many
companies in developing countries, including the giants of Russia, India and China, do not as yet
have a tradition of using formal methods of project management.
Project management isnt rocket science. A lot of it is common sense and anyone who has been
involved in running a project informally will find much that is familiar. However, established methods
provide a more complete and systematic framework for defining and controlling a project as well as
helping with less tangible, but vital, areas like establishing good communication, clarifying roles and
building strong teams.
In addition, the outsourcing of a project to a professional manager brings transparency and removes
conflicts of interest.
Learner Notes: A new project should be seeing as an opportunity to develop project management skills.
Learner Notes: Assess the companys tasks to determine which would be better tackled as projects.
Page 44 of 283
PROJECT BASICS
Do you know whether you are currently involved in a project?
Has your organisation been trying to implement changes that could be

more efficiently implemented if undertaken as a project?
Would you work more effectively if you regarded certain tasks as part of a
project?
Could project management techniques help to make you more efficient?
What Is A Project?
A project has clear start and end points, a defined set of objectives and a sequence of clear cut and
logical activities in between. Many entrepreneurs associate project management with multi-million rannd
deals only. This is a misnomer, as a project can be anything from painting a restaurant to building a
bridge. In addition, a projects activities must be co-ordinated, with clear starting and finishing points,
undertaken by an individual or team to meet specific objectives within defined time, cost and
performance targets.
Effectively, a project is any undertaking that has a defined timeframe, a defined scope of work and a
budget. In addition, a project is more likely to be successful if the project manager invests time before
the project to understand the purpose and environmental factors that do and in future could influence the
outcome of the project. The scope must be clearly defined, fair and realistic; at times a professional
project manager may be too optimistic in his or her tendering for a project. It is as important to get the full
(and signed) commitment from the sponsor and to use a motivated and dedicated project team.
From experience, the above is merely the start. Time worn lessons for project managers include:
Ensure that the expected (and promised) resources are made available.
The Project Team's attentions must never be diluted by other responsibilities.
Focus on early planning, including, in addition to the overall chronological strategy plan, identification
of issues, detailed objectives and targets for each Stage of activity.
Define roles and responsibilities for each internal and external participant.
Establish clear channels of communication, ensuring that the sponsor is kept informed.
Involve all clients from the earliest Stage in the planning process and, thereafter, consistently
throughout the Project.
Despite the best intentions of project management and above time-worn dictates, projects still go wrong.
The following are common reasons why Projects do go wrong:
Scope/Brief is unclear.
Lack of no clear understanding of what the Project is trying to achieve.
Resources inadequate.
Project Management & the Project Manager

Entrepreneurs would be surprised at how many students cannot distinguish between what is a project is
how is it different to other business activities. A project is happening when a number of people are
organised to deliver a new product or service within a given timeframe and budget. So, producing a
monthly report is not a project if the same report is produced month after month. However, if a new
report needs to be designed with ideas from a range of senior managers and requiring technical work
from information technology experts and all done within a specified budget and timeframe, then it is a
project.
The author is often asked, Why is project management important in my project? An organisation may
be small or large, public or private, old or new. You may be using projects everyday to deliver
customised products or services to client. Or you may be using them irregularly, such as to design and
install a new computerised software system or to write and implement some new procedures.
Page 45 of 283
Whatever the situation, an organization uses projects to get new things done. Some organisations do
projects well, while others go from one disaster to the next, never seeming to learn the lessons of the
past. The following are common to companies implementing projects without due consideration to
structure and logical follow through:
Solutions delivered are often not what were originally required.

Budgets are usually over the stated amount.
Projects usually run past deadlines.
The scope is often changed.
Time is not properly managed.
The delivered goods or services are often riddled with errors and defects.
Project team members are not co-ordinated in a proper management hierarchy.
The sponsor shows little interest in the project.
By applying project management principles and methods, entrepreneurs can avoid the common
problems experienced above. The discipline of Project Management is now relatively mature and can be
applied successfully to any kind of project, small or large.
Following the logic of applying the principles and practice of good project management, the project
manager is more likely to:
Get the project done on time and within budget.

Deliver a quality product or service that will delight clients and end users.
Make sure that project team members will come away from the project with a sense of personal
achievement and satisfaction.
Project management is effectively a set of tools, techniques and knowledge that, when applied, helps to
produce better results for projects. Trying to manage a project without project management is like trying
to run a billion rand company without strategy.
Why Project Management?

But as voluntary organisations projects grow in size and complexity its clear we too can benefit from the
established body of knowledge that exists on effective project management. Project management isnt
rocket science. A lot of it is common sense and anyone who has been involved in running a project
informally will find much that is familiar. But established methods provide a more complete and
systematic framework for defining and controlling
In today's competitive business environment, a flexible and responsive approach to changing client
requirements is essential. Project management enables you to focus on priorities, track performance,
overcome difficulties, and adapt to change. It gives you more control and provides proven tools and
techniques to help you lead teams to reach objectives on time and within budget. Organizing activities
into a project may be time-consuming initially, but in the long term it will save time, effort, and reduce the
risk of failure.
Project management is the application of skills, knowledge, and tools to achieve the predetermined
project objectives.
Who Uses Project Management?

Formal project management techniques were developed in the 1960s as part of the early missile
programmes. Today these techniques are used in every area of society, from government to non-profits,
and from stock market listed companies to sole proprietors.
Learner Notes: A well planned project is usually completed quicker and on or close to specified
budgets; when compared to ones that are haphazard and not planned.
Page 46 of 283

Planned vs Unplanned Projects
In addition to helping the project manager plan, a project management method also helps to keep a
project on track and solving problems as they arise. It helps to manage changes that might be required
for the project. Note that in the above diagram unplanned projects does start earlier and with less
resource (costs). This is a temporary situation and is the most tempting for project managers, who are
not skilled.
SUCCESSFUL PROJECT MANAGER & MANAGEMENT TRAITS

Lets start with the person, who will be responsible for the entire operation: The project manager.
Project Manager Traits

What qualities are most important for a project leader to be effective? Since July 2000, when the author
left stockbroking and took on project management assignments, realised that repeatedly similar traits
kept surfacing during projects. Below are traits, which usually accompanies successful project
managers:
Inspires a Shared Vision: An effective project leader is often described as having a vision of where
to go and the ability to articulate it. Visionaries thrive on change and being able to draw new
boundaries. Visionary leaders enable people to feel they have a real stake in the project. They
empower people to experience the vision on their own.
Good Communicator: The ability to communicate with people at all levels is almost always named
as the second most important skill by project managers. Project leadership calls for clear
communication about goals, responsibility, performance, expectations and reviews. There is a great
deal of value placed on openness and directness. The project leader is usually the team's link to the
larger organisation. The leader must have the ability to effectively negotiate and use persuasion
when necessary to ensure the success of the team and project.
Integrity: One of the most important things a project manager must remember is that his or her
actions, and not words, set the tone for the team. Good leadership demands commitment to, and
demonstration of, ethical practices. Creating standards for ethical behaviour for oneself and living by
Page 47 of 283
these standards, as well as rewarding those who exemplify these practices, are responsibilities of
project leaders.
Enthusiasm: companies want leaders with enthusiasm, with a no-nonsense, go-getter attitude. Staff
and consultants tend to follow people with a can-do attitude, not those who give reasons why
something can't be done. Enthusiastic leaders are committed to their goals and express this
commitment through optimism.
Competence: Leadership competence does not necessarily refer to the project leader's technical
abilities in the core business. As project management continues to be recognised as a field, project
leaders will be chosen based on their ability to successfully lead others, rather than on technical
expertise. Having a winning track record is the surest way to be considered competent.
Delegate: Trust is an essential element in the relationship of a project leader and his or her team.
That trust is demonstrated in others through actions - how much you check and control their work,
how much you delegate and how much you allow people to participate. Individuals who are unable to
trust other people often fail as leaders and forever remain little more that micro-managers, or end up
doing all of the work themselves.
Pressure: In a perfect world, projects would be delivered on time, under budget and with no major
problems or obstacles to overcome. A leader with a hardy attitude will take these problems in stride.
When leaders encounter a stressful event, they consider it interesting, they feel they can influence
the outcome and they see it as an opportunity. Remember: No problems only opportunities!
Team-Building: A team builder can best be defined as a strong person who provides the substance
that holds the team together in common purpose toward the right objective. In order for a team to
progress from a group of strangers to a single cohesive unit, the leader must understand the process
and dynamics required for this transformation. He or she must also know the appropriate leadership
style to use during each stage of team development. The leader must also have an understanding of
the different team players styles and how to capitalise on each at the proper time, for the problem at
hand.
Problem Solving: Although an effective leader is said to share problem-solving responsibilities with
the team, companies expect project leaders to have excellent problem-solving skills themselves.
Project Management Traits

Lets examine what constitutes successful project management traits. Note that some will obviously be
the same as the project manager traits set out above.
Management methods: An effective method provides the project manager with the steps and tools
needed to complete a project successfully. Unless the project manager is an expert in the field, with
tons of experience, there is no real sense in inventing his or her own method. It is simply better to
use a method thats proven and focus instead on leading the team through its steps. The most
important element of the first key is the word use. No method is effective if it isnt used. The
application of the method is what produces results. Reading about a method, but not using it doesnt
produce anything tangible.
Planning: Many project teams dive into execution without having developed a project plan. They
think that getting started on creating the deliverables will shorten the time it takes to do the project,
which is simply not so. Successful planning traits include:
o
Help to avoid problems and minimise re-work.
Tends to keep the project focused and on track.
Page 48 of 283
Shorten the total time it takes to do a project.
Ensure that the right problem is being solved for the client and that the best possible solution
for the problem is the one being implemented. Continually check that final deliverable will help
the client to solve the problem being experienced.
Never start a project without a scope/brief. Starting a project without a scope is like driving in
a foreign country without a map. You will get lost.
Ensure that a thorough definition has been made of the scope, clients and customers, risk
plan, schedule and budget. Get the plan approved by the sponsor, resource managers and
any other key customers. The project plan is a map for getting to the destination. It defines
exactly where youre going, how many pit stops you intend to make, what your meal plan is
everything that you need to arrive safely at your destination.
The client: Projects exist to satisfy a client. Project teams often have difficulty identifying the client,
understanding clearly what he or she needs and wants, and then translating that set of requirements
into a deliverable item. The best way to achieve this is to involve the client in the project process,
particularly in the early stages when the scope of the project is being defined. This helps to avoid,
among other, continual changes to scope and client dissatisfaction.
o
Therefore, the client should always be involved in the project. During the execution phase, the
project leader should meet regularly with the client, reporting on progress and gathering
feedback and information that might be important to the project. When problems arise, let the
client know that an action plan (with various options) is ready to resolve the problem. Then
report back on how the implementation is progressing. After the client accepts the final
deliverable, ask him or her to evaluate not only the results of the project, but the process used
to create the results. Clients can be your best allies on projects.
Make it manageable: Its easy to get overwhelmed. Project managers have a goal to reach that
seems unreachable with limited resources. Often the consultants, which you choose, do not seem to
know what to do. Dont panic. Define the goalthe final deliverable clearly. Break the goal down
into pieces, interim deliverables and then organise those into sub-projects. Assign someone to
oversee each sub-project. Making a project manageable means making it workable, and when a
project is workable, it can get done.
Develop the team: One of the key roles of the project leader is to develop a team. It is crucial for the
manager to assess what skills and customer representation he or she will need on the team and then
use the team to help you develop the project plan.
o
The Magliolo Methodology suggests that various consultants, in the same field, are appointed
as associates and used in different projects. That way, when one consultant is busy on
another project, other associates are available. For instance, if the usual financial forensic
auditor employed by the project manager is not available for a specific project, use another
consultant in the same field.
When you get to execution, have the team participate in keeping the project on track. Ownership by
the team during execution will produce more commitment to solving problems that arise. They will
retain ownership of the project and any problems will belong to the whole team, not just to the project
leader.
o
Team-based tools will help you engage the whole team in the project process. If youre used
to conducting meetings where everyone sits around a table and talks, using team-based tools
that engage all three sensory learning styles might feel uncomfortable at first.
Page 49 of 283
Learn from mistakes: Maybe the most important key is learning from mistakes, so these mistakes
can be avoided in future. Its also important to learn from successes, so you these can be repeated
next time around. Once all lessons have been documented, consider doing a root cause analysis of
the problems experienced. This will help to trace back what were some of the most important things
that could have done differently to avoid the problems in the future. During the project, its also
important to continually solicit feedback from the team and customers about what could be improved.
o
All teams evolve through the stages of team development, but not all make it to the highest
evolutionary stageperforming. Part of the job of the project leader is to manage the team
process so that the team does make it to the performing stage, where people are satisfied
with the work theyre doing and theyre productive. Managing the team process starts at kick
off and continues through close out.
The sooner you know there is a problem, the sooner you can fix it. What you learned from the
project can be translated into templates or checklists for the next project team. Each project
team will then learn from the last one, improving the capability of the entire organisation to
successfully carry out projects.
Concluding: In spite of best efforts, some projects will still not be successful. Unfortunately, this is
part of the nature of projects. Using the tools, tips and techniques in this book will raise chances of
success significantly. Theres only improvement to look forward to.
CHARACTERISTICS OF A PROJECT MANAGEMENT TYPES

The normal definition of method is a system for getting something done. If you are doing a project on
your own, you can use whatever system works for you. However, when working with a group of people,
there is a need for a common project management method, because the project team must work
together. There are two approaches the team could use for coming up with a method. One, they could
invent one themselves, or two they could use an already developed, proven methodology. The value of
using a proven method is that the work of developing the method has already been done for you. That
allows you to focus on whats really importantthe content of the work.
Directive Project Management

The directive approach represents old management technology. It assumes that the project manager is
the person who can do the best job of planning and controlling the project. The project manager does the
planning and then delegates tasks to the team members. He or she the follows up with individual team
members to make sure they are completing their tasks on time. Communication flow is primarily between
the team member and the project leader. If a problem is encountered, its up to the leader to solve it.
Although the directive style is useful in some circumstances, because it saves time in planning the
project, it has a number of significant downsides:
The whole project takes longer, because the phase in which the work gets done (called
execution), which is the longest phase of any project, takes longer due to confusion,
misunderstandings, and re-work (having to redo work because it wasnt done right the first time).
Team members have little understanding of the project as a whole or how their work fits into the
big picture.
There is little team ownership or commitment to the project.
There is a twist to this methodology: effectively a mid-way between directive and participative.
The project manager controls the project, but uses experts in their respective fields.
The project managers role changes from being autocratic to one in which he or she keeps the
flow of work, controls quality and co-ordinates the project until it is completed.
Page 50 of 283
No confusion exists, as the consultants are well versed in their respective fields and their tasks
are not in question.
Participatory Project Management

Participative project management represents the newer management technology for projects. The
project leader facilitates the project management process, leading the team through the steps of
planning. The team, under the direction of the project leader, monitors the progress of the project as the
work is completed. Decisions about the work are made with the involvement of the team and
communication flow is not only up and down from team members to the project leader, but across the
team as well.
The benefits of a participative approach are:
Each member of the team understands how his or her individual piece of the project fits into the big
picture.
More ideas are generated.
Better decisions are made when everyone participates.
Participation creates ownership, which strengthens commitment and accountability.
Team morale is usually higher.
There is less re-work.
Individual and team performance is increased.
A participative approach generally provides for better project results.
SCOPE & PROPOSAL

Always define a start and closure stage for all

projects.
Some projects are repeated often, but are not

processes, because they have clear start and end
points.
Routine work can be distinguished from projects,

because it is recurring, and there is no clear end
to the process.
Defining The Project

Projects that go wrong tend to do so right at the beginning. All project management methodologies
emphasise the importance of the successful initiation of a project. This is done through the use of a
Project Definition, also called a Project Initiation Document.
The production of these documents ensures that the project is defined accurately and that
key issues like the overall purpose of the project and its key objectives are clear.
The Project Definition will also specify the key deliverables of the project the things it will produce, and
will timetable the work of the project, broken down into a series of tasks. The Project Definition provides
the foundation of the project, the baseline against which progress can be measured and controlled. This
doesnt mean that the project is set in concrete. As it proceeds there will be a need for changes, but
these can be made in a considered way, against the background of the definition, rather than being
incorporated piecemeal into the project.
Page 51 of 283
The process of defining and presenting the project accurately helps ensure its accountability. The Project
Definition provides a clear statement of what the project entails and can be used to make sure that
everyone understands what it will do. The Project Definition is a great vehicle for communication and
should be used to avoid misunderstandings of what the project is about, and to build consensus around
its objectives. It is better to have the debate about what the project will do at an early stage of the project
rather than let different points of view cause problems at a later date.
Project Description Template
Details of Team:
Purpose of the project:
Scope/brief of the project:
Details of the project:
Delivery of the project:
Quality criteria:
Review process:
Scope is a general term to describe everything that your project encompasses, everything that must be
achieved for the project to be complete. This would encompass the vision, goals and requirements and
would be embodied in documents such as a project proposal and at a lower level commercial
specifications and technical specifications.
Vision
The word vision produces shudders in technical and non-technical people the world over. And rightly
so, for a vision is normally a collection of meaningless catch phrases and marketing dribble intended to
dupe people into thinking that businesses are there for polite and altruistic reasons. This is not the kind
of vision the author means.
When project managers talk about vision, they simply say that you need a single encapsulated idea that
defines the aim of the project. Why are you doing the project in the first place? A project is a standalone
task (or set of tasks) that has an intended outcome.
Leaner Notes: the project aim cannot be stated in a single sentence, then its not a project.
A project is a defined task with a finite life, with a fixed end point and that end is defined by your vision.
Without a single, linking goal all the dependent steps of project planning become difficult. That single
vision may be broken up in sub-goals, but it provides the link that holds all of the disparate parts of the
project together into a single enterprise. It gives teams a sense of purpose and defines the success of
the project.
Goals
In establishing goals, quality is usually improved.
Using a formal project management methodology often results in an

improved way of working.
Objectives must be identified for all those involved in the project.
Page 52 of 283
Goals are more specific than the vision. Goals should directly support the overall vision of the project,
but refine its definition. Typically, goals are set out by clients and define how the success of the project
will be achieved. While the vision encompasses the whole project, goals may refer only to the objectives
of a particular segment of the project. Note that the terms scope, vision and goal are largely
interchangeable. Different organisations use them in different contexts to refer to much the same
concepts.
While further steps in the project planning aim to be more and more specific, the initial goal should be
broad enough to encompass the whole project. The vision must state, succinctly, the ultimate goal for
the whole project. The vision should be inspiring or, appropriately enough, visionary.
In addition, goals tend motivate teams, as everyone knows what has to be done and when. Goals like to
deliver the cheapest system, in the shortest time will not inspire anyone or motivate a team. Yet, goals
like Deliver the best sales and marketing system on the market is more likely to inspire personal
commitment from the team and customers.
Visions dont have to be written down or cast in stone. They dont even have to be formalised in any
particular sense. In large organisations they often are, since thats often required in their annual results.
Definition Stage Plan And Agreement

Project management is a necessity for big projects that involve large teams, perhaps working separately
on different parts of the project. In this context, clear documentation and sound communication are
essential if everyone involved in the project is to work together effectively. On a smaller project, involving
only two or three people, formal project management is less essential. In a small team, communication
can take place more informally, especially if the team members work closely together. Agreement on
objectives and the scheduling of work can all be done informally.
Yet even small projects can go wrong. Communications can break down, things can get forgotten, and
objectives can be subtly redefined, especially where there are staff changes.
Learner Notes: Project management can help even on the smallest project.
The issue for smaller projects is to make use of project management techniques at an appropriate level.
It makes little sense to produce copious documentation on a tiny project; the effort has to be justifiable by
the result. A project definition document may appear bureaucratic, but it will help to clarify ideas and will
improve communication and accountability. A project schedule will help to plan ahead and allocate
resources. A clear statement of what the project will produce will help to communicate needs to
suppliers. If project management techniques make for a successful project, no matter how small, it is
worth the extra effort.
Effectively, the Project Definition must deliver three main things:
Project Definition Document

Business Case
Project Plan
Learner Notes: There is no doubt that writing a project definition is difficult.

Writing a Project Definition is a demanding process. It involves thinking ahead, clearly and logically
to structure the project into its different elements. Projects are complicated enough, without the added
problems of obtuse and abstract concepts. It may be hard, but the effort you put in here will be repaid as
the project proceeds. You are building the foundation for the project, setting the framework for its
development and constructing a vehicle for communication. Someone has to write the Project Definition
but it shouldnt be a lonely task. You wont be an expert in every element of the project, so youll find it
hard to confidently estimate the duration of tasks and the resources youll require.
Page 53 of 283
However, if the project manager has a team of specialists at hand, he or she can talk to them to obtain
their opinion, gained from knowledge and experience. The same applies to uncertainties, like the needs
of project users and the benefits that the project will deliver. Dont struggle to define these on your own,
but involve those within the organisations who deal in these issues. This may mean leading a discussion,
but it is better to resolve these issues with all those involved, than to struggle to resolve them on your
own.
A simple Project Brief is produced as a first step: this is then developed into a Project Initiation
Document. The template for a Project Brief can be used very successfully as the agenda for an initial
brainstorming meeting. Project Managers have two different roles to play.
To develop a logical structure to the project.

To facilitate communication between the different staff involved.
These are distinct and very different skills. Some Project Managers feel more comfortable with the
detailed work of planning, but the communication element is the key to the production of an effective
Project Definition and a successful project.
A Decent Proposal
Sometimes referred to as a business case, the project proposal states the highest level goals in a
project. It outlines the overall business goals and vision for the project as decided by the client. It is
sometimes drawn up well before the project starts although the project manager should have a say in its
creation.
The basic proposal should contain the vision for the project and the business goals, what the client
hopes to achieve at a business level. There may also be a large amount of supporting information in
order to qualify or corroborate the stated goals, but the goal itself should be clear. The supporting
information might include preliminary forms of the project planning documents, such as budgets and
schedules.
Project proposals are vital documents, because these are the documents that become the contract
between project manager and client. It is the foundation for the signed agreement. To conclude, the
vision is stated first and then a list of specific business and technical goals is listed. Each of the specific
goals contributes directly to the vision of delivering the sales and marketing system.
Stage 1: Initiation
The first Stage of a project, which is called initiation, begins after management decides to authorise the
project. The goal of initiation is to set the direction for the projectwhat the project is expected to
accomplishand define any constraints on the project. Both project direction and constraints should
come from the sponsor, because the sponsor is the management person, who is accountable for
ensuring that the project meets the strategic goals of the organisation and that the benefits of the project
outweigh its costs. Due to many sponsors not being able to write (or claim not to have the time to do so)
a scope/brief, it is usually left up to the project manager to do so. The sponsor must review and approve
it when youre done. In addition, it is important that the client also approves the brief.
The scope should answer the following basic questions about the project:
What are you supposed to produce?
For whom?
By when?
At what cost?
These are explained in the following section.
Page 54 of 283
Writing The Scope Section

The first section of a proposal is called the scope section and it defines what will be produced for whom.
The first entry in the scope section form is the project name. Keep the name short and easy to say,
because youll be writing and saying it repeatedly. The name should reflect the main purpose of the
project.
Next, describe the business case for the project. What are the business needs that justify the
project? How does this project help to support the strategic objectives of the organisation? How will it
improve the organisation? What benefits will the organisation realise as a result of doing this project?
Under project objectives, describe the purpose of the project. This should be a brief statement or a
couple of bullet points about what the project will accomplish. Make sure that the statement of purpose
only includes things that youre willing to be accountable for. Any benefits that the organisation will
receive as a result of doing the project should be included in the business case and not in the objectives.
The sponsor is accountable to make sure the project meets the needs of the organisation. The project
leader is accountable to make sure the project meets the project objectives. Organisational benefits of a
project are outside the scope of the project and should not be included as objectives. Next, define the
final deliverable of the project.
A final deliverable can be a product, service, process, plan or a combination of the above. The final
deliverable is the final output from the execution phase of the project that is delivered to the project
client. It is also the primary reason the project has been undertaken, because projects exist to satisfy a
client, and his or her satisfaction is achieved when the final deliverable meets or exceeds his or her
expectations. If there is more than one final deliverable, define each one.
EXAMPLE: A project manager is assigned the task of merging two companies and listing these on an
exchange. In such case, there are four deliverables:
1. Assessment of company A.
2. Assessment of Company B.
3. Merger of A & B.
4. Listing of new company on an exchange
Beware of any scope that contains too many final deliverables. It may be a sign that the scope is too
broad. Try to keep the number of deliverables to one or two. This will help to keep the scope of the
project to a manageable size.
For now, you just need to get an overview of what the client is looking for, from his or her point of view.
The best way to get this list of requirements is to ask the client directly. The last section in the scope
section is client need. This is the problem the client is trying to solve by means of the final deliverable.
clients dont really need deliverables. What they need is a solution to a problem. For example, you dont
really need a car. What you need is a means of transportation and/or a status symbol.
The car is a means of satisfying your need. In the client-needs section youre trying to define the real
reason the project is being undertaken for the client: the problem they have that will be relieved through
the production of your final deliverable. The problem will not necessarily disappear after your project is
completed, but it should be alleviated through the use of our final deliverable. Sit down with the client
and ask him or her what the business problem is that he or she expects the final deliverable to help
resolve. The better you understand the need that is driving the project, the more likely youll be to satisfy
the client. Finally, list the projects customers. Customers are people or groups who will be affected by
the project. These can include major suppliers, resource managers, or any groups that might be affected
by the deliverable of the project, like a workers union, for example. Clients, the sponsor, and team
members are also customers, but they will be identified in other sections of the charter document.
Page 55 of 283
The Description
After defining client requirements, the project manager is ready to write a description of the final
deliverable. This is called the scope description. The purpose of the scope description is to fully describe
what will be produced to the satisfaction of the client. The description is effectively a communication tool
to ensure that what is to be produced is what the client and sponsor want you to produce. The
description should be short less than one page. However, a diagram often helps to describe the final
deliverable, so include it. Anything that communicates what your final product will be is helpful and
should be included. It will be too late, after all, to try and include details after the scope has been signed
off by the client.
Another hint: add whats not to be included in the scope of the project. These are the scope boundaries
for the project. By defining the scope boundaries, a project manager will avoid confusion about whats
included and excluded from the project and do a better job of steering a straight course to the goal of
satisfying the client.
To define the scope boundaries, write the name of the final project item
(product/service) to be delivered on a piece of paper and draw a large circle around
it. This is the project managers are of work. Inside the circle, list all major tasks that
will be required to be produced. For example, a new product launch may be country
specific, so outside the circle would be all other countries.
Now that boundaries have been defined, it is crucial to determine whether there are any overlaps.
The project manager must quickly find out whether other project teams have been employed that
may overlap with his or her project. In 1995, the author was commissioned to investigate the demise
of the South African cement cartel and its influence on the clients company. At the same time, the
client had hired another consultant to sell his business. The author worked for six months,
interviewing dozens of cement industry associations, unions and company professions. Strategies
were drafted and government organisations consulted and so on. When the final document was
completed, the client announced that he had sold the business and no longer required the final
product. Dont let this happen to you. Find out what other projects are planned or in progress that
might impact your project.
To complete the scope boundaries, the project manager needs to define exactly when the execution
phase of the project will end. The easiest is always when the product/service is presented o the client. If
the project manager defines project end to when the product/service is launched, he or she may have to
wait indefinitely. Colleagues of the author stipulated in contract that the project will end on the product
being launched in South Africa. The company decided that the product would be best suited for the
Australia market. Using all the work, time and resources that the authors colleague managed, the
company launched in Australia and refused to pay for the work done. After all, they didnt launch in
South Africa, did they?
Not to say that everyone is unethical, but it is better to have an exact and stipulated final delivery sign
off.
Resources must be separated.
Projects are allocated time, people and budgets
Not all projects operate as part of daily business routines.
Operating within budgets (resources) is a fundamental part of a successful

project managers role.
The second section, called Resources, relates to who, when, and how much. The first question,
who, refers to who will be on the project team. If youre writing the scope, now is a good time to decide
who you will need on your team. What skills will you need to create the final deliverable required by the
client? Which customers do you want as members of the team? If the sponsor is writing the scope, then
Page 56 of 283
the sponsor has the option of appointing members of the team or just appointing the project leader and
letting the project leader choose the team.
Next, define the limits for the project. First, what is the deadline for the final deliverable? If there are
no deadlines, are there expectations about when the final deliverable will be completed? If not, indicate
that there is no deadline. Are there any other deadlines that the team must meet? Include an explanation
of why each deadline has been set. This will help the team understand the reasons for the deadlines.
The deadline section should not be used to create a schedule for the team. Thats micro-management
and it is neither helpful to the team, nor will it improve the teams chances of completing the project on
time. During the planning process, the team will create a schedule they can live with, and the sponsor
and customer will then have an opportunity to review and approve it.
Is there a limit on the amount of time that people can spend on the project? The time that internal people
spend on a project is called staff-effort time or just staff effort. Sometimes organisations decide that
people should not spend more than X percent of their time on a project or that the project should not
require more than Y total person hours. If you have a staff-effort limit of any sort, list it here. Also, list the
reasons for the limit.
Whats the maximum amount of money that can be spent on this project? Try to find out how much
money has been allocated to the project, even if you dont have a project budget. In many organisations,
the managers of the resource areas spend the money, not the project manager. If this is the case, list the
amount of money available from each department for the project. This will be important in trying to plan
your project spending during the planning phase. List any reasons for setting the spending limit at the
amount designated.
Are there any other constraints on resources? An example of a constraint would be not hiring
consultants or only using existing equipment. List any constraints the sponsor has placed on the project.
Finally, the team needs to know the priorities within the project.
What is more important: scope, schedule or cost?
These three variables are interdependent and its important to know their order of importance, because
during the planning phase the project manager WILL have to make trade-off decisions between them.
They are known as the triple constraint. In order for the team to make the best choices between the
three variables, they need to know how the sponsor prioritises scope versus schedule versus cost. Is
schedule the most important with scope next and then the cost? Or, is scope first and then cost and
finally schedule. One way to ascertain the priorities is to ask the sponsor.
The Triple Constraint
GETTING APPROVAL
Review the scope section with the client to make sure he or she agrees with your definition of what will
be produced by the project. Also, review the deadline date with the client, and if the client is paying for
Page 57 of 283
the project, also review the expected budgets. Ask the client to sign the scope. When the project
manager and sponsor are comfortable with the document, both sign it.
The approval of the scope launches the next phase of the project, which is planning. Too many times,
teams rush off and begin planning without due diligence on building the right team, with expert
knowledge in the clients market, starting with the issues list.
The Issues List

The first planning tool that must be created is the issues list, which captures any issues that need
resolution or any actions that need to be completed prior to (or during) the Planning Stage. It may sound
as if this should form part of the planning stage, but experienced project managers know that until some
tasks are completed, planning really doesnt start. For example, survey teams must be employed before
the survey can be planned, or land secured before construction planning commences.
Designing the list
The first column is the issue number; set out consecutively.
The second column sets out the problem/issue to be resolved.
The third column must state who will undertake the task.
The fourth column states the current date.
The final column sets out comment which included how the task was resolved, the date of
completion and lessons learnt during the process.
For a template, go to www.magliolo.com.

The issues list is maintained by the project leader and is updated at each project team meeting. It is not
a replacement for a project schedule. It is said during the planning phase, before a schedule is created,
to track any planning tasks that must be completed. It is also used during execution to track issues or
action items that are not significant enough to put on the schedule. It should not be used to track the
deliverables or tasks that must be completed during the execution phase.
Learner Notes: The issues list should be monitored and updated at every team meeting.
The project leader should be notified as soon as the person assigned to the issue knows that he or she
will not be able to resolve the issue or when he or she needs help getting the issue resolved on time.
This allows the project leader to be proactive before the issue is overdue. If necessary, enlist the help of
the sponsor, if the project team cant get an issue resolved on its own.
In the next chapter, key roles are examined.
Page 58 of 283
CHAPTER 2: DEFINING KEY ROLES

Projects can involve a wide range of people with very different skills and backgrounds. However,
there are several pivotal roles common to all projects, and it is important to understand the parts
that each of these key people play!
UNDERSTANDING ROLES
Learner Notes: Project managers must create a list of all key people, who might be able to help them in
their undertaking.
The project manager is in charge of the entire project. While this is the accepted practice, there will be
times when the sponsor will insist on running the project. It is strongly advised that the project manager
walk away from such projects; these will always run into personality conflicts and the project will die
before reaching completion.
However, taking control of a project does not suggest that the project manager can succeed on his or
her own. Therefore, establishing good relations with other key players in project management is vital.
Important project people, include the sponsor, who may also be the project client may also be the
backer/funder of the project. Other team members, represented by consultants in finance, research and
operations may be either part- or full time are nevertheless important to the success of the plan. There
will also be customers, or people with an interest in the project, such as suppliers.
Learner Notes: Build a good communication with all main team members, including downstream
customers.
Learner Notes: The team must consist of people that the project manager trusts; skills, experience and
morally, i.e. their work ethics must be unquestionable.
Cultural differences will dictate key roles round the world.
North American projects need a senior sponsor to get off the ground and be accepted by customers.
Australian flatter management structure means that projects also depend on senior support.
In the UK, the sponsor can be at a lower level, provided that there is a strong business case for the
project.
Involving Stakeholders (Customers)

The author prefers to call Stakeholders customers. These are people or organisations that will be
buying or using the new services or products of the company launching the project. Essentially, if the
companys customers are happy with the product and they support the venture, then the company is
relatively sure that they are not wasting time and money on a product or service that will not be bought.
The project manager must, therefore, aim to involve all important customers at an early stage. Not all
customers will be equally important, so identify those who could have a significant effect on the project.
When the project manager draws up the project plan, conclude how important it is to keep customers
informed, which will depend on how broad or narrow the market is, how specialised the product is and
whether there are many customers or not. Enthusiastic and strongly supportive customers are positive
for the project, as their assistance will convince the sponsor and client that the project is, indeed,
important. Ensure that strong alliances are forged, particularly if the customer controls the downstream
purchasing requirements.
Page 59 of 283
Identifying Key Players & Roles
Client: This is the person, who employs the project manager to undertake the task of
drafting and implementing a new proposed project. The client is usually an appointed
director of a company, possibly the managing director. This person either employs the
project manager directly, or through a duty managing director or similar position.
Sponsor: The person who employs the project manager is called a sponsor, which means that this is
the person to whom the project manager will report. The sponsor is thus the most senior team
member. In addition, the sponsor ensures that the project is of real relevance to the organisation. He
or she helps in setting objectives and constraints and at times (particularly during tough times) acts
as an inspirational figurehead.
Project manager: This is the person who is responsible for achieving the project's overall objectives
and leading the project team. It is under the project managers guidance that a detailed plan of action
is finalised. He or she motivates and develops project teams and communicates project information
to the client, customers and other interested parties. Progress is also monitored by the project
manager, to ensure that the project remains on track.
Customer (also called Stakeholder in some books). The use of the term Stakeholder can be
confusing when dealing with larger companies, who have large numbers of shareholders, which is
also called Stakeholders in many countries. So, to eliminate confusion, this book uses the terms as
follows:
Denotes persons or organisations that own shares in a

company.
Also called shareholders.

Denote any parties who would be affected by a new
product/service being launched by a company, i.e. they
would be the buyers or uses of that ser vice or product.
Stakeholder
Including main company customers in the team may be

either positive or negative. That would have to be
decided through due diligence and research.
In many countries, customers can use their buying

power to leverage better deals with companies.
Providing customers with knowledge about a new
product or service could influence their advice during
team meetings, i.e. they may purposefully give incorrect
advice. For additional explanation, contact the author on
mentor@magliolo.com.
On the positive side, customers could give direction as

to more efficient method of supply, demand trends and
customer needs.
Customer
Team members: These are people who (either full or part time) assist the project manager with
specific or general task; provides the breadth of knowledge needed to complete the project. They
make a major contribution in examining feasibility and planning a project, through technical,
accounting, legal and other specialist skills. It is the correct employment of consultants which is
directly responsible for project being completed on time and within budget.
Page 60 of 283
Project Board
In large and extremely expensive projects, a Project Board is appointed and often a boardroom is
dedicated to that project. The project manager can then pin up[ Gantt Charts, Schedules and Planning
tasks.
In essence, The Project Board is charged with the task of controlling the project and consists of:
Executive: Someone from the company; usually the Sponsor, who is charged with the overall
responsibility for the project.
Divisional Head: Represents the interests of that companys division.
Specialists: these may be people or organisations that will provide specific skills (geological, mining,
financial) and often represent interest groups, such as unions, government or world agencies. For
instance, if a companys project is to list on a foreign stock exchange, then specialists from those
countries would form part of the team.
Project Manager: Runs the project on behalf of the Project Board.
This type of Project Board can become large when the project involves many people and organisations
in various countries and in specialist fields, like the drilling of oil in a foreign country. The emphasis,
therefore, is on controlling the project; it is much more a working group than a talking shop. It shouldnt
be seen as a steering group representing the interests of all the customers. If there is real need for such
a body, it may well be required in addition to the Project Board.
Such a board does have some strength. The inclusion of the executive and a manager from the
organisations division provides a champion for the project and ensures it doesnt get isolated or
completed against the wishes of the divisional head; resistance in the implementation of the project
usually leads to failure.
The following chapter looks at the essential factors for success.
Page 61 of 283
CHAPTER 3: PREREQUISITES FOR

SUCCESS
To achieve the desired outcome, projects must have defined and approved goals, a committed
team and a viable plan of action that can be altered to accommodate change. Abide by these
essentials to keep you on course for success.
THREE FUNDAMENTAL ELEMENTS TO SUCCESS

Element 1: Precise Goals
Learner Notes: The project manager must always ensure that all key role players understand what he
or she is aiming to achieve.
To be successful, a project must have clearly defined and specific goals. When goals are very general,
like The project must increase sales turnover, the project manager is simply taking on an extremely
difficult task. For instance, the project is completed on time and within budget, and according to scope,
but the sponsor delays the launch of the product, to the detriment of sales. Whose fault is it that the
project didnt increase sales? The last thing any project manager wants is to get into an argument about
the contract or to take such issues to lawyers. It would be better to state The Project aims to increase
sales turnover of the automotive division within an 18 month period; from date of launch.
These goals must be agreed by all involved, so that everyone proceeds with same expectations. The
scope of the project must remain consistent, so that it achieves what it set out to accomplish. Whoever
agreed to the initiation of the project, usually the project sponsor should not need to make significant
changes to its scope or extent.
People who are key to the success of the project must commit their time to it, even if their involvement is
only on a part-time basis.
Element 2: Only Full Commitment is Acceptable

Learner Notes: Use team members to read established goals; ensure that these state when is intended.
Goals should be amended, If any comments are negative.
An enthusiastic, skilled and experienced team is vital to the success of any project. To achieve this, the
project manager must have sound people skills. However, it is even more important that each member of
the team knows exactly what is required from them, in terms of task, time and budget. As project
manager, it is his or her responsibility to develop the best team that they can, guide it in the right
direction, and ensure that members benefit from the experience. Choose the team carefully, get ongoing
support from the sponsor and other interested parties. This is crucial from the outset.
If you see that a demand needs to be fulfilled, do you respond to the companys customer by
initiating a project?
Do you approach management, the managing director, chairman or shareholders to initiate a
project?
Have you investigated whether there actually is a need for the project and are you confident
that all key role players will support you in this endevour?
Will the project be achievable? Why?
Page 62 of 283
Learner Notes: Project managers must learn to accept that change to any well-thought out plan will be
required.
Learner Notes: Project managers must, essentially, plan for any eventuality, or at least be prepared
for the worst.
Element 3: Planning
Learner Notes: Plans will have to be revised and improved at several stages during the project
management process.
For a project to run smoothly, the resources required must be determined, allocated and available prior
to the project commencement. There will be times when the resources will be available at the beginning
of each stage, which is acceptable. However, the author suggests that (in contract) it is stated that the
Stage will not commence until the resources have been made available.
This demands effective planning, taking into account not only people, but also facilities, equipment and
raw materials. A detailed, complete plan guides the project and it is this document that communicates
the project managers overall objectives, activities, resource requirements and schedules. It is also vital
that he or she keeps everyone, who is involved, fully informed of the plan and update them whenever it
changes.
Learner Notes: Always start with a sufficient budget and realistic time frame. This will reduce the
potential of the project being threatened later, because time or money has run out.
Be Flexible
In a rapidly changing global business environment, the ability to think ahead and anticipate risks, trends,
demand patterns and opportunities/threats can make the difference between achieving project objectives
or not. The professional project manager must be prepared to change his or her plans in a flexible and
responsive way.
It is unlikely that the original plan (as signed by the project manager and sponsor) will be the one taken
through to completion. At least, not without some changes being implemented along the way; since
circumstances and requirements generally change as the project unfolds. Take for example, the 1997
Emerging Market Crash. Suddenly, companies operating in developing countries had to rethink their
strategies. Now, image how the author felt when all his plans to assist a South African retailer to expand
into Africa had to change. The week before project closeout, the crash happened and all projects were
suddenly frozen. Without the ability to conduct research into countries that had little statistics, the project
would have, indeed, being killed.
Instead, the author used the opportunity to convince the sponsor to launch immediately and take an
advantage over their competitors. Not only did the company succeed in launching its satellite technology
in six African countries before competitors, but it also took the major slice (and has since held onto) of
the IT African market share. These strategies are well documented in the authors 2003 university MBA
text book Jungle Tactics: Global Research, Investment & Portfolio Strategy.
This means that the project manager must have plans and strategies to re-evaluate any plan and to
adapt an existing one accordingly: If a project is to succeed, the project manager must be able to
anticipate and recognise the need for change, implement it and measure its impact effectively.
THE PLANNING CYCLE: A STARTING POINT

The planning process is well set out in Chapters 7 to 15. For this section, therefore, a Planning Cycle
needs to be set out, which should bring together all aspects of planning into a coherent, unified process.
Page 63 of 283
By planning within this structure, the project manager will ensure that plans are fully considered, well
focused, resilient, practical and cost-effective. It provides for reviews, feedback and effective decision
making. The cycle will help the manager to plan and manage ongoing projects of any complexity. For
projects involving many people over a long period of time, more formal methodologies and approaches
are necessary; as set out in Stage 2 of this book.
Learner Notes: It is best to think of planning as a cycle, not a straight-through process.
Evaluating before implementation
Once the manager has devised a plan, that plan should be evaluate to determine whether it is likely to
succeed. This evaluation may be cost or number based, or may use other analytical tools. This analysis
may show that the plan may cause unwanted consequences, may cost too much or may simply not
work. This provides the manager with the ability to cycle back to an earlier stage and rethink the
strategy. Alternatively, he or she may have to abandon the plan altogether - the outcome of the planning
process may be that it is best to do nothing!
The Planning Cycle
The stages in this planning process are explained below:

Step 1: Analysis of Opportunities
The first thing to do is to assess and conclude what has to be done. This is the first step which acts as a
filter to effectively tell the project manager whether an idea can crystallise into a plan or not. The details
of the assessment will be formulated and detailed in Stage 2: Planning. One approach to this is to
Page 64 of 283
examine the companys current position, and decide how such a position can be improved. There are a
number of techniques that will help to do this:
SWOT Analysis: This is a formal analysis of your strengths and weaknesses, and of the
opportunities and threats that the client will face in future (See Appendices for SWOT Analysis
Template)
Risk Analysis: This helps the project manager to spot project risks, weaknesses in organisation
or operations, and identify the risks to which the company is exposed. From this, the project
manager can plan to neutralise some risks (See Chapter XXX for risk analysis).
o
Understanding pressures for change: For instance, competitor growth may force the
client to re-look at his or her company or the environment may be rapidly and
fundamentally changing. Pressures may arise from changes in the economy, new
legislation, changes in people's attitudes, new technologies or changes in government.
A different approach is to use any of a whole range of creativity tools to work out where
you can make improvements. These creativity tools are widely available.
Step 2. Identifying Clients Requirements (Aim of the Plan)

Once the project manager has completed a realistic analysis of the opportunities for change, the next
step is to decide precisely what the aim of your plan is. Defining an aim sharpens the focus of the plan
and helps the project manager to avoid wasting effort on irrelevant side issues.
The aim is best expressed in a simple single sentence.
If the project manager is struggling to formulate the aim of the plan, ask the following questions:
What do you want the future to be?

What benefit do you want to give to your customers?
What returns do you want?
What standards are you aiming for?
What values do you and your organisation believe in?
In listed companies, this aim can be presented as a 'Vision Statement' or 'Mission Statement'.
Vision Statements express the benefit that an organisation will provide to its customers. For
example, the vision statement for many retail firms is: To enrich our customers lives by providing
the best quality foods and food stuffs to help ease their daily lives. While this is wordy, it explains
what this site aims to do.
Mission statements give concrete expression to the Vision statement, explaining how it is to be
achieved. The mission statement for the above retailers site is: 'To provide a well structured,
accessible, easy to use and best pricing available in the South African retail market.
Step 3. Option Determination

By this stage the project manager must know what his or her options are, relative to the current position
of the firm. Therefore, the next thing to do is to work out how to undertake the project. Remember to
generate as many options as possible, even though it is tempting just take the first idea that comes to
mind. By taking a little time to generate as many ideas as possible, then project manager may come up
with less obvious, but better solutions.
Step 4. Selecting the Best Option
If time and resources are available, evaluate all options and carry out detailed planning, costing and risk
assessment for each. Normally, that is not possible. Two useful tools for selecting the best option are
Page 65 of 283
Grid Analysis and Decision Trees, which are both set out in the authors 2007 MBA text book The
Corporate Mechanic.
Grid Analysis helps the project manager to decide between different options where he or she
needs to consider a number of different factors.
Decision Trees help to think through the likely outcomes of following different courses of action.
Step 5. Detailed Planning

By the time planning is started, the project manager should have a good picture of what he or she wants
to achieve and the range of options available to them. Detailed planning is the process of working out the
most efficient and effective way of achieving the aim that has been defined. It is the process of
determining who will do what, when, where, how and why and at what cost. When drawing up the plan,
techniques such as use of Gantt Charts and Critical Path Analysis can be immensely helpful in working
out priorities, deadlines and the allocation of resources. These are set out in later chapters.
Remember that, in addition to the determined plan, the project manager must ensure that he or she also
thinks about the control mechanisms that they will need to monitor performance. These will include the
activities such as reporting, quality assurance, cost and time control. These will help to spot and correct
any deviations from the proposed plan.
A good plan will:
State the current situation.

Have a clear aim.
Use the resources available.
Outline the tasks to be carried out, whose responsibility they are.
Outline priorities and deadlines.
Outline control mechanisms that will alert the manager to difficulties in achieving the plan.
Identify risks and plan for contingencies.
Set out and implement rapid and effective response strategies to potential and real crises.
Step 6. Evaluate Plan and Impact

Once the details of the plan have been set out, the next stage is to review it to decide whether it is worth
implementing. While it is always difficult to be absolutely objective, use the team to comment on the plan.
It is, however, always better to quickly find out whether a plan is worth while or not; better than when
time, resources and personal standing in the success of the plan have been invested. Evaluating the
plan now gives the manager the opportunity to either investigate other options that might be more
successful, or to accept that no plan is needed or should be carried out.
Depending on the circumstances, the following techniques can be helpful in evaluating a plan:
Cost/Benefit Analysis: This is useful for confirming that the plan makes financial sense. This
involves adding up all the costs involved with the plan, and comparing them with the expected
benefits.
Force Field Analysis: This helps the manager to get a good overall view of all the forces for and
against the plan and allows the manager to see where he or she can make adjustments that will
make the plan more likely to succeed.
Cash Flow Forecasts: Where a project decision has mainly financial implications, such as in
business and marketing planning, preparation of a Cash Flow Forecast can be extremely useful. It
allows the manager to assess the effect of time on costs and revenue. It also helps in assessing the
size of the greatest negative and positive cash flows associated with a plan. When it is set up on a
spreadsheet package, a good Cash Flow Forecast also functions as an extremely effective model of
the plan. It gives you an easy basis for investigating the effect of varying assumptions, which is also
called what If Scenario planning.
Page 66 of 283
Learner Notes: Any analysis of a plan must be tempered by common sense.

If analysis shows that the plan will (or wont) give sufficient benefit, then either return to an earlier stage
in the planning cycle or abandon the process altogether.
Step 7. Implementing Change
Once the manager has completed his or her plan and decided that it will work satisfactorily, it is time to
implement it. The Stage 2: Planning section of this book will explain how. It should also detail the
controls that you will use to monitor the execution of the plan.
Step 8. Closing the Plan
At this point it is often worth carrying out an evaluation of the project to see whether there are any
lessons that you can learn. This should include an evaluation of the managers project planning to see if
this could be improved. It is likely that the manager will, in future, carry out many similar projects, so it is
worth developing and improving an Aide Memoire. This is a list of headings and points to consider during
future planning projects. Using it helps to ensure that lessons are not forgotten.
Key Conclusions to the Planning Cycle
It is a process that helps managers to make good, well-considered, effective plans.
The first step, the analysis of opportunities, helps to base the plan firmly in reality. The second,
definition of the aim, gives the plan focus.
The third stage is to generate as many different ways for achieving this aim as possible. By spending
time looking for these you may find a better solution than the obvious one, or may be able to improve
the obvious solution with parts of other ones.
Next, select the best approach, and make a detailed plan showing how to implement it. Evaluate this
plan to make sure that it will be worth implementing. If it is not, return to an earlier stage and either
improve the plan or make a different one. If no plan looks like producing enough benefit to justify the
cost, make no changes at all.
Once you have selected a course of action, and have proved that it is viable, carry it out. When it is
finished, examine it and draw whatever lessons you can from it. Feed this back into future planning.
The next chapter takes the process of defining the various Stages of project management to a
more in-depth level
Page 67 of 283
CHAPTER 4: DEVELOPING PROJECT

STAGES
There are almost as many stages to a project than there are books on the subject. Some authors
love to set out over 10 steps to a project. However, in its simplest form, there are four stages to
any project. Project management is the planning, monitoring and control of all aspects of a project. This
includes motivating those involved to achieve the objectives on time, and to cost and quality targets.
How these are placed into phases will, ultimately, depend on a project managers experience.
LETS RE-ITERATE
Knowing how students like to skip chapters, here are the four Stages to project management, as
advocated in this book:
Stage 1 - Initiate: In this first project management Stage, the preliminary work is done to clarify the
problem or opportunity that has presented itself to a client. The task is to evaluate the clients
aim/idea and assess how a solution would look. All project management and other interested parties
are consulted and the project is scoped. Essentially, a brief is written to ensure that all parties have a
clear understanding as to what the project is, as well as stating budgets and timelines.
Stage 2 - Plan: Before starting on the planning stage, it is normal to undertake additional work to
determine whether the proposed project will be of real benefit to the client and his firm. If it is
conformed that it will be beneficial for the client to undertake the project, approval is granted and
more detailed planning starts. Business benefits, project objectives, requirements, governance,
scope and project management methodology are agreed. The Project Manager draws up the
detailed project schedule and task and budget allocations.
Stage 3 - Execute: The issues outlined in the planning Stage are undertaken is a logical and formal
and agreed to manner. Customers are interviewed to ascertain trends and demand patterns, possible
solutions are discussed and one plan of action is carried out. Next, the solution is designed, built and
finally implemented. Project management activities in this stage also include managing the project
budget and schedule, reporting project progress, communicating with client, customers and
responding to project risks, issues and proposed changes.
Stage 4 - Completion and Evaluate: The purpose of this final stage is to determine whether the
project was a success and what learning can be gleaned and applied to future projects. Evaluation is
typically conducted in order to answer three questions:
o
o
o
Did the project deliver on time, within budget and to the signed brief and quality
requirements?
Were project team members and client satisfied with the project?
Did the project achieve the envisaged business benefits?
Adhering to the project stages ensures that everything is done in a logical and orderly manner. This way,
quality is checked and sponsor approvals are gained before the next stage of work is started. Re-doing
work is minimised, saving frustration and possibly significant costs.
THE FOUR STAGES OF A PROJECT

There are many different variations to creating project management stages. These are all based on the
same ideas and a common logical thread running through all processes. In fact, the same principles
apply whichever method is used. While the real meaning of using stages to a project is to provide a
Page 68 of 283
framework, the real success of a project depends on the skills and intelligence of the project managers
who carry out the stages.
The overriding factor to success is to choose a project management system that it is suitable for the size
of the project, so that the methods meet the needs of the organisation. It must be noted that a new
method can be difficult to get used to, so a good training programme is essential for the people involved.
The Four Stages of Project Management
The above four stages consist of a whole host of sub-categories, which will be set out in this book. Of
course, each of the above has numerous steps that have to be followed before the next stage can be
started. This is a basic fault that many project managers, who are keen to please their client, do. One
common mistake would, for instance, be to move to the planning stage before a contract is signed
stating that the project has been formally commissioned.
The sequence of activities, from commissioning the project through to its completion, is essentially the
same for every project, whether the project is simple or complex, large or small, involves a few people or
many people. A stage of a project constitutes a major set of activities that must be performed within the
project management process. These four phases are done in sequence, starting with initiation and
ending with close out.
Progression of Stages
Learner Notes: Each stage builds on the stages that preceded it.
If the project manager does a poor job during initiation, then the next three stages will suffer. Similarly, If
he or she does a poor job of planning, execution and completion will suffer. If the project manager fails
during the execution stage, the entire project will fail. Each stage ends with an approval process that
must be completed before moving on to the next stage. This keeps the manager from being enticed to
jump the process to complete the project quickly and below cost. Skipping ahead to the next stage
prematurely simply ends in disaster. The approval process should have a name, so that it becomes a
process rather than a theoretical exercise. Some project managers call this approval process Phase
Gates, or Stage Gates.
One of the benefits of having approvals at the end of each stage is that it minimises the cost of the
project, because project expenditure increases exponentially as you move from initiation to planning to
execution. The costs then drop off dramatically during completion stage. By making sure that all aspects
of a stage have been completed thoroughly and according to the scope, problems in the next stage are
minimised. Time is also saved.
Whenever time and budget is of the essence, it is critical to have a system to keep teams, management
and pressure groups from forcing the pace of progress. A system of check and balances such as go
and no-go decision gates, such as Stage Gates, should ultimately prevent serious problems form
Page 69 of 283
occurring before the project is completed. A worse scenario is for problems to occur after the project
manager has left. These decision gates are particularly useful when projects run into many months,
simply because people forget and a process can be easily skipped; even at the detriment of the overall
success of the project.
The approval for moving from one stage to another, or to pass through a stage gate should be part of the
organisations project management system, which is set up and maintained by the project manager, after
consultation with (and approval of) the sponsor.
Stage 1: Initiation
The first Stage, initiation, begins after the project is selected to be a project by the management team;
the sponsor for the company (the client) and the appointed project manager. The purpose of the initiation
stage is to provide direction to the project team about what should be accomplished and what constraints
exist. The output of the first stage is a document called a scope or brief. Some project managers
(espoused by some authors) call this a charter. The initiation phase is the responsibility of the sponsor,
but in most organisations, the project leader actually writes the scope document and then has the
sponsor approve it.
Learner Notes: Limits, constraints and project priorities are defined in the scope.
(Getting the project commissioned)
1: Initiation
STAGES
Steps
1. Project
feasibility
(based on
clients
needs) must
be proved
2.
Obtain
project
authorisation
Action
A document must be drafted to confirm that there is a need for the project
product/service to be delivered. Some project management books call this
item the deliverable.
The document must broadly describe:

o The deliverable.
o Means of creating the deliverable.
o Costs of creating and implementing the deliverable.
o Benefits to be derived by implementing the deliverable.
Decision Gate: A "go/no go" decision is made by the sponsor (on behalf of
the client).
A project manager is assigned.
A "project scope" is created which:
o Formally recognises the project.
o Is issued by the client to ensure that he or she can meet project
needs.
o Authorises the project manager to apply resources to project
activities.
3. Obtain
authorisation
to start the
Stage
Decision Gate: A "go/no go" decision is made by the sponsor, which

authorises the project manager to apply organisational resources to the
activities of a particular stage.
Written approval of the stage is created which:
o Formally recognises the existence of the stage.
o Is issued by the client so that the project manager can meet the
project needs.
Notes to the Initiation Stage

Before starting a project, time should be spent on understanding the size and nature of the task. This is
helped by:
Defining the project objectives clearly.

The client must identify a senior manager, who will have overall responsibility for the project; called
the sponsor.
Prepare a business case; the reasons for the project.
Define the scope; particularly setting out what the boundaries of the project are.
Page 70 of 283
Check resources; do you have the resources you need?

Identify risks
o Build a team
o Form a Project Board
o Create a Project Initiation Document (PID)
o Establish procedures for managing risks, issues, change and quality.
Once these have been thought through, it is a good idea to set up a workshop with the people involved
in the project in order to 'kick-start' the process.
Stage 2: Planning
The output of the planning stage is a project plan document, which a complete plan for how the project
will be executed. The sponsor must approve this document on behalf of the client.
During planning, the project manager (with the project team) develops a plan for how and when the
project will take place. There is no doubt that planning is the most critical stage of a project, because it is
in planning that decisions are made about who will do what and how to ensure everyone works together.
If the manager is not serious about the laborious process of planning and skips even part of this stage,
the important pieces of the project puzzle will be missed. As a result, he or she will end up with having to
re-work the plan, which is expensive, time consuming and frustrating. Experience highlights the
importance of properly planning a project to significantly improve the chances of success.
(Deciding on the best method to undertake the project)
2. Planning
STAGES
Page 71 of 283
Steps
Action
1. Describe scope
2. Define project
activities
3. Estimate time for
tasks and
resources
4. A schedule must
be developed
5. Estimate costs
6. Set up a budget
plan
7. Create a formal
quality plan.
8. Create a project
communications
plan.
9. Organise and
acquire staff
10. Identify risks.
11. Plan for and
Statement of project scope.

Scope management plan.
Work breakdown structure.
Set out a list of all activities that will be performed on the project.
Updates to the work breakdown structure.
Estimate time required for each activity and set out assumptions for each
estimate.
Updates to activity list
Project schedule in the form of Gantt charts, network diagrams, milestone
charts or text tables.
Supporting details, such as resource usage over time, cash flow
projections, order/delivery schedules, etc.
Cost estimates for completing each activity .
Supporting detail, including assumptions and constraints.
Cost management plan describing how cost variances will be handled.
A cost baseline or time-phased budget for measuring/monitoring costs.
A spending plan, telling how much will be spent on what resources at what
time.
Quality management plan, including operational definitions.
Quality verification checklists.
A communication management plan, including:
o Collection structure.
o Distribution structure.
o Description of information to be disseminated.
o Schedules listing when information will be produced.
o A method for updating the communications plan.
Role and responsibility assignments.
Staffing plan.
Organisational chart with detail as appropriate.
Project staff.
Project team directory.
A document describing potential risks, including their sources, symptoms,
and ways to address them.
Procurement management plan describing how contractors will be
acquire outside
resources.
12. Organise the

project plan
13. Close out the
project planning
stage
14. Revisit the project
plan.
obtained.
Statement of requirements describing the item (product or service) to be
procured.
Evaluation criteria.
Contract with one or more suppliers of goods or services.

A comprehensive project plan that pulls together all the outputs of the
preceding project planning activities.
A project plan that has been approved, in writing, by the sponsor A "green
light" or okay to begin work on the project.
Confidence that the detailed plans to execute a particular stage are still
accurate and will effectively achieve results as planned..
Notes to Planning
Planning helps to identify where potential problems could arise. Planning also helps to identify problems
early, when they will be easier to fix and stops resources being wasted on the wrong things. Good plans
reassure everyone involved that the work is under control and that the manager knows what he or she is
doing.
Important issues:
Split the work into manageable stages.
Decide what deliverables will be created for each stage.
Identify milestones, which helps to keep the project moving forward and according to plan. This also
provides a measure of progress.
Estimate how much time each deliverable will take to achieve.
Identify any deliverables that are dependent on each other.

In what order are the deliverables achieved?
Can some be achieved at the same time as others?
Do some have to be achieved before another can start?
Can some only start on a fixed date?
Identify who will carry out the work involved.
Are there sufficient resources to make the plan work?

To support the scheduling of these, tools such as Gantt charts and critical path analysis can be useful.
This planning process enables tracking, reviewing and reporting on project progress, and re-planning as
necessary.
Stage 3: Execution
After the project plan is approved, the plan must then be executed.
During the execution phase, the work of the projectcreating the deliverables is done. To make sure
the work is on track, the project manager monitors project progress, and if required, recommends
changes to the project plan. The team also communicates project progress to the manager. At the end of
the execution phase, the final deliverable is delivered to the sponsor and, ultimately, the client.
Page 72 of 283
(Managing the team, monitoring

progress and controlling events)
3. Execution
STAGES
Steps
Action
1. Execute
project
activities.
2.
Control
project
activities.
Work results (deliverables) are created.

Change requests (i.e. based on expanded or contracted project) are
identified.
Periodic progress reports are created.
Team performance is assessed, guided and improved if needed.
Bids/proposals for deliverables are solicited, contractors (suppliers) are
chosen and contracts are established.
Contracts are administered to achieve desired work results.
Decision to accept inspected deliverables.
Corrective actions such as re-work of deliverables, adjustments to work
process, etc.
Updates to project plan and scope.
List of lessons learned.
Improved quality.
Completed evaluation checklists (if applicable).
Notes to Execution
A project that is underway is not immune to failure. There still is much to be done before success can be
declared. Project managers should:
Monitor progress and check the quality of the work.
Avoid unnecessary change ('scope creep').
Manage the risks that have been identified.
Regularly review plans, risks, assumptions, constraints, issues and other relevant matters.
Make sure the project team is supported and kept informed.
Maintain regular contact with key people.

Stage 4: Completion
After the client accepts the final deliverable, the close-out stage begins. In this stage the client evaluates
his or her satisfaction with the project. The sponsor and the team also do project evaluations. Then the
team discusses what it learned from the project and translates these lessons into recommendations for
improving the organisations overall project management system.
A final status report on the project is issued and included in the final project report, also known as the
close-out report. This report is sent to the sponsor, client and key stakeholders. When the completion
report is complete, the project is over. But, its important to remember to celebrate, not only at the end of
the closeout stage, but throughout the project, whenever the team has accomplished something
important.
Page 73 of 283
(Wrapping up the Project)
4. Completion
STAGES
Steps
1. Close out
project
activities.
Action
Formal acceptance, documented in writing, that the sponsor has accepted

the product of this stage or activity.
Formal acceptance of contractor work products and updates to the

contractor's files.
Updated project records prepared for archiving.
A plan for follow-up and/or hand-off of work products.
Notes to Completion
The project should be formally closed to ensure that:
The client is content that all elements of the work are satisfactorily achieved.
Any work to be carried on in an operational environment is well-defined and has a clearly defined
client.
Documentation and other paperwork is up -to-date and stored appropriately.
Any further actions and recommendations are documented and distributed.
A post project review is planned. This is a post mortem of the project.
A report of the lessons learned is produced and distributed.

Start with a burst, end positively; and recognise the different techniques and skills required to
negotiate the four key stages of project management.
Learner Notes: Make an issue of a new project so that people know it is happening.
Despite every book stating that teams should be brought together quickly, many sponsors still dont;
believing that the project manager can introduce himself or herself to the team at some later stage.
Experience suggests that a formal introduction has a far more powerful influence over the team and
the project managers ability to lead that team effectively.
It is important to start off on a good footing, so the sponsor should be positive and stress the
importance of working together as a team, under the leadership of the project manager. Now that the
stages of project management have been defined, Chapter 5 looks at how to assess the viability of a
project.
Chapter 5 assesses project viability.
Page 74 of 283
CHAPTER 5: ASSESSING PROJECT

VIABILITY
Before starting down the road of project management, the appointed project manager and his or
her team must determine whether there is a good chance that the project will be successful. He
or she must take the relevant steps to find out whether a project is feasible in terms of time,
budget and quality. Will the project, in effect, benefit the sponsor, client and the company? The
project manager must, therefore, determine whether the project is worthwhile before going ahead
with it.
DESIRABILITY IS NOT VIABILITY

At this stage of project development, it would seem obvious that the project manager has at least a
committed sponsor, who has vision, goals and a project scope that is realistic and reasonable.
Unfortunately, that is often not the case, with the sponsor confusing a desire to achieve a deliverable,
with the ability (realism) of achieving that deliverable. However promising and desirable a project may
seem, the project manager must always carefully examine whether time, funds and ability to succeed
in a project are possible. Remember that in reality, the project manager will have a number of projects
to choose from at any one time. Would it is better to choose a project that has an 80% chance of
success, or a really exciting one that only has a 10% chance of success?
Learner Notes: The project manager must be sure that he or she is undertaking a task that can be
achieved.
Learner Notes: Assess areas where a project could fail.
The answer should be to take on a project with an 80% chance of success, but that is not always the
case. Some project managers will take on high risk projects, if the risk-to-reward ratio is high. Such a
scenario is possibly for another book, but in the fair and realistic world of project management, always
assess and reassess the viability of success.
Example: Two Projects, One Solution?
In 1991, the author was simultaneously offered two possible projects. The first was tom conduct a
hostile bid for a Cape Town company on a Johannesburg-based group. The chance of success
was less that 15%.
The second project was the analysis of the oil industry in Cape Town for the UK-based Petroleum
Economist. The task involved many interviews, surveys and research. Success rate was higher
than 90%.
During the early 1990s, internet and cellular phones didnt exist, so reports, surveys, interviews,
research and negotiations all had to be done in person.
The first project was a lot more exciting and offered the possibility of sharing in the spoils of war,
so to speak. The second was certainly more sedate and the reward as boring.
Faced with the same choice, a project manager should choose the one that has the highest
probability of success. In reality, though, a highly skilled project manager would choose both. The
higher rate of success would be managed by the project manager, but a team would undertake the
leg work. The same project manager would take control of the first, heading negotiations, backed
by a team of consultants, such as forensic auditing and a legal team.
Page 75 of 283
Faced with the same choice, the author did do both and, as expected, the takeover didnt
materialise, while the petroleum report was completed and used in the Petroleum Economist.
Take into account other projects that have already started. Some organisations have so many projects
in place that it is not possible for them all to succeed, so the project manager must consider either
cancelling high risk projects, or at least postponing those that are unlikely to produce valuable results.
Since all projects require access to limited or even scarce resources, it is vital that each has a clear
reason for existing and that now is definitely the right time for it to happen.
BASIC INITIAL DETERMINANT: IS THE PROJECT VIABLE?

Rule of Thumb: 80/20
Every project manager will eventually face the problem of having to make a quick decision (without time
to undertake full analysis) on whether to accept appointment to undertake a project. The 80/20 rule then
must apply. This is simply a means of making a decision on as much information as possible, using a
rule of thumb: if the project looks likely to succeed, based on available information, skills and experience
and an 80% positive chance relative to a 20% negative possibility, the answer is yes. Accept
appointment and then undertake the relevant analysis to determine whether the project is viable or not.
Leaner Notes: The 80/20 rule is a means to determine whether the project manager is interested in a
project. It is not to determine whether a project is viable.
The 80 side of the rule
Every project is driven by the needs of the client, sponsor and the company.
The stronger the need to have something done, changed or sold, the more likely the project is to
succeed.
If, for example, a project involves winning back lost customers, the driving force is very strong.
To create an 80-rule list, or reasons why the project manager should accept the appointment, decide
whether the project could have a benefit (positive) on the overall company. Secondly, decide whether
the benefit will be more than other projects offered.
For example, if two projects are offered that should increase sales, then the 80-rule is to choose the
one that will have the highest sales.
The 20 side of the rule
There are always reasons why projects may not be completed.
Such forces include the real resistance that people have to change, the weight of the current
workload, lack of information or resources, skills levels and experiences.
There is no point in accepting a project if the majority of the project is finding people with specific
skills which are not available in the country where the project will be established.
Identify these resisting forces so that a decision can be made: do you accept the appointment.
A strong 20 side of the rule usually involves trying to change the way people carry out their jobs. If
people view a project as simply another management initiative, it will take great skill to motivate them
to make it happen.
Project managers are limited in the number of projects that they can take, even if many
consultants can back up the project manager. Consider if there are any ongoing projects
with a higher priority than the one being offered, and are there key resources available if
the project can be taken up.
Does the project meet the ideals and visions of the project manager? For instance, if the
project manager refuses to work in a particular industry, then all projects involving that
industry would be part of the 20-Rule.
Is there a chance that a new project will positively influence the performance of the
organisation?
Could this project damage the chances of another project being successful?
Page 76 of 283
Learner Notes: Examine whether a given schedule is realistic.

The following can be used independently, as a filter system or in combination.
1. Cost-to-Benefit Analysis
Cost-to- Benefit Analysis is a simple and widely used technique for project managers deciding whether
to make a change. As its name suggests, you simply add up the value of the benefits of a course of
action, and subtract the costs associated with it. Costs are either once-off or ongoing. Benefits are most
often received over time. The effect of time is built into analysis by calculating a payback period.
Definition: This is the time it takes for the benefits of a change to repay its costs. Many
companies look for payback on projects over a specified period of time e.g. three years.
In its simple form, cost benefit analysis is carried out using only financial costs and financial benefits. For
example, a simple cost benefit ratio for a road scheme would measure the cost of building the road and
subtract this from the economic benefit of improving transport links. It would not measure either the cost
of environmental damage or the benefit of alternative travel. A more sophisticated approach to building a
cost benefit models is to try to put a highly subjective financial value on intangible costs and benefits.
As this section of project development is merely a decision process to determine the viability of the
project, the author suggests a simple decision making methodology. Where large sums of money are
involved, project evaluation can become an extremely complex and sophisticated art; as explained in the
authors 2003 MBA text book Jungle Tactics.
Example:
An upmarket vehicle sales executive has to decide whether it would be beneficial to implement a new
computer-based contact management and sales processing system. The company has only a few
computers, and the sales team are (largely) not computer literate. Basic research indicates that
computerised sales forces around the world are able to contact more clients and give a higher quality
of reliability and service to those clients. While it may sound obvious, the executive has to make a
decision: does he buy more computers in the hope of higher sales? Does he know that computers
will do the same for his company? He is also aware that it takes training to get staff to be computer
literate.
His financial cost/benefit analysis is shown below:
Page 77 of 283
Costs
Benefits
New computer equipment:

o 10 network PCs with supporting
software @ R2,450 each
o A server @ R3,500
o Three printers @ R1,200 each
o Cabling & Installation @ R4,600
o Sales Support Software @ R15,000
Training costs:
o Computer introduction: 8 people @
R400 each
o Keyboard skills: 8 people @ R400 each
o Sales Support System: 12 people @
R700 each
Other costs:
o Lost time: 40 man days @ R200/day
o Lost sales through disruption: estimate:
R20,000
o Lost sales through inefficiency during
first months: estimate: R20,000
Total cost: R114,000
Tripling of mail shot capacity: estimate: R40,000

pa
Ability to sustain telesales campaigns: estimate:

R20,000 pa
Improved efficiency and reliability of follow-up:

estimate: R50,000 pa
Improved client service and retention: estimate:

R30,000 pa
Improved accuracy of client information: estimate:

R10,000 pa
More ability to manage sales effort: R30,000 pa
Total Benefit: R180,000 pa
Payback time: R114,000/R180,000 = 0.63 of a year = approx. 8 months

The payback time is often known as the break-even point. Sometimes this is more important than the
overall benefit a project can deliver. Break even occurs at the point the two lines cross. Inevitably, the
estimates of the benefit given by the new system are quite subjective. Despite this, the executive is very
likely to introduce it, given the short payback time.
Key points:
Cost-to-Benefit Analysis is a powerful, widely used and relatively easy tool for deciding whether to
accept a proposal, change current work methods or introduce new operations..
To use the system, firstly work out costs and then calculate benefits.
Where costs or benefits are paid or received over time, work out the time it will take for the benefits
to repay the costs.
Cost-to-Benefit Analysis can be carried out using only financial costs and financial benefits. The
project manager may, however, decide to include intangible items within the analysis.
Larger projects are evaluated using formal finance/capital budgeting, which takes into account many
of the complexities involved with financial Decision Making. This is a complex area and is thus not
included in the scope of this book.
The literature on cost-to-benefit analysis is vast and the techniques that can be applied in order to
undertake such analysis range from complex statistical analyses to simple cost projections. The
purpose of this chapter is to suggest some of the key headings and areas that can be considered
when undertaking a cost-to-benefit analysis, rather than to prescribe a single approach. The
approach and level of detail will vary with the size and complexity of the project.
The structure of a Cost-to-benefit analysis could include the following:

Page 78 of 283
Describe the business case: An outline for the reasons for the change should be made and
any internal or external reasons for the changes highlighted. Common reasons could include
obsolescence, change in legal requirements etc.
Describe the proposals or alternatives under consideration: This analysis should describe
the proposals being put forward and identifying the major risks affecting the proposals. A
continue as or no change option should be included together with the associated costs. Any
options that have been ruled out and deliberately excluded may also be considered together with
the reasons for eliminating them. A description of the current situation which is going to be
changed by the proposal should be outlined.
Outline of benefits and costs: The following points can be considered:

o
A description of the benefits of each of the options considered should be provided with as
assessment of the costs. It is difficult to quantify some benefits and, if this is the case,
then it may be better to include these as part of the business case.
As this analysis usually deals with the future and, therefore, is based on judgement, any
assumptions that underlie the calculations should be stated clearly. These may relate to
inflation factors, productivity savings, development costs or supporting infrastructure.
Quantify costs and benefits for each option, including start up and on-going costs.
An outline of the risks associated with the realisation of any costs or benefits.
Layout. Computations should be presented in table format to facilitate comparisons.
Avoid the temptation to oversell the benefits.
Benefit Realisation Plan: State timeframes, budgets and what has to be done to realise the
benefits.
2. Force Field Analysis

A useful technique, known as force field analysis, will help the project manager to decide whether the
driving forces outweigh the resisting forces, and, consequently, whether the project has a reasonable
chance of success. By creating such analysis, the manager will be able to see at a glance whether the
balance is weighted toward success or failure. To assess the relative impact of each force, remember
that drivers range:
One = a weak driver

Five = essential need.
Minus one = a resisting force that is not much of a threat to the success of the project
Minus five = a force that is very strong, and that, unless you can minimise its impact, is likely to
hinder you in achieving the desired project results.
Create a simple diagram, such as the example below, to compare dining and resisting forces. List the
driving forces against a vertical grid, and give each column a number between one and five. Do the
same with the resisting forces but give them a negative measurement.
Force Field Analysis is a useful technique for looking at all the forces for and against a decision. In
effect, it is a specialised method of weighing pros and cons. By carrying out the analysis the project
manager can plan to strengthen the forces supporting a decision, and reduce the impact of opposition to
it. See Magliolos 2007 MBA text book Corporate Mechanic for a full outline of Forced Field Analysis and
go to www.magliolo.com to download the tool.
Page 79 of 283

Forced Field Analysis
To carry out a force field analysis, follow these steps:
Describe the proposal in the middle of the diagram (under PLAN).
List all forces for change in one column, and all forces against change in another column.
Assign a score to each force, from 1 (weak) to 5 (strong); next to the black arrows.
Once you have carried out an analysis, the manager must decide whether the project is viable. In the
case of a project already being commissioned, Force Field Analysis can help to work out how to improve
its probability of success. Here you have two choices:
Reduce strength of forces opposing a project, or

Increase forces supporting a project.
Often the most pertinent solution is the first: just trying to force change through may cause its own
problems. People can be uncooperative if change is forced on them.
Key points:
Force Field Analysis is a useful technique for looking at all the forces for and against a plan. It
helps the manager to weigh the importance of these factors and decide whether a plan is worth
implementing.
Where a plan has been have decided on, Force Field Analysis helps to identify changes that
could improve it.
3. Cash Flow Forecast

The true meaning of Cash Flow is the recording of cash movement within a project or company. If it can
be assessed how cash is earned or spent, then a prediction can be made as to whether sales or income
will cover the costs of a new operation. They also allow the project manager to analyse whether a project
will be sufficiently profitable to justify the effort put into it. For the project manager trying to decide
whether a project is worth supporting, cash flow is useful to make quick financial decisions. For instance,
a project may have capital funders, but poor cash management will quickly dry up those sources. By
carrying out a Cash Flow forecast on a spreadsheet package, the project manager can investigate the
impact of changing factors within the forecast. This type of what if capability can be used very
Page 80 of 283
effectively to plan basic to more complex projects. A properly structured spreadsheet enables the user to
see, more or less instantly, the effect that cash flow changes will have on a project.
The norm is to structure Cash Flows as tables. On this table, the project manager uses columns for each
period (normally a month) within the forecast. Rows show individual cash movements such as sales of a
product, sales costs and particular expenses. This forecast table is created in three stages; set out
below:
Cash Flow Forecast Stage 1. Set Up Column Headings: The project manager must decide on the
period of time over which to run the forecast, and the length of the periods within it. Typically, the
forecast will run over 1-2 years, with the periods as months. Head up one column with the title 'Cash
Movement'. Then enter the periods of the forecast as the next column headings. This will provide column
headings of, for example, Cash Movement, January, February, March, April. etc.
Cash Flow Forecast Stage 2. Set Up Row Titles: Rows are organised into three main groups:
Income: These rows show income expected during the period. It is recommended that a
separate row is set up for each source of income. Where costs of operation are directly
dependent on the amount sold, it can be decided to deduct the direct cost of the sales made
within this group of rows. Put in a subtotal at the bottom of the group.
Expenses: These rows show all of the costs and should be itemised by the type of cost. Set up a
subtotal at the bottom of this group.
Totals: The next row shows the total of the income rows minus the total of the expenses rows for
the month. This shows the profit or loss for the month.
Underneath this, put in a running total. In this row add your profit or loss for the period to the previous
running total. This shows your financial position at the end of the period.
Cash Flow Forecast Stage 3. Estimate values: The table is set to input values. When you are entering
projections for sales for a new business, bear in mind you will not sell much until your clients have seen
mention of your business several times (often over 10 times). The estimates for sales will be much more
reliable if it is based either on previous years' revenues or on in-depth market research. The sponsor
cannot argue with the project manager is research indicates a general sales growth trend of 15% and the
project manager uses a mean growth rate of 12%.
When entering values for costs, try, where possible, to base projections on costs from previous years. If
this is not possible, base estimates on real prices quoted to keep estimates as realistic as possible.
Calculation: On most modern spreadsheet packages this will happen automatically, providing the
project manager has set up totals correctly. As changes are made within cells, it can be seen that the
period totals and running totals change appropriately.
Learner Notes: Cash Flow Forecasting is a relatively simple technique for checking the viability of a
project.
JUSTIFICATION FOR THE PROJECT

After having conduced reasonable assessment to decide whether to accept appointment to a project, the
next step has to be defined. Normally, the next step would be to assess whether it is justifiable to
undertake a project. To justify a project, the project manager has to define the scope, costs and benefits
of what he or she is proposing, and make sure that all interested parties are aware (and approve) of
them. Otherwise, the project is out of control from the start.
Page 81 of 283
The next steps are:
The project manager must make sure he or she knows the background to the project, who is
affected, what is expected, what will it cost and how long will it take.
It is recommended that the project manager meet the client, sponsor, manager and staff. Sometimes,
a project is just never going to get off the ground. This is not an analytical assessment, but rather a
sense that is developed over time; one that can stand the project manager well when assessing
people, projects and potential non-analytical issues.
Assess costs and benefits.
Estimate resources required to deliver what the sponsor requires.
Produce a Project Proposal.
Present the proposal for approval.
What happens next?
The project will be approved or rejected.
A Project Board may need to be set up.
A budget is needed.
A Project Manager will be appointed.
Before presenting a proposal for approval, the project manager must ask him or herself if they would
approve it if it had been written by someone else. The following template should help:
Page 82 of 283
BASIC PROJECT PROPOSAL DOCUMENT - TEMPLATE
Document Identification
Title, sponsor, author, version number
Background
o Current situation, related projects, known constraints and dependencies, any other projects
dependent on this project.
Objectives
o The aims of the project
Benefit Statement
o The business case an itemised list of tangible and intangible benefits.
Scope
o Definition of what the project includes it may also be necessary, for clarity, to identify items
which the project does not include
Deliverables
o List of what will be produced by the project.
Assumptions and Constraints

o Clearly identify any assumptions or known constraints e.g. resource issues, deadlines
which are statutory, etc
Estimates
o Outline of tasks with estimates of costs, resource needs and anticipated timescales.
For a more comprehensive template see Appendices
In the last chapter of Stage 1, projects have to be prioritised with schedules.
Page 83 of 283
CHAPTER 6: INITIATION & SCHEDULES

In reality, project managers have to handle a wide number of projects simultaneously, ranging in
industry, complexity and funding. In addition, he or she may be handling several projects for the
same client. Therefore, the manager must evaluate which project is the most important to the
client and his or her organisation. The manager does this to allocate time and resources.
Schedules are used to prioritise time and resources effectively.
PROJECT INITIATION
Learner Notes: Projects must be prioritised to avoid confusion, conflict and financial problems during
later stages of a project.
Learner Notes: The project manager must ensure that his or her appointment aligns with the clients
organisational priorities.
Before anything else is done and time and money wasted there is a need to have a project initiation
stage to determine, i.e. it is a stage that may seem like a waste of time, but project initiation sets the tone
that the project manager is serious about the management of a project.
Project Initiation begins when the Project Justification process (see Chapter 5) has been completed. It is
the process of making sure that a project starts in a planned and controlled manner. It is a truism that a
project that doesnt start under control, unravels quickly during the early stages of project management.
To achieve control, the manager must make sure that scope, costs and benefits of the project are
clearly defined. All interested parties must understand them.
As stated in the previous chapters, the project manager (with his or her team) should have assessed and
attained approval for the project. In many cases the project manager will have drafted a budget, an
indicative time frame and, more importantly, ensure that the promised resources have been allocated by
the client.
If resources are not available, then the justification stage (previous chapter) has not worked properly.
First documents
Two options exist:
Produce a Terms of Reference for the project.
Produce a Project Initiation Document.
Produce a Project Proposal.

It is up to the project manager to decide which document to use, but experience dictates that clients
seem to prefer a Project Initiation Document for major projects and a Terms of Reference for lesser
important projects. Whichever document is used must be completed seriously as it does set the tone
for the project. In addition, the document forces the manager to define how the project will be carried out,
how it will be managed, what its objectives are, how its success will be measured and what the potential
constraints (financial or resource) will be. A Project Proposal is often used as synonymous to the
initiation document, but is actually a more formal document, which sets out more detail and often focuses
on the financial aspects of a project.
More Approval
The document also requires an approval process. In this case, the project management team, client,
sponsor and customers clients should all be consulted.
Page 84 of 283
PROJECT INITIATION DOCUMENT TEMPLATE
Introduction to the Project

Background, Business Case and Benefits
Project Definition and Assumptions
o
Objectives
o
Scope
o
Constraints
o
Exclusions
o
Deliverables and Outcomes
o
Other Reference Data
Project Organisation Structure and Roles and Responsibilities
Project Quality Plan
Project Plan
o Gantt chart
o Breakdown of deliverables (within the chart)
o Flow of deliverables
o Key Stakeholders
o Resource Allocation
Project Controls
Exception Process
Risks
Contingency Plan
Project Filing Structure
REQUIREMENTS CAPTURE
This is the process of identifying and documenting project requirements in line with the needs of the
client. The goal of the process is to manage the identification, gathering, prioritisation, processing,
validation and tracking of requirements.
Requirements Capture will commence once there is an approved project proposal document - either a
Terms of Reference, a Project Proposal or a Project Initiation Document. The main activities are:
Determine the feasibility of the requirements defined so far in the project proposal document and
examine any options or trade offs, e.g. where there are a number of ways of addressing
particular needs.
Identify and document the functional and non-functional requirements.
Analyse the requirements to ensure consistency and lack of ambiguity.
Verify the requirements.
Define the acceptance criteria at this stage, to ensure that the requirements can be tested.
Evaluate alternative strategies to ensure the requirements can be fulfilled.
Depending on the type of project it is and the amount of resources required, the approval process may
have to involve the companys business manager. Once the resource requirements are approved, the
project manager can move into the control stage of the project.
Page 85 of 283
There will be times when a project needs to be tested before additional resources are allocated, such as
the launch of a new computer system or call centre. The intention is to test the system to ensure that the
deliverable is attainable. This means that, simply, the client wants to be sure that the system will work
before spending millions of rands. There are two effective methods:
Proto-typing: This is a technique of developing a system quickly, without full functionality and
demonstrated to confirm the feasibility of an approach. The aim is to convince the client that if the
approach can work without full development then it confirms that the identified requirements are, in
fact, valid. A prototype systems should never be implemented. By definition it is a trial system and is
generally discarded and development begins again from scratch.
Piloting: This is the technique whereby a fully developed system is tested out in a single area before
becoming generally available to all system users. For example, a system might be run on a pilot
basis in one faculty before being implemented throughout the university.
SCHEDULING PROJECTS
Assuming that the project initiation document is accepted and the project manager has been appointed,
what happens next? In fact, before starting a new project, the project manager must consider how many
people and what resources will be needed to meet its objectives. The aim is to deploy the organisation's
resources to projects that offer the greatest value in their results. The more complex the project, the
more important it is to seek the opinion of others before you prioritise.
Learner Notes: A failure to prioritise, however, leads to disorganisation, resulting in none of the projects
achieving their intended value.
The creation of schedules help project managers to you decide early on how best to tackle a variety of
projects. The easiest is to create a form known as a master schedule. At this stage, the manager will not
need to identify resources in detail, but in simple estimates. This is done to enable the manager to see
where there are potential resource clashes between projects and confirm (or deny) the feasibility of a
new project. If, for example, two projects require a crane at the same time, and the manager only has
one available, one project must be rescheduled to ensure that the crane is available for both.
MASTERSCHEDULE
Jan
Feb
March
April
May
June
1
2
1
2
2
2
3
3
6
4
5
5
1
2
1
1
2
1
1
2
1
3
2
1
3
2
1
3
2
1
Project1
Project2
Project3
Project4
Resources
Projectmanager
Financial
consultants
LegalConsultant
Strategist
Creating A Master Schedule: Create a series of monthly (or; for complex projects, weekly)
columns running to the right of the form. List all your ongoing projects and, underneath, detail
the resources (people, equipment, materials) you think you are likely to need
Accurate Time Forecasting

Page 86 of 283
This section discusses how to estimate time when managing projects. Accurate time estimation is an
essential skill to good project management for two main reasons:
Time estimates drive the setting of deadlines for delivery of projects and, consequently, will affect
peoples' assessments of your reliability.
Time estimates often determine the pricing of contracts and, therefore, their profitability.
Generally, people vastly underestimate the time needed to carry out tasks, especially if they are not
familiar with the task to be carried out. Often, this is simply due to inadequately accounting for
unexpected events, unscheduled high priority work or by simply failing to understand the full complexity
involved within a particular job.
Learner Notes: The first stage in estimating time accurately is to fully understand what you need to
achieve.
This involves reviewing the task in detail, so that there are no unknowns. Inevitably, it s the difficult to
understand, tricky problems that take the greatest amount of time to solve.
Key points:
Project managers can lose a great deal of credibility by underestimating the length of time needed to
implement a project. If time is underestimated, not only are deadlines missed, the entire team is
placed under unnecessary stress. Projects will become seriously unprofitable, and other tasks cannot
be started. Often, the problem is not one of inaccurate time scheduling by the project manager, but
rather his or her competing for the project; lowering their prices and reducing timeframes.
The first step towards making good time estimates is to fully understand the problem to be solved.
The next step is then to prepare a detailed list of tasks that must be achieved, which should include
all the administrative tasks and meetings that must be carried out as well as the work itself.
Finally, allow time for all the expected and unexpected disruptions and delays to work that will
inevitably happen. In South Africa, there are many public holidays, which turn into entire weeks
where consultants, suppliers, researches et al are not available and, therefore, the project slows
down.
The best way to review the job is to list all tasks in full detail. Simple techniques such as Drill Down
are useful for this.
Drill Down
Drill Down is a simple technique for breaking complex problems down into progressively smaller parts.
To use the technique, start by writing the problem down on the left-hand side of a large sheet of paper.
Next, write down the points that make up the next level of detail on the problem a little to the right of this.
These may be factors contributing to the problem, information relating to it, or questions raised by it. This
process of breaking the problem down into component parts is called 'drilling down'.
For each of these points, repeat the process. Keep on drilling down into points until factors contributing
to the problem are identified and understood. If you cannot break them down using the knowledge you
have, then you need to carry out whatever research is necessary to understand the point. Drilling into a
question helps to get a much deeper understanding of it.
Key points:
Drill Down helps to break a large and complex problem down into its component parts, so that a plan
can be developed to deal with these parts. It also shows which points must be researched in more
detail.
Page 87 of 283
Once a detailed list of all the tasks is set out, the project manager must make a best guess at how
long each task will take to complete. The project manager must allow time for project management,
detailed project planning, liaison with outside bodies, meetings, quality assurance and any
supporting documentation necessary.
There must also be time for:

o
o
o
o
o
o
o
o
o
Other high urgency tasks to be carried out which will have priority over this one.
Accidents and emergencies.
Internal meetings.
Holidays and sickness in essential staff.
Contact with other clients, perhaps to arrange the next project.
Breakdowns in equipment.
Missed deliveries by suppliers.
Interruptions.
Quality control rejections.
If the accuracy of time estimates is critical, the project manager may find it effective to develop a
systematic approach to including these factors. If possible, base this on past experience.
Scheduling Simple Projects
Simple projects usually involve a few people over a short time. Typically, simple projects will have few
tasks dependent on other tasks and will be relatively simple and easy to coordinate. Examples might be
coordinating delivery of resources for a workshop session, implementing a small marketing plan, or
delivering a simple software enhancement.
With simple projects, tools like Gantt Charts and Critical Path Diagrams may over-complicate project
scheduling and communication. Unless project team members are trained in their use, they can often
lead to poor communication.
Appropriate Timetables and Action Plans are often sufficient to coordinate and implement simple
projects. These should be explained and negotiated with project staff to improve the plans and get staff
understanding, input and buy-in.
Another method the Action Plan, which is a simple list of all of the tasks that must be carried out to
achieve the objective. It differs from a To Do list in that it focuses on the achievement of a single goal.
Drawing up an Action Plan helps to think about what must be done to achieve the goal. It also ensures
that the project manager gets the appropriate help where need and keeps the project running on time
through monitoring your progress.
To draw up an Action Plan, simply list the tasks that are needed to achieve the goal. This is very simple,
but is still very useful. Keep the Action Plan with you as you carry out the work and update it as you go
along with any additional activities that come up.
Key points:
Simple projects are often best run using simple Timetables and Action Plans. These should be
prepared and negotiated with project staff to get buy-in and progress the plans.
During the project the action plan will contain sufficient control points and deliveries to monitor project
progress and take any appropriate remedial action.
An Action Plan is a list of things that you need to do to achieve a goal. To use it, simply carry out
each task in the list.
An Action Plan will often be enough to create a work back schedule, starting from the date by which
the project must be completed, and listing all of the tasks in reverse order with due dates for each.
Page 88 of 283
Whatever the size of a project; ensure that you have agreed its scope with the person who wants it
done, before you start planning. This will help you to resist changes to its scope known as "scope
creep", which will seriously affect your plans, once you have started working.
Final check before moving to the next phase
END OF STAGE 1 CHECK-LIST

Project Checklist
1
Is the project in line with the strategic plan?
2
Has the project sponsor been identified?
3
Have project scope and objectives been defined?
4
Is the Business Case in place?
5
Is an options appraisal necessary?
6
Has a Project Initiation Document (PID) been completed?
7
Has a project manager been appointed?
8
Does the project team have the correct mix of skills and professional
experiences?
9
Are project jobs clear and documented?
10 Are levels of authority clear?
11 Has the project infrastructure been set up?
12 Has a stakeholder analysis been carried out?
13 Is there a need for a partnership agreement?
14 Have clear project management processes been set up?
15 Has a risk management system been set up?
16 Are there clear procedures for managing issues and changes?
17 Are there clear procedures for managing project quality?
18 Have project review procedures been set up?
Comments
IF CHECK-LIST CONFIRMS THAT THE STAGE IS COMPLETE
STAGE
1
2
3
4
Page 89 of 283
PROJECT
Initiation
STATUS
Planning
Execution
Completion
STARTING
To be completed
To be completed
Move to:
CASE STUDY COMMENTARY: STAGE 1

(Download documentation from www.magliolo.com)
Magliolo had a history with Carver B Consultants, the company wanting to list. For four years, the
parties communicated over industry related issues. When the owner of the consultancy, Steve, believed he
was ready to list he invited Magliolo to present a listing strategy to him and his team . He also wanted
Magliolo to present to the owners of the company with whom he wanted to merge.
Uncertainties included the nature of the proposed merger, the industry, which had obviously changed in
the four years since the original advice had been given.
As per the Guerrilla Principle, Magliolo appointed a team At Risk to assist in the Research and Due
Diligence of the industry and companies. The process took three weeks, but the result was staggering.
The team consisted of a designated advisor (stockbroker who lists companies on AltX), an accounting
forensic expert and an advocate, who deals in consultancies and, in particular, the mechanical
engineering industry.
Among the host of findings, which was made part of the presentation to the two companies, was:
The two companies erroneously believed that there were only five main competitors in the market.
There were in fact 28 main competitors and a host of smaller one. They had omitted foreign
companies looking at South Africa for growth as potential competitors.
The two companies did compliment each other, but the directors didnt. There would be problems in
gaining one directors trust he didnt understand why the two companies had to merge and list.
The accounts consultant found inconsistencies in both companies financials. These were not
insurmountable, but would need to be discussed during the Planning Stage.
Pre-requisites for success were defined as:

Growth in the mechanical engineering industry, with focus on the emerging markets of India and
Russia.
Merger had to take place and a listing would avail the companies with expansion funding.
Steve was declared sponsor and sole contact person to Magliolo, the project manager.
The full list of due diligence questions was made available to the company directors and, thus,
contingency time was gained.
The legal and accounting consultants after discussions with Magliolo on corporate finance issues, including
a valuation determined that the new proposed listed company would meet listing requirements for
AltX. The project was thus viable, with conditions these would be assessed during the Planning Stage of
the project.
Terms were discussed and timing and schedules were outlined and agreed to:
Schedule: Four Stages:

Stage 1 - Initiation Stage: one week
Stage 2 - Planning Stage: three weeks
Stage 3 - Execution Stage: Four weeks
Stage 4 - Closure: one week.
The Listing would then be initiated.
Budget:
Cost of profession fees: R250,000 per Stage
Cost of lawyers, accountants and other company related fees =
expense to be covered by both companies.
Stockbroker/listing costs to list: R2 million
Project success bonus: 6% of shares to be issued
CONTRACT WAS SIGNED AND THE PROJECT LAUNCHED
Page 90 of 283
STAGE 2:
PROJECT PLANNING
An effective plan maps out a project from start to finish, setting out what needs to be done, when
and how much it will cost. A well prepared plan is a guide to success.
Page 91 of 283
LESSONS LEARNED: PLANNING

The lessons learnt log for planning should include:
Has the plan been explained in a way that the whole team understood it?
Is the context clearly described?
Is the plan written in plain language and avoiding jargon and abbreviations?
Did writing the plan provide fresh insight into the business and the project?
At key points in the planning - such as at the end of a stage, at a Gateway Review or when an
important milestone has been achieved - the project should be reviewed to determine what
key lessons emerged.
Always involve as many of the project team in the process as possible. One way of doing this
is to hold short brainstorming meetings. Review project documentation to see what lessons
have arisen, especially:
o
o
o
The Lessons Learned Log.

The Risk Register.
The Issues Register.
Summarise planning lessons in a brief document that can then be shared around the project
team.
Page 92 of 283
CHAPTER 7: PLANNING A PROJECT

To achieve anything of substance in a global, hostile and competitive environment, planning is
extremely essential if success is to be achieved. Therefore, having a clear idea of what a project
will achieve is the foremost basic element to ensuring that the project will accomplish something
of perceived value. Start the planning process with a clear statement that describes the project
vision.
IDEAL VISION VS REALISTIC DEAL

There is always a risk that the project manager will, in the submitted proposal, commit to impossible
schedules and budgets. It is thus important to create a precise vision, but avoid ambiguous results. See
if the team and sponsor agree with the proposed vision of the future.
The project manager must always ensure that everyone knows exactly what the project is expected to
attain by setting out aims. With key team members and sponsor, it is important to create a statement that
describes the project vision.
For the statement to explain the proposal properly, it must answer the following question: "What are we
going to change/implement and how?"
Check the vision statement with the client and customers, who may help to refine it by describing what
they would expect from such a project. If the project creates something of value for the client, that is a
good indicator of its desirability.
Therefore, the project manager must start with an out line of his or her vision, with specific focus on what
the ideal would be. Start from a blank sheet of paper and ask the team to describe what, in an ideal
world, the project would achieve. Be realistic, but also creative in the thinking process, i.e. that is what
brainstorming is about; setting out all options and then eliminating the unrealistic and unattainable. A
recommendation is for the project manager to avoid ignoring alternatives simply because he or she did
not derive the strategy. Check how feasible the ideal is to arrive at the desired vision.
Encourage team members to question every aspect of the vision to check that it is truly workable and
achievable. Once the vision has been agreed to, ensure that everyone is committed to attaining that
vision.
The following are some suggestions:
It is always a reasonable assumption that the project manager will have to compromise on the ideal
to arrive at the vision.
Once the above has been achieved, the project manager must make the vision statement explain
why the project is needed.
It is also reasonable to assume that the team will ignore potential obstacles at this stage, seeing that
the team is new and hungry to push ahead. It is realistic that, at this early stage, the team will believe
that they can overcome obstacles. It is recommended that they do not, as these may prove to be
major stumbling blocks during later stages of the project.
Remember that the more people are involved in the decision process, the longer and more varied the
process will take. Don't involve too many people this early in the process.
Learner Notes: Ask the question: Is the vision clearly worth attaining?
Page 93 of 283
PLANNING A PROJECT
There are effectively only a few steps to a planning process:
Break the work down into manageable stages.
State the expected outcome of each stage before the stage commences. Be brief at first (future stages)
and more comprehensive for current stages.
What are the milestones? These are key points that show the project is going according to plan and
they provide a measure of progress.
Estimate how much time each deliverable will take. Remember that some tasks will not be completed
before others are, i.e. some tasks are dependent on each other. Identifying these will help to organise
the work and related schedules to complete these tasks.
Determine is the sequence of events.
Appoint team members for specific tasks.
Again, the issue of resource is to be reviewed. Are there enough to complete the task?
Planning who will do what when - or scheduling - is fairly straightforward if there is a team of less than
five people. However, with a team of a 20, 30, 50 or more people it can be difficult to work out who will
do what, when and how all the tasks fit into each other. If the project manager is able to get the plan
right, the projects should run relatively smoothly. Every member of a project team has a right to expect it
will be clear to them which tasks they will perform, when each task should be done and what each task
should deliver. In small team projects, the project manager can easily plan the work, but in large people
projects, there is no way the project manager can personally produce plans for every team member.
Learner Notes: On larger projects, there is a need to employ team leaders to produce the detailed work
plans for their teams. All work is then filtered up to the project manager.
Large Project team framework
In large projects, the project manager will not be interested in the thousands of individual tasks in the
plan: yet plans have to be summarised and progress chartered. The task of compiling the data files is the
responsibility of the project manager, but this does not mean that he or she has to do the physical work.
Page 94 of 283
In addition, each task has to be summarised, but the sponsor only needs to see the overall project
summary.
Good plans:
Help make best use of resources: A bad plan can mean people sitting around with nothing to do,
because something they need hasn't been produced yet.
Show each team member what they must do and when. Having consultants appointed for specific
tasks and paid professional fees on completion, means that they will push others to complete work
scheduled, so that they can commence their tasks. If this is done in an open forum, then tensions
need not rise. The completion of the plan is to everyones benefit.
Include everybody who has some work to do in the project: There is still a tendency among
companies to exclude important members of a company. For instance, excluding the business
development manger in a project will result in antagonisms when the project is launched. If he or she
were involved from the beginning, launching the project would be encouraged and approved by
management, sponsor and development manager.
Are visible and intelligent: It is very reassuring when you walk into a project team's working area
and up on the wall is a whiteboard across the top of which is a calendar of week-ending dates and
down the side the team members' names and in each week some indication of what each person will
be doing in that week. Why is this reassuring? If the plan is that visible everyone will have critiqued it
and pointed out the errors and it will have been changed so that it is now a viable and realistic plan.
By contrast, poorly constructed plans will make the client and sponsor very nervous: what are they
hiding? The plan must not leave anybody in doubt about what they must do and when.
Are agreed by everyone: Some team leaders get everyone to sign the plan to evidence the fact
they've seen it and think they have a fighting chance of achieving their part of it.
Lead to better quality deliverables.
Take time and expertise to produce: Planning a large project is quite an art.
Are revised as the project progresses.
Whether the project manager initiates a project him or herself, or the client and sponsor suggests it,
the first step in the planning process is to agree a vision for the project, stating exactly what it will
achieve. To do this, you will bring together your core team members and people with a close interest in
the project's result, known as customers.
After defining a vision, identify objectives, agree on actions and resources, order and schedule
tasks and finally validate the plan with all concerned and gain their commitment to it.
The production of a Project Plan, or Schedule, is a key part of the development of any project. The
schedule will set out the key stages to be completed during the project, with their starting and finishing
dates, and the resources that need to be allocated.
These stages can be turned into smaller tasks, which are then much easier to budget for, and can be
smoothly allocated to one or more people. The reliance on one piece of work finishing before the next
can begin is readily visible and so a fairly accurate timescale for the whole project can be set, alongside
a cash flow profile which will show at what stages of the project money will be spent. Progress can be
monitored against each stage and completion readily reported on.
Planning also brings more subtle benefits. The planning process can be a very effective tool for
communication. At each stage of the process, from setting objectives to deciding on tasks, the project
manager will need to talk to all those who can bring knowledge to the project or are likely to be involved
Page 95 of 283
in its implementation. If handled well, the planning process will set up channels of communication and
draw participants into involvement in the project. This will provide the basis for good teamwork.
Objectives and roles
Team members need to know where the project is going and what they have to do. In most projects
some tasks will be dependent on each other. The Project Plan should make these dependencies clear
or other tasks in the project may be delayed.
There are many ways to produce this Project Plan. The manager must use what he or she is most
comfortable with, whether it is a white board, excel spreadsheets or be a set of dates in a calendar or on
a wall chart.
So, the appointed project manager arrives to start at the beginning of a stage: what does he or she do?
How does he or she go about transforming a blank piece of paper into the plan for the stage? Where do
they start? The first place is to have a Project Brief, followed by a sound understanding of what is
required and how you expect to achieve planned targets.
TEMPLATE: Project Brief

1
2
3
4
5
6
7
8
9
10
11
12
Outcomes: what difference or impact is hoped the project will make?

Objectives: the purpose of the project; what the project will do must be measurable.
Outline deliverables: the specific things (products) that will be produced.
Scope: what is and isnt included in the project (users, geographical boundaries, depth and type of work)
Approach: how the manager will go about it, set out values.
Exclusions: what will the project not include.
Constraints: the things that might prevent the manager doing all that the client wants.
Outline business case: needs, benefits, users (numbers), income generation, funding sources, and marketing,
budgets.
Reasons for selecting this solution
Outline project plan/schedule: timetable
Quality expectations: including monitoring and performance indicators.
Risk assessment: what could go wrong and what the contingency might be.
Understand what must be delivered from the stage. It is surprising how often people do not think this
through and thus deliver a product or service that was not outlined in the project scope or brief.
It is also important to document every single work task that will need to be done during the stage.
Referring to past projects and standards will help and certainly team input could be very valuable.
Estimate, in hours, how much work each task will take. Bear in mind the number of hours will depend
upon who does the task.
Having allowed for everything that will prevent each team member from doing 'real work' tasks, the
manager can turn to that list of 'real work' tasks and start the tricky business of trying to fit them into
the estimated time schedule.
The stage plan is beginning to take shape. Teams, budgets and resources are specific and signed by
all relevant members of the team.
When the plan is finished, get team members together and present the plan to them line by line, task
by task. The presentation to the team members enables errors (if any) to be found and ironed out
before a formal presentation is made to the client.
It is useful to record a plan in a computer-based scheduling tool. There are many available and, for
advice on which to use, contact the author on mentor@magliolo.com.
Chapter 8 sets out purpose and the importance of prioritising objectives in the planning stage.
Page 96 of 283
CHAPTER 8: PRIORITISING OBJECTIVES

Once a project vision has been finalised, the next step is to set objectives that will measure the
progress and ultimate success of the project. Expand the vision to clarify the purpose of the
project, list the objectives and then set priorities and interim targets.
PURPOSE, OBJECTIVES & INDICATORS
Learner Notes: Ensure that objectives are measurable.
Learner Notes: Gain agreement on objectives from all members of the project.
Learner Notes: Ask the question: will the project be relevant on completion?
The project manager must expand the vision statement to include what he or she will be doing, how long
it will take, and how much it will cost. This statement should reflect and prioritise time, cost and
performance. For instance, if the project is to install a new computer system, then time frame is the key
driver.
Learner Notes: Nominate a team member to research industry standards, trends and key value drivers.
These will provide a framework for the projects indicators and a check on competitiveness.
The manager must list the objectives he or she wishes to achieve; set out specifically and in detail. The
list should also cover the areas of change that will occur when the project is implemented. Ensure that
progress against objectives is measurable by setting an "indicator" against each one. For example, if the
objective is to list on a stock exchange at a value of 12 time price earnings ratio, then measure against
the all share index, industrial index and the sector index price earnings ratios. If you are having difficulty
in arriving at the indicator, ask the question, "How will we know if we have achieved this objective in a
competitive and economical manner?
The next step is to determine and prioritise the stated objectives. Experience highlights that it is
extremely unlikely that all the objectives will be equally important to the client or sponsor.
A basic system
Give each objective a priority of one to 10.

One is the least important and 10 the most important priority.
It should be obvious which of the objectives are significant and which are not, but priorities of those
falling in between will be less clear and this basic system enables proper scheduling. Discuss with ethe
team which are the highest and lowest priorities first. This reduces the list and enables quicker decision
making. Then set quantity to the objectives. These may be simple, such as increasing sales by 50%, or
they may be more complex. If, for example, your objective is to improve client satisfaction, and the
indicator is based on complaints, you must Count the number of complaints you now receive, and set a
target for reducing them.
Learner Notes: Be prepared to drop any objective that has a low priority.
Write down your objectives, indicators, priorities, current performance and targets. This will help to
decide which aspects of the project require most effort and resources.
Page 97 of 283
Objectives should be appropriate for the whole organisation, not merely the project
managers viewpoint.
It is easier to identify and prioritise objectives if these are discussed with the team,
client and sponsor.
Well-defined and appropriate targets will motivate team members and encourage
morale.
Example of Prioritising Objectives
Objective
Indicator
Complete due diligence and

Market conditions and industry growth
research
Acceptance of stockbroker and capital
Complete prospectus
providers
Get best quote from major financial
Capital Raising
banks and institutions
All documents in place
Presentation to the exchange
Listing
Capital raising completed
P Current
Target
10 Date set: Oct 2007
March 2008
April 2008
Expects to raise R80

million
To raise R100 million

in 12 months
June 2008
NOTE:
Objectives: key objectives that determine project success
P: Priority of objective
Indicator: measure if the objectives success
Current: Level of performance
Target: Desired level of performance
PURPOSE OF A PROJECT PLAN

The purpose of a project plan is to maintain control of a project.
As a complicated process, a project always threatens to exceed the limit of the project managers
control. Some people are better than others at controlling complex problems, but everyone will reach
their limits at some stage. To maintain control the manager needs help in the form of tools and the best
tool is the plan.
The project plan controls the project by:
Breaking a complex process down into a number of simpler components.

Providing visibility for obscure or ambiguous tasks in the project.
Providing a single point of reference for all team members, client and sponsor.
Enforcing scrutiny of the sequence and nature of events.
Providing a baseline against which execution of the project can be compared.
Anticipating likely events and providing pre-planned means of avoiding them.
A project plan must be as accurate, complete and as specific as possible.

Factors That Make Up A Project Plan
Every project planning methodology has its own specific setup, but in a very broad sense the minimum
elements a project plan must specify are:
The job spec: what is desired of the project and what it must deliver to succeed. A high level scope
document is required.
Page 98 of 283
Date to completion: The deadlines by which the objectives must be met, usually in a schedule of
some kind.
The team: The people, sometimes unkindly labelled resources, who are to deliver those objectives.
This also usually implies costs, since the application of costs implies the use of labour. These must
be documented by a project budget.
Project methodology: The method of delivery, covered by documents such as a technical

specification and test plans.
Note that the project manager should complete all the relevant documents before proceeding with the
project. In reality, though, these are not completed prior to starting the project. Typically, a draft of the
proposal, schedule and budget are finalised before the project commences. Each of the other
documents is completed at some later point. Nor should any of these documents be regarded as static or
inert manuscripts. Each is an expression of the project and they should evolve as your project evolves.
Finally, none of these documents has an obligatory size, format or length. The author notes that
templates are merely guidelines and tools. It is the objective that counts, not the form. The only right
form for the project manager is the one that works for him or her.
A more specific approach is outlined in Chapter 9.
Page 99 of 283
CHAPTER 9: A PHASED APPROACH

In Johannesburg, the author works with a number of venture capitalists. These are high powered
individuals, who do not want to wait more than two weeks for any project to be initiated, planned
and implemented. Every time the author gets a call form such a client, two things happen: firstly,
on hearing the clients voice, the author feels extreme tiredness coming his way in the near
future, and secondly, a rush of excitement as the project will inherently be exciting, rushed, on a
level of high power, involve many millions of rands and pressure. Extreme pressure at that, so
what should the project manager do when confronted with such an offer?
THE EXTREME OPTION

The opportunity is to manage and succeed in such a project is simply too much to give up. However,
success can only be achieved if the project manager has all relevant team members in place and a call
away. He or she must know who to call, who works rapidly and, more importantly, accurately. Under
such extremes, the project can be done in two ways.
Extreme 1: Get the scope directly from the client. Ignore brainstorming, discussions with
customers, initiation documentation and determining options. In addition, ignore team building and
discussion platforms.
Appoint each consultant independently from the other and the project manager must co-ordinate the
entire process.
Start with legal and accounting due diligence, industry research and strategy, which have to be
completed within a week.
The weekend is a good opportunity to meet the team individually, assess the tasks and co-ordinate a
summary sheet. A single sheet is provided to the venture capitalist and a decision to implement must
be either:
o
o
YES: Implement Project according to the venture capitalists scope.

NO: drop the project.
The secret to an association between a venture capitalist and project manager is that each trusts the
judgement of the other. In essence, the client believes in the skill and knowledge of the project
manager, agrees to a professional fee quickly and without hesitation. All requested documents are
provided within hours to the project manager.
These are highly intense projects and, when they do work out, extremely profitable.
Extreme 2: Get implementation strategy from the client. The client has already made up his or
her mind that the project will go ahead, and the instructions are to conduct the takeover, purchase or
merger at the best possible price.
The project manager has to appoint a team to undertake the scope, without objections to detail.
The secret is to have the right contacts, financial backing and legal/accounting teams that can work
to the project specs.
This is a "big bang" approach and is usually undertaken within days and not weeks. For instance, a
bid is made for a company and the client appoints the project manager to make a counter bid.
Page 100 of 283
This would involve analysis of the bid, determination as to whether it is a fair and realistic offer, can a
counter bid be mounted, who would back such a bid, accounting and legal assessments of the bid
and the actual counter bid itself.
Which of the above extreme structures might be the better approach? As always, it depends on time,
resources and skills available. There are pros and cons for each.
Extreme Pros & Cons

Pros for using an extreme methodology:
Its visible and quick.
More participation from the client, i.e. active participation, rather than passive.
Only one implementation, one disruption to the business.
Use highly skilled consultants.
High level of professionalism.
Nice clean switch from old to new.
No temporary bridges from old to new.
Everything being done only once so lower cost.
Less spent on project control.
Less waste on never-used functionality.
Easier to manage four small projects than one large one.
Easier to commit people for two weeks than for three years.
Cons for using an extreme methodology:
Better team motivation in longer term projects.
Quicker implementation of the project for management.
Learning from experience can only be achieved if a project is over a long period.
Easier to handle change in a long term project.
Considered Facts & Compromise

The following are some factors that are pertinent when building a team, planning a project and getting
ready to execute the tasks.
Better team motivation. Project managers will concur with the following statement: "We've got three
years to do this project, so lets take it slowly." This lack of urgency can mean that not a lot gets done
for months. If, on the other hand, the completion date is only six or eight weeks away, there's much
more natural urgency and the statement changes to: "We haven't got long, we'd better get on with it."
Project control. The larger the project the greater the percentage of its budget will need to be spent
on controlling it. So, four smaller release projects may well, in total, spend less on project control
than one large multi-million rand project.
Greater flexibility. There are many times when expensive projects (some years down the line) get
cancelled because new management dont have the same vision as the one who originally
commissioned the project. This cancellation is sometimes called descoping a project. There are
times when descoping a project is actually more expensive than completing the tasks; not to mention
the money and time wasted on what has been build, that must now be thrown away.
Learning from experience. There is nothing to substitute experience. When the time comes to
make crucial decisions, which will affect the entire outcome of a project, experience and mere gut
feel often win the day.
Handling change. Suppose at the start of a three year long project you define in great detail the
business requirements that the project will satisfy. Obviously, over the three years a lot of those
Page 101 of 283
requirements will change continually change. The longer the project, the greater the percentage of
its budget will be spent changing things, that have been wholly or partially completed. In fact, some
projects are so long and so disorganised that eventually, they become a in-house joke. They either
get cancelled, or more money is poured into completing a task that is no longer wanted. After all,
economic, socio-political and business trends change rapidly within months, not years under a
globalised world.
Risk. Implementation of a large project brings its own risks and, if the project runs across countries,
additional risks have to be taken into account, i.e. currency, cultural, political risks. For instance,
implementation of a whole new computer system in a global company (changing the whole
operation) to the new system could represent a massive business risk - what if it doesn't work?
Easier to manage smaller projects. Small projects are usually easier to manage than large ones
and will probably need a smaller percentage of cost spent on project control.
Easier to commit people. It's much easier to appoint someone in to a project for eight months than
for three years. And committing business people for months probably means their skills will still be
current when the project ends. The longer the project the greater the risk that people will leave during
it. More people will leave during a three year long project than during a six or eight month long one.
Anyone leaving a project team constitutes risk.
Lower overall cost. Project managers are in a quandary: secure one long term project or secure a
whole host of smaller ones that make the same period as the longer term one. It is true that smaller
projects are easier to handle, report back to the client is easier and the client is kept informed and
confident that the contract will deliver the promised goods or services.
The answer is a compromise: Long-term projects must be broken down into smaller deliverable
tasks. That way, the client can see progress and project descoping becomes less of a threat.
In practice it depends upon so many factors that you can't say one option or the other will always be the
better. If it were that simple people, wouldn't be paid all that money to manage projects. The correct
answer is, ultimately, the project manager. This doesn't mean the project manager makes a random
selection in splendid isolation. It means that the project manager makes the client and sponsor work out
what is really needed and what isn't really needed on day 1. However, in managing that process the
project manager may well find that he or she ends up knowing even better than the client what they
really need and in the end he may have to, with the sponsor's blessing, make the scope decisions.
To be a good project manager you have to learn how to say the most important word in the project
manager's vocabulary: "No". Politely but firmly: "No". Cut the scope back to the bone, for which everyone
will hate you until the project is implemented on times and in budget (or at least close to it). There
aren't all that many very large projects around so the chances are that the sponsor and project manager
will not have been involved in a very large project before. This inexperience may mean that they drift into
the desired approach without too much thought of the alternatives and on the unconscious assumption
that it must surely be cheaper to do everything just once.
In summary, the short term approach will probably cost less, deliver benefits earlier and be more likely to
succeed. It will also give the business a better return on investment.
The Art of Scheduling

If it were a science, then every project would be delivered on time and in budget. In fact, overruns are so
common in business that most company directors have no faith in project deadlines. In truth, the art of
scheduling is based on experience and the more experience the project manager has, the more accurate
schedules are. However, there is no reason why new and inexperienced project managers cannot
produce a good schedule by following some simple rules.
Page 102 of 283
The Format of Project Schedules
Milestones: The difference between a milestone and a schedule is that the latter denotes a
sequence of events in time, while milestones denote the completion of that sequence. At each
milestone, there should be a completed task (deliverable), to enable the project manager to move on
to the next stage. A complex project may involve different levels of scheduling, which could include
work on a weekly schedule with high level milestones, while other team members will have smaller
scale schedules with shorter (and easer to achieve) milestones. Typically, more detail is involved in
projects where there are a number of parallel activities taking place. Where more than one person is
working on a project at one time, it is obviously possible for these individuals to take on separate
areas of responsibility and complete them concurrently. In this case, the concept of a critical path
comes into play and milestones represent those critical events where branches rejoin the critical
path of a project.
A Simple Example: In the following example, a property development company has to complete a
complex of only four homes. The project schedule is shown below, which lists all of its major
milestones. The usual cycle of designing a property development project has been concatenated into
a single production phase which starts on the 2nd of March and is finishes on the 11th of June.
Milestone
Project starts
Complete scope and plan
Specify requirements
Production
Implementation
Review
Completion
02-March
10-March
21-February
1-April
8-May
11-June
This example is extremely simple and anything more than a one-person project would be unlikely to
succeed using this method. The simplicity makes it easy to understand, but as a control tool it is not very
useful. The extreme high-level of the schedule means that the only indication a project team will have
that a project is not on track is when it misses a major milestone. This could be embarrassing and
possibly terminate the project. Also, there is no contingency scheduled between tasks, which could lead
to complications, or failure of the project to deliver on time. By assuming that everything will run to plan,
the project manager is leaving him or herself little room to manoeuvre should anything go wrong.
A More Complicated Example: In the following, more realistic example, a project is broken down into a
number of stages and the start and finish of each stage is recorded separately. Columns have also been
added to include the duration of each stage and the deliverables (tasks) to be completed at the end of
that stage. This new project schedule includes three scheduled tasks for the production cycle of property
development. The deliverables for these production cycles are an alpha, beta and final version of
the system.
Phase
Scope and plan
Specify requirements
Production stage 1
Production stage 2
Production stage 3
Acceptance testing
Implementation
Launch
TOTAL
Start
01-Jan
13-Jan
3-Feb
24-Feb
17-Mar
7-Apr
21-Apr
28-Apr
67 days
Finish
10-Jan
24-Jan
14-Feb
7-Mar
28-Mar
11-Apr
25-Apr
28-Apr
Duration
7 days
10 days
10 days
10 days
10 days
5 days
5 days 0 days -
Deliverable
Project proposal
Requirements spec.
Alpha
Beta
Final candidate
Release system
The first thing to note is that the Duration column does not exactly match the number of calendar days
between the scheduled start and finish dates. This is due to the duration column indicating the number of
working days between the two dates.
Page 103 of 283
The next important point to note is that the stages of the project no longer occur simultaneously. That is,
there are distinct gaps between some stages of the project. For example, between the specification of
requirements (which concludes on the 24th of January) and the commencement of the first production
stage (on the 3rd of Feb) there are five working days unaccounted for. The wise project manager would
keep these days in reserve as contingency in case things not going to plan. If things go exactly to plan
the project can simply scrap the contingency and move the schedule forward to the next stage (with
subsequent reduction in delivery time). Either way, everyone is happy!
How much contingency to include is a matter of experience. While it can inflate delivery times
considerably, it can also save the project from damaging and costly failure. In the above example
contingency amounts to nearly 50% of the overall production time and represents an excessive amount
of caution on the part of the project manager. As a rule of thumb 10% to 20% is normal, although more is
not uncommon.
Another method is the use of Gantt Charts, as outlined in later chapters. The next chapter sets out
possible constraints that the manager can expect during the later stages of project management.
Chapter 10 looks at how to assess project constraints.
Page 104 of 283
CHAPTER 10: ASSESSING CONSTRAINTS

Every project faces constraints, such as limits on time or money. Occasionally, such
constraints may even render a project not feasible; too expensive or cannot be completed on
time. All team members must understand the constraints in advance, and ensure that they wick
be able to work within them.
CHANGING WHAT DOESNT WORK

Learner Notes: There are few constraints that cannot be overcome through diligent planning.
Once it has been decided that a number of changes are needed, the team must write a list of the
proposed changes, why these are necessary and how the changes are to be completed. The project
manager must discuss any changes with the team and then, after the list has been reduced, a
discussion with the sponsor must take place. Be prepared to accept that some will not be approved,
as there may be valid reasons for keeping certain processes or practises intact.
There is little point in change for the sake of it if you can work within the constraints of what currently
exists. Even if you identify an area for improvement, it may be better to include the change in a later
project, rather than deal with it immediately. This is because too many changes can put a project at risk
as people try to cope with too fluid an environment. Also, by taking on too many changes, there is the
danger that you will not be able to identify those that have resulted in the success of the project, or
indeed, its failure.
Time Constraints
A fast-moving global business environment often gives projects a specific window of opportunity. If the
project manager is facing a competitor, who is to deliver a new product into the stores for the summer
season, he or she will have to work within that time constraint. There is no benefit to driving a team to
work hard to deliver a competitive product if there is no chance of the product can be launch in time for
customers to place orders. Whether the manager likes it or not, a time constraint has been set and he or
she must work within that boundary.
Learner Notes: Ignoring constraints will lead to business failure..
Learner Notes: Do your best to find short cuts to success
Resource Limitations
Most organisations work within limited resources and budgets, and projects are subject to similar
constraints. A new project may entail an extravagant use of resources, so it is crucial to ensure that the
promised resources are really available. There is no point in taking on an assignment if success of a
project depends on a level of resources that is unlikely to be forthcoming. If a manager is in a position to
negotiate for more time and money, to enable the project to go ahead, do so.
Page 105 of 283
Assess how important time is for the completion date.

Analyze required resources and whether the client can afford them.
Will it be possible to use the clients internal resources?
Identify any external constraints, such as legal or environmental regulations.
Decide whether to proceed within the given constraints.
Learner Notes: Explain the constraints to all who agree to take part in the project.
Internal Resources
In order to reduce project time frames, the manger must assess the clients internal resources. For
example, other departments may have funding available (and not used) or current technologies that
would avoid the need to invent something new. It is important to consider these issues and re-use as
much as possible. It is rarely a good idea to start from scratch, no matter how appealing that may seem.
By studying systems in the clients other departments, he or she can capitalise on internal
expertise and experience, at the same time saving time and money.
In chapter 11, the project manager looks at listing activities.
Page 106 of 283
CHAPTER 11: THE TASK LIST

Having identified objectives and constraints, the project manager can set about planning
in greater detail. It is at this stage that the real business of project management
commences and the way to kick-start the process is to make a list of all the activities
needed to achieve the objectives and to divide these into groups. This will make it easier
to assess what must be done, when and by whom.
THE TASK LIST

Learner Notes: There is a natural desire to conduct and write the list independently, and not include
sponsor or team members, to expedite the process. It is recommended that the manager consults widely
when creating this activity list, as project tasks will be based on this list. Not doing so often leads to
problems during the execution stage.
Breaking the project work down into smaller units, or tasks, enables the project manager to identify
whether there are overlaps, and how some activities may affect the timing, budgets or the start of other
tasks. Since the list can be long, it helps to divide activities into groups so that each set of tasks
becomes more manageable and easier to track when monitoring performance and progress. Grouping
activities also helps the manager to determine how these tasks (within groups) fit into a logical sequence
for completion. This will make setting up schedules easier and also enables the manager to investigate
the number of people and skills needed.
Listing activities in this way also reduces the risk of misunderstandings, since everyone knows what their
tasks are.
Learner Notes: The true skill of an experienced project manager is to define each activity within short
sentences.
Start the process by brainstorming a list of activities. The project manager may need to include more
people at this stage, i.e. client, sponsor, team and customers. It is often useful, for example, to ask
various customers for their views on what it will take to complete the project, especially if it is a
complex one. The use of consultants enables the project manager to use expertise, experience and
skills that are often not available in a company. Ideally, if someone in the organisation has previously
completed a similar project, consult the original project manager and use the previous plan as a
checklist. At this stage it is not necessary to be concerned with the order in which the activities will
occur.
Learner Notes: Keep checking the list to eliminate duplications and assess whether anything is missing.
Page 107 of 283
Setting up the Task List
Use a brainstorming session to generate ideas on all the activities needed to complete the project. In the
above diagram, the process starts with brainstorming between the project manager and client, sponsor,
team and customers for every suggested activity, no matter how inconsequential. The aim is to draw up
a comprehensive list, then to group into tasks. This grouping is the investigated to eliminate duplications
and add missed tasks. Once all that has been completed, then a more refined list of tasks is assigned to
the relevant team members.
To be effective, it is important to break down the long list of activities into smaller, more manageable
units by putting the activities into logical groups. Placing tasks into categories or tasks will also help the
project manager to set up the final corporate structure of the project at the execution, i.e. overlaps are
removed and the company then has a clear and well defined set of products or services. Most groups
will be obvious, while certain activities will be concerned with one event occurring later in the project, or
some may all involve the same department or people with similar skills. If an activity does not fit into a
group, the project manager must question whether it is really necessary or leave it as a separate entity.
Learner Notes: The project manager must list activities so that these are clear and easy to understand.
To group activities effectively, a time-stamped, logical order must be determined, i.e. consider the order
in which tasks will take place. One group, for example, may not be able to start before another is
complete.
Learner Notes: Specialist consultants can help in grouping activities, such as corporate attorneys or
accountants.
Learner Notes: Review the list after a few days for a final check.
Typical Groups
In a typical project, there will always be a group or groups of tasks assigned to various team members,
which will be ticked off as these tasks are completed. In essence, when all the tasks are marked as
completed, the project will be over. However, before the final closure occurs, these closed tasks are
Page 108 of 283
checked for quality performance against preset indicators. A project record should be made for the
client for future reference. Finally, most projects should be issuing weekly progress reports.
Finally, the importance of reviewing the list of activities is to ensure that it is complete, to avoid
possibly serious implications on the project's budget, schedule or other resources. Once the
manager is confident that each group is complete, give each task within the group a unique
identifying number.
Does completing all the listed activities mean that you have completed
the project's objectives?
Does the activity list reflect the project managers original priority list?
Have all task duplication been removed?
Another group of activities that features in many projects, especially when the purpose is to create
something entirely new, is a pilot implementation. Typical activities include choosing a limited number of
people as a pilot team, implementing the whole project on a limited basis and keeping records of the
experience. By building a pilot stage into the plan, the project manager will have a far less stressful and
error-prone time when it comes to rolling out the entire project.
Choose people for the pilot programme carefully and make them aware that they are, for this particular
project, guinea pigs. Testing a new idea, even one as complex as an automotive production line, allows
problems to be solved before a new system is introduced more widely.
Chapter 12 concentrates on the important task of managing resources.
Page 109 of 283
CHAPTER 12: COMMITTING & MANAGING

RESOURCES
Before implementing a project, the manager has to set out a budget, stating in specific detail
how much is required. It must be noted that projects often get cancelled at this stage,
particularly if the project manager cannot justify the expenditure when stated relative to the
expected benefits.
THE PROCESS: START WITH HR

Determining Resources
Many project managers believe that they should start the resource investigation with how much money
the client will allocate to the project. There is no denying that without adequate funds, the project will not
get off the ground or will run out of budget before it can be launched. Despite this obvious fact, there is
another more influencing variable: if you cannot find the right people to join the project team, then the
project manager will simply be operating in the dark and problems are bound to occur throughout the
project.
Leaner Notes: The project manager must think about who needs to be involved in each activity and for
how long.
EXAMPLE: While a team member may be commissioned to work for 10 days, he or she may only work
for five hours a day. What is that members true total commitment? If the member can usefully work on
other projects for the rest of the time, the cost to your project will be a fraction of the member's 10-day
earnings or charge. However, if he or she cannot make any contribution to any other project, then the
project's budget must bear the full cost. Another option is to use the Magliolo Methodology as stated in
the Preface; the consultant is paid for work commissioned and delivered, within the specified contractual
time frame. In this manner, the budget is set and there is no need to calculate the true nature of his or
her contribution.
Page 110 of 283
Learner Notes: There is nothing more important in project management than accuracy: remember to
determine costs carefully as, once approved by the client, the project manager is bound by them.
Learner Notes: Insist that the client and sponsor provide the best supplies, facilities and equipment that
they can afford.
Other Resources
While the major cost of a project is usually professional fees paid, there are other resources that will also
have a major impact on the budget. For example, there will be times when major geological surveys,
mining or environmental impact studies will be required. These are conducted by professional
organisations that charge significant amounts to carry out such research. It is better, then to always start
with undertaking budgets on such reports, including costs and time it will take to complete.
Facilities, equipment and materials can also involve expenditure. Failure to identify all the costs will
mean that loosing credibility when others examine the project to balance its costs against its benefits. A
comprehensive estimate of costs at this stage also reduces the risk of requesting extra funds once the
project is up and running. Many clients consider this as the single highest indicator of a lack of
professionalism by the project manager.
The better the detail at this stage, the more likely the project manager will avoid problems during the
execution stage. This also enables the team to focus on achieving objectives, rather than on fixing
matters that were poorly planned.
Which is better: the project manager estimating costs, or asking
professionals to help?
Using old reports is a better and cheaper way to project management, as

it cuts down costs?
Always ask: Are estimates realistic, conservative or optimistic?
COSTING METHODS
There are two basic ways to calculate costs:
Absolute costing: This means keeping track of every cost in the project, no matter how small. For
example, if a motor vehicle is needed, add the cost of buying the vehicle. If the company already has
a car, factor in depreciation, usage and fuel.
Marginal costing: The definition of marginal cost is: only allocate costs to the project if they would
not be incurred if the project did not take place. For example, if an existing computer, which is not
being used, is required, the marginal or extra cost, of the computer is zero. The cost of the computer
should not be in the project budget. With practice, marginal costing is easy to calculate and is
generally a more accurate measure of the cost of a project to an organisation.
Learner Notes: The true accuracy of a budget is one that will allow the project manager to complete
all the activities, which will result in a successful project handover.
Compromise
Project managers know, from experience, that they will usually not get the full budget that they have
requested. In reality, the manager will usually have to cope with less. This does not mean that the
sponsor will deny parts of the budget; there may be specialists who are not available, equipment that
costs too much or can only be imported at a later stage or the perfect location may not be available.
Learner Notes: The project manager must adapt and make compromises.
Page 111 of 283
If it can be assumed that compromises will have to be made, the secret is to make such compromises
that will not threaten the overall aims and objectives of the project. For example, a professional that is
not available to join the team full time could be employed as an advisor to check the final research or
other documentation, i.e. give advice to those less experienced, yet able, team members.
The key to ensuring that the required resources will be available is to produce a document that the client
and sponsor can agree to.
This is known as a commitment matrix.
It can also, during the different stages of the project, be used to remind the sponsor of his or her
commitments. Check that a full matrix is completed as comprehensive as possible to ensure that all
resources have been identified. When you have identified all the resources and estimated costs,
document these on a commitment matrix and seek the clients agreement.
Example of Commitment Matrix
Task
Team
Professionals
Duty
Resources
Equipment
Materials
Cost
Total
Learner Notes: Refine resource needs, so that anyone can work from it, but avoid cutting back on tools
that are really needed.
Learner Notes: If resources are scarce, consider alternatives; these may be to abandon the project.
Using Outside Resources
It will be unusual to for a team to be made up of only full time consultants. While most of the required
resources will come from within the team, the project manager will need to go outside for others. The
secret is to quickly get such professionals to commit (in contract) at competitive prices. The aim is to get
these professionals to commit to performance that is easy to monitor. A useful skills to have is the ability
to negotiate deals that ensure that the best deal is possible. While it may seem unnecessary to go into
such detail at the outset, the tighter the agreement, the more likely the project manager can avoid
conflict at a later stage. In essence, strength of negotiating with numerous professionals is the
networking aspect of deal making. Even if the manager does not need to use them this time, an
extensive network of contacts could well prove useful for future projects.
Approval and Sign-off
Before a project manager can obtain the official go-ahead for a new project, it must be proven that:
The project is still a business priority.

The benefits of the project to the organization considerably outweigh its costs.
This is known as investment appraisal, or cost-benefit analysis, and it is a discipline used widely in
many organisations that often have formal systems for the project management process. If the
costs are the same or more than the benefits, the sponsors have three alternatives:
They can proceed with the project regardless (although this is seldom desirable unless the
strategic value of the project is very important to the long-term aims of the organisation).
They can modify the objectives and change the activities in a way that reduces costs.
Page 112 of 283
They can cancel the project, because it is considered unfeasible.
If the organisation has an official system for obtaining sign-off for a project this should be followed.
Finance departments can provide useful feedback on estimates by comparing a project managers costs
with others. The benefits of a project should never be exaggerated - promises will be expected to be
delivered.
Learner Notes: The project manager must work rapidly to justify choices, dates and budgets. The longer this
stage takes, the less the chance of getting final approval for the project to go ahead.
MANAGING RESOURCES
It may seem like an obvious statement to make that a successful project manager effectively manages
the resources assigned to the project. Yet many do not include labour hours of full time team members,
those that have been sub-contracted to undertake specific work or the management of equipment and
material used by the people and equipment assigned to the project. In fact, look at people, equipment
and materials as if each are limited resources, which cannot be replaced.
People: Managing the people resources means having the right people, with the right skills and the
proper tools, in the right quantity at the right time. It also means ensuring that they know what needs
to be done, when and how.
o
Equipment: The equipment that has to be managed as part of the project depends on the nature of
the project. A project to construct a warehouse would need earth moving equipment, cranes and
cement trucks. For a project to release a new version of computer software, the equipment would
include computers and test equipment.
o
Managing direct employees normally means managing the senior person in each group of
employees assigned to your project. Remember that these employees also have a line
manager to whom they report and from whom the usually take technical direction. In a matrix
management situation, the task of the project manager is to provide project direction.
Managing labour sub-contracts usually means managing the team member responsible for
the sub-contracted workers, who in turn, manage their workers.
The project management key for equipment is the same as managing people. The manager
has to make sure he or she has the right equipment in the right place at the right time and
that it has the supplies it needs to operate properly.
Materials: Most projects involve the purchase of material. The project management issue with
supplies is to make sure the right supplies arrive at the right time.
All the management skill won't help, however, unless the project manager can keep to the project
schedule. Therefore, time management is critical in successful project management.
Chapter 13 looks at ordering activities and how to use Critical Path Analysis.
Page 113 of 283
CHAPTER 13: ORDER & CRITICAL PATH

ANALYSIS
Not all activities can, or need, to start at the same time to meet the project's planned completion
date. Put activities into a logical sequence, estimate the duration of each, and then use clear
documentation to help you devise a project schedule.
SCHEDULE ORDER
In previous chapter, the author outlined methods of completing a list of the activities, which is required to
complete the project. The next step is to look at how these interrelate. A decision has to be made as to
which activities should start immediately, which need to be completed before moving on to the next and
work through all the activities until the end of the project. There is also the issue that some activities will
be the result of the completion of a number of tasks. For example, in the music industry, promoters of a
new music CD will have to complete the music, design cover and determine the name of the CD etc
before the project manager can make a presentation to the people involved in sales and promotion.
To draw up an effective schedule, the project manager needs to know how much time each activity is
likely to take. Effective project management, therefore, means placing a timeframe on each task and in a
specific order. Failure to do so will simply often mean that the project either gets stalled or, in a worst
case scenario, abandoned. It is crucial that all team members, sponsor and client are able to have input
to ensure that they all agree to the estimated activity times. More importantly, they should be able to
work to these stipulated schedules.
From experience, it is always important to have best and worst case scenarios for all the major tasks.
These provide flexibility in cases where team members get sick etc. the next step is to take the mid-point
between best and worst case timeframes and use that as the expected date of completion. This is part of
the compromise outlined earlier. If a project is under time pressure, this will help to identify where the
project manager can reduce the overall time frame.
Is it possible to undertake time trials, before making a final decision?
The Magliolo Methodology suggests that timeframes should be left to

the appointed professionals, who have the experience in such matters,
i.e. they will have completed similar projects in the past, and can state
with accuracy as to how long it will take to compete a project.
Therefore, duration of an activity is more accurate if expert advice is

sought?
An alternative is to look at previous and similar project plans to see how

long activities take.
Could I ask other project managers for their advice?
Learner Notes: Activities can be carried out at the same time.

Learner Notes: Ask whoever is responsible for an activity to give best estimated start and end dates.
Page 114 of 283
Introduction to Critical Path Analysis

A diagram can be used to display the relationship between various activities, and which ones depend on
the completion of others. The diagram may be simple or highly complex, according to how many
activities there are and how they interrelate. Where there are several routes through a network, there is a
chance to complete tasks simultaneously. The project managers job is to indicate how long each task
will take and add up the total time required to complete each route. This will enable the project manager
to find the longest route through the network.
Learner Notes: The longest route is known as the critical path and shows the shortest possible duration
for the project.
The skilled project manager will use a diagram to find opportunities for shortening the project schedule.
This involves looking at where he or she can cut the amount of time it takes to complete activities on a
critical path. For example, by increasing the resources available to a particular activity can reduce routes
that might have some slack. It may then be possible to reallocate resources to reduce the pressure on
the team members, who are responsible for activities on the critical path.
Businesses are constantly working on projects and, from experience, a diagram is important. There are a
number of methods that can be used to successfully manage a project, but the author suggests that,
from experience, focusing on the specific aspect of time is extremely important to all businesses.
Defining Critical Path
(Note: Critical Path Analysis and variations are set out in greater depth in Chapter 14)
The critical path analysis is a tool that illustrates the individual tasks of a project and highlights the
expected starting and completion dates for each task. More precisely, the critical path analysis can be
used to:
Estimate the minimum/maximum time that tasks will be started and completed.
Estimate the minimum time that the whole project will take to complete.
Identify if resources are not being used effectively.
Make aware any tasks that could create a possible delay.
Ultimately, the critical path analysis will suggest which tasks are critical to keep on time and how to
anticipate delays in any one of the other tasks that could delay the whole project. The critical path
analysis is hard to explain in more detail without the use of diagrams, and so the working example in the
following section will make it better to understand.
EXAMPLE: XYZ Limited has decided to carry out some research to ultimately create a selling strategy
for their new product. They have decided to create a questionnaire, which they will issue to the public. In
addition, they will use the internet to send out a similar survey to get the opinions of those that live
outside of the area.
Each task (A - F) has been given an expected completion time, which is crucial for XYZ Limited. The
project manager has, therefore, requested a Critical Path Analysis of the project. An unexpected time
crisis can put a business under pressure, which could place the project managers reputation at risk. So,
how can the project manager plan time and identify where delays could occur, which will enable him or
her to make alternative decisions to compensate for such situations.
Page 115 of 283
TaskDescription
Order/Logic
Time in weeks
A Plan Primary Research
To be completed first
1
B Prepare Mail Shot (Postal Survey) Start when A is complete
3
C Prepare Questionnaire
Start when A is complete
2
D Send and Wait for Mail Shot Replies Start when B is complete
3
E Issue Questionnaire
Start when C is complete
3
F Compile and Analysze Results
Start when D & E is complete
2
G Plan Selling Campaign
Start when D, E & F is complete
2
Now, take a good look at the diagram below. Each circle (Node) will be used to enter specific data. The
numbers currently in the nodes (1 to 7) are only there to make following the diagram easier - nothing
more. The arrows represent the tasks (as set out on the above table) and each is given their respective
completion times.
Before moving on, look at the above table again and ensure that you understand what is being said by
linking it back to the diagram. Basically, all tasks cannot start until the previous task has been
completed. This is not true for tasks B and C, which can start at the same time. Note that this is the only
tricky area.
Firstly, the project manager has to identify the earliest starting time (EST) for each task. This figure is
then entered into the top right hand segment of the node. To work out the EST's, move from left to right
on the diagram. The diagram below shows all the EST's for the project.
Secondly, the project manager must work out the latest finish time (LFT) for each task. This
calculation is similar to the EST's except that figures are subtracted and the work is from END to
START, i.e. from right to left on the diagram. The LFT is then placed inside the bottom right hand
segment of the node.
Page 116 of 283
The
e Guerrilla Prin
nciple: Winnin
ng Tactics for Global Projec
ct Managers
No
ow the EST's
s and the LF
FT's have be
een calculatted, a critica
al path can be determiined. This iss found
by recognising
g those node
es where the
e EST = LFT
T. By looking
g at the abovve diagram, all the node
es have
equal EST and
d LFT excep
pt for numbe
er 4. By ackknowledging this, the pro
oject manag
ger can iden
ntify the
crittical path as
s:
A-B-D-FG
(Indicated by the arro
ow in the ab
bove diagra
am)
In other words
s, these iden
ntified tasks cannot be d
delayed, oth
herwise the project completion time
e will be
als
so be delaye
ed beyond th
he expected
d 11 weeks ((as per table
e above). Th
his is not true for the tassks that
do not lie on th
he critical pa
ath. So, wha
at can be dettermined fro
om those tassks that do not
n lie on the
e critical
path (C and E))? Well, eithe
er task C or E can be de
elayed by 1 week withou
ut affecting the
t completion time
of the project.
This is called The Flo
oat.
The
ere are two types of flo
oat - the tottal float and
d the free flloat. Only th
hose tasks that are nott on the
critical path will have a floa
at.
The
e total float is
i the accum
mulated floatt up to the specific task. This is worrked out by subtracting
s
tthe EST
and
d the duratio
on from the L|TF:
L
Total Float
F
= LFT - EST - Duration
Lea
arner Notes
s: Get expert help to drraw the first Critical Patth diagram. This should
d enable the
e project
ma
anager to kee
ep on sched
dule.
Tottal Float
Pag
ge 117 of 283
The
e Guerrilla Prin
nciple: Winnin
ng Tactics for Global Projec
ct Managers
Task
Dura
ation EST
LFT
Tota
al Float (wks)
Free Float (w
wks)
(refer back to diagram - click
here)
0 : (1 - 0 - 1)
0 : (1 - 0 - 1)
0 : (4 - 1 - 3)
0 : (4 - 1 - 3)
1 : (4 - 1 - 2)
0 : (3 - 1 - 2)
0 : (7 - 4 - 3)
0 : (7 - 4 - 3)
1 : (7 - 3 - 3)
1 : (7 - 3 - 3)
0 : (9 - 7 - 2)
0 : (9 - 7 - 2)
11
0 : (11 - 9 - 2))
0 : (11 - 9 - 2)
g. For task C,
C the total float = 4 - 1 - 2 = 1 (weekk)
E.g
Fre
ee Float
The
e free float iss worked ou
ut by subtraccting the EST
T at the startt of the task and the durration, from the
t EST
at the
t end of th
he task: Free
e Float = End
d EST - Starrt EST Durration
So
o, again for ta
ask C, the frree float = 3 - 1 - 2 = 0
This is showing that task C can be de
elayed (like all tasks), bu
ut it will havve an effect on the start time of
the
e next task. All
A tasks tha
at calculate zero
z
has the
e same rule applying. Bu
ut, what abo
out those tassks that
callculate a figu
ure other tha
an zero? If the
t project m
manager wo
orks out the free float fo
or task E, he
e or she
will get:
Fre
ee Float = 7 - 3 - 3 = 1 week
w
No
ow, this mea
ans that task
k E can be delayed
d
by o
one week without
w
having an effect on
o the start time of
the
e next task (F).
(
Any dela
ays over thiss time would
d only then affect
a
the prroceeding ta
ask. For example, if
tas
sk E was de
elayed by tw
wo weeks, itt would dela
ay the start time of task F by one week one
e week
com
mpensated by the float, and the other causing o
one week de
elay.
Fin
nally, let's no
ow look at th
he floats for all
a the tasks.
Byy looking at the table, those tasks without a 'total floatt' (i.e. zero)) are consid
dered 'criticcal' and
coiincidentally are
a found on
n the critical path. It is, therefore, im
mportant that these taskss are not delayed in
ord
der to complete the proje
ect on time as
a planned ((11 weeks).
Accknowledging
g and integ
grating float is very im
mportant. Those tasks tthat do carrry float may have
res
sources (lab
bour, capital, equipmen
nt, etc) thatt could be used
u
elsewhere to com
mplete othe
er tasks
quicker. Also, for those ta
asks that do
o carry float, any delayys can be a
accepted un
nless it is su
ufficient
minate the float
f
comple
etely. In succh case, a major probllem has occurred; the project
enough to elim
anager mustt investigate and act imm
mediately.
ma
Chapter 14 ou
utlines the fa
actors need
ded to set d
deadlines.
Pag
ge 118 of 283
CHAPTER 14: SETTING DEADLINES

Having identified how the activities follow on from one another, and worked out the minimum
duration of the project, the project manager can now set real dates to the tasks. It is highly
recommended that potential conflicts are taken into account and not ignored.
TIME MANAGEMENT
Time management is a critically important skill for any successful project manager. The most common
cause of exceeding discussed and approved project budgets is lack of schedule management.
Fortunately, there are many software packages on the market today to help manage project schedules
or timeline. To reiterate statements made in previous chapters:
Tasks include timeframes, available resources and dependency on each other.

Schedules include management of teams and setting deadlines for tasks.
Critical Path is a decision making process to help assess tasks that could run out of timeframes.
Any project can be broken down into a number of tasks that have to be performed. To prepare the
project schedule, the project manager has to figure out what the tasks are, how long they will take, what
resources they require and in what order they should be done.
Each of these elements has a direct bearing on the schedule.
If a task is left out, the project won't be completed. If time or available funds is underestimate, the
schedule may be miss. In addition, the schedule can also be blown if the project manager makes a
mistake in the sequencing of the tasks.
Do the following:
Build a project schedule by listing, in order, all the tasks that need to be completed.
Assign a timeframe for each task.
Allocate the required resources.
Determine which task:
o
o
Has to start first.

Can't start until after each task has been completed.
The difficulty in managing a project schedule is that there are seldom enough resources and enough
time to complete the tasks sequentially. Therefore, tasks have to be overlapped so several happen at the
same time. Project management software greatly simplifies the task of creating and managing the
project schedule by handling the iterations in the schedule logic for you. For more information on such
software, contact me on mentor@magliolo.com.
When all tasks have been listed, resourced and sequenced, the project manager will see that some
tasks have a little flexibility in their required start and finish date. As stated in the previous chapter. This
is called float. Other tasks have no flexibility, zero float. A line through all the tasks with zero float is
called the critical path. All tasks on this path, and there can be multiple, parallel paths, must be
completed on time if the project is to be completed on time. The Project Manager's key time
management task is, therefore, to manage the critical path.
Be aware, that items can be added to or removed from the critical path as circumstances change during
the execution of the project. Regardless of how well a manager manages the schedule and the
resources, there is one more critical element - managing the budget.
Page 119 of 283
ESTIMATING TIME ACCURATELY

The ability to accurately estimate time is a skill essential to good and successful project management. It
is important to get time estimates right for the following main reasons:
Time estimates drive the setting of deadlines for delivery of projects
The sponsor and future potential clients will assess the project managers ability, reliability and skill
according to his or her time management professionalism.
Time estimates often determine contract pricing and hence the projects profitability.
The international norm is to vastly underestimate the amount of time needed to implement projects. This
is true particularly when they are not familiar with the task to be carried out. Project managers forget to
take into account unexpected events or unscheduled high priority work. Managers also often simply fail
to allow for the full complexity involved with a job.
This section discusses how to estimate time on small projects. Time estimates are important
inputs to organise and structure medium and large sized projects. Both Gantt charts and Critical
Path Analysis techniques reduce large projects down into a set of small tasks.
The first stage in estimating time accurately is to fully understand what you need to achieve. This
involves reviewing the task in detail so that there are no unknowns. Inevitably, it is the difficult-tounderstand problems that take the greatest amount of time to solve. The simplest and best way to review
the project is to list all tasks in full detail. Simple techniques such as Drill-Down are useful for this and,
once the project manager has a detailed list of all the tasks that must be achieved, he or she must make
the best guess at how long each task will take to complete. Ensure that this includes time estimate for
detailed project planning, liaison with outside professional bodies, meetings, quality assurance and any
supporting documentation that will be necessary.
Learner Notes: Experience suggests: Make a guess then triple the time.
Make sure that you have allowed time for:
Other high urgency tasks to be carried out, which will have priority over this project.
Accidents and emergencies.
Internal meetings.
Holidays and sickness in essential team members.
Breakdown in equipment.
Missed deliveries by suppliers.
Interruptions from electricity suppliers (particularly in emerging countries, which do not have steady
power supplies).
Interruptions.
Quality control rejections.
These factors could double the length of time needed to complete a project, which is why a tripling of the
time is a good thumb suck technique to pre-analysis accuracy. If the accuracy of time estimates is
critical, the project manager may find it effective to develop a systematic approach to including these
factors. If possible, base this on past experience.
Key points:
The project manager can lose a great deal of credibility by underestimating the length of time needed
to implement a project.
If time is underestimated, not only does the project manager miss his or her deadline, he or she also
puts other project workers under unnecessary stress. Projects will become seriously unprofitable and
other tasks cannot be started.
Page 120 of 283
The first step towards making good time estimates is to fully understand the problem to be solved.
A detailed list of tasks should include all the administrative tasks and meetings to be carried out, as
well as the work itself.
Finally, allow time for all the expected and unexpected disruptions and delays to work that will
inevitably happen.
Use a diagram to help calculate start and end dates for each activity. Begin with the first activity and
work through all the others, starting each as early as possible to allow as much time as possible. If
an activity is not on the critical path, start and end dates can be more flexible, since these will not
necessarily affect the overall project duration.
Finally, plot the dates against a timeline to produce a Gantt chart. These charts are useful for early
schedule planning, for showing individual timelines on complex projects and for comparing progress
to the original schedule.
USING GANTT CHARTS

This chart lists tasks on the left and the project timeline in weeks across the top. The bars show
when tasks start and finish, providing a clear -visual overview of project tasks and timings.
Gantt Charts are useful tools for analysing and planning complex projects and will:
Help to plan out the tasks that need to be completed.
Give a basis for scheduling, when these tasks will be carried out.
Allow to plan the allocation of resources needed to complete the project.
Help to work out the critical path for a project, where it must be completed by a particular date.
Deliverable/
Task
Report Drafted
Task 1
Task 2
Task 3
Report Reviewed
Task 1
Task 2
Task 3
Report Delivered
Task 1
Resources
Example of Gantt chart

PROJECT NAME:
Upgrading Johannesburg Airport
PROJECT MANAGER: Jack Landow
WEEKS
1 2
3
4
5
6
7
8
9
10 11 12 13
14
15
16
Ken
Joe
Ann
John
Ashley
Mark
Erica
When a project is under way, Gantt Charts help to monitor whether the project is on schedule. It also
allows the project manager to identify when a project is running behind schedule and to identify the
necessary remedial actions.
Parallel & Sequential Activities

An essential concept behind project planning is that some activities are dependent on other activities
being completed first. These dependent activities need to be completed in a sequence, with each stage
Page 121 of 283
being adequately completed before the next activity can begin. Dependent activities are called
'sequential' or 'linear'. Other activities, which are not dependent on completion of any other tasks and
may be done at any time before or after a particular stage is reached, are called nondependent or
parallel tasks.
To draw up a Gantt diagram, follow these steps:
List all activities in the plan.

For each task, show the earliest start date, estimated length of time it will take,
and whether it is parallel or sequential. If tasks are sequential, show which stages
they depend on.
Outlined in greater detail on the next page.

Gantt charts are simply a visual representation of a schedule. In a Gantt chart, time is represented along
a horizontal axis and tasks listed down the left-hand side. The duration of a task is then represented in
the body of the graph by a horizontal bar. Milestones are usually represented by single points or
diamonds. Dependencies between tasks are also shown as linked arrows. An arrow indicates the
necessary order of completion for each task and therefore the progress of the project.
To draw up a Gantt diagram (Gant diagram), follow these steps:
List all activities in the plan: For each task, show the earliest start date, estimated length of time it
will take and whether it is parallel or sequential. If tasks are sequential, show which stages they
depend on. The following table is an example of such a list:
Project: Launch of new IT System
possible start
Length
Type
week 1
week 1
week 3
week 1
5 days
1 day
2 weeks
2 weeks
sequential
sequential
parallel
sequential
1
2
1
week 1
week 4
week 4
week 5
week 5
week 7
week 6
week 6
week 6
week 7
week 4
2 weeks
3 weeks
3 weeks
1 week
1 week
1 day
1 week
1 week
2 weeks
1 week
2 weeks
sequential
sequential
sequential
sequential
sequential
parallel
parallel
parallel
sequential
sequential
parallel
4
4
5
6
7
6
5
5
5
1-13
13
1. High level analysis

2. Selection of hardware platform
3. Installation and commissioning of hardware
4. Detailed analysis of core modules
5. Detailed analysis of supporting utilities
6. Programming of core modules
7. Programming of supporting modules
8. Quality assurance of core modules
9. Quality assurance of supporting modules
10. Core module training
11. Development of accounting reporting
12. Development of management reporting
13. Development of management analysis
14. Detailed training
15. Documentation
Head up graph paper with the days or weeks through to task completion
Plot tasks onto graph paper: Next, draw up a rough draft of the Gantt Chart.
Dependent
on...
Plot each task on the graph paper, showing it starting on the earliest possible date.
Draw it as a bar, with the length of the bar being the length of the task.
Above the task bars, mark the time taken to complete them.
Do not worry about task scheduling yet.
Page 122 of 283
All that is being done is the establishing of the first draft of the analysis. This will produce an
untidy diagram like the one below
Schedule Activities: Now take the draft Gantt Chart and use it to schedule actions.
o
Schedule them in such a way that sequential actions are carried out in the required
sequence.
Ensure that dependent activities do not start until the activities they depend on have been
completed.
Where possible, schedule parallel tasks so that they do not interfere with sequential actions
on the critical path.
While scheduling, ensure that you make best use of the resources you have available, and do
not over-commit resource.
Also allow some slack time in the schedule for hold ups, overruns, quality rejections, failures
in delivery, etc.
Presenting the Analysis: The final stage in this process is to prepare a final version of the Gantt
Chart.
o
This should combine the draft analysis with scheduling and analysis of resources.
This chart will show when the project manager anticipates that jobs should start and finish.
A redrawn and scheduled version of the example project is shown below
Page 123 of 283
By drawing this example Gantt Chart, you can see that:

If all goes well, the project can be completed in 10 weeks
If the task must be completed rapidly, the project manager needs:

o
o
o
o
o
One analyst for the first five weeks

One programmer for six weeks starting week four.
One programmer for three weeks starting week six.
Quality assurance resource for weeks seven and nine.
Hardware to be installed by the end of week seven.
Analysis, development and installation are essential activities that must be completed on time.
TWO PLANNING AND SCHEDULING TOOLS

Critical Path Analysis and Program Evaluation and Review Technique (PERT) are powerful tools that
help the project manager to schedule and manage complex projects. They were developed over 60
years ago to control large defence projects. As with Gantt Charts, Critical Path Analysis helps the project
manager to plan all tasks that must be completed as part of a project.
Learner Notes: Scheduling tools act as the basis both for preparation of a schedule and of resource
planning.
During the management of a project, these tools allow the manager to monitor achievement of project
goals. They also assist to see where remedial action needs to be taken to get a project back on course.
The benefit of using Critical Path over Gantt Charts is that the former identifies tasks which must be
completed on time for the whole project to be completed on time and also identifies which tasks can be
delayed for a while if resource needs to be reallocated to catch up on missed tasks. The disadvantage of
Critical Path is that the relation of tasks to time is not as immediately obvious as with Gantt Charts. This
can make them more difficult to understand for someone who is not familiar with the technique.
Page 124 of 283
A further benefit of Critical Path Analysis is that it helps to identify the minimum length of time needed to
complete a project, which helps the project manager to minimise cost, while still achieving objectives.
As with Gantt Charts, the essential concept behind Critical Path Analysis is that a project manager or his
or her team cannot start many activities until others are finished. These activities need to be completed
in a sequence, with each stage being completed before the next stage can begin. These are 'sequential'
activities. Other activities are not dependent on completion of any other tasks. You can do these at any
time before or after a particular stage is reached. These are non-dependent or parallel' tasks.
DRAWING A CRITICAL PATH ANALYSIS CHART
Step 1: List all activities in the plan

o
For each activity, show the earliest start date, estimated length of time it will take, and
whether it is parallel or sequential. If tasks are sequential, show which stage they depend
on.
The same task list (as in the above table, titled Project: Launch of new IT System) is used
as explained in Gantt Charts.
Step 2. Plot the activities as a circle and arrow diagram

o
In these, circles show events within the project, such as the start and finish of tasks.
Circles are normally numbered to allow you to identify them.
An arrow running between two event circles shows the activity needed to complete that
task. A description of the task is written underneath the arrow. The length of the task is
shown above it. By convention, all arrows run left to right.
EXAMPLE: An example of a very simple diagram is shown below:

This shows the start event (circle 1), and the completion of the 'High Level Analysis' task (circle 2). The
arrow between them shows the activity of carrying out the High Level Analysis. This activity should take
1 week.
Where one activity cannot start until another has been completed, start the arrow for the dependent
activity at the completion event circle of the previous activity. An example of this is shown below:
Page 125 of 283
Here the activities of 'Selecting Hardware' and 'Core Module Analysis' cannot be started until 'High Level
Analysis' has been completed. This diagram also brings out a number of other important points:
Within Critical Path Analysis, project managers refer to activities by the numbers in the circles at each
end. Activities are not drawn to scale. In the diagram above, activities are one week long, two weeks
long, and one day long. Arrows in this case are all the same length. And, in the example above, the
numbers are above the circles. These show the earliest possible time that this stage in the project will be
reached. Here units are whole weeks.
A different case is shown below:
Here activity 6 to 7 cannot start until the other three activities (12 to 6, 5 to 6 and 9 to 6) have been
completed. See figure 5 for the full circle and arrow diagram for the computer project we are using as an
example. This shows all the activities that will take place as part of the project.
Notice that each event circle has a figure below it as well as a figure above. This shows the latest time
that it can be reached with the project still being completed in the minimum time possible. You can
calculate this by starting at the last event (in this case number 7), and working backwards.
You can see that event 4 can be completed any time between 1.2 weeks in and 7.8 weeks in. The timing
of this event is not critical. Events 1 to 2, 2 to 3, 3 to 4, 4 to 5, 5 to 6 and 6 to 7 must be started and
completed on time if the project is to be completed in 10 weeks. This is the 'critical path' - these activities
Page 126 of 283
must be very closely managed to ensure that activities are completed on time. If jobs on the critical path
slip, immediate action should be taken to get the project back on schedule. Otherwise completion of the
whole project will slip.
Exceptions
The project manager may find that he or she needs to complete a project earlier than that stated by the
dawn Critical Path Analysis. In this case, the manager needs to take action to reduce the length of time
spent on project stages. He or she could pile resources into every project activity to bring down time
spent on each. This would probably consume huge additional resources. A more efficient way of doing
this, would be to look only at activities on the critical path.
Program Evaluation and Review Technique (PERT)
PERT is a variation on Critical Path Analysis that takes a slightly more sceptical view of time estimates
made for each project stage. To use it, estimate the shortest possible time each activity will take (the
most likely length of time), and the longest time that might be taken if the activity takes longer than
expected.
Use the formula below to calculate the time to use for each project stage:
Shortest time + 4x likely time + longest time
6
This helps to bias time estimates away from the unrealistically short time-scales normally assumed.
Critical Path Analysis is an effective and powerful method of assessing:
What tasks must be carried out.

Where parallel activity can be performed.
The shortest time in which a project can be completed.
Resources needed to execute a project.
The sequence of activities, scheduling and timings involved.
Task priorities.
The most efficient way of shortening time on urgent projects.
An effective Critical Path Analysis can make the difference between success and failure on complex
projects. It can be very useful for assessing the importance of problems faced during the implementation
of the plan. Not only do these ease the drawing of Gantt Charts, they also make modification of plans
easier and provide facilities for monitoring progress against plans, as well as generating resource
histograms.
Breaking down tasks
Page 127 of 283
In the above diagram, it must be noted that Production Phase 1 has been broken down into three sub
phases.
Core database.
Account screens
Sales module.
These have been estimated separately. Together they form the overall estimate for the first production
phase and delivery of the Alpha version milestone. Note that either different people are working on the
core database and account screens (since they are happening in parallel) or someone is working
overtime!
While this visualisation can be a great help in organising a schedule it should be remembered that the
Gantt chart is only a tool. The project manager who constructs the most elaborate and pleasing Gantt
chart is not necessarily the one who will complete his project on time. Far too often project managers are
lured into the intricacies of artefacts like Gantt charts and spend more time constructing them than
managing the project. A Gantt chart helps to design, monitor or communicate a schedule. If it does none
of these then it is simply a waste of time.
Learner Notes: Gantt charts must be kept up-to-date at all times.
Learner Notes: Starting non-critical tasks early, frees up resources later.
LOOKING FOR OVERLAP

To check that the dates calculated are realistic, refer to Gantt charts, commitment matrix and master
schedule. The Gantt chart shows immediately where project activities overlap. Where an overlap
exists, the commitment matrix will reveal whether an activity requires the same resource at the same
time. In these circumstances, the project manager will have to amend that activity's start and finish
dates. The final piece of information comes from looking at the master schedule, which will tell him or
her whether there is any overlap in resources between two or more projects.
Non-critical activities may also be scheduled as late as possible in order to show how much work can
be delayed, without causing the critical activities to slip.
When team members have too many commitments on several projects, It may be possible to reduce
the overlap by assigning some of their activities to others.
Final Check
The project manager must discuss the dates that he or she has set with the key people to make sure
that they are truly available at the time they are needed. On long projects, remember to allow for the fact
that team members will not necessarily be available every day, even if they are theoretically working fulltime on the project. The percentage of time they will be available is often around 66% of the calendar
year. Use that number to check that you have allowed time off for holidays, sickness and training.
Learner Notes: Team members must be realistic about dates.
Chapter 15 is the final part of Stage 2, and outlines what needs to be done to validate the project
plan.
Page 128 of 283
CHAPTER 15: VALIDATING THE PLAN

No matter how well a plan has been written, the unexpected is bound to occur and circumstances
will certainly change. It is for this reason that the project manager must work closely with both
sponsor and project team to predict and pre-empt potential problems.
IDENTIFYING THREATS
By this stage, the project manager has drafted a schedule to assess potential delays and timeframes.
Brainstorming all these activities to determine potential threats is a necessary evil; many project
managers feel that this is a waste of time, as Gantt and Critical Path Analysis would have highlighted
any potential threat to the timeframe of the tasks and ultimately to the overall project.
In fact, it is still important to analyze each potential threat to assess its impact on the overall plan. Deal
with every threat in turn, paying most attention to those that may have an impact on the activities as set
out in the Critical Path; work out the best counterattack in advance.
Learner Notes: Make a point of discussing the final plan with the client, sponsor and customers.
Bring together a representative group of customers and those with relevant experience, and assess what
could, in their opinion, go wrong.
Learner Notes: Use other project managers experience to identify threats.
Pre-Empting Problems
The first step is to organise team members to focus on preventing the problems from occurring. This is
done by asking the team the following question: "What can be done to reduce the probability that each
potential problem might occur?"
For instance, if a clothing store is to launch a summer catalogue, make sure that the launch is in a warm
climate. Often, clothing stores promote their clothing ranges at least a season early. In addition, it would
be wise to launch a new manufactured product after the union wage negotiating period of the year is
over. If key materials are in short supply because of a union strike, in your clients organisation or that of
the supplier, the project manager could find him or herself holding a great document and plan, without
the product.
It is not possible to pre-empt every eventuality that could harm the project. Get the team to consider what
it will do if certain threats occur, and how to minimise the impact of the threats. If the project needs a new
piece of equipment, for example, the project manager must look at what he or she could do if it were to
be delivered late. If the equipment is late, and the project manager does not have a contingency plan in
place, it is he or she that the sponsor will blame if the project fails. In addition, the sudden need for an
alternative plan will probably add to the cost of the project. Bring this to the attention of those in control of
budgets. It will then be necessary to revisit the cost-benefit analysis.
Completing the Plan

Once the list of threats has been made and a strategy to pre-empting problems has been undertaken,
the project manager will be able to decide what changes to make to the plan. Once these alterations
have been made, the plan will be complete. The team has its "baseline" or starting point. It knows what
the situation is now, and what will be the result of implementing the plan. Remember, though, to ensure
that the team is prepared for the fact that the planning and implementation process is rarely sequential. It
is likely they will have to recast some of the plan as activities are carried out and changes occur.
Page 129 of 283
CONSIDER THE FOLLOWING

The more customers who validate a plan, the more likely it is to be implemented.
If there is a strong likelihood that a contingency plan will be needed. Be prepared.
Time spent validating the plan and preparing for problems in advance is rarely wasted.
The entire plan should be double-checked by the project manager before implementation.
Learner Notes: The project manager must always be proactive in planning, i.e. if he or she even thinks
that there is a possibility that one of the team members may be leaving, ensure that a replacement has
been organised.
Learner Notes: Check contingency plans with whoever supplies resources.
Learner Notes: Table the plan, with contingencies, at a review meeting with sponsor , customers and
team members.
Chapter 16 is the start of Stage 2: Project Execution
Page 130 of 283
FINAL CHECK BEFORE MOVING TO THE NEXT PHASE

Planning Checklist
Have appropriate project planning tools and techniques been
1
identified?
Has the project been broken down into tasks?
2
Have costs and schedules been drafted for project activities?
3
Have costs and scheduled been drafted for project resources?
4
Has a milestone chart or Gantt chart been produced?
5
Is there an overall budget plan?
6
Has advice been sought from financial experts?
7
Are estimates accurate?
8
Has the critical path for the project been identified?
9
10 Has a communications plan been developed and incorporated
in the project plan?
11 Is ongoing risk analysis included in the project plan?
12 Are contingency plans in place?
13 Are reporting and reviewing procedures for planning being
implemented?
14 Are appropriate project planning tools and techniques being
implemented?
Comments
Page 131 of 283
STAGE
1
PROJECT
Initiation
STATUS
Planning
Execution
STARTING
Completion
To be completed
Move to:

At the end of Stage 1 Magliolo held a two-day workshop. During these two days a multitude of questions
were asked and worrying issues were discussed, and laid to rest. The full agenda for this meeting is set out in
the Appendices.
Planning A Project: Magliolo discussed the companies goals and visions to determine whether the directors
had realistic expectations or not.
It was assessed that, of the four directors, one did not understand the complexities of listing, and one
wanted to use the listing as an exit strategy.
The new groups vision was to expand skills shortages by employing industry experts.
More importantly, the corporate structure would be to have a holding company (to list), which would
control the two individual companies, which would not become a single unit.
Both entities had brand names that needed to be enhances and not amalgamated into the larger
company. Essentially, there would be a holding company with two divisions.
Magliolo and the appointed team held first strategy session to break down the merger process and listing
tasks into manageable timeframes. It was decided that the following would occur:
The two companies had to be valued; using the same methodologies.

The two companies financials had to be merged.
Formal shareholder agreements had to be drafted and signed.
Once the merger was completed, objectives included:
o Application to the Competition Board for permission to list on an exchange.
o Analysis of the merged entity and new structure to determine whether changes had to be
made to meet listing criteria.
o The business plan had to be drafted to meet AltX criteria.
Meetings schedules were set up.

Magliolo and the team set up a War Room at the Magliolo offices of Business Consultants International.
An information co-ordinator was appointed.
Each team member was given internet access to the documents located in a secure FTP site, called
the Directors Log (a software designed for Magliolo, which enables teams to access information
relating to projects. The system logs and registers of who enters the site, what they choose and when
they submit documentation; for additional information on this log, contact Magliolo on
mentor@magliolo.com)
Gantt Charts were set up.
Constraints were assessed and potential problems identified; the main one being the resistance of one of the
directors to list on an exchange. It was confirmed that an expert in mechanical engineering had to be
appointed to assess the local industry and potential problems that could impact on the final delivery.
The plan was validated by the team and ratified by the sponsor.
Page 132 of 283
STAGE 3:
PROJECT EXECUTION,
CONTROL & MONITORING
The success of a project plan relies on the people who execute it. Therefore, the project manager
must have leadership skills necessary to build a strong, committed team and guide them to the
final deliverable.
After a plan has been approved, its time to get to work. However, getting to work does not
equate to completing tasks that meet project specifications, i.e. the task must complete part of
the project. its important to continually monitor the progress of the project to make sure it stays
on track.
The only way to do so in a rapidly changing global business environment, is to continually
assess and determine if any new risks have risen that werent anticipated in the original risk
analysis.
Page 133 of 283
LESSONS LEARNED: EXECUTION

This Stage is also called Managing The Process. So, lessons learnt during this stage include:
To hold regular meetings with the project team, to included task and project reviews.
To do this at interim stages and at the end of a task:

o
o
Assess whether this is on schedule and budget.

Did the task achieve what it set out to do?
At key points in the project, such as at the end of the Execution Stage, at a Gateway Review or when
an important milestone has been achieved, the project should be reviewed to determine what key
lessons have emerged.
This will enable the lessons to be captured while still fresh in people's minds. It will also enable them
to be applied to the remainder of the project. As this is an interim review, keep the process short and
simple.
Involve as many of the project team in the process as possible. One way of doing this is to hold a
short brainstorming meeting.
Review project documentation to see what lessons have arisen, especially:
The Lessons Learned Log

The Risk Register
The Issues Register
Summarise the lessons in a brief document which can then be shared around the project team and
copied to the information co-ordinators office where relevant.
It will also help when completing the more formal Lessons Learned Report at the closure of the
project.
Set out what went well during the period, what went less well, what might have been done differently,
what unforeseen problems arose and what did you do about them.
Page 134 of 283
CHAPTER 16: ROLE PLAYERS & TEAM

BUILDING
To successfully implement a project plan, the project manager, team members and all relevant
parties must understand what is involved at the outset. Key tasks, responsibilities and skills
involved must be verbalised and written down, and the project manager must be prepared to lead
the project team successfully.
PROJECT MANAGEMENT ACTIVITIES

After the project plan is approved, its time to create the final deliverables. In most projects, team
members or sub-project team members go off and work on producing their own deliverables. This is the
delivery of the task that has been assigned to them. Most of the execution stage involves co-ordinating
team members and amalgamating delivered tasks, which ultimately becomes the final product or
services that is delivered to the client.
Hopefully, the project manager has a solid project plan to work from, because not only is execution the
longest phase, but it also consumes most of the resources; time, effort and money. If the project
manager has followed the laboriously long winded instructions in the previous chapters on project
planning, he or she will be in great shape as they move into the execution phase.
As the work is getting completed, there are four basic project management activities that will need to be
performed:
Monitor the environment factors that influence business, i.e. Economic, business, political and
technological.
Change management, which is assessing risks and monitoring the project.
Track progress.
Communicate progress to sponsor and team members.
Project Meetings
The four activities outlined above are primarily done during the project team meetings, which are periodic
meetings with the team to make sure the project stays on track. The frequency of the meetings will
depend on the length of the project and the amount of activity going on. The following guidelines can be
used to determine how frequently the team should have meetings:
Length of Project
< six months
>six months, but < 1 year
>1 year
Meeting Schedule
Weekly or fortnightly
Fortnightly
Monthly
At each team meeting, the project manager will review the deliverables that were completed since the
last meeting and look ahead to deliverables scheduled for completion before the next team meeting. A
general rule of thumb is that there shouldnt be more than six deliverables completed between one team
meeting and the next. If there are more than six deliverables scheduled to be completed before the next
team meeting, consider adding another meeting to the schedule.
Leaner Notes: There is no straightforward rule about how often to have team meetings.
Page 135 of 283
The Magliolo Methodology is to have regular meetings with the consultants, but apart from the whole
team. These meetings take place weekly and the full team monthly. It is better off starting with more
frequent meetings and then postponing them if they arent needed.
Meeting Attendees
Team meeting should include the project leader, the members of the main project team, and any ad hoc
members, who have been invited to the meeting. If the project is small, the members of the main project
team will be the people doing the work. If the project is large, the project team members will consist of
sub-project team leaders. These sub-project leaders should meet with their sub-project teams, covering
the same agenda items, before they attend the main project team meeting.
Before the team meeting, project team members should prepare a status update on their project tasks.
That means each team member should be prepared to report on the progress of his or her portion of the
scope, risk, schedule and budget.
Each will be covering more or less the same topics each time they meet, so the following is a typical
agenda for either a project team or sub-project team meeting.
A. REVIEW
o Current status of the project: Team members should review the status of their projects and
state:
What was supposed to have been completed.
What was actually completed.
Provide reasons.
Complete the status report form.
o
Discuss potential problems:

Monitor the environmental factors for any new, potential problems that were not
anticipated in the risk assessment.
Decide what to do about problems that might occur.
B. STATUS REPORT.
o Review requests for changes to the plan. Review the justification and develop an impact
analysis for pending change requests.
o Review and update the issues list. Discuss the resolution of pending issues. Add any new
issues to the list. Complete the status report form.
o Remove issues that have already been resolved.
o Recognise accomplishments. Thank team members for the work that has been done.
Page 136 of 283
Evaluate the meeting. Do a quick check on how well the meeting was conducted so that it can
be improved for the next time.
DEFINING RESPONSIBILITIES
As project manager, he or she will have overall responsibility for the project's success. Having negotiated
the planning process, he or she must now translate the plan into action. This involves selecting the right
team members, focusing and motivating them to achieve project and task goals. Some project books
advocate that team members should be helped to develop both as individuals and as team workers. The
author suggests that this should be left up to the company to do and not the appointed project manager.
Learner Notes: Know the project plan inside out and answer questions authoritatively.
Learner Notes: Keep the business priorities in mind, especially when the project goal is to make a profit.
Leadership
A successful project manager is both a manager and leader. Leaders command authority and
respect, follow up plans with actions and are able to inspire and motivate others. They also adopt
different leadership styles as circumstances dictate. These skills can be developed through training
and experience. Mainly, leadership skills are developed by taking responsibility for objectives. The
project manager may have to start by becoming accountable for a group of activities before he or
she you can take on an entire project.
To be an effective leader, the project manager must develop several important attributes. The following
shows some of the essential qualities of a successful project manager:
Question
YES NO
Are you willing to stay with the project for its entire term?
Are you interested in developing people and helping them to become leaders?
Do you have a real interest in working on the project?
Can you delegate objectives to the team as well as tasks?
Assessing Yourself
If the project manager is not sure whether he or she has what it takes to be a leader, ask someone
whose opinion he or she respects for objective comments. For example, the project manager should
talk to people with whom he or she has worked with in the past to ascertain how they regard them. If
they plainly feel that they could work with the project manager, then that is a good indicator. Once
facts have been gathered, the project manager must create a picture of where he or she wants to be
in the future, and put together a plan for developing the necessary skills.
Defining the Project Managers Role
Page 137 of 283
Negotiating Skills
Negotiation is the process of achieving consensus, while avoiding conflict. Central to this is the
understanding that the best solution to a problem is one which attracts the consensus of all those
involved. A unilateral solution is by definition not the best solution since it alienates or disappoints
someone. Finding the best solution will involve compromises and the project manager will be the fulcrum
around which the discussions between different parties revolve. Most people view discussions as a zerosum-game. That is, in order to win or succeed, someone must lose.
Example: a salesman might believe that he will win if he can convince someone to buy a product at a
high price. This is a zero-sum attitude, the salesman has won and the client has lost. A client on the
other hand might not care about the price and might be willing to pay if the product has the right features.
If the salesman can work out what the client wants, he or she might be able to sell him or her the right
product. Further, if a particular product doesn't have those features, the salesman might be able to drop
the price or offer other incentives that will convince the client to buy. If he or she achieves this, then they
both win.
Problems can be broken down into a number of elements which, when handled separately, produce
trade-offs by which the project manager can achieve a win/win solution. This is a solution where both
parties walk away happy. There are countless times when the project manager will have to hone
negotiating skills. The first time will be when he or she meets the client and his or her allocated sponsor
to the project. The project manager will have to negotiate a professional fee for undertaking the project, a
budget for the profit and fees for consultants and funds for contingencies.
Then, during the project, the manager will have to negotiate with researchers, customers, and specialists
when necessary. It has been said that the professional project manager is actually a high flying, power
dressing salesman. While the author would not agree with such sentiment, there are many times that
negotiating skills are required to produce a better and more efficient project.
The Project Managers Negotiation Tool Kit
Listening and understanding is fundamental to negotiation. The project manager must understand
the proposal under discussion and the options available. He or she must understand what each party
involved in the discussions seeks to gain from the discussion. If the discussion is composed of
groups of individuals the manager should understand the goals of the individuals and the goals of the
groups.
o
How can the manager know what the sponsor wants? He of she listens carefully, asking
questions to ensure that he or she completely understands what will be required in the
completion of the project.
The project manger must ask him or herself the following question: What do I bring to the
table and what am I prepared to concede. By knowing what there is to trade the manager
can enter the discussion with an open mind and flexibility.
Empathy is understanding the emotions of those involved. Emotion can cloud communication or it
can enhance it, but it cannot be excluded. By understanding the basic feelings of individuals in a
negotiation, it is possible for the project manager to appeal to them on a more direct level, than
simple logic.
Trust and honesty: Successful negotiations are built on trust. Without trust there can be no true
compromise and, therefore, no solution. If the concessions offered are insincere or grudging, then
the manager will get an equally grudging response from other parties involved. Often, it is the
responsibility of the project manager, who holds a pivotal position, to take the lead by establishing a
basis of trust between the parties involved.
Page 138 of 283
By setting the standards, a project manager establishes the basis for negotiations and the
tone in which they are conducted. This can often be done by a simple appraisal of the facts
and an appeal for assistance to the parties involved.
Project managers are usually secretive, given that commercial disclosure is often
contractually forbidden. Naturally, projects can provide a client with a competitive advantage
over competitors and, thus, the project manager and his or her team have limited disclosure
powers. When this happens, honesty with the team mates is a must tell them that
contractual obligations forbid disclosure. Answer questions directly and act as a conduit of
information for the team and not a barrier. If information cannot be divulged, say so. The team
will appreciate honestly and reciprocate by relaying information and producing honest and
accurate estimates.
Contribution: When discussing each members expected contribution to the project as a whole,
problems will occur. These should be clearly stated and agreed upon and solutions offered. During
this stage of the discussion, it is essential that all parties contribute. Silence is not acceptable.
Everyone in the team should assist in trying to find the most plausible solution. Failure to do so will
leave one or more parties feeling disenfranchised and disenchanted.
Consensus: Once the various solutions have been discussed a possible solution can be proposed
and if it is acceptable to all, taken forward. If not, some form of compromise must be hammered out
and each party must be ready to conceding elements of their requirements in order to find a solution.
Each party must then signify their willingness to accept the compromise and move forward.
Building a team: The author winces violently when it is suggested that team building should take
place before a project is officially commissioned. Rather than the fatuous team building games often
encounter at companies, the author prefers to interview professional consultants individually and
then to introduce them to the team.
Equality: A serious mistake that some project managers make is to treat members of the team
differently; criticising some in public, other in a personally manner. Being criticised in public, in front
of your peers, is not a motivating force for anyone. If there is a project issue that needs to be
addressed, it should be broached in person first, then as part of team discussions. By sharing the
burden for issues, most teams pull together to resolve the problem. Open discussion of the problem
will encourage the team to take ownership for the problem and solve it themselves; anything else
often causes resentment, which is not conducive to efficient project management.
Loyalty to the team: There is always a conflict between loyalty to the client, who after all has
commissioned the project, and loyalty to the team members. Usually, these two aims should be
neatly aligned but not always! In a situation where you have to choose between the two you need
to take the difficult moral stance. Discuss the situation with the team and come up with a solution and
present this to the client.
Delegate: When dividing up work among the team members, ensure that delegation has been done
properly, which entails laying out the task so someone understand its, so that it has reasonable and
achievable goals and so that you give them all the support they require to get the job done. It also
entails giving them enough room to get the task done on their own. If you leave the execution of
tasks to them they will, in return, leave you alone to get on with your job.
Roles & Responsibilities

All projects are different, which means that the project manager must be versatile and well versed in
many spheres of the economy and socio-political issues. As such, each project will need a unique
approach, but one that fulfils clear and unambiguous message. Look at the following:
If the ultimate source of authority is unclear: members do not know who is leading, which results in
poor leadership and poor deliverables.
Page 139 of 283
Team members must know their responsibilities, or they will not do what they need to do to make the
project successful.
Without proper channel of authority, decision making will be slow.
Poor communications will lead to complications as tasks are not completed on time.
If no-one takes responsibility of the project, a lack of accountability results in little incentive to do
things properly.
If resources are not committed, the project will stagnate.
Without clear objectives, the project will vacillate and ultimately fail.
So, before any project begins, the project manager must ensure among very many other things:
A clear management hierarchy exists for the project.

Each team member has a defined and agreed set of responsibilities.
People will be held accountable by their line manager for performing their project role, completing
tasks and communicating results to the project manager.

How much do you really know about the people chosen as team members?
Can you ever be comfortably with the members that you have chosen?
Does the team member have the necessary skills and talent to do the job?
Learner Notes: Try The project manager must, when choosing team members, try to be as objective as
possible.
Role of the Client (owner of the project)
A project exists to satisfy a client. The project client is the recipient of the main output of the project,
called the final deliverable. In order to make sure the final deliverables satisfies the client, the client must
convey to the project team what the needs and requirements for the deliverable will be.
A client can be internal or external to the organisation.
Most projects are done for internal clients, although the final deliverable, produced by the project, might
eventually be distributed to or purchased by an external customer. Most projects are done for internal
clients, who then represent the needs of customers outside the organisation. However, some projects
are done directly for an external customer. In these cases, the customer usually pays for the final
deliverable directly. An example would be a project in a consulting firm to develop a customised piece of
software for an external customer. The external customer would pay based on time and materials or as a
flat fee for the project.
Whether the customer is internal or external, there are certain similarities in the role they must play
within the project:
Provide the project team with a clear picture of their needs and requirements.
Review and approve the scope.
Participate on the project team where appropriate.
Inform the project leader of any changes in the environmental factor, that would affect the project
deliverables.
Approve changes to the project, when needed to make the project a success.
Review project status reports.
Page 140 of 283
Provide feedback to the project leader on a regular basis.

Evaluate the final deliverables as well as the project process.
Review and approve the entire project plan.
Review the final status report.
Here is an important notice: If the project manager accepts an appointment to head a project with an
external customer, it is imperative that he or she has an internal sponsor working on the project. The
internal sponsors job is to balance the needs of the external client with the needs of the internal
organisation.
Role of Project Sponsor
The following responsibilities should be carried out by the Project Sponsor, who really is the person
appointed by the owners of the company to keep an eye on the project. In many companies this will
simply be the managing director or someone appointed by him or her. Roles can vary, but the norm is for
him or her to fulfil the following:
Accountable for the project. In companies, Board of Directors hold sponsors accountable, who may
in turn become interested in who is managing the project for them - their fate is partly in the hands of
the project manager.
Select, or at least approve, the project manager.
Acquire funding for the project from the Board of Directors (the client), or whoever it is that authorises
funds for projects.
Champion the project, promote and support it in high places.
Own the project's business case.
Accountable for realising benefits once the project is delivered.
Give the project manager the go or no go at the start of each project stage.
State and own the project's objectives and agree with the vision of the project manager.
Make a presentation at the start of a project to explain why the project is important.
Sort out problems or issues which the project manager can't sort out.
Accountable for legal compliance of the finished product.
In really large, multi-million rand projects, chair the project steering committee.
Empower project manager to manage the project.
Commission post implementation business case review.
How much work is involved in being a sponsor will always depend on the sponsor and his or her trust in
the project manager. It should really only be one or two days a month, but it may be everyday so it is
suggested that the project manager sets the parameters before starting the project. There is no reason
why it cant be part of the appointment letter.
Learner Notes: The trick is to have a sponsor who is senior enough to have decision making powers,
but junior enough to be interested in the project if it's a small one.
Page 141 of 283
Another problem can arise if more than one person takes on the role of sponsor. Under such
circumstances, the project manager will not know who was in charge. Always insist on one contact within
the clients firm: one sponsor or reject the appointment. There will always be other projects.
Role of a Project Steering Committee
Ion really large projects, that involve significant funds and other resources and timeframes that span
years, the company is likely to appoint a steering committee, which will comprise the heads of those
parts of the company that are significantly involved in or affected by the project. For instance, if the
project is for the Marketing division, perhaps the Marketing Director would be the sponsor and the client
would join him or her on the Steering Committee. The norm is that the sponsor would be the managing
director, assisted by the divisional head and the companys financial director.
Who decides who should be on the steering committee? The sponsor should, but the project manager
should make strong representations and suggest who would add value, who would actually help the
project to succeed - that's why they're there, after all. Also agree with the sponsor when the steering
committee should meet: the frequency may well vary during the project's life and agree the mechanics of
steering committee meetings: who will chair them (the sponsor), who presents what, etc.
A steering committee can be problematic, cause delay by not making decisions and meddle in the detail.
By contrast, a good steering committee can be a tremendous asset to a project. What is the role of a
member of the steering committee - what would you want them to do to help you, what would you want
them not to do? The project manager would want them to:
Help the project manager secure resources. The steering committee should have the authority to
make financial decisions.
Interact with other steering committee members to resolve inter-departmental disagreements.
Make timely decisions.
Publicly back the project manager's decisions.
Support the project.
But, as suggested above, the project manager does not want them to:
Meddle in the detail.
Keep changing their minds.
Play politics.
Undermine the authority of the project manager.
Remember that it is the project managers task to make sure the steering committee members
understand their role. A successful project manager is one with leadership skills to ensure that everyone
knows what their roles are in the project, who is running the project and who is in charge. Even when a
project manager is a relatively junior person, courage is required, but he or she must stamp their
authority quickly. It is not without reason that good project managers get paid a lot of money.
Does every project need a steering committee? Not really.
Project Managers Role
The project leader is also referred to as the project manager. However, in a participative approach, the
main role for the project manager is leadership, so many authors refer to him or her as a project leader.
Page 142 of 283
The main role of the project manager is to:
Provide direction to the project team.

Lead the project team through the project management process (creating and executing the project
plan).
Obtain approvals for the project plan.
Issue status reports on the progress of the project versus the plan.
Respond to requests for changes to the plan.
Facilitate the team process, which is the interpersonal process by which team members develop as a
team.
Remove obstacles for the team so they can complete the project.
Act as the key interface with the project sponsor.
Act as the key interface with the project client.
Call and run team meetings.
Issue the final project report.
The essential role of the project manager is to lead the project team through the project management
and team processes so that they complete the project successfully. The project leader is accountable for
the overall success of the project.
Project Team Members
Project team members sit on the project team their role is to:
Provide technical expertise.
Provide ideas that can help the team create quality deliverables, on time and within budget.
Ensure that his or her part of the project work gets completed on time.
Communicate issues back to the project team.
Participate in the project planning process.
Interface with the suppliers for his or her area.
Keep the boss informed on project issues, as required.
Keep the commitment he or she makes to the project.
Help to keep the project on track.
Provide updates to his or her resource manager on the status of the project.
Help to keep the team process and content on track.
The project team member has an active role to play in a participatory style of managing a project. The
project team member not only provides technical expertise and produces deliverables, but he or she also
helps in the planning and monitoring of the project. The project team member is accountable for ensuring
that his or her work contributes to the overall success of the project.
Creating a Strong Team
Project managers will lament the fact that, in any team, they will find members who do as little as
possible, while others will work 24 hours a day if required to do so. To operate efficiently, the project
manager, as the team leader, must allocate tasks to the members to get them active in the project; in
addition to the project tasks allocated to them. For instance, the project manager will want someone to
perform the roles of critic, external contact, coordinator, ideas person, team builder and inspector. Most
team members will fit strongly into one or more of these roles. The project manager needs them all, and
if one is not present, that role will have to be conducted by him or herself. The secret is to keep
challenging the team throughout the project.
Many authors ascribe to the philosophy that projects are done through people and, therefore, part of the
role of the project leader is leading a team. While that may be correct, professionals do not need to be
pampered, trained or continually reassured. Get a team together that can work independently and as
part of the team; each are equally important. Most projects require a diversity of skills, experience and
specialised expertise in order to create the deliverable for the client. That means a group of people will
be needed, with each person contributing something unique and each one depending on the others to
Page 143 of 283
get his or her task completed. By developing group members into a team, the project manager can
manage the inter-dependence in such a group.
The following seven key elements can help the project manager to create a solid and coherent team.
1. Create a sense of ownership
The sense of ownership brings with it the feeling of self determination. This is very different from the
feelings that arise when you are at the behest of someone else. Self-determination is motivating; being
on the receiving end of delegation is not. When people on a team work together to create a project plan
and monitor and control the project, they take ownership not only for their own work, but for the entire
project.
When the team owns the project, they have a sense that they are all in it together, which is fundamental
to building a strong team. The Magliolo Methodology states this simply: each professional consultant is
appointed to deliver a specific task, which he or she effectively owns. When that task is implemented into
the project, he or she must be there to ensure that the task is implemented correctly within the overall
project. This makes him or her part of the team.
The ultimate reward is shared by the team members when the project is finally launched.
2. Simplify the project
When team members understand what is required of them and explained how their tasks will fit into the
overall project, the project manager can be relatively sure that tasks will be carried out properly. In
effect, when team members understand the project, they are more effective as individuals and more
effective as a team. They are also more motivated, because through understanding they engage not only
the mind but the heart as well.
When everyone understands the whole project, misunderstandings among team members are
minimised. Understanding can best be achieved through team participation in the project management
process, which creates ownership, understanding and helps to build the team. Team participation is not
the same as team building.
Team building is an activity that is directed at getting people to better understand and trust each
other. It usually has very little to do with understanding the work that must be accomplished. As a
result, when people return to doing the work after the team building is over, the same work conflicts
erupt again. What really counts is not artificial team building, but involving the team in the real
decision making for the project.
If team participation is so effective, why dont more people do it? First, they claim that they dont
have the time for participation. Participation does require more time during the planning stage, but
planning is neither the longest stage nor the stage that consumes the most resources. That stage is
execution, and lack of team participation during planning adds even more time to the execution
phase.
3. Inspire People
Projects need to be meaningful to the people who work on them. To make a project meaningful to the
team, then project manager needs to connect the project to the strategic goals of the organisation. The
team members need to know that the client supports the project and that the results of the project are
important to the organisation. In spite of the fact that people will get paid whether or not the work is
important, they dont want to waste time on busy work. They want to do work that makes a difference.
As people understand more about the project, it will become more meaningful to them, assuming the
project is needed by the organisation.
Page 144 of 283
4. Use team-based tools

Team-based tools allow the entire team to participate in the project management process, whether that
involves planning, decision making, idea generation or conflict resolution. Tools provide a structured way
for everyone on the team to contribute and make help in making logical decisions that will benefit the
project as a whole.
When consensus cannot be reached, the project manager must step forward and make the final
decision. However, using team-based tools does help the group reach consensus with minimal conflicts.
Team-based tools should incorporate all three sensory learning styles:
Visual learners need to see what is going on. They take in information through visual means, written
documents, flip charts and overheads. Team-based tools should make visible everyones inputs,
ideas and comments. This is typically done by working with self-stick notes on flip-chart or banner
paper taped to the wall. In this way everyone sees the same set of information.
Auditory learners learn by hearing and talking. They need to be involved in a discussion in order to
fully comprehend the issue at hand. When a decision is reached, it is important to restate the
decision verbally and ask for verbal agreement from team members. Team-based tools should
include a vehicle for discussing the ideas or issues being worked on.
Kinaesthetic learners learn best while doing or sensing. They need to get the feel for the ideas or
issues and they do this best while physically moving around. Team-based tools should incorporate
movement in the exercises, where team members move self-stick notes from one place to another,
physically organizing the ideas being worked on. The team-based project management tools well be
covering in this book cover all three sensory learning styles.
Essentially, sensory learning styles are the ways in which individuals take in and process information. By
using these tools, the project manager will ensure that everyone on the team is engaged in the process
and is taking in and understanding the information being presented.
5. Display appreciation
When the team is valued, it performs better. Not everyone on a team will feel valued in the same way.
However, there are some standard ways in which to value people and teams:
Recognise accomplishments.
Thank people for the work they do.
Celebrate successes.
Respect each persons inputs and opinions.
Stand up for the team.
Be honest.
The project manager will need to take time at each team meeting to recognise accomplishments and
thank people for their contributions. In addition, when significant accomplishments are achieved, take
time for a small celebration. As important as recognition and celebration are, its equally important for the
team to feel that the project manager is on their side, and if they take a risk, he or she will support them.
In fact, the project manager should be the shield that stands between them and the outside world,
providing them a safe place to work on the project.
6. Build trust and respect
Trust takes time to build. Although trust is built slowly, it can be destroyed in an instant and when it has
been destroyed, rebuilding trust takes a very long time. Therefore, the project manager must take time to
develop and maintain trust between him or herself and the team, and between members of the team.
Tips for building trust include the following:
Honour diversity of thinking, learning, and other individual differences.
Page 145 of 283
Dont make promises that cannot be kept.

Keep commitments.
Maintain confidences.
Value each persons inputs and ideas.
Be honest.
Use good people skills.
Use good facilitation skills.
Eliminate blame.
If the project manager does do something that is distrustful, admit the mistake openly, make amends,
and publicly apologise to the member of the team, when the team is present. That will help you to rebuild
trust. Project managers, who are open and honest, will tend to attract the best professionals to work for
him or her.
7. Empower the team.
Empowered teams are usually more effective than disempowered ones. An empowered team is one in
which decision making and responsibility has been pushed down as far as possible. When a team is
empowered, they take more accountability for the outcomes they must produce. In addition,
empowerment allows the team to share the burden of the project with the project manager. To properly
empower a team you need to do the following:
Clearly define the roles that each person involved with the project will play and hold each person to
those roles.
Clearly define what is expected from the team and from each individual on it.
Provide adequate resources to get the job done. It is the project leaders task, in co-ordination with
the sponsor, to ensure that the team has the resources to complete the project. If, after planning,
there are not sufficient resources to produce the final deliverable, then the project leader must
negotiate with the sponsor for more resources or for a change in the scope. There is nothing
motivating or empowering about trying to get a job done without adequate time or money to complete
the task or without the resources that were promised.
Ensure that team members have the skills and knowledge to get the job done. Make sure the team
has the project and team skills it will need to be successful.
Clearly define accountability for results. Empowerment carries with it the burden of accountability, to
answer for the outcomes that are assigned to you.
In addition, there must be a feedback mechanism, so that the project manager and the team know
how well each person has fulfilled his or her accountability.
Most project managers have been trained to be content driven. They make the decisions and solve
problems. But this focus on content does not produce great project results. In order to let go of control
and empower the team, the project manager will need to help the team clearly define what needs to be
done, who is accountable, when it needs to be completed and then make sure people have the
resources and skills to get the job done.
You should require regular reporting from the team on the deliverables or issues assigned. This closes
the accountability loop; accountability has been assigned and the person accountable reports back on
the fulfilment of that accountability.
These seven basic principles will help you create a more effective team. But teams dont just emerge,
fully formed, and performing at peak capacity. They evolve, through stages.
Page 146 of 283
FIVE STAGES TO PROJECT TEAM DEVELOPMENT

Stage 1
Stage 2
Stage 3
Stage 4
Stage 5
Initiation Vying for position Focusing on the project Unison Celebration
The aim is simple: the project manager must carefully choose members that will successfully traverse
the initiation stage of team building, as the norm is that such members will naturally move on to the next
stage of development.
Stage 1: Initiation
The first stage occurs when the team comes together for the first time and the focus tends to be on
answering the following questions.
Why are we here?

What is my role in this endeavour?
Who are these other people and how will we get along?
Whats the project leader like and how will he or she run this project?
In this early stage, team members are naturally polite, given that mostly they will be strangers. They are
waiting to see what will happen.
Stage 2: Vying for position

Soon after the initial meeting and once they feel comfortable enough to assert their authority, the
unnaturally polite state is broken. Disagreements arise about what needs to be done and who will do it.
Groups may divide into opposing factions. The more difficult the goals for the project, the more vocal the
stage will be. Having a strong common goal for the project is one of the most important driving forces to
resolving conflicts. The authors methodology is to appoint every one of the consultants for their very
different skills, so the stage 2 still exists, but to a lesser degree. No-one has any position to via for, as
these consultants have been contractually appointed.
The wise project manager sees this stage as useful to create understanding, alignment and ownership.
This is when people merge their individual perceptions of how the project should be done and mould a
group perception. This stage may last through much of the planning process.
Stage 3: Focusing on the Project

If the team resolves its conflicts, it moves on to the next stage of development. By this stage the projects
goals, roles and boundaries have been clarified and accepted by team members. They have taken
ownership and accountability for getting the work done. The stage usually emerges at the end of
planning or in the beginning of the execution phase, depending on the complexity and controversy
associated with the project and with the project managers skills at working through the first two stages.
In stage 3, people get on with doing their own work. This stage comes as a big relief to both the project
leader and the project team members.
In this stage, there will be a need to hold regular team meetings so that the members can monitor
progress and solve problems as they arise. The project manager will also want to focus on his or her
team skills, such as:
Holding effective meetings.

Practicing active listening.
Providing constructive feedback.
Resolving conflicts.
Making team decisions.
Page 147 of 283
If the project manager has effectively completed the first two stages of team development, he or she may
quickly reach the next stage of team development, where the highest levels of performance are usually
reached.
Stage 4: Unison
In this stage the team becomes a true team, working in unison, supporting one another. There can also
be a tendency for the team to start to slow down as the project seems to get closer to completion.
Remember that the project manager still needs to attend to the project management process as well as
managing the dynamics of the team. It is also crucial to recognise accomplishments and celebrate
successes.
In all honesty, the general rule is that not too many teams reach this unison stage. In fact, some teams
never make it past stage 2. However, if the project manager is successful, then he or she may have an
additional challenge on his or hands, namely, disbanding of the team after celebrating the projects
completion.
Stage 5: Celebration
People dont like to leave a high-performing team, because they feel good about themselves and what
theyve accomplished together. For most people, this is an infrequent experience that makes it difficult to
let go. However, all projects by definition are temporary and so inevitably the peak experience must
come to an end. In this stage its important to both celebrate and to mourn. Celebration should have
been a theme throughout the team process and this is the time for a final celebration of the overall
achievements of the team. Also, its time for closure on the team process; saying goodbye to friends and
associates.
A closing ritual can be helpful to help bring a close to the project.
Chapter 17 looks at how to launch a project on a positive note, starting with the first meeting.
Page 148 of 283
CHAPTER 17: THE FIRST MEETING

Once the right project management team is in place, experienced project managers will
recommend that an immediate launch of a new project takes place. Start positively, by inviting
everyone concerned with the plan to an informal gathering, and record the project's existence
formally to clarify its purpose. There is no reason why projects should only end with a
celebration; why not also start with a bang.
START WITH A BANG

At an early stage, gather the team together for a full initiation session to let them know exactly what the
project is all about. Explain what the targets and constraints are, let everyone know how the project will
benefit them, and establish ground rules relating to the sharing of information and decision-making. Keep
the session two-way, so that people can ask questions. By the end of the meeting, everyone should
understand what needs to be done and feel motivated to achieve it. They must also know exactly who is
in charge of the project.
The first meeting must make all the project parties feel welcome and comfortable that the commissioning
of the project was the right thing to do. Remember that this is the first time that the project manager can
display his or her skills and experience, by making a solid presentation, speaking clearly and with
knowledge and, of course, to the client, sponsor and team members. Conversely, this first meeting also
offers the sponsor the important platform to address the team and express his or her belief and
commitment in the project. This is invaluable for encouraging team spirit.
Learner Notes: Listen to reactions from all those who attend the first meeting and be prepared to review
activities.
Learner Notes: Ask the client, sponsor and appointed consultants to attend the project launch.
The project manager must always remember that the kick-off meeting sets the tone for the entire project.
It is not only the project manager that will evaluate team members, but rather team members will be
evaluating the project leader at this first meeting. They will quickly assess how the project manager will
lead the team, what style he or she will use, strengths and weaknesses. They, too, will be evaluating the
project and wondering whether it is meaningful, matter to the organisation, can it be done, does it make
sense, what will the challenges be and can these be overcome? Therefore, it is important to plan the
kick-off meeting carefully, so that the project manager kicks off both the project and the planning stage
immediately.
The First Meeting

The following are suggestions for project managers to successfully lauch the project:
Room: Reserve a large room, away from the offices of the client, sponsor and any of the project
team. Plenty of space is needed for everyone to sit comfortably. Try to find a room without too many
windows, which cuts down on the distractions and also gives you more wall space to use.
Seating: If the team is small (10 or less), seat everyone around a rectangular table. If the group
consists of more than 10 people, use a large rectangular table. Do not seat people in classroom
style, where the chairs are lined up in rows that face forward. That configuration suits a
lecture/directive approach, not a participative one.
Supplies: The manager will need at least one easel with flip-chart paper and plenty of markers. Also
bring masking tape so you can tape the flip-chart paper to the wall. Note: These guidelines for
meeting set-up should be used for all team meetings, not just the kick-off meeting.
Page 149 of 283
Meeting Agenda
An agenda should be issued before any meeting, and the kick-off meeting is no exception. The following
is a suggested kick-off meeting agenda:
Introductions
Introductions are important, because they help people get to know one another. During the management
session, have all members introduce themselves, providing their names and the department they
represent. During the working session, ask all members to introduce themselves again, this time
explaining what they do and providing the team with a description of their background. This will help the
team identify what each member brings to the table that could be useful for the project. It will also help
the team begin the process of team formation. If people in the group already know one another, its still
useful to do introductions.
Do not embarrass anyone, but begin the process of breaking the ice.
Create a Sense of Comfort
One of the project managers goals in the initiation stage of team development is to help people to feel
comfortable as a part of the team. One way to do that is to include an icebreaker in the kick-off meeting,
which should:
Promote interactions between the participants.

Not make people feel uncomfortable.
Reveal something about the person and/or group that is relevant to the project.
Have fun, but be brief.
Review the Scope of the Project

Its important that everyone understand the expectations that have been captured in the project scope.
Provide copies of the scope for both team members and invited guests. Have the sponsor review the
scope with the management team guests to get their inputs and concerns. The sponsor should address
their concerns or issues during the meeting, if possible. If they cannot be addressed, the project leader
should put them on the issues list for resolution at a later date. When the management guests have left
the meeting, review the charter again with the project team:
As every section is reviewed, the project manager must ask for questions, suggested changes and
additions/subtractions. The questions, issues, ideas and inputs must be recorded and placed on the
scope or on a piece of flip-chart paper.
As the sponsor addresses each issue or question, the project manager must write the response on
another note and attach it to the first. If he or she doesnt do this, after the sponsor leaves the
meeting, the answer will be forgotten or the project manager will have different perceptions of the
answer.
Any unanswered questions should be placed on the issues list, for follow up, after the meeting.
At this first meeting, a number of questions will related directly at how plausible it is that the project will
be completed. Some of the questions relate to whether or not the project is realistic, which will be
addressed during the planning process, and the project manager must not fall into the trap of trying to
address them at this early stage. On the other hand, unless the concerns are addressed in some
fashion, the team may not be willing to move forward. As such, the project manager must explain to the
team that these are valid concerns and that they will be addressed during the planning stage. If, after
planning, the team decides that its not possible to meet the expectations as outlined in the charter, then
the planning data will be taken back to the sponsor for a resolution. The best way to tackle the question
at such an early stage, is to say that the research and due diligence phase has yet to be completed and
that initial indicative assessments are sound.
The author states that he has never gone into a project management meeting without having completed
an indicative valuation of the project. After all, the planning process is designed to answer these
Page 150 of 283
questions. Therefore, its not necessary to challenge the scope of the project at such an early stage.
However, the last thing that the project manager wants is for this first meeting to deteriorate into an
argument.
After all, what may initially seem unrealistic, may prove to be possible once the team has a chance to
work through the details of planning.
The Team Contract
After the scope has been reviewed, the project manager will need to create a team contract, a set of
guidelines that everyone on the team will agree to follow. Anyone who has worked on a team has
experienced team problems of one sort or another, such as team members showing up late for meetings
and not coming prepared. This contract is in addition to the appointment letters signed by the
professional consultants. The team contract is essentially a tool to help the team avoid common
problems from occurring, instead of waiting for them to happen and then reacting to them. The team
contract is a set of guidelines or ground rules for team member behaviour. Some examples of team
ground rules are:
Keep team issues within the team, unless the team agrees otherwise.
Give everyone the opportunity for equal participation.
Practice active, effective listening skills.
Make decisions based on data whenever possible.
Get input from the entire team before a decision is made.
Meetings will begin and end on time.
Team members will come to the meetings prepared.
All meetings will be recorded and minutes composed.
There are two methods for creating and getting agreement on a set of team ground rules.
Method A: One way to create a team contract is to start with a sample contract and then let the team
members modify it to fit their experiences and concerns. Divide the team into sub-groups of three to four
people and assign each group one or more of the sections in the sample team contract to modify. Its a
good idea to print the sections of the team contract on overhead transparencies and then let the groups
make the changes directly on the transparencies. This will allow them to share their changes with the
group.
Method B: Another approach to developing a team contract is to:
Ask each team member to write down all the types of team problems he or she has experienced on
prior projects. Give team members notes for recording their ideas.
After team members have recorded their ideas, ask them to place them on a piece of banner paper
that has been taped to the wall.
Ask the team to sort the problems, placing similar types of problems together. Its best to have the
team do this in silence.
After the ideas have been organised, have the group define a category heading for each grouping.
After the categories have been named, divide the team into sub-groups of three to four people.
Assign each group one or more of the categories. Ask them to write guidelines based on the ideas in
their category, recording them on flip-chart paper so they can be shared with the entire group. When
all sub-groups have completed their section of the team contract, using either method A or method B,
ask them to share their changes with the group.
Ask for concerns or issues from the rest of the group as each subgroup reviews its ground rules.
Then ask for consensus on each section. When the review is complete and you have a contract that
everyone can live with, ask each person to sign the document. Placing their signatures on something
creates a stronger commitment for people than simple verbal agreement.
Page 151 of 283
Note: Its not a good idea to ask for signatures when you work in a culture where people are afraid of
getting blamed when and if something goes wrong. Remember, your intent should be to build individual
responsibility toward the project, and to build trust between you and the team and between members of
the team. In a fear-based culture, dispense with the signatures. Once the project manager has the team
ground rules, its time to begin the steps of planning the project.
Learner Notes: An experienced project manager can expedite the process by using ground rules from
previous projects. Ask to amend these and move on.
Schedule Future Meetings
Before planning is started, the project manager must set up a schedule for future meetings, so that
everyone can set aside the time required to complete the project plan. The amount of time needed to
devote to planning will depend on the following factors:
Factor
The size of the project team.
The project deliverable
The magnitude of the project
Time
The more people involved, the more time is
needed to plan.
The more complex the deliverables, the more
time it will take to plan.
The broader the project objectives, the more
work there will be and, therefore, more planning
will be required.
Teams that have experience in similar types of
projects will need less time to plan than teams
with people who are new to your type of project.
Combined team experiences
Historical data available
Also, teams that are experienced in project

management require less planning time than
inexperienced teams.
The more information that a project manager
has on similar projects completed, the easier it
will be for you to plan yours.
WRITING A START-UP REPORT

A start-up report should make everyone aware of the vision that has inspired the project and the
measures of success the team will be aiming for, what resources have been allocated to the project,
and associated risks. Finally, it is a good idea to name all the customers so that everyone knows who
they are, and ask key people who are underpinning the project to endorse it by adding their signatures
to the document. These will include the project manager and project sponsor.
PARTS OF A REPORT
VISION
TARGETS
MILESTONES
Page 152 of 283
FACTORS TO INCLUDE
Explanation of the overall aim of the project:
Clarify why the project has been initiated.
Clarify what the project is setting out to achieve.
Set out the benefits of the project.
A summary of indicators, current performance and target figures.
Provide clear information on how the success of the project will be
measured.
Explain what business results are expected to have been achieved by
the end of the project.
Special events that mark progress along the way:
Summarise milestones: what they have delivered
RISKS & OPPORTUNITIES
LIST OF PROJECT
MEMBERS
Set out milestones so that they divide the project into logical, measurable
segments.
A list of the potential risks and additional opportunities:

Explain what needs to be avoided when team members carry out their
roles.
Highlight any areas where improvements could be made in order to gain
even greater benefit from the project.
A directory of all members involved in the project:
All interested parties must be named, with credentials. These add to the
credibility of the project.
List all customers, and state what each customer expects to gain from
the project
Learner Notes: Reports must be free of jargon.

Learner Notes: Ask for signatures to the plan as a formal agreement.
Implementing a project
The Success of the implementation phase rests with the project team and, ultimately, the project
managers ability to lead them. It is thus his or her responsibility to think about team selection,
understand how each will develop as the project progresses, agree on key decisions and adopt different
leadership styles to inspire and motivate different personalities. To gain the commitment of all
concerned, it is important for the project manager to start with a well prepared burst, using the authority
of the sponsor, client and customers to focus everyone on the plan. He or she must ensure that
everyone has access to key project information and keep communication flowing at all times.
Chapter 18 looks at how the project manager and his or her leadership style can lead the project
effectively.
Page 153 of 283
CHAPTER 18: LEADING EFFECTIVELY

There are many different styles of leadership, to suite all styles. While it may not be
appropriate to be dictatorial in many instances, there are some cases where the project
manager must lead effectively, and to do so, needs to be the sole decision maker. The
norm, though, is that projects rely on good team work and members are often
appointed from the company itself to run the project; it is important to favour a
consensus-building, rather than a dictatorial, approach under such conditions.
A SPECTRUM OF STYLES
Many authors speak about team building and using only participative leadership methods. The reality is
that the project manager will have to use all the leadership styles at certain points in the project. While
the project managers approach will vary at different stages of the project, the leadership style that
becomes part of the project managers personality will ultimately depend on his or her organisation, the
nature of the project, the characteristics of the team and his or her personality.
It needs to be stressed that the higher up the project chain the manager moves, the more everyone will
depend on him or her to make all important decisions. For instance, a used car sales company wishes to
change the look of the showroom. The owner calls his top salesman and tells him to rearrange the way
that the showroom is laid out. The manager looks for opinions among the other staff for ideas and,
ultimately, a consensus is reached and the showroom is changed. Under such circumstances, there is
one leader, who has adopted a consensus-based style. Everyone is happy that they helped and, for the
manager, it is unlikely that the owner will go against everyones suggestions and demand that the
showroom be changed again.
Now, take the example where an entrepreneur is to make a multi-billion rand acquisition in the mining
sector. The owner appoints a consultant to make these decisions, and he or she is expected to answer
questions when these are poised to them. Under such conditions, time is of the essence and lengthy
consensus meetings are simply not tolerated. A extremely dictatorial style takes place, as it is the
appointed consultants responsibility to make decisions and to implement these.
Learner Notes: A manager should be always be approachable.
Leadership Styles
Dictatorial: Making all decisions alone, but taking all risks and control. This style is appropriate if the
project needs a strong willed person make changes that are perceived as unpleasant
(retrenchments) or difficult decisions based on fundamental, technical and complex problems such
as specialist expertise required in the fields of corporate finance, law, geology, finance etc. However,
since it discourages teamwork, it should be used sparingly.
Analytical: Gathering all the facts, observing and analyzing before reaching decisions. This style,
which requires sound analytical skills, may be used when a project is under time pressure or threat,
and the right decision must be made quickly.
Consensus: Gathering team opinions on which to base decisions. This style can be used to build
team confidence and show that the teams opinions are valued, as well as to impress the client and
sponsor, who like to be consulted.
Democratic: Team participation is encouraged right up to and including decision-making. Project

managers must accept that this is an essential style, which can be used regularly to empower team
members, and help strengthen their commitment to a project
Page 154 of 283
Styles & Circumstances

Circumstances should often be used as the determining factor in choosing a leadership style, even if it
initially feels uncomfortable. The key secret to consensus leadership is to listen carefully to everyone
before making a decision, which everyone agrees to. If someone can argue most convincingly that it is
the wrong move, the team can rethink their decision. The problem with participating in decision making,
is that it is a lengthy process; a resource often not available to the project manager.
It must be understood that every member of the team will have a unique personality and style. If time is
available, then the project manager must study each individual and understand what motivates them, so
that he or she can provide the level of guidance they need. Some team members will prefer to be set
objectives, with the project manager delegating responsibility to them for how they should be tackled.
Others will react better to being given specific tasks. Use the appropriate style for each individual.
Project managers in the UK often create an inner circle of key team members to speed up decisionmaking, while, in the US, the entire team is frequently brought together. In Japan, decisions are reached
by consensus, in which unanimous agreement is reached through a labourious process.
Choosing a Style
There are only two factors to consider when deciding which style of leadership to use.
Firstly, if a project is under time pressure, there is no alternative to the dictatorial style.
Secondly, if a project is not under a time constraint, and the project manager does want to gain
commitment, he or she must involve others in the important decisions to increase their
willingness to make the decision work.
Whichever style is chosen, the quality of the decision is vital. The caveat is to only impose a decision
after assessing all available facts.
When a team member believe that a small point should be included in a discussion it is important to do
so, as it will win the member over.
Project managers have to right to be dictatorial when a project is threatened, delayed or over-budget.
Conflict
Personality clashes are inevitable when many people work together for many hours over many months.
There may be differences of opinion or disputes that arise from people having different standards on
quality of work, or there may be one or two team members who simply do not get along. If team
members disagree, the project manager must find a way to resolve the conflict either dictatorially make
decisions or use consensus and ask the team to resolve the problem,.
When a conflict between team members threatens the project's success, the answer is to take control
and make decisions to get the project back on track. Look for solutions that bring some source of
satisfaction to each party.
Learner Notes: Problems should be seeing as opportunities to improve, resolve and improve the
ultimate project deliverable.
Ultimately, the team's development is important, but not at the expense of achieving the objectives of the
project.
Learner Notes: Respect between project manager and team is non-negotiable.
Learner Notes: Continually introduce new ideas, but keep focus on the deliverable.
Chapter 19 looks at making team decisions.
Page 155 of 283
CHAPTER 19: MAKING TEAM DECISIONS

Here is a warning: as the project manager gets closer to project completion, the higher the
pressure to make correct decisions, monitor other team members decisions and to keep a tight
reign over budgets and timeframes. Stress is heightened and it becomes easier to make
decisions that are not suitable, correct or even according to plan. Therefore, quality decisionmaking is crucial, but in an established and logical process.
ESTABLISH A DECISION MAKING PROCESS

Following the same process in making every decision does have several benefits. The team becomes
faster at decision-making, since if everyone knows the process, they quickly eliminate invalid options and
come to the most sensible alternative. The quality of decisions improves, because using a process
removes some of the guesswork and, finally, any team members, who might initially have been against a
decision, are more likely to accept it if it has been reached via a process of consensus.
Brainstorm a list of criteria against which the project manager will measure decisions, and ask a team
members to record each suggestion on a flipchart, so that everyone is using the same wording to
describe the ideal.
So, the team must agree on the criteria against which they wish to measure a decision and the ideal
performance against each criterion. This list gives the team a way of filtering options and comparing the
alternatives.
Experience and project management experience will speed up the use of a decision-making process.
The decision-making process can be clearly explained to client and sponsor.
People implement decisions more willingly when they have participated in them.
Learner Notes: Never make a decision without all the facts.
Option Criteria
The project manager, together with the team and sponsor, must brainstorm to identify which criteria
are most important in creating a logical decision-making process. Usually, there will be no more than
five such factors. Now, measure all options against the ideal agreed for each criterion. The process is
logical, but good creative thinking is still needed to evaluate the options effectively: Having carried out
this evaluation, the project manager may find that the decision is obvious.
If not, take the next most important criterion and repeat the exercise. Continue until one option stands
out, or until the team is certain that, say, two options have nothing between them. Where that is the
case, choose the option that will be the most acceptable to the sponsor.
Page 156 of 283
MAKING SAFE DECISIONS
What would be the impact on the project if an incorrect decision was made? If could be catastrophic, so
a simple and logical method is to assess whether a decision is suitable, acceptable, feasible and
enduring. The Acronym SAFE means the following:
SAFE-TEST
S
A
F
E
SUITABLE
ACCEPTABLE
FEASIBLE
ENDURING
QUESTION
Is the decision really the most suitable one, given the
current state of the project?
Is the decision acceptable to the project, sponsor, client
and team members?
Will it be feasible to implement the solution, given the
project's time and resource constraints?
Will the solution endure to the end of the project and
further into the long term?
Remember that the SAFE test can be applied as a quick and useful check for any decision made by
teams or individuals.
Learner Notes: Debate must be encouraged to avoid missing potential threats to the project.
Learner Notes: All project members must critic the decision-making list and give feedback.
Chapter 20 looks at budgets and systems to creating accurate ones.
Page 157 of 283
CHAPTER 20: MANAGING INFORMATION,

COSTS & PROFITS
The ease of information transfer today simply kills any excuse that a team member was not able
to get information, or did not know that he or she had to complete a task by a certain date and
time. Every project manager knows that most of a projects information should be available to the
whole team.
MANAGING RESOURCES & BUDGETS

Besides confidential appointment letters, non-circumvention and non-disclosure agreements between
the project manager, sponsor and client, there should be easy access to key project information
whenever team members need it. The easiest way to do this is to create a war room, as discussed in the
authors university MBA text book on strategy, called The Corporate Mechanic. This is effectively a room
dedicated to the project and includes wall charts, the scope, objectives, brainstorming ideas and
conclusions. It also sets out schedules, with names, tasks, dates and times. It is reiterated - there is no
excuse for project management team members not to have kept up to date with the project.
Learner Notes: Set up a knowledge centre and appointing a coordinator to manage it.
In 2004, the author was appointed to lead a team to investigate the viability to creating a Corporate Think
Tank for a large global accounting house. At the end of the six month, the project was delivered on time
and (miraculously) dead on budget. So, at the launch of the project, the sponsor turned to the author and
asked: Thanks for the party. The cost comes off the team members professional fees. The immediate
reaction was that this was a joke. It wasnt. Often a Project Manager is evaluated on his or her ability to
complete a project within budget, which includes all the after event launches, parties, interviews, travel
and everything else until the sponsor has signed off on the project.
If the project manager has effectively managed the project resources and project schedule, budgets
should not be a problem. It is, however, a task that requires the project manager's careful attention. It is
not possible to manage every single cent, so it is more important to only manage effectively a limited
number of cost items, so focus on the critical ones.
Costs: Estimated and actual

Contingencies: Weather, suppliers and changing price trends (petroleum climbing, interest rate
hikes etc.)
Profit: Cost, contingencies and remainder
Each project task will have a cost, whether it is the cost of the labour hours, professional fees, delivery
bills or travel. In preparing the project budget, each of these costs is estimated and then totalled. Some
of these estimates will always be more accurate than others, as experience over the years will help the
project manager to properly budget band forecast.
Other estimates are less accurate, such as the cost of specialists, union labour and global market costs.
When the estimated cost of an item is uncertain, the project budget often includes a contingency to cover
possible shortfalls. Unusual weather or problems with suppliers are always a possibility on large projects.
Therefore, a project budget is composed of the estimated cost, plus the contingency, plus any profit. The
project manager's job is to keep the actual cost at or below the estimated cost, to use as little of the
contingency as possible, and to maximise the profit the company earns on the project.
To maximise chances of meeting project budgets, use the project schedule.
Page 158 of 283
Learner Notes: The most common cause of blown budgets is blown schedules.
Experienced project managers know that meeting the project schedule won't guarantee that the project
will be within budget, but it does significantly improve the odds of achieving the set budget. And above
all, manage the project scope. Don't allow the project scope to "creep" upward without getting budget
and/or schedule adjustments to match.
Successful project management is an art and a science that takes practice. The ideas presented above
can give you a basic understanding of project management, but project managers must consider these
as only a beginning.
Appoint a War Room Co-ordinator
In projects where information flow is limited, the project manager will be able to manage the data him or
herself. However, in a large project that spans months (even years), across countries and
product/service ranges, it is better to have a dedicated place and person to sort the mass of information.
Place a team member in charge of the knowledge centre, either full-time or part-time. Such a person is
known as the knowledge co-ordinator, and the most likely candidate for the job is the team member who
most takes on the role of co-ordinator. He or she will keep the planning documentation up to date and
collect, index and make available all the important project information gathered by the team.
Learner Notes: The proper co-ordination and documentation of a project provides the client with a
complete history of the project.
Everything is important
During the life of a project, emails are sent and received, notes are taken, telephone calls made and
formal and informal discussions are held. All this produces a wealth of data, that should be itemised and
filed. Each item of information should be regarded as potentially valuable, either to the current or future
projects. An unpleasant thought: discussions are held and issues agreed to, but at some stage the
sponsor denies having said or agreed to an issue without proper documentation, nothing can be done.
The author has seen projects fall apart due to a lack of foresight in the need to be prudent and to
document everything. After all, over the years project managers will do similar projects and the
accumulated wealth of knowledge will enable the to work quickly and, with knowledge and experience,
complete the project on time and within budget.
Learner Notes: Keep notes of errors made and lessons learned for future reference.
Learner Notes: Index information clearly to make it more accessible.
While it may be obvious as to what should be documented and stored, it is better to have a process of
creating data folders that can be grouped into two types:
General planning information, such as the vision statement, objectives, master schedule, analytical
diagram and general data such as any background information on the project, teams, the product
etc.
Activity information, which can be further divided:

o
o
o
o
Completed activities
Activities currently in progress
Activities still to be started.
In this way, everyone Will know exactly where to look for the information they need.
Costing & Budgeting

Some projects are relatively straightforward to cost, but most are not; some can even be a nightmare, as
the sponsor becomes unavailable to discuss costing issues. Even simple figures like the cost per
Page 159 of 283
man/hour of labour can be difficult to calculate and often estimates are used. Accounting, costing and
budgeting are individually extensive topics and simply not covered in this book. Rather, the in the
following text is an explanation of costing and budgeting terminology and principles.
The concept of prudence: It is always prudent to be pessimistic in creating a budget and use the
age old axiom: anticipate no profit and provide for all possible losses. Provide for a margin for error
and not just show the best possible financial position.
The 'accruals' concept: Revenue and costs are accrued or matched with one another and are
attributed to the same point in the schedule. For example, if the costs of hardware are in your budget
at the point where you pay the invoice, then ALL the costs for hardware should be accrued when
the invoice is received.
The consistency concept: This is similar to accruals, but it emphasises consistency over different
periods; this helps to compare costs and profits over periods, i.e. In 2007 costs were lower than
2006, while profits were higher by 20%. If the basis for calculation or the annual reporting date is
changed, comparisons cannot be made. It is important for the company to be able to compare
financials to see if it is improving its financial strength and also to compare these financials to
competitors.
o
Note that the principles are listed in order of precedence. If the principle of consistency comes
into conflict with the principle of prudence, the principle of prudence is given priority.
Costing: At a basic level the process of costing is reasonably simple. A list is drawn up of all
possible expenditure and a value is placed against each item; the total therefore represents the
tangible cost of the project. The problem is that there may also be intangible items that need to
have a cost attached.
o
Tangible costs:
Capital Expenditure: Any large asset bought for the project, which includes plant,
hardware, software and sometimes buildings.
Page 160 of 283
Buildings can be accounted for in a number of ways.

o Lease costs: Some assets are not purchased outright, but are leased
to spread the cost over the life of the project.
o These should be accounted for separately to capital expenditure since
the project or company does not own these assets.
Staff costs: All costs for staff must be accounted for and this includes salary,
pension, insurance, recruitment and any other cost that can be tied directly to
employing, training and retaining staff for the project.
Professional services: All large-scale projects require the input of one or more
professional groups such as lawyers or accountants. These are normally accounted
for separately, since a close watch needs to be kept upon expenditure in this area.
Without scrutiny the costs of a consultant engineer, accountant or lawyer can quickly
dwarf other costs.
Supplies and consumables: Regular expenditure on supplies is often best covered

by a single item in your budget under which these figures are accrued. They are
related to overhead below.
One-off costs: One-off costs apply to expenditure that is not related to any of the
above categories, but occurs on an irregular basis, eg. Staff costs.
Intangible costs: It has become fashionable to account for intangible assets on the balance
sheets of companies and also projects. The prudence principle suggests that intangibles
should be included in the cost of the project. Typical items include goodwill, intellectual
property and trade marks.
Budgeting: Once a full cost has been worked out, a project budget can be prepared to secure the
requisite funds to start the planning phase. Remember to plan the cash flow over the entire project.
o
Overheads: Sometime called indirect costs, these are costs that are not directly
attributable to any of the above categories, but do impact upon a budget. For
example, it may not be appropriate to reflect the phone bill for a project in staff costs,
yet this still has to be paid and accounted for. Costing for overheads is usually done
as a rough percentage of one of the other factors such as staff costs.
An accurate cost model must include detail and specification so that the scope can be
determined. Unfortunately, the sponsor will require an indicative budget before the project is
approved, despite stating that this is an indicative budget, more often than not the project
manager will be held to his or her original estimates. Be extremely careful with initial
estimates and always follow the promise low - deliver high commandment.
As the project manager refines the budget, it will influence scheduling, so there is a need to build in
an adequate contingency to account for unexpected expenditure. For example, if the Critical Path
Analysis shows that a task needs to be completed, but isnt the budget will be affected as the
carefully planned cash flow moves out of line, i.e. expected cash inflows wont happen (the task is not
completed), so the next phase or new task cannot start.
o
If the project manager, however, has carefully budgeted his or her project then variations
should be relatively easy to spot as they arise. Just as in scheduling, the project manager you
should have regular budget reviews, which examine the state of finances and expenditure to
date and adjust the planned budget accordingly.
Developing a Budget
All projects consume resources and most cost money, so its time to craft a budget for the project and
then the project manager can start to assemble the completed project plan. There are basically two
types of costs that are included in a budget:
Costs that are internal to the organisation: such as the costs of peoples time, inter-departmental
charges.
Costs that are external, such as purchases of equipment or services.
So, while all projects consume resources, sometimes no money is spent outside the organisation.
Internal expenses will still occur, as working on the project arent cost free. The effort that they expend
on the project, which is called staff effort, costs the organisation in salary, benefits and overhead
expenses.
The cost of staff effort is the principal internal cost for a project. Many organisations ignore the cost of
peoples time, because projects are done for customers and the organisation absorbs the cost of the
project as part of the cost of doing business. The cost of peoples time is usually ignored, because
its a sunk cost.
o
Its not a good idea to ignore staff-effort costs, because management should know the total
estimated cost of a project before they give the go-ahead to begin.
If they dont know the cost, they may approve a project for which the benefits do not outweigh
the costs.
Page 161 of 283
However, it is not the project managers decision whether to estimate staff costs; its up to the
sponsor.
Organisations that get paid for doing projects for external customers usually calculate the cost of their
staff-effort time, because their ability to make a profit on the project depends on getting paid for staff
effort. Whether you do projects for internal or external customers, the steps for calculating staff-effort
costs are the same.
Staff Costs
Staff costs are the costs associated with work done on the project by employees. To calculate staff
related costs, the project manager will need an estimate of the time each person will spend creating his
or her deliverables.
The project manager must add up the total staff time, per person, to get the total deliverables staff
related project cost.
A less obvious expense is the cost of the time the project management team takes to complete the
plan and to manage the project.
o
To get a total project management staff project-related estimate add the deliverables and the
time it took to complete the project.
One of the benefits of doing the staff estimate, even if its not required, is that it helps the
resource managers know just how much time the project manager will need from the
companys staff.
When the resource managers sign the project plan document, they commit to providing the
resources documented in the plan. This will also enable them to plan for the project needs. At
least they know what they are committing to and it will be more difficult for them to withhold
resources that they have signed off on.
In a consultancy related costing, the professional gets paid for the work done, which includes all the
above fees. It is a simpler method, but some companies will insist of the project manager using the
companys staff.
COMPLETING THE COST ESTIMATE

In addition to staff costs, there may be other internal costs that may have to be estimated:
Any inter-departmental charges from within the company or across the corporations companies.
Any overhead charges to the project
In addition to internal costs, most projects incur external costs, which are costs for people or things that
must be purchased from outside the organisation. Even if you dont estimate internal costs, most projects
are required to estimate external ones. Record each outside purchase and estimate the cost. External
costs will include such items as:
Assets, equipment and other to be purchased.

Outside services, such as consulting services.
Supplies.
Travel.
Add together all the external costs to get an external cost total. If there are internal costs, add the two
numbers together to get a total. This is the budget or spending estimate. Next, the project manager
needs to assess the accuracy of these estimates.
Page 162 of 283
Accuracy
Some estimates are more accurate than others, so there is a need to convey this to the sponsor. To do
this, the project manager must create an accuracy rating and a range to his or her estimate.
The sponsor has little way of knowing how accurate the project managers estimate really are unless he
or she provides them with an accuracy rating. The following are some factors that can affect the
accuracy of the estimate:
The experience of the people on the team.

The number of times the project manager has created similar project plans.
The accuracy of the historical data on staff costs and how applicable it is to the project.
The length of the project; the longer the project, the less accurate the estimate.
Based on these factors, rate the accuracy of estimates as high (H), medium (M) or low (L). After the
rating ahs been done, add a range to the spending estimate, i.e. plus or minus a certain amount that
reflects the accuracy of the estimate. What the range states is that it is possible to be over-or under
budget, but the project manager believes that he or she is sure that their final estimate will fall within the
range.
Here are some suggestions for adding ranges to estimates:
If the project manager has a high accuracy rating, he or she might want to use a range of +/ 10%.
A medium accuracy might require a range of +/ 25%.
A low accuracy range might need a range of +/ 50% or more.
Expressing spending estimates as a range will:

More accurately communicate the true potential costs of the project.
Eliminate surprises later on in the project.
Manage client expectations about what will be spent.
Include a contingency for risks.
The difference between the project managers actual estimate and the high end of the range gives him or
her a pool of contingency money for expenses that may not have been predicted. Once the range has
been calculated, there is a need to compare the high end of the range to the spending limit that was
given in the scope. If the high end of the spending range is below the spending limit, then spending
estimate is complete. However, if the high end of the range is above the spending limit, the project
manager must:
Check calculations to see if assumptions and calculations are correct.

Check with the sponsor to see if there is any leeway in the spending limit.
o If cost is the number one priority for the project, then its unlikely there is room for negotiation
on the limit.
o
If cost is the last priority, then you might get lucky.
If the spending limit cannot be changed, the project manager will need to look for ways to reduce
costs. This usually means one of three things:
o
Convert outside effort into staff costs, increase the risk of the project by eliminating countermeasures that cost money, or reduce the scope of the project.
Ask the sponsor which option he or she is most interested in having pursued or provide the
sponsor with several options to pick from.
Before the results are documented, do a content and process check to make sure nothing
has been forgotten.
Page 163 of 283

Did you ask the sponsor if you needed to estimate internal costs?
Did you include project management time in your staff estimate?
Did you estimate all the external costs associated with your project?
Did you estimate the accuracy of the spending estimate and calculate a
range?
Do you have consensus from the team on the estimate?
Is the high end of your range under the spending limit? If not, has your
sponsor given you the okay to go ahead or has the sponsor raised the
spending limit?
In order to document the spending estimate, the project manager may want to complete a spending
estimate form like the one shown on the following page. Enter the spending totals, the accuracy rating
and range, and explain the reason for the accuracy rating. This will communicate to the client how the
numbers were derived and why the actual amount spent may be different. It will also serve as a reminder
to the project manager at the end of the project about what assumptions used to creating the estimate.
COST ESTIMATE FORM

TYPE OF EXPENSE
COST
Internal Costs
Item
Item
Item
Sub-total
External Costs
Item
Item
Item
Sub-total
TOTAL
Accuracy Rating
Difference
Learner Notes: Check that cost estimates are updated regularly.

In Chapter 21, communication support and the projects health is checked.
Page 164 of 283
CHAPTER 21: COMMUNICATION, HEALTH

CHECKS & PROJECT SUPPORT
The better the communication between project manager, his or her team and client, the quicker a
project will reach completion. An essential task of the project manager is to ensure that everyone
has easy access to permitted project information through the information co-ordinator, as set out
in the previous chapter.
MORE ON COMMUNICATION
It is extremely easy to say that everyone has access to the project information database. This assumes
that everyone is honest and not an opportunist. One of the highest rising crime rates in business around
the world is industrial espionage. There has to be some form of security to prevent the intentional or
erroneous loss of information.
So, the project manager must consider who will really need project information, in what format and when.
Start with the list that was established at the start-up report and make sure that no one is omitted. In fact,
use that list as people to whom the project will grant access to the database. The project manager must
then instruct the co-ordinator on whom and how these members can access the information. It is crucial
that a plan is set out on how the project manager will make the information available, bearing in mind
that these activities should take up as little time as possible.
Learner Notes: Granting access to project information is a necessary waste of time. With experience,
the project manager will establish these structures quickly, at the initial stage of the project management
process (on appointment).
Learner Notes: A non-negotiable rule is to insist that privacy and confidentiality is respected and that all
members must avoid sending random messages that could hinder, rather than help, the project.
The easiest way to disseminate information, which is also the most efficient method, is to use available
technology. This will improve communications, while keeping the information relatively safe. Email is an
extremely useful time-saving device, provided that it is handled correctly. For instance, using the latest
word processors may be efficient, but sending documents in word processor form could see the
document being changed inadvertently or purposefully. A better method is to have the software available
to convert such documents to avoid changes being made, or copied or forwarded to third parties.
For additional information on such software, contact the author on mentor@magliolo.com.
In addition, team members have their own ideas as to how information can be dispersed with relative
safety. Ask for feedback and use simple questionnaires to ascertain how they would like the
communication aspects of project management to operate.
Page 165 of 283
QUESTION
ANSWER IN RELATION TO:
How do you think communications could

be improved?
Is there anything that could be changed if

the work had to be re-done?
The specific task
How are the client, sponsor and/or

customers reacting to the work being
completed?
The future completion of the

project
Are there any negative reactions from

client, sponsor, customers or other team?
LISTEN TO EACH OTHER

A skill that some project managers possess is the ability to hear what people say, but to also understand
the deeper implications of how they have said something.
In 1997, the author was appointed to assess the viability of a Cape Town-based company achieving
certain profits prior to a new expansion plan being implemented (the project). The directors kept stating
that they would warrantee profits of 25% a year for at least the next five years, yet somethingb in the way
that they kept avoiding issues relating to the profits raised alarm bells.
Having completed due diligence and in-depth research into the company prior to accepting the
appointment, the author knew that the holding company may have ulterior plans for the company in
question. The issue of the holding company interfering in the plan had been raised and eliminated; or
had it.
The directors agreed to retire for the day, but the author contacted the holding company and threatened
to walk away from the project if then truth wasnt immediately told. The real story was that the holding
company was waiting for the plans to be effected launched, before their own takeover plans wee
implemented. Costs of the project would be borne by the Cape Town firm, and the holding company then
benefits from the growth plans.
Ultimately, the project would be the same for either company, except that the directors were stated
inflated profits because they would be paid out at higher values once the takeover plans were
implemented.
Learner Notes: Hear what people have to say, but more importantly, how they say it,. It will save time
and resources.
Finally, the project manager must make it absolutely clear that negative feedback is only an opportunity
to improve the project. Understanding that some team members will not speak when others are around,
speak to team members individually and in small groups to get feedback on how they think the project is
progressing.
The aim of project support is to help projects start out with things adequately planned and to provide
advice during project execution.
RULES TO REVIEWING PROJECTS

Unless a project constitutes less than five people, it is recommended that the project plan must be
reviewed by the project team before the sponsor is requested to make a go or no go decision. The
following table sets out the review process.
Page 166 of 283
QUESTION
REVIEW
Estimates
Schedule
Risks
Stage agreement
Change and issue procedures
Reporting
Quality
How are these derived?

Provide details, including the mathematics involved.
Has a schedule been drafted?
Has it been seeing and agreed to by the team members?
Has the team signed it?
Have they been assessed?
Is there a plan to manage, monitor them?
Are resources committed?
Are they set up?
Are adequate tracking and reporting mechanisms in place?
Is it clear who will communicate what to whom?
Are quality assurance activities included in the schedule?
If the project manager undertakes solid planning, the review should not take long. If the project manager
is inexperienced the review may add a lot of value. But the fact that everyone running any significant
project must go through the review, should mean that fewer projects start with poor plans.
The aim is to start each Stage of the project with better plans and less chance of re-doing work, simply
because time was set aside to review the objectives of the Stage to remove doubt and inconsistencies.
So, a project support review does not mean the plan is perfect and guaranteed to succeed, it simply
means less chance of failure.
During a stage
There are two effective types of independent reviews of projects; as outlined hereunder.
Health Check
Project Definition
Requirements Analysis
User Functions Design
Informal Review
IT Technical Design
Build and Test
User Acceptance
Health Check
The project sponsor decides which projects are important and appoints project managers to implement
these projects. These tend to be large, business-critical or high risk projects. The rule then is that any
project designated as a key project must plan in at least one health check. Long projects may have a
second health check planned at the mid-point.
Leaner Notes: Health checks are planned and not used as surprise tests for the team.
In fact, the health check objective is to offer advice to the project manager and to provide the sponsor
with an independent verification of the status of the project. It will also become clear that health checks
only really work if project managers see them as adding value and, therefore, do not hide important
issues from the health check review team.
The Health Check Review Team
A favoured approach is that the health check team consists of a maximum of three people, led by a
project support person to lead the review. He or she would have a legal and an account consultant.
A week before the health check, the project support person, who will lead the review, meets with the
project manager to discuss possible areas of project weakness. It is then the job of the project support
person to choose review team members, who can add most value in those perceived areas where
Page 167 of 283
improvement is most needed. For instance, if the change control process seems to be causing problems,
project support will find someone with expertise in that specific area.
Typical Schedule
Monday
Tuesday
Wednesday
The review team assesses the project's written records.

Investigates the written plan vs. actual data.
The project manager makes a full disclosure presentation of status, problems
and planned actions, issues and major risks.
The review team begins to formulate their assessment and identify further
information they need.
Vitally, the review team is empowered to speak to anyone they wish to: the
project sponsor, the users or trainee developers. Essentially this is fact finding.
The review team discuss their findings and recommendations with the project
manager.
The review team write the health check report.
For very large projects, which can be scattered across countries, sectors and production sites, the health
check process may take longer than three days, but the recommended schedule gives an idea of how
long it might normally take. Note that health checks are only done on larger projects and the work
reviewed is in the project plan.
Checking the Project Plan
It must be notes that the health check review is being conducted half way through a Stage. The process
is simple as a project plan must exist as part of the project management contract signed between
sponsor and project manager. The health check is thus a checking of the plan in relation to the actual
work completed. For instance, sometimes the written plan looks great, but at the halfway stage team
members it's show obvious signs of confusion, lack of understanding the plans vision and not having
met objectives set in the schedule. The task of the review team is thus to:
Firstly, establish whether the plan is as good as it looked.

Secondly, is the team following the plan?
Finally, is the plan being updated as the project progresses?
At this point, problems can occur. Remember that the project manager has been appointed to carry out
the tasks set out in the project plan. So, if he or she havent done so, the review team has to state the
facts to the sponsor. The review would be broken into two parts:
Roles. Are role players stepping up to their responsibilities?

Resources. Are promised resources being supplied?
The point is: keep the findings factual and unarguable. Any problems should be discussed with the
project manager before the Health Check report is written. This provides the project manager with an
opportunity to speak to his or her team and to resolve problems, if they occur. There may be innocent
and logical reasons for such perceived problems. The recommendation is to sort these out quickly and to
return to the appointed task.
To avoid such potential problems, the project manager should keep control of tasks through weekly
communication meetings with the team.
Every week review the tasks.

If need be, revise the plan to reflect the cost overrun to date.
If the project budget is about to go into deficit, make changes (if possible), or substantiate the need
for additional resources.
Go to the sponsor and explain the situation. How he or she reacts, if always in question.
Page 168 of 283
Learner Notes: A health check report is not normally a huge document.

One thing health check reviews do not do is to examine work products, to try and assess their
correctness and completeness: the health check review team neither have the time nor the expertise to
do that. What they do examine is whether those who were planned to check these products for
correctness have actually done so.
Chapter 22 outlines how a projects progress is tracked and controlled.
Page 169 of 283
CHAPTER 22: PROJECT PROGRESS

SCHEDULING, TRACKING & CONTROLLING
An interesting phenomena creeps in by the time the project has been planned and the lengthy
process of execution starts whether it is an eagerness to finish, or simply tiredness due to the
grind of completing a project project managers slack off. They stop monitoring and, in many
cases, even stop tracking progress.
STATUS REVIEWS
The thought is that, being so close to the end, the project manager will remember those final events
that ultimately led to the completion of the project. No so. Often, unforeseen problems occur that extends
the life cycle of the project.
Therefore, there is a need to continually monitor the project and the environment within which the project
operates. The project manager must see if anything has changed since the start of the Execution Stage.
For instance, there could have been a change in the clients business, or a competitor has announced a
similar product to the one commissioned by the client. Any new or different occurrence from what the
project manager expected should be evaluated.
Monitoring potential problems must be done by the project team and in meetings with the customer and
sponsor. The project manager must ask whether these parties have noticed whether anything has
changed that could affect the project.
Environmental changes
If there is an environmental change, the project manager must guide the team to determine the
extent of the potential impact on the project.
o
Immediate impact: evaluate the nature, extent and impact on the project plan. If an
impact has occurred, use change-management procedures; as outlined in this book.
Future Impact: If this is the case, the project manager must adjust the risk profile. If the
change in risk requires new counter-measures that would change the plan, implement
change-management procedures.
There is a definite benefit to regularly reviewing the current status of a project. This allows the project
manager to track the projects progress relative to the drafted project plan, which simply means
comparing the current status of the project versus the scheduled. The importance of this review is that
the project manager can determine whether action is needed if the project has veered off course.
Leaner Notes: The purpose of tracking progress is to ensure that a project is completed on time.
To the professional manager, delivering a project on time and budget is the main goal. If anything has
happened to hamper that goal, there should be a mechanism in place to remedy the situation. After all,
the project managers reputation is built on delivering quality on time and on budget. When projects get
side tracked, it generally costs more to return to the planned schedule.
There are six areas that need to be continually tracked:
Risk
Scope
Schedule
Team tasks
Page 170 of 283
Budget
Changes to the plan
Tracking and monitoring are based on the following basic premise:

Tasks should be completed on the scheduled time. Are they? If not, why?
Note: Project organisation is not tracked since it stays pretty constant, unless there is a change within
the company that will require a re-assessment of the composition of the team.
Can monitoring the environment detect new risks to the project?

Can monitoring detect a change in assumptions project risk?
Is it necessary to add various options if the projects risk profile changes?
Any changes in the risk assessment for the project should be noted on the status report?
Tracking, Controlling and Reporting

Monitoring individual tasks to attain milestones & product launch
Project control is very simple in principle. It is merely knowing who is doing what, how and when that
task will be completed. Then it is comparing that to what was expected to happen according to a
schedule, which every member of the team signed. Each task is tracked relative to expected milestones
and the project as a whole. When all tasks have been completed, the project can be launched.
What is the purpose of project control and should there be some form of control for professionals?
Controls enable accurate reporting of project status and the issue is not that the project manager does
not trust his or her team, but things do go wrong; often beyond the control of the member. Clearly,
therefore, there need to be a method to identify deviations from the plan and to quickly and efficiently
sort them out. The real art of project control is to continually assess the environmental factors of politics,
business, economics and technology to determine potential future problems. This is called scenario
Page 171 of 283
planning and is discussed in great depth in Corporate Mechanic. The aim is to avoid problems, rather
than trying to fix the issue after a problem has occurred.
Identifying potential problems
Tracking a project and determining when a problem occurs can create its own problems. For instance,
where does the project manager draw the line in cases where minor schedule mishaps occur? Take the
issue of the number of public holidays in South Africa and the culture of not going to work for the whole
week when there is a holiday on a Wednesday. The team member may be on schedule, but needs a
single document signed before submitting the task as completed to the project manager; yet it is one of
those weeks and the client is away! The team member cannot meet the schedule, but the task has been
effectively completed. Where should the boundary line be drawn? There should be a predetermined
tolerance limit and only variances outside that limit need to be approved by the sponsor. In the case of a
task needing a signature before submission, the project manager can sign off the task, enabling the next
task (especially if is inter-dependent) to start. The project manager is taking responsibility for the task to
be completed by the next meeting.
Learner Notes: If tolerance is too small, the project manager would spend all his time getting tiny
variances approved.
Learner Notes: If the tolerance is too wide, the sponsor has little or no control over costs.
Before a stage starts, the project manager agrees how much he or she can change things without
sponsor approval, i.e. tolerance limits. The project manager must then decide how much of his or her
tolerance he or she will delegate to those below him or her in the chain of command. The amount of
tolerance that the project manager had depends upon who he or she is; how much the sponsor trusts
him or her, which ultimately would be judged on the project managers skills, experience and reputation.
Yet is will always be the project managers duty to decide who does the tracking, controlling and
reporting. He or she is, after all, the appointed professional to deliver the task.
Project Manager
What should a project manager do to keep control?
Monitor team's status: Know exactly where the team is versus their plan.
Have tasks really been completed: Check. Particularly at the start and for new team members.
Responsible for task quality: Individuals are accountable for the quality of their work, but ultimately
if quality is poor, it will reflect on his or her ability to manage the team.
Keeper of project records: On large projects the project information co-ordinator will look after the
record keeping, but on smaller projects it often falls to the project manager to keep the records
straight.
Collect weekly time sheets: Once a week establish precisely where each team member is versus
the schedule.
Keep the team work plan up to date: Capture actual status from each member of the team,
including tasks finished, hours worked and costs. The manager then revises the team plan so that
the plan reflects exactly what he or she thinks will actually happen over those next six weeks. Critical
path tasks more than six weeks should be re-planned if they are going to be late.
Weekly team meetings: The project manager gets the team together for an hour once a week. Each
person says where they are and what they are doing. Risks, issues and changes relevant to the team
are reviewed.
Page 172 of 283
Agree tolerance limits with team members: Discuss these issues with the individual consultants,
as each will have different tasks that require different tolerance levels. For instance, in South Africa
law courts close in December and many forms of legal documents cannot be processed.
SCHEDULES
There are two essential questions that are continually asked about projects and timing:
Has the project manager accomplished what he or she intended to accomplish by this time?
Does the project manager expect to be on time in the future?
These issues are best attained by monitoring whether the project manager and his or her team have
reached stipulated milestones and whether they have delivered determined tasks. How do the actual
dates compare to the planned dates? Has the task met all deadlines, including those set to be achieved
at a predetermined interim point; or was it a frenetic rush at the end. Under such conditions, team
members often negate quality for time.
In fact, a frenetic pace suggests that a team member cannot keep up with the schedule. Remember that
this person was part of the decision making process in setting the deadlines. The project manager must,
under such conditions either replace the team member, or add personnel or funds to assist that member
to achieve targets. There are tasks that cannot start until others are completed. So, a single task not
meeting deadlines can have a domino effect on the whole project.
Learner Notes: Meeting deadlines is pointless if quality has been sacrificed.
In addition, it is better to monitor a position and pick up if a task is slipping than to wait until the schedule
has slipped. The project team can work to determine what might be causing the problem and brainstorm
with the whole team member to get the project back on track. Not every actual or projected slip in a
delivery date will affect the project deadline; so focus energy on potential changes that do jeopardise the
deadline date, i.e. the ones on the critical path. Minor deviations from projected dates are expected.
Major deviations that may cause the whole project to fail; either completely, deadlines, in promsed
quality or budgets.
Most projects need two types of schedules:
The first type depicts the ultimate delivered item, i.e. when and how the whole project will be
launched.
The second type helps the team manage the deadlines for the various tasks of the project; these are
called milestones. These display every task that will be produced, associated dates and the interdependencies between the tasks.
The purpose of the milestone schedule is to highlight the major elements of the schedule and
communicate those to the client and sponsor. The task schedule serves a number of purposes. It shows
the delivery date for each task and which sub-project will produce this task. The following is highlighted
by the schedule of tasks:
Maps the inter-dependencies between the tasks.

Shows the milestone dates.
It is also a method of monitoring task progress when the pace of the project speeds up significantly
during the Execution Stage of the project.
Milestones
Different project managers will have their own set of milestone that they will wish to include. However,
there are standards throughout the industry, as follows:
Page 173 of 283
The first three milestones are the Stage gates (discussed in previous chapters). These represent
the major accomplishments in the project management process.
o
The first phase gate, the scope document, is not included as a milestone, because it was
completed before the Planning Stage was started.
The other Stage gates:
Completion of the project plan, which is the end of the Planning Stage
Delivery of the final deliverable to the client, which signals the end of the Execution
Stage.
Completion of the close-out report, which is at the end of the Completion Stage.
Add six milestones during the execution phase of the project. Choose major deliverables that each
represent major segments of tasks completed.
If the project manager is given specific dates to accomplish certain tasks by the client or sponsor, these
would be milestones, because these have been designated as important, and the milestone schedule
should reflect the most important deliverables.
Learner Notes: Stage gates are major points of accomplishment in the project management process.
Another important issue to consider is whether chosen milestones span whole stages and are not
concentrated in certain Stages or in bunches within Stages. Under such circumstances, the project
manager cannot determine whether tasks are on time, will be on time or not. This does loss of
confidence in the project manager, for the sponsor, which can lead to meddling. All project managers
would rather avoid such conditions from developing. Spreading out the milestones (see diagram below)
provides the client with enough faith, throughout the project, to leave decision making to the project
manager. There is, effectively, less room for the sponsor to doubt the project managers ability to lead
his or her team to deliver the final product or services.
Spread Milestones throughout the Execution Stage
After the milestone events have been chosen, discussed, written down and signed off by every team
member a detailed schedule can be se out. If the sponsor has specific deadlines, these are in fact also
milestones that must be included in the schedule and written in red. Next, team members will need to
prepare for the deliverables schedule meeting. In preparation for this meeting, each team member
should prepare notes for his or her deliverables, including any counter-measures that were assigned to
them during the initial schedule meeting. Then, they should estimate how much time will be required to
produce each of their tasks.
Page 174 of 283
Team Tasks
The actual working time (hours, days or weeks) that is required to produce tasks is often called staffeffort time or just staff effort. In a consultancy environment, where there are no staff members, this term
becomes meaningless. It would be preferable to call this working time Task Time Schedules or Team
Scheduled Task Times.
Whatever the terminology, the team members have specified the amount of time it will take them to
produce a specific task. Note that the specified time is not the number of days over which the team
member needs to spread the effort, but its the actual time the team member will devote to working on
the task. Remember that the member will be working on various tasks at the same time. Most people
dont work on projects full time, and, therefore, the calendar time that will be required to create a task will
be longer than the Scheduled Task Time.
As such, the project manager will know how much time will be spent on a task, but when will that task be
completed? In fact, the more tasks the team member has, the longer the duration for the completion of a
task.
Learner Notes: The team member must state how much time he or she will be working on a task, but
also state what day that task will be completed.
Learner Notes: Duration should be expressed as the number of work days, calendar weeks, or calendar
months required to complete the deliverable.
While the team member is the one estimating Task Time Schedules for his or her tasks, if he or she has
been appointed to undertake a task that has many components to it (also called sub-projects), then that
team member must appoint sub-project leaders, who must in turn estimate durations for their tasks.
Be warned. Team members will try to add contingency time to each task. If each member does this, then
the project will take much longer than expected. It is always better to have a contingency plan for the
project as a whole than for individual tasks.
Simply, people will squander contingency time when its included in their task durations. The aim is
always to start a task on time, but if there is a contingency time to a task, it is certain that the member
will start that task late, effectively using the contingency time before the task has even being started.
Its better to estimate the normal time it would take to produce the task and then have a pool of time at
the end of the schedule that can be reallocated to a team member when problems occur. Team
members should record the Task Time Schedule and duration on the bottom of each task note.
Learner Notes: the project manager must write the members name and task number in the centre of
the note.
Page 175 of 283
SCHEDULE GRIDS
Inter-dependencies
Predecessor & successor Tasks
Before task dates can be established, the project manager must determine which tasks have to be
completed first. For example, a basic project could be the building of a wall, plastering that wall and then
painting it. In such a case, the tasks would be as follows:
Example: Inter-dependent tasks
Therefore, inter-dependencies must be identified before time schedules are established. These are
called predecessors and successors. A predecessor is a task that serves as an input for the next task,
which in turn is called the successor.
A. Schedules for single tasks
Time schedules for tasks that do not have predecessors, can be displayed as follows:
Page 176 of 283
Date to start the task: write the date in the lower left-hand corner.
Duration of the task: write the duration in the bottom, middle part of the note. The duration should
be expressed in working days, weeks or months.
Delivery date: This is the calculation of start date plus the duration. Write this number in the lower
right-hand corner.
B. Tasks that are predecessors

After the project manager has scheduled the tasks that dont have predecessors, he or she must move
on to the tasks that depend on tasks that must first be completed. Effectively, the start date is usually the
day following the latest delivery date of a predecessor. For tasks that have more than one predecessor,
the project manager must use the latest predecessor delivery date to calculate the start date for the
successor deliverable.
Steps to be taken include:
Step 1: Identify all predecessors.
Step 2: Identify the latest delivery dates for predecessors.
Step 3: Set the start date for the next task; the day after the latest delivery date.
Step 4: Add the time that it will take to complete the task.
Step 5: Draw arrows from the predecessor to the successors).
After all tasks have been set with schedules, reassess and review the schedule. The project manager
must check to see that every task forms part of the overall project and, if there are tasks that dont have
successors or complete a part of the overall project, then he or she must assess whether there was a
need for that task in the first place.
In cases where milestones cannot be met:
The project manager must ask the sponsor if he or she could allow time contingency.
If the milestone cannot be changed, the project manager will need to revise the schedule.
Start, time & Completion dates
In the above example, compeltion fo a project means that a project manager has two predecessor tasks
and one successor task to undertake before the project can be delieverd to the sponsor/client. In the top
two tasks, the left had one started on 5 January 2008, took five days to complete and thus the delivery
date, of the task to the project manager, was the 10 January 2008. The right had task also started on 5
January 2008 and took six days to complete, which means that the delivery of the task to the project
manager was 11 January 2008.
Page 177 of 283
The successor task would thus start one day after the latest of the two tasks, namely the 12 January
2008. This successor task took 10 days and thus the final delivery of the project to the sponsor/client
was the 22 January 2008.
View From The Top
Creating a schedule per task is easy to understand, but when there of 300 or more tasks to manage,
how does the project manager keep track? While there are computer software packages that can
certainly help, the manual method works just as well.
Schedule View of Tasks with Overall Project
Everyone on the team understands whom he or she will be depending on and who depends on them.
Team members know their own schedules and can adjust the start and delivery dates for their
deliverables to best integrate with any other commitments they have.
Everyone on the team understands the big picture and how their pieces fit into the whole.
Slack Time
After the project manager has drawn the schedule (as per the last diagram) or in using a Gantt chart, he
or she will notice that some pairs of tasks have no space between them. For other pairs there will be a
space.
Learner Notes: The space between tasks is called slack time.
Slack time is extra time between the delivery date of one task and the start date of the next. This usually
happens when there are multiple predecessors for a task and the successor cannot start until the last
predecessor is complete, resulting in slack time between the successor and one or more predecessors.
Slack in the schedule means that, if the predecessor task (with slack in front of it) is delayed for less time
or equal time than the slack time, the successor can still start on time. When there is no slack, a delay in
the delivery of the prior deliverable will cause a delay in the start of the successor deliverable.
Page 178 of 283

Slack Time
For each pair of predecessor/successor tasks, that has slack, mark with a circle. This also helps to
identify the tasks without slack.
Adding Contingency Time
All projects managers face the same problem when drawing up a schedule: they cannot foresee whether
unfortunate events will happen in the future that will detract and delay the individual tasks and,
ultimately, the project as a whole. However, there is the comfort of knowing that, the closer the project
gets towards the end, the less the future can influence the project.
Learner Notes: Shorter schedules tend to be more accurate than long ones.
So, to somewhat negate the possibility of schedules being changes to accommodate late delivery of
tasks, time contingency is used to help protect milestones. The aim, however, is not to have too much
contingency. Therefore, assess the following factors:
Complexity of the project: The more complex the project, the more contingency could be needed.
Risk profile: The more risk, the more contingency.
Time: Longer projects require more contingency, because more time means more chances of
problems occurring.
Project managers Experience: Then higher the level of the project managers experience, the less
contingency will be needed.
Team member experience: More experienced teams require less contingency.
Accuracy of research data, including previous projects: The amount and accuracy of historical
data available from similar projects means less contingency is needed. With accurate data, the
project managers estimates should be closer to reality and less contingency will thus be needed.
Client reliability: The more unreliable, the more contingency youll need.
Resources: The less reliable delivery of promised resources is, the less accurate a project manager
will be due to greater uncertainty in the duration estimates.
Reducing Schedule Times

There will be times when the project manager will need to shorten the schedule. The following are some
questions to ask when evaluating ways in which the schedule can be shortened:
Page 179 of 283
Question
Can tasks, which are being created in sequence, be produced in
parallel instead?
Can parts of a task be started before the predecessor has been
completed?
Will adding more members to a task shorten the time it takes to
completion?
Can health checks be performed by telephone rather than in person?
Can these checks be madder in groups rather than individually?
If you have to order equipment, can the order be placed in advance?
Can delivery times be reduced by using overnight couriers?
Can the sponsor help to remove other commitments for a key
resource, so that he or she can complete their deliverable sooner?
YES
NO
Concentrate on the YES and dont be afraid to ask the sponsor for help or ideas. In addition, the project
manager can take the tasks schedule to him or her and see where he or she thinks the project manager
could find time in the schedule. Some project managers simply shorten the time schedule, which may
look good initially, but ultimately creates an unrealistic schedule that cannot be met and milestones are
missed anyway.
TRACKING THE PROJECT PLAN

It is highly recommended that the project manager includes his or her milestones schedule in the project
plan document. Even best-laid plans can go wrong, at the least expected time, which is why it is crucial
to have an early warning monitoring systems. Keeping control of a project involves carefully managing to
keep it moving forward smoothly. Effective monitoring allows the project manager to gather information,
so that he or she can measure and adjust progress toward the project's goals. It enables communication
to take place between project manager, team members, sponsor and client and gives the project
manager the confidence to make sound judgement calls and thus changes to the schedule; which should
not have a significant impact on the final delivery date.
Learner Notes: Keep comparing current schedules and budgets against the original plan.
Learner Notes: Always keep tight control, even when all is going to plan.
Learner Notes: Monitor the project consistently from start to finish - problems can occur anywhere along
the Stages, in any task and at any time.
USING REPORTS
Anyone responsible for an activity or a milestone must report on progress; in written form. The author
encourages all project managers to use latest recoding technology, which enables him or her to store the
actual recording of the discussion with the group or individual team member, but also convert the
recorded session to text. Contact the author on mentor@magliolo.com for more information.
Reports must be taken seriously, as these are ultimately the blue prints for the project. Reports should
record the current state of the project, achievements since the last report and potential problems,
opportunities or threats to milestones. Once received, the project manager must review the reports and
summarise each for the client/sponsor.
If the project is large or complex, reports will be required more frequently.
When a project involves tackling issues for the first time, tight and frequent controls should
be established.
If team members are used to working on their own, too frequent monitoring may be counterproductive.
Page 180 of 283
Think about how often there will be a need to write a progress report. Regular review meetings provide
an opportunity to resolve issues, discuss progress and review performance. While there is no hard and
fast rule as to how often such meetings need to be held, such meetings should be at least monthly, but
more frequently if a project is complex and demands guidance from the project manager.
Chapter 23 sets out issues relating to review meetings
Page 181 of 283
CHAPTER 23: HOLDING REVIEW MEETINGS

Review meetings are held throughout the project life cycle. They are a means to discuss
progress, achievements, milestones and potential problems. These meetings are and must be
taken seriously to encourage teamwork and provide all involved with an accurate picture of
how the project is progressing.
PLANNING A REVIEW
There are two types of review meeting:
Regular formal reviews: occur monthly, which monitors detailed achievements of tasks. Attendees
include project managers and their teams. The leaders of these teams have their own meetings with
sub-task members.
An event-driven review: When milestones are achieved, the sponsor and team members are
invited to discuss objectives of the project. Ask the following questions to the team member:
o
o
o
o
Have you achieved objectives set out at the last meeting?

Have you achieved the milestone as planned?
If not, what went wrong?
How can you avoid this happening again?
It is true that, if objectives have not been met, the future of the project could be held in doubt. This
would depend on the severity of the delays.
While the project may be keen to invite the sponsor every meeting, it is recommended that he or she do
not do so.
The principle is simple: the more people attending a meeting, the longer it will take to complete
the meeting and the more explanations of past issues that will have to be explained.
Key team members must attend all reviews, while other members should attend if they have specific
questions, need assistance or highlight how milestones were attained.
The project manager can also schedule times to meet specific team members, so that some have to
attend only part of the session.
Learner Notes: Every aspect of the project must be open for discussion.
Learner Notes: Ensure that review meetings are not too long; people lose interest after 45 minutes.
Learner Notes: All progress must be praised.
Agenda & Attendees

There is a presumption that every team member is important, so they must all attend every project
meeting. This is simply not true and the easiest way to sort out the question of who attends and who
doesnt is to have an agenda. This is circulated to all members, who respond in two ways:
They accept or reject the invitation.

They add items to be discussed to the agenda.
The key to a successful review meeting is discipline. The project manager must have all issues written
down and each agenda item must be allocated enough time. The aim is to keep everyone up-to-date
with progress and give them a shared understanding of what is happening.
Page 182 of 283
One of the most important issues that must be discussed at the review meeting is team members
promises made relating to task delivery times and whether they have achieved these. If they have,
then allocate next tasks.
In addition, the project manager must:
Record the entire session.

Control the meeting: allocate time to each issue and keep to this time.
At appropriate moments, summarise views and decisions made.
As objectives are achieved, consider releasing those people who are no longer needed.
Key decisions are made at review meetings, so it is essential for the project manager and team
members to prepare for them well.
Learner Notes: Remind people of the agenda when they stray from it.
Learner Notes: Always seek to end a meeting on a positive note.
Project Review
Once all tasks have been delivered, a final review of the entire project has to be made. Most projects
consume significant amounts of time, money and resources. There will always be issues to discuss,
explain and record. No project runs perfectly with perfect outcomes, so a post-project review is the
opportunity for the project manager and the project team to learn valuable lessons in how to run the next
project more effectively.
All these issues are discussed in chapter 28, so it is sufficient to state at this point that the final delivery
to the sponsor and client must have been agreed to before the project was started. Make sure that the
measures of success are objectively verifiable by an independent person and documented in the various
project documents. There is nothing worse for the project manager and his or her team than expecting
completion, but the sponsor states that there are still some issues to be completed. Know what the
project criteria for completion are before the project even starts.
Project success criteria are:
Was the project delivered on time, on budget and according to the signed scope
Were project team members, sponsor and client satisfied with the project
Did the project actually deliver the organisational benefits proposed?
With the issue of time and budget, remember that these will have changed before the project comes to
an end. However, with a well-disciplined project change control process in place, changes to the
projects original schedule, cost and scope will be captured in the major project documents. The project
manager must make sure that he or she reviews the latest version of the documents in constructing his
or her performance measures.
On completion of the project, the project outputs are handed over to the client, who is then responsible
for using the products or services of the project for the benefit of the firm. Benefits realisation, then, is the
third area in which to evaluate the projects success. The last stage of the post-project review process
develops and uses measures to determine to what extent benefits were actually achieved. In some
cases, this review is undertaken some considerable time after the project is completed.
In the next chapter how to overcome problems during the different Stages is outlined.
Page 183 of 283
CHAPTER 24: THE CASE METHOD OF

DECISION MAKING
However solid project plan may be, once operation start problems will occur. That is probably the
one certainty that project managers can guarantee. Therefore, there should be some form of
decision matrix to assist the project manager to determine the seriousness of that problem.
IDENTIFY PROBLEMS EARLY

The aim of any decision tool is to identify problems early, to prevent placing the entire project in crisis
mode. There are too many novice managers who take the approach that, if left alone, a problem may
just solve itself. It seldom does and it is far more difficult to take action when a problem has become
urgent than when it surfaces. With experience, a project manager and his or her team will get better at
judging whether (and when) to raise the alarm that a problem may be occurring. For instance, a project
to design and launch a new computer game may see a team member raise concern if that member
(tasked with registering the name) perceives that there will be problems the trademark. There may be
other games with similar names, so the team would be called in to discuss alternative names for the
product, before the software developers have completed their task.
In addition, there will be different levels of seriousness with problems, which will range from minor and
easily solved problems to ones that could have a major impact on the project. There is also the issue
that, if concerns are raised too early, task delivery times and dates will be affected, which is in itself a
problem.
Learner Notes: Assesses how serious a problem is (or may be) before trying to resolve it.
Learner Notes: Better to be prepared with a matrix, than being affected by festering minor problems that
become serious (often irreparable).
Learner Notes: Team members must raise concerns, but also solutions. This is what makes a team
member truly valuable.
Solving Difficulties
Before calling meetings, raising alarm bells and effectively disrupting the flow of the project, assess (as a
first and cursory step) where the problem is. This often identifies how serious the concern is and a
solution presents itself. For example, if a company should be producing 1000 vehicles per day on their
production line, but the number has fallen to 800 vehicles a day, the problem may be as follows:
Target
Question
Assessment
People
Product
Process
Page 184 of 283
Is staff the problem?

Do they have the right skills?
Are they producing less, because they are taking
too much time to do their specific tasks?
Do they need support?
Are they not motivated?
Are there design problems?
Are production methods incorrect?
Are raw materials the issue?
Is the process efficient?
Is the whole process a problem, or is it only a small
part of the process?
Would an improvement in specific processes
YES
NO
Procurement
resolve the problem?

Investigate whether products and services being
bought are inferior.
If any of the above is a YES, investigate further. For a more in-depth analysis of this form of
troubleshooting, see the authors 2007 MBA textbook called The Corporate Mechanic. It is thus sufficient
to state in this book that the project manager should:
Find the problem, but not start to resolve the issue, until he or she has a complete understanding of
the problem.
Not assume that his or her team members have problem-solving skills.
If suppliers are the problem, discuss the issue with the owners and, if the problem cannot be
amicably resolved, change suppliers immediately.
If the problem is a process, change it immediately. These problems do not go away.
All problem issues and solutions must be documented by the information co-ordinator in the
knowledge centre. These should be open to all the members with access. After all, significant
problems may have been resolved, but it could be at the expense of having to change the plan. All
relevant team members need to know that the plan has been changed, so that affected tasks can also
be changed by team members.
Learner Notes: Keep the sponsor and client informed if changes to the plan have been made.
Learner Notes: Ensure that solved problems do not reoccur.
DECISION MAKING TOOLS

Important decisions should always be made after effectively brainstorming, organising, analysing and
with complete information. This book has so far outlined methodologies to improve the flow of projects,
keep track, monitor and schedule tasks, but a methodology is needed during the Planning and Execution
Stages to assess and resolve problems quickly and efficiently. While there may be more generic
decision-making tools available to entrepreneurs in manual and computer software, the past two
decades of experience has enabled the author to develop an effective tool that can be used for:
Resolving problems.
Determining the validity of an idea.
The method is called CASE and the process is outlined hereunder.
Page 185 of 283

The CASE Decision Making Tool
The four basic steps under Case are the start of the creation of a basic decision-making filter system
These should provide the project manager with the basic tools that he or she will require to help the team
make the best possible decisions during both the planning and the execution Stages of a project.
C
A
S
E
Categorise the problems or idea

Arrange these in a logical manner
Study the ideas etc.
Elect the best solution
The name developed from both the acronym and from repeatedly asking team members prove your
CASE to me? Is your idea better than that existing in the environment? Is it easily used and
implemented?
Decision-making tools can be used for all sorts of issues, from making a holiday decision to mergers and
acquisitions. In addition, the Case process is a more in-depth process than outlined in this book and may
be the subject of a future book. In this book, Case will be concentrated on tools for project management.
Leaner Notes: Decision making is a process of identifying problems, exploring possibilities and
implementing a solution or solutions.
The Case process is best used in the following situations:
The problem is project specific: Where a problem has been identified and there are many possible
solutions and techniques to solve the problem. It is also used when new ideas can be implemented in
numerous ways.
Project team specific: Where a problem exists between more than two tam members, the Case
process should help to resolve conflict.
Lets start with Categorising problems.
Categorising (The C in Case)

It may seem obvious, but project mangers will concur: the more people involved in a project, the more
ideas will be formed and the higher the potential for problems to occur. So, in large projects, when new
ideas need to be discussed or problems occur, then the best and most efficient way to handle the
situation is to categorise the problem and brainstorm with the relevant team members and experts.
Page 186 of 283
The following four steps will assist project managers to expedite the process of categorising problems
and ideas into more succinct groups:
Step 1: Define the problem or idea. Begin the process by clearly defining the problem that has to
be resolved.
Step 2: Brainstorm all possible solutions with the team and relevant experts. The latter can be
psychologists to resolve team based problems or industry specific issues that have to be solved. For
instance, a supplier of a prerequisite raw material is unable to provide the product on time or, worst
case scenario, has gone bankrupt, which is not always easy to solve, i.e. strategic industries
petroleum, mining or scarce resources.
Use brainstorming guidelines to encourage quality ideas that are qualified by experts and
confirmed by team members.
Continue brainstorming until all obvious potential solutions have been discussed and
eliminated. This is a necessary and time consuming evil, as it is often it is the simplest idea
that is the best solution to resolve a problem.
The next step is to categorise the more complex solutions.

There will be few ideas and solutions. It there are many ideas, then the problem
cannot, by its very nature, be a complex problem. There should be few, high-level
solutions suggested and categorised.
Next, each potential solution must be brainstorming, but the emphasis is expert
assistance to resolve the problem, so a time must be set.
Step 3: Organise the team member into groups to sort out the categorised problems, i.e.
accountants for financial problems, human resources for employee problems and so on. The team
then begins the organising process in silence, which:
o
o
o
Reduces the influence of the project manager over the group, so that team members can
focus on the problem and not on saying the right thing in front of the project manager.
Encourages team members to assess problems as both general and as a project issue.
The process works faster, as fewer people are assessing the various categories; according to
skill and subject knowledge.
Step 4: identify importance of categories. Once the groups have completed their basic
assessments of the groups, two things happen:
o
o
All ideas and solutions that are not appropriate are discarded.
All ideas and solutions that have merit can be arranged into a priority list to be analysed.
The effect of the categorising past of Case is that time is saved, as not every idea is
analysed, but only pertinent and credible ones are.
Arrange (The A in CASE)

The next step in the process is to arrange the prioritised groups in such a manner so that cause and
effect on the project or task is identified. This will include separating the cause of the problem or its
symptoms. This will enable the team to determine the driving forces for change and whether change will,
in fact happen, i.e. symptoms may not be the root cause of a problem or issue. If it is not, further analysis
has to be conducted.
Leaner Notes: When evaluating potential solutions as set out in a priority list, there is tendency to focus
on solutions that will resolve the symptoms of a problem and not its root cause.
Page 187 of 283
The method of arranging issues and problems, to identify root causes, is outlined as follows:
Step 1: Attach a possible solution to each problem.
Step 2: Assess the possible solutions to see if these could be root causes to the problems.
Limit the number of root causes to a maximum of 10.
There will be times when the number will be higher than 10. Under such conditions, it is
recommended that some of the causes are grouped to keep the number of causes to no more
than 10.
Arrange the root causes in a circle, as follows.
Step 3: Compare each pair root cause to the others. For each pair, the project manager and
his or her team must determine whether one of these toot causes is a cause of the other. If one
of the two is a cause, then the other is an effect of that cause, which creates a cause-and-effect
relationship between the two.
o
When this occurs, the project manager must draw an arrow from the cause to the effect
and, where there is no clear cause-and-effect relationship, leave blank.
Every pair must be analysed in this manner.
Step 4: add up the number of arrows touching each pair:

o
o
o
Page 188 of 283
Outputs are arrows going out

Inputs are arrows coming in.
For example, if a pair has two inputs and one output (2/1) it means there are two arrows
into the pair and one leaving the pair.

Inputs & outputs displayed by arrows
Leaner Notes: The pairs with the most outputs are root causes, while those with the most inputs are
major effects or symptoms.
Step 5: Rearrange the pairs with root causes on the left (most outputs) and major effects (most
inputs) on the right. Place pairs with no outputs in the middle.
o
If there is a question about which root cause the project manager must work on, move to
the Study part of CASE, which include making decisions using Matrices.
Study (The S in CASE)

When there is a need to make decisions from a number of root causes, a matrix can be useful in that it is
objective. The following Matrix decision making tool will assist the project manager to see beyond the
symptoms to the root causes of either the problem or the solution. A similar matrix is outlined in the
authors 2007 bestselling book on derivative trading, called Richer than Buffett: Day Trading to UltraWealth.
A copy of the Decision Matrix can be downloaded for free from the authors website, www.magliolo.com.
Using a matrix can be time consuming, so the project manager tends to use one when there is a
significant or complex decision to make and he or she would like to analyze all options that are based on
a set of decision criteria. Usually, the visual display of the root causes (as stated above) are not enough
as there will usually not any consensus on what the best option is. Interpretation of diagrams (in Step 4
of A in CASE) can be subjective and, that too can be a problem.
Page 189 of 283
Step 1: Create the decision matrix, using an excel spreadsheet.
Decision Options
Criteria
Weight
DECISION SCORE
Step 2: List the decision options across the top of the matrix. These are the options that were
brainstormed as a group. Define a clear description for each option, and all team members (involved
in this process) must understand them before moving on to the next step. The following example is
one where the sponsor would like to add a derivative and forex training programme for the
companys senior analyst.
o
From the working groups, three options were determined:

OPTIONS TRAINING SPECIFICATIONS
Option 1 Training for senior analysts, who wish to
sign up for training sessions.
Option 2 Senior analysts are told to attend
prearranged workshops.
Option 3 Some analysts are trained in forex, while
others are trained in derivatives.
DECISION LABEL
Voluntary
Compulsory
Compulsory Choice
Step 3: Determine a list of criteria that will be used to make the decision. This set of criteria
must be pertinent to the options available and it must assist the project manager to make that
decision. The following are examples of decision criteria. The project manager must choose those
that will produce a YES, and not a NO in the matrix:
o
o
Cost of implementing programme must be Low.

Senior analysts cannot take mush time away from work.
The programme must be easy to implement
The implementation of the programme must be quick
Will forex and/or derivative training help the analysts make better and more improved trading
decisions?
Each option will be compared against each of the criteria chosen. Use a maximum of six
criteria and the project manager must use only the criteria that will assist him or her to in
make the decision that they need
Page 190 of 283
Step 4: List the criteria in the left hand column, as outlined in the next diagram.
Decision Options
Criteria
Weight Voluntary Compulsory Compulsory

Choice
Easy to implement programme

Senior analyst time away from
work
Benefit of training programme
DECISION SCORE
Step 5: Create a weighting system for each criterion. Use a 1 to 9 scale to give each criterion
a weight:
Weights
1 to 3
4 to 6
7 to 9
o
Criteria
Would be useful to implement such a programme
A programme would be highly beneficial
The programme must be implemented immediately
While it is best to have different weightings for each criterion, there are times when the
team members will not (or cannot) agree to what constitutes highly beneficial or a must
have criteria. When this happens each person must weight the criterion individually and
then the project manager can use the average weighting.
Decision Options
Criteria
Easy to implement programme
Senior analyst time away from
work
Benefit of training programme
Weight Voluntary Compulsory Compulsory

Choice
1
3
7
DECISION SCORE
Step 6: Rate each decision option against each criterion. The project manager can use set of
weighting. For the example above, the following rating scale is used:
3
6
9
o
Page 191 of 283
Decision is not satisfactory

Decision is only moderately positive
Decision satisfies the criterion completely
Write the rating in the top left-hand corner of the cell, as shown in the following diagram.
If consensus cannot be reached as a group and after discussion, the project manager
must ask each person to rate the decision options versus each criterion and then use the
average.
Step 7: Multiply the ratings by the criteria weights.

o
Page 192 of 283
Calculation:
Ratings (in the upper left corner of the cell) x criteria weights (second column from
the left).
Totals are in the bottom right-hand corner of the cell.
For each decision option, add the right corner numbers and place the total at the
bottom of the column.
The column with the highest number is the solution to be considered.
Discuss this as a team and decide if this is the best solution based on the defined
goal set by the project manager and his or her team before this process started. If
the solution doesnt make sense, review the criteria, the weights given and the
ratings.
If it is not necessary to use an analytical approach to making the decision, the project
manager can use a faster and simpler decision-making tool, the E in CASE. It is
recommended, however, that the last part of CASE is used to confirm the decision made
with the Matrix, rather than using it as an alternative.
In the example, the decision made was to make it compulsory for senior analysts to
attend one programme, either derivative or forex traing.
Elect (The E in CASE)

The elect from decisions method allows the project manager to use a method to quickly narrow down a
set of options when the decision matrix (as outlined in the previous section) is not completely clear. For
instance, if the decision score was Voluntary 55, Compulsory 59 and Compulsory Choice 58, then the
project manager could make the decision, which could be seen as subjective and not part of a team
effort. Under such conditions, the project manager can ask the team to vote, so that consensus is
obtained.
Step 1: Ask each person to think about the criteria he or she will use to make his or her decision.
Then ask each person to vote for the decision options that he or she feels are the best.
Step 2: When the voting is complete, count the numbers for each option. Rank the options from
highest to lowest votes. Check to make sure this ranking makes sense to the group. Before making a
final decision, the project manager can:
o
o
Pick the highest ranking option as the decision for the group.
Weigh the strengths and weaknesses of the top two or three options, and then choose one.
Chapter 25 is a more in-depth assessment of potential risks associated with project.
Page 193 of 283
CHAPTER 25: RISK MANAGEMENT

It is amazing how many project managers, despite globalisation of markets, industry and
business, cannot draft an adequate project risk management plan. The reasons seem to depend
on the country of origin, where first world country-based project managers tend to assess
company risk, rather than the environment within which they operate. That is a highly
presumptuous stance, and an extremely dangerous one for the long term prosperity of the
project.
TYING RISK TO PROJECT DOCUMENTS

This chapter is a brief guide to assist project managers to compile a risk management plan.
The Basics
The following is a summation of issues raised earlier in the book, but tying them to the spectre of risk.
Risk Management: The ability to manage risk is one of the most essential traits of a skilled project
manager; particularly in a globalised world, where risks rise exponentially. Understanding the
concepts of risk management is all important when trying to juggle the multitude of tasks that have to
be prepared, completed, checked and discussed. It is also a useful tool to identify anything significant
that could go wrong with the project and then set out a risk management plan to eliminate (or at least
mitigate) these risks; hopefully avoiding their consequences.
o
Normally, project managers use risk techniques as warning bells to warn them before a
project is influenced by risk. One of the best uses of risk management is to discuss risk in
all regular project meetings to highlight, to everyone, the risks that the project currently
faces.
Risk Management Officer: One way for larger-scale projects to control their risk is to appoint a
risk management officer, which could also be the information co-ordinator. The risk management
officers responsibility is to identify all the risks to a project and to prioritise and present them to
the project team for resolution.
o
Risk management is part of the project managers role, particularly in the case of smallscale projects. Rather than appointing a risk management officer, a discussion of risks is
added to regular team meetings. The formalised process of profiling and resolving risks
can then be applied in an informal manner to plan for potential threats to the project.
The simplest way of recording risks is with a spreadsheet that lists the risks in a prioritised
manner. These can be regularly reviewed by the project team and action taken to mitigate
or eliminate these risks.
Learner Notes: The more likely a problem is to occur, the more risk it poses the project.
Risk Profiles: there are two major elements to measuring risk, namely, the likelihood of failure
and the impact of failure.
o
Page 194 of 283
Even fairly minor problems or issues can become a threat to the project if they occur
frequently and cannot be avoided.
Some problems can destroy a project, so a warning system is necessary. Many complex
systems exist for categorising problems (as set out in previous chapters), but project
managers can use a simple method of looking at the likelihood of a risk happening and, if
it does, assessing what the impact on the project will be. Simply rate risk according to low,
medium and critical and, once profiled, can be ranked into an ordered list to be examined
by the team, appointed experts and the project manager.
On a simplistic level, typical actions for identifying risk are as follows:
Research: Once identified, a risk must be assessed according to the environmental factors to
determine its potential impact on the project.
Accept: Risk cannot be avoided and, as such, must be faced head on. It is also critical to categorise
risk according to its potential severity so that it can be resolved accordingly. For instance, a minor
risk of someone being too sick to continue to work is minor, when compared to war breaking out in
the country where the project is being run. Anticipation therefore become the key to dealing risk.
Reduce: The project team must act to reduce risk and to establish contingency plans should a
particular risk re-occur. Risks have to be continually reviewed to define whether such risks have been
mitigated or whether they could rise again.
Eliminate: The project team must put in place procedures, not only to ensure the immediate threat is
eliminated, but that it does not re-occur in the future.
PROJECT MANAGEMENT SPECIFIC RISK

A risk is something that may or may not happen, but if it does could have a serious impact on the project;
in whole or in part. When the author is approached by a team member with panic in the eyes, saying that
the project is at risk, we may have a problem, which will have an adverse impact . The first issue is
that may implies that the risk is not a certainty, which means less than 100% chance that it will manifest
into a real impact on the project. The second issue to consider from the panic statement is that, if a risk
doesnt have an adverse impact, it is not a risk. The tendency is to panic, but with proper planning, risks
can usually be handled and, if done properly, mitigated.
Risk Management Plan

There are five stages to risk management. Many text books suggest that monitoring and control are the
same. They are:
Stages of Risk Management
Page 195 of 283
Identifying Risk: First, identified the risk and given a name. The best approach is a workshop with
experts (legal, accounting etc) to carry out the identification. Project managers can use a
combination of brainstorming and reviewing of standard risk lists.
o
There are different sorts of risks, which makes it more difficult to generically identify risks and
possible affect on projects. The project manager and his or her team must decide on a
project-by-project basis what to do about each type.
Business risks are ongoing risks that are best handled by the client and his
managing director.
Generic risks are risks to all projects and include anything from a team member
being sick, production lines failing and union strike action. Each organisation must
develop standard responses to generic risks. Risks should be defined in two parts.
Quantifying Risk: Risk need to be quantified in two dimensions:

o
o
The impact of the risk needs to be assessed.

The probability of the risk occurring needs to be assessed.
For simplicity, rate each on a 1 to 4 scale, as indicated in the following diagram. The larger
the number, the larger the impact or probability. By using a matrix, a priority can be
established.
Cause of the situation.

Impact
If probability is high and impact is low, it is a Medium risk.

If impact is high and probability low, it is High priority.
Responding to Risk: There are a number things that a project manager can do about a risk. The
strategies are:
o
Avoid the risk: this doesnt mean ignoring the risk; that would be disastrous. The project
manager could remove the threat of a risk by, for instance, changing supplier of raw
materials etc.
Transfer the risk: The project manager can make someone or some other organisation
take responsibility for a risk. For instance, risk of currency fluctuations can be mitigated by
taking out insurance. It is important to note that some risks are not (fully) transferable, in
particular the transfer reputation.
Page 196 of 283
Mitigate the risk: Direct action is taken to lessen or avoid the impact or chance of the risk
occurring. If the risk relates to availability of resources, draw up an agreement and get
sign-off for the resource to be available.
Accept the risk: The risk might be so small the effort to do anything is not worthwhile.
Tolerate: The exposure (i.e. the risk) may be tolerated without any further action being
taken. Even if the risk is not tolerable, the ability to do anything about some risks may be
limited, or the cost of taking any action may be disproportionate to the potential benefit
gained. In these cases, the response may be to tolerate the existing level of risk. This
option of course, may be supplemented by contingency plans for handling the impacts
that will arise if the risk is realise,
Terminate: Some risks will only be treatable, or containable to certain levels, by

terminating the activity concerned. It should be noted that the option of termination of
activities may be severely limited in government when compared to the private sector,
because the associated risks are so great that there is no other way in which the output or
outcome, which is required for the public benefit, can be achieved.
Treat: By far the greater number of risks will be addressed in this way. The purpose of
treatment is to constrain the risk to an acceptable level. Such controls can be further subdivided according to their particular purpose, as follows:
Detective Controls: These are designed to identify occasions of undesirable

outcomes having been realised. Their effect is by post-event, so they are only
appropriate when it is possible to accept the loss or damage incurred.
Directive Controls: These are designed to ensure that a particular outcome is

achieved. They are important when it is critical that an undesirable event is
avoided. Examples of this type of control include a requirement that suitable
protective clothing be worn on a building construction site, or that staff be trained
with required skills before being allowed to work unsupervised.
Preventative Controls: These are designed to limit the possibility of an

undesirable outcome being realised. The more important it is that problems do not
occur, the more important it becomes to implement appropriate preventative
controls. The majority of controls implemented in organisations tend to belong to
this category. An example of a preventative control would be separation of
financial and budget management duties, whereby no one person has authority to
commit expenditure without the consent of another authorised person.
Corrective Controls: These are designed to correct undesirable outcomes that

have happened. They provide a route of recourse to achieve some recovery
against loss or damage. Contingency planning is an important element of
corrective control, as it is the means by which organisations plan for events that
cannot be control, such a death of key employees.
A risk response plan should include the strategy and action items to address the strategy.
The actions should include what needs to be done, who is doing it and when it should be
completed.
Risk Control: The final step is to continually monitor risks to identify any change in the status of
that risk. It is best to hold regular risk review meetings to identify actions outstanding, risk
probability and impact, remove risks that have passed and identify new risks.
Page 197 of 283
Learner Notes: Risk management is not a complex task.

The steps outlined above will enable the project manager to start the process of compiling a risk
management plan. Without a plan, the success of the project, and the reputation as project manager, are
at risk.
ANALYSIS OF RISK
Every Project has Problems
The key to keeping chaos at bay is preventing as many of the problems from occurring as possible. Yet
this is not always possible. Even highly skilled and experienced project managers have unexpected
problems happening to them. For instance, travelling should be a well planned event, with booking of
airplane tickets, hotel and vehicle standard items to complete before leaving on the trip. A well travelled
Johannesburg businessman arrived in Cape Town, late due to poor weather, went to the car rental
agency, to find that there were no vehicles available. The agent had given his car to someone else,
because his plane had been late.
Furious, went back into the airport terminal and decided to take a bus shuttle to the hotel. After all, the
hotel could then arrange a vehicle for him. Unfortunately, his booking at the hotel had been given away,
as it was after six oclock in the evening.Sorry sir, the hotel is full.
So, the businessman had no car and no hotel to stay in. could anything else go wrong? What was the
risk of that happening? He phoned his secretary, who did arrange vehicle and hotel, but when he
arrived at the hotel found that he had left his wallet in the taxi. Have you ever had unexpected events
cause your best-laid plans to go astray? The planning activity that helps you avoid unnecessary
problems is called risk assessment. In the case of the businessman, his secretary could have phoned
the hotel to confirm the booking, stating that he would arrive late, the car issue could have been resolved
if his vehicle had been booked through the airline, which would have linked his flight ticket to the car. The
agent would have known that he would arrive late and the car would be waiting for him.
The goal in assessing risk is to prevent potential problems from turning into real problems, but how
would risk assessment help with something as uncontrollable as the weather, or currency fluctuations or
even worse natural disasters? There are some risks that cannot be eliminated, or even mitigated.
However, most risks can be minimised through proper planning.
Types of Risks
While there are many risks that can influence a project, from market, business, trading, currency and
financial risks, there are three main project management related risks.
Scope risk: The risk of not being able to meet the sponsors acceptance criteria. Also known as
technical risk.
Schedule Risk: The risk of not being able to meet the schedule risk deadlines, particularly
milestones and the final deliverable.
Cost risk: The risk of exceeding the budget.
The project manager and team members can help to identify risks, because they participate in the entire
process, through the four stages of project management. The sponsor and client also have a large stake
in the customer project, so it is to their benefit to help to identify risks. Other parties include the resource
managers, key suppliers and anyone else affected by the project. These people have an interest in the
project and will contribute ideas and end up as supporters if they are included in the meeting. It is also
wise to invite industry experts, who know something about technical aspects of the project. They can
help to identify potential technical problems.
Page 198 of 283
Meetings of all relevant parties can achieve the following:
Getting their concerns discussed, so they can be quickly addressed.

Benefiting from other peoples experiences.
Raising awareness of a projects needs and risks.
Increasing understanding of project issues and challenges.
Developing commitment to the solution.
RISK ASSESSMENT MEETING

Its important to have the right people at risk assessment meetings. There is no point in inviting only
team members to risk assessment meetings. Invite everyone who might help to identify potential
problems. People outside the team add value to the risk assessment process by:
Adding another source of ideas.

Leveraging a scarce resource, especially someone needed by the team, but who cant be a team
member.
Obtaining commitment and buy-in to the solutions and countermeasures generated.
Stage 1 of the meeting

The first stage, identifying risks, begins with brainstorming. The project manager must ask the group to
brainstorm all the things that could go wrong with the project. Remember:
All ideas are good ideas.
Make sure each idea is complete; do not use one word ideas, because the member will forget
later what they meant.
Make sure each idea is recorded.
Go for quantity, not quality.
No judgment.
Keep the momentum going.
When the group seems to have exhausted its ideas, ask them for 10 more. That will help the group push
the creative thinking process. Next, ask the group to identify any assumptions they hold, which if proved
not to be true, would create a problem for the project. Record the groups assumptions, then convert
these assumptions to risks by asking what would happen if each assumption were not true and, as a
result, would cause a problem for the project. Write the problem and include it with the other
brainstormed risks.
Once the project manager has identified all the possible things that could go wrong during the project, its
time to define how likely it is that each of those potential problems might occur and, if they do, the impact
or damage that would be caused by the occurrence.
The chance that something might occur is called the risk probability.
First, rate the probability of occurrence as zero, low, medium, or high. When there is consensus on the
probability rating, write it in the lower left-hand corner. Zero-probability risks are events that the risk will
not occur.
Page 199 of 283
Next, ask the group to rate the impact of each of the brainstormed risks.
Probability Rating Meaning
Zero: There is no chance that this risk will occur
Low: The probability that this event will occur is between 1 and 40%
Medium: The probability that this event will occur is between 41 and 70%
High: The probability that this event will occur is between 71 and 99%
RISK MATRIX
After each risk has been rated, its helpful to organise them into a priority list. This is done by placing
each risk into a risk analysis matrix, called a Probability/Impact matrix; as outlined hereunder.
Probability Rating Meaning
Zero: There is no impact if this risk should occur; therefore, its not truly a risk.
Low: The impact on the project is minor, but would be noticed by the sponsor.
Medium: The impact to the project is significant and would cause the team to miss deadlines, or
overspend the budget.
High: The impact is significant and would jeopardize or kill the project probability and high impact,
but the overall rating for this risk would be medium.
Number all the risks on the grid consecutively, starting at the top right and working down to the bottom
left. The order isnt particularly important; just assign a unique number to each risk. It will make it easier
to keep track of them later.
Now its time for the project manager to step back and look at the distribution of the risks on the grid and
ask the team:
How risky is this project overall?

Is it highly risky? Medium? Low?
Impact Probability Matrix
Developing Counter-Measures
For each risk in the medium or high sections of the matrix, brainstorm ways to prevent the risk from
occurring or reduce the probability and/or impact of the risk.
Page 200 of 283
The project managers risk sessions should see each member write counter measure ideas and work
through each risk, brainstorming potential counter measures. If a single counter measure addresses
more than one risk, write the risk numbers on the note and attach it to one of the risks. Once the
brainstorming process has been completed, the project manager will need to choose which counter
measures to include in the project plan. Obviously, the ones that are freethat dont add time to the
schedule or costs to the budgetshould be added first. Next, add any counter measures that address
multiple risks and that are good ideas. Then add counter measures that reduce the risk from a high or
medium level to a low level.
Make sure the counter measures chosen dont end up costing more money or time than the potential
associated risk. Choose counter measures that are consistent with the project priorities set down in the
scope. As counter measures are selected, assign these to team members, who will be accountable for
implementing the counter measure. Then, reassess the impact and probability ratings for the risk(s) that
the counter measure will affect.
RE-ASSESSING OVERALL RISK

Once the project manager has selected the counter measures, revised probability and impact ratings, he
or she will need to step back and reassess the overall risk of the project.
Is the project still of a high or medium risk?
If so, the manager will need to discuss the situation with his or her sponsor, to find out what he or she
wants you to do about the remaining risks. Options then need to be discussed with the client mto have a
final decision.
Final |Risk Check
Before the project manager can wrap-up the risk assessment, he or she must ensure that anything has
been missed. To achieve this, ask the following:
Did the project manager invite technical experts, client and team members to the risk assessment
meeting?
Were all risks identified? Did you have outsiders in the risk assessment make sure that nothing was
missed?
Did the project manager eliminate risks that had a zero impact or probability?
Were all possible counter measures brainstormed, including some that sounded crazy?
Were the counter measures chosen based on the projects priorities?
Did the project manager assign someone to be accountable for each counter measure?
Is the overall project risk low and, if not, has anything been gotten, eg. permission from sponsor? Or,
has the sponsor agreed to accept a higher level of risk?
PROJECT PLAN DOCUMENT

The final step is to document the information that has been gathered. A simple form is the best way to
capture the work done with the risk assessment group. Write the name of the project and the name of
the project leader. Then list the original risk rating for the project before the developed counter
measures.
Next, list the final risk rating for the project, with the counter measures. In the body of the table, write the
risk number, the name of the risk, the original probability and impact ratings. List all of the counter
measures that were brainstormed for the risk, including those that were not included. Next, place a
check mark after those that will be used and then write the name of the person who is accountable to
make sure the counter measure gets done.
Finally, record the new probability and impact ratings for the risk, based on implementing the counter
measure. This is the risk assessment.
Page 201 of 283
RISK ASSESSMENT FORM

Project Name:
Project Manager:
Risk no.
Risk
Risk Rating:
Original:
Project
Rating
Impact
Rating
Counter-measures
Final:
Team
Member
NEW
Project
Rating
NEW
Impact
Rating
TAKE THE OPPORTUNITY

This option is not an alternative to those above, rather it is an option that should be considered whenever
tolerating, transferring or treating a risk. There are two aspects to this:
The first is whether or not, at the same time as mitigating threats or risk, an opportunity arises to
exploit positive impact. For example, if a large sum of capital funding is to be put at risk in a major
project, are the relevant controls in place judged to be good enough to justify increasing the sum of
money at stake to gain even greater advantages?
The second is whether or not circumstances arise which, while not generating threats, offer positive
opportunities. For example, a drop in the cost of goods or services frees up resources which can be
redeployed elsewhere.
In designing controls or counter measures, it is important that the applied control is proportional to the
risk. Apart from the most extreme undesirable outcome, it is normally sufficient to design control to give a
reasonable assurance of confining likely loss within the risk appetite of the organisation. Every control
action has an associated cost and it is important that the control action offers value for money in relation
to the risk that it is meant to be controlling.
Learner Notes: The purpose of control is to constrain or manage risk, rather than to eliminate it.
For very small projects, risk assessment might involve getting the team together a week before the
project manager is due to make commitments. A half hour meeting in which you ask the team what they
think are the risks and maybe to go through a simple checklist (see the Appendix) may be all that's
needed. Though risk reduction may still be difficult.
For very large projects, the project manager may have much more formal processes, perhaps formal
health and safety risk assessments, and even employ consultants to assist if the company has no
experience of projects of that size and nature
Chapter 26 sets out methodologies to assist the project manager to deal with change, and how
that change impacts on the project.
Page 202 of 283
CHAPTER 26: DEALING WITH CHANGE

Change is inevitable. So, why would it be different for projects and project managers? As such,
flexibility is in management style is essential if the team is to get through all the issues, changes,
risks and errors that seem standard in global projects. This does not mean that every change
must be taken as sacrosanct. The scope of a project will change; buy how much, depends on the
project managers ability to negotiate, adapt and keep everyone informed about what is
happening.
CHANGING SCHEDULES
There are, without doubt, different levels of severity in the impact that changing macro-economic
environments or specific issues can have on the future project landscape for the project manager. Some
changes will be minor and easily controlled, while others will be forced on the team through natural
disasters, personal team member problems, difficult sponsors or clients. These issues are imposed upon
the team and, if not monitored, can have a negative impact on the project. Therefore, when influencing
changes do take place, the project manager must be in a position to adjust the project plan; efficiently
and rapidly. In addition, there must be a mechanism to measure whether the desired effect on the project
has been achieved, so that he or she will know if the change has been successful.
If the project manger has a strong team, then he or she can meet to evaluate how changes might impact
on the project plan, by assessing proposed changes against the original goals, budget, team
specifications, resources and time.
Learner Notes: Change is not always negative to a project plan. Assess alternatives before making
changes that may have a major, long-term impact on the plan.
Learner Notes: Once a decision has been made to implement a change, do it quickly and efficiently.
Hesitation is the quickest way to turn minor problems into cruel ones.
Assessing Impact
An assessment of a defined and identified necessary change must be assessed to determine its
potential impact on the project. Therefore, there is an urgent need to review how such changes will affect
the schedule, budget and resources; as set out in the project plan.
Can the projects objectives be achieved using alternative methods?
Once changes have been made, the information co-ordinator must
document them on the original plan.
Approval must be obtained from client, sponsor and team members before
implementing them.
There will be times when the change comes from the client or sponsor. When change is dictated, it may
not always make sense. Determine whether carrying out the change will affect the eventual outcome of
the project, but if the change is frivolous, or negative, first approach those imposing it and make them
aware that the findings are that the benefits of the project will be minimised. Again, document this and
add it to the project plan. If the project manager is a full time employee of the organisation, he or she will
usually capitulate and do the bidding. It is always better, however, for the project manager to fight for his
or her belief, because if implemented and the project does fail to deliver original promises, the
sponsor will still look at the project manager and team for answers; despite the issue been documented.
If the project manager is an appointed professional, he or she should insist on a clause in the
appointment letter/contract that states that the sponsor and client may not interfere with the project.
Under conditions that are critical, interference should be carried out as team efforts and not arbitrary,
independent dictatorial commands.
Page 203 of 283
An alternative is to offer the sponsor different choices that would have the same impact as the change
that he or she insisted on; but one that would still meet the projects objectives. The only other choice is
to walk away from the project, stating breach of contract.
When forced to make change by sponsor or client, the project manager and team are effectively told that
their hard work on scheduled tasks was wasted time. The team gets despondent and demotivated.
These are standard responses for the project manager and team, so the quicker it is dealt with, the
quicker the team will be able to return to their tasks.
Talk to the team about how changes will affect them.
Explain the rationale behind the changes and why they had to happen.
Redefine new objectives, time frames, or roles.
Discuss issues individually if anyone is still unhappy about the changes.
CHANGE MANAGEMENT
Learner Notes: Do not hesitate to explain the benefits of change to those affected by it. They will be
waiting for an explanation.
Change Management should be applicable to all sizes and types of projects and the goal is to control
these changes to minimise the impact on the project as a whole. Any change to a task will involve
resources to make the change and have potential impact on other tasks and, ultimately, the overall
project. Only when the change is assessed in relation to its overall impact on the project, can an
informed decision be made on the merits of the change.
Whatever change management process is used, it should be designed for project managers. A Change
Request is raised and approved and is the mechanism which triggers the deployment of the Change
Management process; see three step process later in this chapter.
In many corporations around the world, change will not be permitted without approval of the sponsor,
usually due to the need to change budgets and time of project delivery.
Factors Taken into Account in Making a Change
The project manager evaluates the proposed change by taking into account such factors as business
benefit, costs, process change, impact on users and the company, risks, impact across function etc.
By considering the additional amount of resource required from the business, change must be
defined as either:
o
o
o
Priority
mandatory
non-mandatory
Raise Change Request. The information required is as per the Change Request template (see
diagram).
Track Change Request progress.
Update documentation and plan as necessary.
Review change request information and assess risk and the impact of the change within the project
and plan contingency action. Where necessary, approval to proceed should be obtained.
Allocate the change to the appropriate resource and estimate change to the schedule; including roll
out of the change and integration of the change into project plan.
Page 204 of 283
Ensure that all changes to released items are authorised as appropriate.
All changes must be tracked until closed.
It must be possible to trace a change in a task, to the change request, in which the change was
raised.
Controls & Measures

Change requests are approved by the sponsor and client. If the change affects the scope of the project
then the approval needs to be by the client; the person who signed the project managers appointment
letter.
Changes, which have been implemented, must be publicised by the project manager through the efforts
of the project co-ordinator; project documentation, project web-sites, email distribution, project meetings
or any other medium deemed appropriate.
Who is responsible for what?
Function Activity
Evaluate change, prioritise and raise change
request
Implementation of the change
Deployment of the change
Internal review
External review
Update related documents and version umbers
Sign off
Client
Project
Manager
Sponsor
Team
Members
Primary
Customer
X
X
X
X
X
X
X
X
X
X
X
X
X
CHANGE REQUEST TEMPLATE

Change Request documentation may vary from company to company. The key issue is that a Change Request
mechanism is established and followed. This is a generic template, which may be adapted to suit local processes.
Essentially, the process is split into two sections the Change Request and the Change Analysis.
PART A THE CHANGE REQUEST
Request Serial Number: A reference number, which readily identifies the change request, must be stated.
This number is under the joint control of the project manager and sponsor.
Project: Why is a change request made? Include appropriate version numbers of documents, release
numbers of programs etc.
Originator: Name of person requesting the change
Date Raised: Insert date
Reason for change: What has caused this change request; process change, failure in requirements
capture, new requirement, etc?
Affected Area: A description of the area of the project affected by the requested change, including
business processes which are affected.
Priority: High, medium or low. Describe the priority of this change request and include the required
completion date.
Change Authority: On whose authority is the change being requested? The project manager, sponsor or
Page 205 of 283
client?
Change Description: A description of what happens prior to the change and a description of what will
happen as a result of the change.
Cost: Estimated costs, including any team member and business involvement.
Impact on dates: Any known or estimated impact on project dates.
Benefits: What is the benefit of making this change; financial. Labour saving, fixing a problem etc.
Status: Completed on ongoing basis by change requestor
Date: insert current date
PART B - CHANGE ANALYSIS
Implementation: How is the change going to be addressed?
Affected Items: What will have to be changed? Any documents, tasks, process descriptions, any
associated programmes etc.
Implementation effort: How much effort is estimated to be required to undertake this change? Including
roll-out.
Cost: Overall cost.
Impact on dates: Any update to the estimated impact on project schedules.
Sections affected: Details of the groups or individuals affected by the change.
CHANGE ISSUES
Here is a truism. There is always uncertainty at the start of a project. However well the requirements are
defined, they will change as bit as the project progresses. Issues will arise that were not foreseen.
What is an 'Issue' in the context of a project? An Issue is simply a threat to project success. The next
question then, is what is the difference between an Issue and a Risk? The distinction is minimal, but
some text books claim the following:
Threats to project success, that are identified at the start of the Stage, are called risks.
Things that occur during the project are handled as issues.
Personally, the only issue is how to handle these risks/issues. In a small project, the risk/issue
management process is usually a discussion at the weekly status meeting, and assigning these to a
team member to resolve and document (in the minutes) what the risk/issue is and how it is eventual
resolution. In larger projects, the risk/issue is analysed in more depth and decision-making tools are
applied (see Chapter 24).
These seem to be two extremes: change discussed during regular meetings or placed through intensive
decision-making tools. Whichever extreme used, the issue management process comes down to this:
Before the project starts, design an issue process that will meet the project's need.
When an issue arises, write down what it is.
Page 206 of 283
Assign the issue to somebody to resolve. In a small project the project manager will decide who to
give the issue to for resolution. In a large project that might be delegated to the team leaders - they
decide which team member should be asked to resolve an issue.
The person asked to resolve the issue does whatever it takes to get it resolved.
Escalation paths must be open. The last thing that the project manager wants to occur, when the first
major issue arises, is not to know how to get to the sponsor. Before the project starts, agree with the
sponsor how to communicate with him or her if urgent issues arise.
The sponsor must agree to as set deadline to make timely decisions.
Write down how the issue was resolved.
In status meetings, monitor open issues and give particular attention to issues that are past their
target resolution date. Occasionally, what seems to be a minor issue is raised, given to a team
member to resolve by a certain deadline - but they don't resolve it in time - and what seemed to be a
minor issue conceals a much bigger problem lurking underneath.
One thing to watch out for on larger projects: make sure the person who raised the issue is satisfied
it is closed. Otherwise, if the loop isn't closed like that, and they aren't happy with the closing, they will
raise the issue again under a slightly different title. A project of any significant length will necessarily
deviate from its original plan in response to circumstances. This is fine as long as the change is
understood. If the change is not managed, but is happens at a whim, it is no longer a project, its
anarchy!
Change management is a way of assessing the implications of potential changes and managing the
impact on a project. For example, a change in client requirements might mean a minor fix or it might
mean a complete re-write of the design. Change management gives the project manager a process to
evaluate this and introduce the change in a controlled fashion.
Since change is inevitable, the project manager needs a flexible way to handle the inputs to the project,
so that change can be easily handled. If inputs are static, unchangeable documents then you are going
to be hamstrung by their inability to keep pace with changing circumstances in your project.
CHANGE-MANAGEMENT PROCESS PLAN
Change Management Process Plan
So far, discussion relating to change management has been broad. Now, in the case of a multitude of
change requests, the project manager will need a change-management process to handle these
requests; even once approved. Without a formal process for handling such volume of changes, the
project manager is likely to run into the problem of scope creep, which occurs when the client and others
continue to add things to the scope once the project plan is approved.
Page 207 of 283
Even without scope creep, projects often experience some need to change the scope or even the
schedule or budget, while the project is being executed. This is not due to inability of managers to
accurately predict future events, but because conditions may change during the project. Therefore, there
needs to be a method to make corrections as the project proceeds.
A change-management process
Forces evaluation of each request, so that changes are not assumed to be automatic.
Keeps the project scope, schedule and budget under control and current.
Helps the team to differentiate between necessary changes and unnecessary ones.
Requires that the impact of each change be evaluated.
Keeps the project plan current.
A change-management process should include
A description of the change-management process. This shows the steps that will be taken when a
change is requested.
A change request form (sample: See Appendices). This is completed by the person requesting the
change to the project plan. This might be the client or it could be the project team, if, for example, it is
determined that a deadline date cannot be met or a feature of the final deliverable cannot be created.
In addition, the project leader will need a change log to track the status of each requested change.
THE CHANGE-MANAGEMENT PROCESS

The three Step Process
These three steps are primarily managed using a change-request form, which has three parts: the
request for a change that includes an explanation of why the change is needed (the justification section),
Page 208 of 283
an analysis of the impact of the change on the project (impact analysis section), and a section for
approvals (approval section).
The justification section is completed by the person requesting the change; client, sponsor or project
team. Or, if the request is sent to the team via e-mail or a phone call, the justification section is
completed by the project manager and then signed by the person requesting the change. The project
team completes the impact analysis section. The approval section is completed by those people who
need to approve a change to the plan.
Step One: The Request. When a change to the project plan is requested, the first thing that needs
to be done is to complete the top section of the change-request form. The justification section of the
form addresses the following questions:
o
o
o
o
What does the requestor want changed?

Why does the requestor want it changed?
How does the requestor suggest you incorporate the change into the plan?
How urgent is this request?
Step Two: The Impact Analysis. Next, assuming that the change is a good idea, the project team
will need to analyze the change request and develop a proposed plan for handling the change. This
involves having the team go back through the steps of planning to assess the impact of the change
to the project plan.
In this planning session, the team will have to evaluate the effect the change will have on
scope, risk and resources.
Step Three: Approvals. Finally, after the impact to the project is analyzed, the request must be
approved if the project plan is to be amended. The people who need to approve the change vary
from one company to the next, but typically the originator of the request, the project manager,
sponsor, and client must approve a change. If other approvals are required, the project manager
must include them on the form. A change-request form, including instructions for completing it,
should be included in the project plan.
o
THE CHANGE LOG

The project leader needs a method for tracking the status of each change request. For projects that
receive very few change requests, this isnt much of an issue. However, some projects receive continual
change requests and a formal system for tracking those change requests is required. This tracking is
done via a change log. An example of a change log is shown in the following table. Each change request
is given a number. The originator of the request is recorded and the change that is being requested is
described.
The date the change request is received and the date a decision on the request is required are also
noted. An urgency column can also be added. Next, record the impact-analysis results. Describe the
changes that will be made to the scope. For schedule impact, indicate the number of days, weeks, or
months that will be added or deleted from the schedule. For spending impact, show the amount of
increased or decreased funds in the budget. Finally, record the date the change was approved or
disapproved.
If the project manager has the date the change request was received and the date it was
approved, he or she can calculate the cycle time for each change request/.
This is the time it takes from when a change request is received until a decision is made on
whether to proceed with the change.
This completes the change-management section of the project plan.
Page 209 of 283
ASSEMBLE THE PROJECT PLAN

The project manager now has all the pieces he or she needs to assemble the main body of the project
plan. The project manager must review the following check list to ensure that he or she are not missing
anything.
PROJECT CHANGE LOG
Project Name
Project Sponsor
Changes
#
Originator
Description
Date
Received
Date
required
Scope
Impact
Schedule
Impact
Spending
Impact
Approval
Final check before moving to the next phase

Checklist
1
Have tolerance levels been agreed?
2
Are monitoring and reviewing procedures being implemented effectively?
3
Has a management by exception approach been adopted?
4
Is it clear who reports what and to whom and how?
5
Are reporting mechanisms meeting the needs of the project?
6
Are regular planned versus actual reports being created?
7
Are variations quickly flagged?
8
Is there adherence to the meeting schedule?
9
Is quality being maintained at the specified standards?
10 Are audit requirements and schedules being met?
11 Is an appropriate level of control being applied (loose versus tight)?
12 Are issue and change management procedures being implemented effectively?
13 Are risk management procedures being implemented effectively?
14 Are quality management procedures being implemented effectively?
15 Is there a need for User Acceptance Testing?
16 Have all necessary records/documents for project management and control
been created and kept up-to-date?
Page 210 of 283
STAGE
1
PROJECT
Initiation
Planning
Execution
Completion
STATUS
STARTING
Move to:
Y N Comments

The Execution Stage aimed at carrying out schedules that were set during the previous Stage.
As expected, problems were identified and alternatives were discussed at weekly project management
meetings. The aim was to Identify problems, so that these could be avoided. The assessments looked at:
Staff: the potential of senior staff leaving when the merger took place. To counter the potential
departure of skilled staff, it was determined that a share incentive scheme would be implemented for
staff, who would (according to a pre-determined formula) get shares in the new listed company.
Industry trends were tightening: Competition was increasing as global players were entering the
local market quicker than first estimated. It was determined that the new listed company would have a
planned acquisition rollout. Two potential candidates would be targeted.
A new task was added to the schedule; Magliolo would start analysis and possibly discussions with
these two takeover candidates. This change meant that professional fees had to be renegotiated; the
bonus was lifted to 8%.
The issues of Black Empowerment and corporate governance was brainstormed.

o
Empowerment legislation would be studied and solutions brainstormed. After completion, it

was assessed that only a plan for had to be adopted prior to listing. A plan was sorted.
Corporate governance issues (as per South Africas King II guidelines) were assessed and
strategy outlined to the companies. A meeting with management was set up to discuss
options.
Options were accepted and signed-off by the sponsor.
As expected, the sole wayward director (a 40% shareholder of ProKomTol) called a meeting to declare that
he was against the listing.
Using CASE Methodology (as set out in this book), Magliolo and team countered by setting out new
strategies for the group.
The two companies would still list, but the holding company would own 100% of Carver B, but only
60% of ProKomTol. The director would keep his 40% in the company, but have no control in
ProKomTol or have shares in the new holding company. Guerrilla Principles operating at its best
The meeting was heated, as the director refused to budge and had, ultimately, to accept that he would end up
being be a major shareholder in a division of a listed company.
The second step was to quickly tie up all relevant skilled personnel with the share incentive scheme. It was a
possibility that the director would cause malicious trouble for the process going forward.
The teams advocate got a gagging order to prevent him from talking to staff until after the merger. It
was also a possibility that he would talk to the targeted takeover competitors.
The War Room was only for team members, and he was also not the appointed sponsor. He thus had
not access to information relating to scope or schedules.
Page 211 of 283
STAGE 4:
PROJECT COMPLETION &

POST-MORTEM
Effective monitoring keeps a project on track in terms of performance, time and cost. The project
manager must focus on his or her plan, while rapidly acting to tackle problems and changes in
order to stay on course.
Page 212 of 283
LESSONS LEARNED: PROJECT CLOSURE

At the end of a project, the project manager must carry out a Post Implementation Review. As part of
this, he or she should pull together all the lessons learned throughout the complete lifecycle of the
project. As with the interim reviews, include as many people involved in the project as possible. Review
all the project documentation, especially:
The Lessons Learned Log

The Risk Register
The Issues Register
Quality plans and logs
Draw from the information contained in review summaries, but reconsider all the stages of the project
from the beginning as some lessons may not have become clear until later in the project.
Lessons Learned Report
Bring all the lessons together in a Lessons Learned Report.
The purpose of the report is to identify those lessons, which could be applied to other projects in the
future, in order to improve the project management process. It is important to identify successes and not
just concentrate on failings and weaknesses.
Examples of areas to consider might include the following:
Was the project well managed? What would the project manager do to make sure that he or she
would do it again next time?
What went less well and why? What should be done differently next time?
Was there a clear definition of success? Was it achieved? What is the sponsors view?
How well were risks and issues managed? Was the project affected by unforeseen problems and
how well were they handled?
Has there been any deviation from the original Project Brief/Initiation document.? How did this arise
and how was it managed?
Did the project team have the right skills in place?
The report should be signed off by the sponsor and client.
Sharing Lessons and Good Practice
Ensure that a copy of the report is filed with the project documentation, so that the sponsor can consider
whether there are lessons relevant to other projects.
Having completed the project, as part of celebrating success, why not give a presentation to other
project teams in the programme.
Include a summary of key lessons, especially those that might be relevant to other projects?
Page 213 of 283
CHAPTER 27: QUALITY, SPEED &

CLOSURE
As a project draws to a close, it is important to evaluate exactly what has been achieved and
what can be learned for the next project. The project manager should take the project through a
formal closure process that marks its success.
STAY FOCUSED
Learner Notes: Evaluate this project well to better manage the next one.
Inevitably toward the end of a project, some team members will start to move to new assignments. It is
important to keep remaining team members focused on final objectives until the very end of the project,
when a formal closure report is written and a final meeting is held. As incredible as it sound, at the very
end, things can still go wrong. The tendency is for team members to move to other projects, leaving the
project manager alone to wrap up all final issues.
Yet, there are tasks that the members should complete, such as ensuring that resources are not closed
too early. This could result in benefits being dissipated, because final activities are completed
haphazardly. Finally, the project manager wants his or her team to learn as much as possible from the
exercise and to ensure that the predicted results are delivered in full.
It is extremely easy to loose focus at this late stage, particularly for those team members who have being
appointed to new projects.
Learner Notes: Ensure that all jobs have been completed.
Learner Notes: Publicise the achievements of the project team.
Is the sponsor satisfied that the original aims and business objectives of the project have been met?
Is the companys customers satisfied that they are receiving improved services or products?
Have all project related parties being alerted about final results? Have all team members being
thanked?
Have all new insights and ideas been recorded?
The end depends on the beginning

At the outset, a project manager has few choices in undertaking a project. He or she can undertake a
project to complete it as quickly as possible, complete it as quickly as time allows or he or she can try
and do it right the first time, no matter how much it costs or how long it takes.
Obviously, the third alternative is unlikely to happen. The first two, then, represent a choice between two
very different approaches to project management. Setting out to do it as quickly as time allows is a
perfect excuse for not bothering too much about quality. Managers, who set out to do it right as quickly
as possible, really mean the project will deliver better quality, but over a longer period.
Even in some large projects there is no process in place for identifying errors as the project progresses
and then everyone wonders why there are problems at the end. And, some project teams never ask the
question: what causes us to make errors? If that question is never asked, errors are unlikely to be
addressed and the same problems will be continually repeated. When undertaking the complex process
of project management, errors will never be distributed evenly throughout the different Stages. They will
Page 214 of 283
be clustered together, which means that problems or errors will occur in groups. If the project manager
and the team have no idea where these groups are, corrective action cannot be undertaken.
So often people say they want to deliver good quality, but in practice they are doing little or nothing to
achieve it. For project managers, there is a need to manage quality. Hoping that the delivered item will
be a quality service or product, is simply not good enough; not to say unprofessional.
The Final Quality Test
Learner Notes: Always ask: What constitutes quality?
Delivering what the client has asked for in terms of the signed project brief is all that a project manager
has to deliver, which includes meeting time and budgets. Adding unnecessary features is not adding
quality, but it is wasting time and money.
Quality should not be something the project manager hopes for. In addition, quality should not be
measured only after delivery; that is too late. Therefore, quality should have:
Objectives, even numerical, and targets set at the outset of the project.
A plan for achieving those targets.
A review mechanism to assess whether quality targets are being met.
Quality should be as planned, predicted and measured as any other aspect of the project, which means
that it is to be managed actively, rather than hoped for passively.
Unfortunately, the notion that going for quality will ultimately make the project cost less is not the initial
thought of the client or sponsor. Everyone perceives that quality is the enormous cost of being
meticulous, planning, research, checking and re-checking. The easy option is for the project manager
not to fight to for higher resources (to include quality controls). Instead, the project manager expects to
have to resolve problems at the end of the project, as quality controls were not in place. The experienced
project manager inserts these quality control costs as part of the planning Stage and the costs are
included in the budget. There is no reasons why these quality costs should be made separately.
From experience, talking to sponsors about quality often gets the following response: "We should
improve quality; we are getting far too many errors, far too many problems, far too many delays." Without
quality checks, such comments will become commonplace.
LEARNING FROM PROJECTS

The perfect person to draft a report about the project, its successes, history and problems is the
information co-ordinator. He or she is well positioned to write the report, given that they were the ones to
gather facts, processes used and compiled sets of meeting minutes. If similar projects are to be repeated
in future, the co-ordinator should meet team members to go through the project from start to finish. He or
she should ask people to point out where, with hindsight, they could have made improvements. The
team will benefit significantly, if discussions lead to the drafting of a template for such a project plan,
including a Gantt chart.
The closure Report

The report should include the following:
Performance of Indicators: A comparison of what the project has achieved relative to the original
targets set.
Page 215 of 283
The co-ordinator should explain in full the reasons for any variances between targets and
actual achievements.
It is recommended that the comparison is worded in a way that validates the original
investment appraisal.
Use of Resources: An assessment of the resources planned and those that were actually used
must be set out.
o
If the project used more or fewer resources than expected, reasons must be set out.
Include any information that will validate the budget allocated to the project.
Strengths & Weaknesses: An appraisal of what went well on the project and what went wrong, or
caused problems must be set out.
o
Team members must be asked for input, in order to conduct as thorough an analysis as
possible.
Make sure that the information recorded enables others to learn from this experience.
Success Factors: A record of the top 10 factors judged as critical to the success of the project.
o
The co-ordinator must list success factors with the help of the team, sponsor and client.
Hoe or she must create a list that will provide focus for future project managers.
Application for Closure

As with any project decision, the process of closing the project should be carefully documented. The
most effective way of doing this, is by writing a project closure report, which should set out the following
minimum issues:
Reasons for closure.

Who authorised closure and agreement of the project board.
Date of the closure decision.
Timeframe for closure.
Statement of delivery against project brief.
How residual risks were managed, i.e. by whom.
How internal and external communications were handled.
How project resource issues were handled, e.g. handling of team member issues, budget underspend or liabilities.
Transfer of responsibilities for the delivery of final project product or service.
Confirmation of whether lessons learnt have been captured and reported.
How the post-closure evaluation is to be conducted.
Confirmation that project documents have been completed.
Confirmation that the project has been closed and archived.
THANKING THE TEAM

It is important that all the members of the project team depart feeling positive and successful. The
professional project manager will, at some stage, work with the same people on subsequent projects, so
good relationships should be kept and maintained for future; including sponsor, client and team
members. It is the project managers duty to speak to everyone in a group and individually to thank them
for their contributions. Hold a final meeting at which the sponsor can confirm that the project has indeed
brought benefits and thank the team for its efforts.
Page 216 of 283
Benefits Realisation
Mark the end of a project with a celebration in recognition of the team's hard work and effort. This allows
people to part as friends and successful colleagues. If a project is not expected to bring some benefit to
the organisation, then what is the point of running the project? In most cases, the benefit to the
organisation will be documented in the Business Case and transcribed into the Project Plan. However,
even when the proposed business benefits are agreed and demonstrated, many projects fail to deliver
on the promises.
Realizing the agreed business benefits requires two key and inter-related activities:
Firstly, the person responsible for ensuring that the projects outputs are used to generate the
business benefits needs to be identified.
Secondly, the plan for realizing the benefits needs to be documented, agreed and monitored through
to conclusion.
The Project Manager is responsible for producing the project outputs, however, they have no authority or
control over how those outputs are used once handed over to the business.
Why do so many projects stop at delivering outputs and fail to realize the expected benefits? Getting
actual business benefits requires people (managers, employees, customers, suppliers) to change their
behaviour in some way. In reality, changing peoples behaviour is not easy. There is peoples natural
resistance to change, often feeling over-whelmed with the rate of change. In many countries, change
often means retrenchments, so they have something to lose, whether it is living lifestyles, respect,
authority or money.
Managing the change required, to bring about the benefits, will require planning and action in these
areas:
Agreeing and setting measurable goals

Clarifying roles and responsibilities
Adopting a communication plan for all major stakeholders
Winning the visible and ongoing support of the executive leadership
Designing and implementing a system of rewards
Putting in place systems of support
Developing a strategy to deal with resisters
Some of these areas will come within the scope of the project. Where they do not, it is important for the
project manager to ensure that they are managed in an overall Change Management Plan.
Page 217 of 283
A project is successful when the needs of the client and customer have been satisfied. Customers are
satisfied when a deliverable has been produced that meets their needs and exceeds their expectations.
The deliverable can be a product (something tangible or intangible), a service, a process, a plan, or a
combination of these.
Expectations can be managed
A good rule is to under-promise what is to be delivered. If the client expect less than what he or she ends
up getting, they are delighted. But if they expect more than they get, they will be disappointed. In both
cases you have delivered the same deliverable; the only difference is what is in the mind of the
customers about what they will be receiving, ie. their expectations.
The second measure of project success is that the needs of the organisation have been satisfied. These
needs may be such things as making a profit or gaining market share. The needs of the organisation are
represented by the sponsor and should be included in the scope.
The third measure of project success is that the project manager, team and the organisation learn
something as a result of the project, so that next time, someone else can build on the successes and
avoid making the same mistakes. This learning process should go on throughout the project and is the
primary purpose of the close-out phase.
Chapter 28 looks at how the project is finalised and delivered to the sponsor.
Page 218 of 283
CHAPTER 28: FINALISATION & THE POSTMORTEM

The work has been completed and the team is ready to disband. Before the project manager
moves on to the next project, there is a need to evaluate the clients satisfaction, check that
lessons encountered during then project have been summarised and a final close-out report is
written. Celebration is the final step before the project is truly finished.
PROJECTS NEVER REALLY FINISH

There is a peculiar belief among some foreign entrepreneurs that tasks can only be partially completed,
but never completely finished. The myth is that, if a project manager must complete a task within 10
days, then after five days he or she must be 50% of the way through the task. After 10 days, therefore,
the task must be 100% complete; it seldom is, as 99% of tasks take longer than allocated time. In
addition, time is not elastic and, therefore, the task will never be considered to be completed. In addition,
even when a task has been done within the stipulated timeframe is it really complete if it hasnt been
reviewed, edited and ready for publication?
In effect, a task is only finished when it is documented and handed over to the commissioning person. If
all this is done within the allocated timeframe and budget, then and only then can a task be
considered to be finished.
Learner Notes: While this all sounds odd, cognisance should be taken that in global markets,
entrepreneurs are not as flexible as in emerging nations.
This misconception is particularly entertained by those people who believe that time is inelastic. That is,
work to schedule and produce within a particular length of time, or dont be a project manager. Under
such conditions, what really happens?
The essence of working in project management is that there will always be problems, so timeframes
and often budgets will have to be changed. In conditions where the sponsor is not flexible, the project
manager simply rolls delayed tasks into the next task. The time can often be made up during the
Execution Stage, as speed is picked up. If it isnt, the project manager will face contractual breaches
and have to pay penalties.
FINAL APPROACH
The close-out Stage can be broken down into a number of typical activities, such as project evaluation
(team members, sponsor and client), writing the final status report, developing lessons learned, issuing
the close-out report and reviewing the report with the sponsor.
There are three issues that have to be effectively wrapped up:
The end of the Completion Stage.
The end of the Project.
The assessment of the project benefits.

In addition, these issues can be resolved in two steps, namely questionnaires and a post-mortem
meeting.
Page 219 of 283
At the start of the book, the author suggested that project sign off would be a requirement for completion.
This should apply to all the team members as well. So, no going home until a post-mortem of the project
is undertaken, written down and signed-off by all team members; in the following two steps.
Step 1: Project Team Members Questionnaires
The survey that is provided to them should address the following:
The way in which the project was led.

The project management process, including the effectiveness of planning, monitoring, and change
control.
The team process: how well the team worked together, how productive the team meetings were.
Organisational support of the project.
It's important for project managers and team members to take stock at the end of a project and develop
a list of lessons learned, so that mistakes are not repeated in future projects. Typically, such reviews
conducted by answering specific questions about the project. The author recommends that this is
combined with a final post-mortem review meeting. The questions will force the members to think about
the issues and the meeting will bring it all together.
The benefit of the first step, done individually by team members, is that it allows the quieter, more
analytical people to develop their responses to the questions without being interrupted by the more
outgoing, vocal types who might otherwise dominate in the face-to-face meeting. Also, it allows everyone
the time to create more thoughtful responses.
The following lists must be changed by project managers to suit the project and circumstances
surrounding the project.
QUESTIONNAIRE 1: GENERAL PROJECT QUESTIONS
Are you proud of the finished deliverable)?
If yes, why?
If no, what's wrong with them?
What was the single most frustrating part of the project?
Could you do things differently to avoid such frustrations?
What was the most gratifying or professionally satisfying part of the project?
Which of the methods or processes worked particularly well?
Which methods or processes were difficult or frustrating to use?
What would you change about this project?
Did sponsor and client participate effectively?
If not, how could their participation in future projects be improved?
Page 220 of 283
QUESTIONNAIRE 2: DETERMINE NEED AND FEASIBILITY
Did the teams needs/market analysis or feasibility study identify all the project deliverables that were
eventually built?
If not, what did the team miss and how can the team be sure that future analyses doesn't miss such
items?
Did the team identify unnecessary deliverables?
If so, how can the team be sure that future analyses don't make this mistake?
How can the team improve the need-feasibility or analysis phase?
QUESTIONNAIRE 3: PROJECT PLAN
How accurate were original estimates of the size and effort of the project? What did the team over or
under estimate?
How can the team improve estimates of size and effort so that it was more accurate?
Did the team have the right people assigned to all project roles?
If no, how can the team make sure that the right expertise is employed next time?
Describe any early warning signs of problems that occurred later in the project?
How should the team have reacted to these signs? How can the team be sure to notice these early
warning signs next time?
Could this project have been completed without one or more vendors/contractors? If so, how?
Were the teams constraints, limitations and requirements made clear to all vendors/contractors from
the beginning?
Were there any difficulties negotiating the contract? How could these have been avoided?
Were there any difficulties setting up paperwork or getting the project started? How could these have
been avoided?
List team members or stakeholders who were missing from the kick off meeting or who were not
involved early enough in our project. How can the team avoid these oversights in the future?
Were all team/stakeholder roles and responsibilities clearly delineated and communicated?
If not, how can the team improve this?
Were the deliverables specifications, milestones and specific schedule elements clearly
communicated?
If not, how can this be improved?
Were team members proud of blueprints or other detailed design specifications? If not, how can this
be improved?
Page 221 of 283
Did all the important project players have creative input into the creation of all required
specifications?
If not, how can it be assured of their involvement next time?
How can the team improve work processes for creating deliverables specifications?
QUESTIONNAIRE 4: DELIVERABLES
Were team members proud of deliverables?
If not, how can this be improved?
Did all the important project players have creative input into the creation of the deliverables?
If not, who were missing and how can the team be assured of their involvement next time?
Did those who reviewed the deliverables provide timely and meaningful input?
How could the team improve work processes for creating deliverables?
Did the team get timely, high-quality feedback about how they might improve deliverables? If not,
how could the team get better feed back in the future?
Was the teams implementation strategy accurate and effective?
Can this be improved?
Did the hand-off of deliverables to the user/customer/sponsor represent a smooth and easy
transition?
If not, how can the team improved this process?
Step 2: Post-Mortem Meeting

There is the possibility that this final review is completed quickly just to wrap up the project. This will not
help anyone, particularly when the teams are likely to work together again in future. Valuable
experiences do not get shared and important documents are not written. However, if an information coordinator is used key data and lessons learned would have been captured at every stage. The postmortem would then be a review of the data, rather than an attempt at capturing lost memories.
The end-Stage reports, therefore, should record the following:
The Stage being completed.
Type of project it is.
How many members of the team (any others) worked on the Stage.
Name the key role players.
What was the budget for this Stage?
Did the sponsor approve extra budgets?
Page 222 of 283
What was the actual full cost and end date?
Issues that hindered and how to avoid them.
Could the projects rules and guidelines be improved?
And for example the information could be recorded on a template something like this:
Stage End Report

Project Name: ________________________
Project Number: ________
Stage being completed: ________________
PROJECT TYPE
Type of Industry:
Normal Lifecycle:
Other:
______________________________
______________________________
______________________________
Number of Individuals Involved: TEAM: _____________

Project Manager: ________________________________________
Project Sponsor: _________________________________________
Project Team member: ____________________________________
Brief Description of Stage:
Budget: __________________________________
Extra Budgets: ____________________________
Approval for extra budgets: _________________
Total Costs: ______________________________
OTHER
Problems incurred during the stage:
How to avoid these in future.
Could the projects rules and guidelines be improved?
Page 223 of 283
OTHER: _____________
A suggestion to expedite this process is to have post-mortems after every Stage. That way, the only
Stage that will need a review is the Completion Sage; after all, everyone wants to get paid, so that they
can move on to the next project.
Learner Notes: Leaving a review to the end of the project will take days, as members will have forgotten
what happened in the early stages.
After the team has completed the questionnaires and have held the post-mortem meeting, two issues
remain to be sorted:
The client and sponsor must still provide feedback

The final report must be written and the project handed over to the client
After all lessons have been captured, discuss how to turn them into recommendations
for improving the overall project management system.
The list of overall recommendations for improvement will be shorter than the lessonslearned list, because not all the lessons will apply to the company.
Include the recommendations for improving the overall project management system in
the close-out report.
Dont forget that this is a learning meeting and, remember to look at successes as well
as your failures, because there may be lessons that the team need to learn from them as
well.
Project teams tend to focus on mistakes and how to correct them, but its equally
important to analyze successes to learn how to repeat them.
SPONSOR & CLIENT EVALUATION

Sponsor
Ask the sponsor to evaluate the project using the same method you used for the team. First send him or
her survey forms and then conduct an interview.
Leaner Notes: Provide the sponsor with the final status report, before you ask for their project
evaluation.
Here are some statements that should be included in the questionnaire:
Was the project planning process thorough?

Was the project planning process efficient?
Was the involvement of sponsor in the project process was effective?
Were project resources used efficiently?
Could changes to the project scope been anticipated during the planning process?
Did the project manager do a poor, good or excellent job?
Were issues that were escalated to the sponsor, appropriate for sponsor intervention?
Add any additional statements that will provide helpful information for the team in future projects. After
you get the survey back, conduct a sponsor interview in the same manner as the team interview. Record
the responses from the sponsor.
Client
Page 224 of 283
After the sponsor has accepted the final deliverable, its time to have the client evaluate the project. This
is best done through a survey form. What is included on the survey is statements that the client can rate
on a score card basis which states whether he or she strongly disagree or strongly agrees.
Its best to use an even-numbered scale so that the customer is forced to pick a number that is not in the
middle. This will give the project manager a better idea if he or she is positive or negative, rather than
neutral. Sample statements that explore the clients opinion on the results of the project include:
The final deliverables met acceptance criteria.

The final deliverables met expectations.
The delivery date met needs.
The cost met needs.
Overall, the client was satisfied with the results of the project.
The project plan was complete and effective.
The scope of the project was well defined.
The change-management process was effective.
The clients level of involvement in the project fits his or her needs.
Status reports were clear and complete.
The client was kept informed on the progress of the project.
Overall, the client is satisfied with the project management process.
Also add statements specific to the project to the list.

FINAL STATUS REPORT
Once the project manager has the clients project evaluation, he or she is ready to complete the final
status report. This is done in the same way as the interim status reports except:
Add a scope section to describe how well the final deliverable met each of the clients acceptance
criteria.
In the schedule section, list all of the major milestones with planned versus actual dates. If the final
deliverable was not one of the milestones, add it to the list.
In the team budget section, summarise actual spending versus the final approved plan amount.
In the changes to plan section, summarise the changes made to the original plan.
The final plan section should match the final plan columns in scope, schedule, staffing and spending.
In the bottom section, explain any variances of the final actual from the final plan amount.
Page 225 of 283
FINAL STATUS REPORT
DATE: ___________________
Project Name: ____________
Project Manager: __________
PROJECT RESULTS
Went Well
YES
NO
Comment
GENERAL OVERVIEW
The Four Stages (General comment)

Stage 1: Initiation
Stage 2: Planning
Stage 3: Execution
Stage 4: Completion
PROJECT SPECIFICS
Scope
Schedule
Team
Budgets
Risks
OTHER
Monitoring
Weekly meetings
Review meetings
Communications (Sponsor etc)
Change Control
General Comments
VARIANCES
Explain what went wrong

How were these sorted
Time & Cost variances
THE CLOSE-OUT REPORT

The close-out report is the final report for the project. It includes an executive summary, the final status
report, the lessons-learned list and any recommendations for improvement.
After the project manager has drafted the closeout report, he or she must schedule a meeting with the
sponsor to review the report before its issued. The following checklist will help you focus on close out.
Has the project manager received honest feedback from sponsor, team members and client about
the deliverables produced and the project process?
Has the final status report been completed?
Has a list of success and failures being outlined in the report; see appendices.
Has each member on the team evaluated the project?
Has the project manager discussed and assembled a list of lessons learned?
Has the team reached consensus on the recommendations for improvement?
Has the project manager discussed the recommendations with the sponsor before issuing the closeout report?
Has the project manager thanked each member of the team?
Page 226 of 283
FINAL FAREWELL
At this stage, the project manager must reflect on the success of the project and on the good work done.
There are lots of ways to celebrate, from as simple lunch to extravagant celebration. Whichever way
project managers choose, have a closing ritual for the project closeout. Always thank the project
management team, as a group and individually for their contributions. If the project wasnt a success,
you should thank people nonetheless.
Acknowledge the good times youve had together and say good-bye. This will help put closure on the
project.
Chapter 29 is a self-assessment questionnaire for project managers.
Page 227 of 283
CHAPTER 29: SELF ASSESSMENT FOR

PROJECT MANAGERS
The following form is for project managers to evaluate their knowledge about their ability to lead
as managers in a hostile and rapidly changing global environment.
The benefit of the following form is that it should improve with every project undertaken, so it is
recommended that the form is filled out honestly. Mark options closest to experiences encountered and
experienced. The form is easy to use: if the project manager believes that the answer is always tick box
4, or if the answer is frequently, tick no 3. Scores are added together and the answer score card follows
this questionnaire. Use the answers to Identify which areas need most improvement.
NO
Questions
1
2
3
Should you check whether tasks form part of a project?

Should you set specific objectives for projects?
Should you plan a project before launching into the work?
Do you have a grasp of the difficulties that you could be
facing in trying to achieve milestones?
Have resources been promised and allocated to the
project?
Are these resources also allocated to other projects?
Should they be?
Should you be communicating with the project client and
sponsor at regular interval?
Should you have an idea of how the project will turn out,
before you start the Planning Stage?
Should you explain to project team members what the
projects objectives are?
Is it important that team members have a sound
understanding of the project objectives before the project is
launched?
Should you set targets for every task that will ultimately
make up the project?
Should you check that a project will not unnecessarily
change what already works?
Should you compile a full list of project activities before
placing them in a prioritised format?
Is it your task to keep count of man hours worked?
Should all parties related to the project sign and approve
the plan before it is launched?
Is it your job to keep a check on the budget?
Should a project always start with a pilot programme?
Should you keep decision making tools continually
updated?
Is it your responsibility to I inform all project related parties
of any change to project resource requirements?
Is it your responsibility to prepare contingency plans for all
major risks to the project?
Is it right to change a leadership style to suit
circumstances?
Is it your responsibility to develop a project teams' skills?
Is it your responsibility to determine whether new team
members fit in with the rest of the team?
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Page 228 of 283
Never
1
Occasionally
2
Frequently
3
Always
4
24
25
26
27
28
29
30
31
32
33
34
Does the team know what is expected of them?

Do you believe in using the projects sponsor to motivate
the project team?
Do you keep track of all milestones and do you document
and circulate these to team members?
Have you established an information centre to enable all
team members access to relevant documents?
Is it necessary to keep secrets from the project team and
client?
Do you think that is wise to omit people from a review
meeting if they are going to be unpleasant?
Do you have a well established communication method for
all interested project members, including client and
sponsor?
Is it your responsibility to prepare agendas for meetings?
Do you have a decision-making tool to logically process
problems?
Do you keep your sponsor fully up-to-date with progress on
the project plan?
Do you believe in problem-solving techniques to arrive at
decisions?
Next: Add up the total score and check performance by referring to the corresponding score card below.
Learner Notes: There is always room for improvement, so identify the weakest areas and refer to the
relevant sections to refine skills.
SCORES
32-64
65-95
96-128
Page 229 of 283
EVALUATION ANALYSIS
The project manager is not well organised.
It is not certain whether he or she has the experience to manage a complex project
through the four Stagers of Project management.
Go back to planning. Be more thorough and review every step of the project
management process.
Start with smaller project and gain in experience and skill before attempting top lead
teams in a more complex environment.
The project manager is reasonably proficient.
He or she will be able to lead small to medium sized projects efficiently.
The project manager has to address some weak points.

The project manager is proficient and has an excellent handle on concepts.
He or she is able to lead a team through difficult issues; talking all four Stages of
project t management well and efficiently.
A warning is not to become complacent, but rather seek more difficult challenges,
more difficult projects in emerging markets and first world countries.
Final check before the project is signed-off by the client and sponsor. The project managers
appointed contract to deliver a product or service has been completed.

Checklist
1
2
3
4
5
6
7
Comments
Is the project still delivering the benefits intended?

If closing the project early, is there a case for
abandoning the project?
Has learning been identified?
Has a lessons learned report been created and
distributed?
Has a final sign-off report been written?
Is there a need for external evaluation?
Is there a plan in place for a post project review?
Page 230 of 283
STAGE
1
PROJECT
Initiation
Planning
Execution
Completion
STATUS

Magliolo and the team completed three phases of project management, including changes to the scope,
schedules and deliverables with speed and accuracy.
No compromises had taken place. Each team member was a professional appointed to undertake very
specific tasks, which they delivered on time. Budgets were their responsibilities.
Loss of time due to the change in shareholding structure was more than made up with contingency time. The
due diligence and research had been completed before the company appointed Magliolo to undertake the
project. All that remained, was for Magliolo to:
Complete all relevant documentation to submit to the sponsor.
This process was expedited, as each team (stipulated in contract) had to provide all documentation to
the information co-ordinator, so that executive summaries could be drafted.
Magliolo incorporated all the summaries into a major report, outlining all the required steps necessary
to complete the merger and amalgamation of the two companies.
A deadline of one month was deemed to be enough time to complete all legal and accounting issues.
Magliolo would complete the business plan to submit to a stockbroker specialising in AltX listings. In the
UK these stockbrokers are called NOMADS, while in South Africa they are DESIGNATED ADVISORS.
Magliolo would do the business plan with the presumption that the accounting, legal and merger work
was done according to the discussions held between Magliolo and sponsor.
One month later, the merger was effected and the deliverable handed to the new merged company.
The first part of the deliverable was signed-off; the merger had been completed and professional fees
paid.
The second part of the deliverable was the appointment of a listing stockbroker; the designated advisor
was appointed and Magliolo was selected as Corporate Advisor to the company. A new schedule was drafted:
Completion of Business Plan: submission to AltX listing committee.

If accepted, proceed with prospectus, capital raising and listing documentation.
It took three months to list the company and, as expected, the wayward director (feeling isolated) rapidly
gained understanding that he would loose capital growth in shares over the years. He decided to sell his
shares to the new holding company.
Magliolos suggestion was to acquire these at a discount, but that decision was left to the shareholders.
Final sign-off was effected on the day of listing and the 8% shares in the company have been distributed
to the team members.
Celebration: the end of the project called for a celebration which under the Guerrilla Principles should be as
radical as the planning process. A holiday for the team and their partners has been planned in the Far East
where new opportunities lie for professional managers.
Page 231 of 283
FINAL WORD
Project management can be a difficult and thankless task. When things go wrong, the project
manager is the one everyone blames, while - when things go right - the credit goes to the team.
Yet, projects come with astounding rewards. Astute project managers know that those managers
who consistently deliver on their promises soon gain reputations for solving problems and
getting things done. These managers are usually very handsomely rewarded.
Having said that, getting things done is not always easy. Politics, resource limitations, technical and
other environmental problems, personal differences and organisational obstructions can all hamper the
plan to deliver on promises made. The ideas outlined in this book are not revolutionary. Rather, they are
a tried and tested practical method to expedite the process of project management, with as little
interference as possible.
Therefore, these concepts are merely observations made by the author on how things actually work, and
then implemented in a formalised way. It is, therefore, drawn from being involvement in projects, some
worth billions of rands, while others were small, quick and easily implemented.
There will always be genuine frustration with methodologies, no matter how well established they are.
Using the ideas in this book, however, should enable project managers to plan, control and execute any
project, anywhere in the world.
It is a model that should be easy for the whole team to understand and will allow you to deliver your
project on time, on target and under budget.
ADVICE
Document everything; even dates and times of meetings etc.

Get and keep every contract; dont start project without a contract.
Keep in contact, send regular reports to everyone in the project team.
Keep to deadlines.
Respect the ability of the team.
Ask for help if required!
Be Tolerant.
Project management isnt just for project managers anymore. If youre not a project manager, but youre
aspiring to be one or youre working on a project team and want to do a better job, this book is for you.
Final word when you complete the project

The following contract is a sample. Change it to suit your circumstances, but get it
signed before you leave for your next project.
Page 232 of 283
CLIENT ACCEPTANCE FORM

[Project Name]
Created by [Author]
Version 1.0 Issued (DATE)
[This document is used to obtain the customer's sign-off once the project it is complete.]
Project: [Project Name]
This document has been issued by: [Person Issuing Document]
Date Issued:
The Project Outcome has been measured against its acceptance criteria and has been formally
accepted on behalf of the client.
THE PROJECT MAY NOW BE CLOSED.

Additional Comments about the Clients Acceptance:
Recorded Shortfalls of the Final Project Outcome (if any):
Sponsor:
Signature:___________________ Name:___________________
Date:
Project Manager:
Signature:___________________ Name:___________________
Date:
Witness:
___________________
Signature:___________________ Name:___________________
Date:
Page 233 of 283
___________________
___________________
APPENDICES
Appendix 1: Project Management Rules
The purpose of these Rules is to remind project managers what they must do when running a project.
The rules do not describe everything that will need to be done to manage a project, they do describe
what is mandatory, what must at least be done.
Authorisation:
o Purpose: To ensure project expenditure is properly authorised.
o Any project costing more than R1 million must be authorised in writing by the project sponsor.
Roles and Responsibilities

o Purpose: To ensure all team members have defined and agreed roles.
o Each stage of project work, including Project Definition, must have roles defined and agreed
before the start. As a minimum the following roles must be in place and the role players must
at least take on the responsibilities shown:
Project Sponsor
Accountable for project success/failure
Authorise in writing each project stage before it starts
Empower the project manager
Project Manager
Ensure project roles are defined, assigned and agreed by each role player
Ensure these rules are followed
Several other roles may also be required depending upon the project. The PM
Guidelines describe other roles and expand upon the role descriptions above.
Project Definition:
o Purpose: To ensure the project is defined, definition is agreed, and an informed go/no go
decision is possible.
o A Project Definition stage costing over R10K must be authorised and managed as a project.
o For each project there must be a Project Definition Document which must at least document
the following:
Goals and Objectives
Project scope: inclusions and exclusions
Project organisation hierarchy chart, role players' names and description of each role
Work Breakdown: sub-projects, releases, stages, etc.
Summary of costs and benefits
How the project will be managed
Majors risks, assumptions, dependencies, constraints
The guidelines give a full description of recommended PDD contents.
The PDD should be written after its contents have been agreed by interested parties.
Large projects should hold a Project Definitions Workshop before the PDD is finalised.
For single stage projects produce a combined PDD/Stage Agreement, not two
separate documents.
Project Control Book:

o Purpose: To ensure all project records are readily accessible.
o The Project Control Book must contain all project records (PDD, Risk Register, etc). The
guidelines list recommended contents.
Page 234 of 283
If records are held online clear access instructions must be readily available in hardcopy.
Planning:
o Purpose: To show when each project task should be performed, and who will perform it.
o Before a stage starts, there must be a task by task plan that is agreed by the people to whom
tasks are assigned.
o Time (hours) for Quality Assurance, Rework, Change and Contingency must be included in
the plan.
o The plan must be updated regularly in the light of actual project status.
Estimating
o Purpose: To ensure the stage cost is known before the stage is authorised.
o The total cost (Rs) of a stage must be estimated before the stage is authorised. The estimate
must therefore at least include:
the time (hours) needed from all participants converted to money at standard rates
supplied by Finance
expenditures such as hardware, software and travel.
The PM Guidelines contain checklists that will help identify potential cost items.
Risk Management
o Purpose: To ensure threats to project success are managed.
o Risks and actions to remedy them must be documented before each stage begins.
o The project sponsor must be made aware of major risks before authorising each project
stage.
o Risks must be managed and risk status reviewed regularly by the project manager.
o The status of major risks must be reported to the project sponsor monthly.
Resource management
o Purpose: To get resource commitments before the stage begins.
o Each project stage must have a Stage Agreement signed by resource supplying line
managers before the stage begins.
o The stage agreement must at least document:
Deliverables
Completion criteria
Risks and actions to reduce
How stage will be managed/controlled/reported
Roles and responsibilities
Resources
Costs
No stage should exceed 5 months duration.
Issue Management
o Purpose: To ensure issues are documented and managed.
o An issue is something that potentially jeopardises project success.
o Issues and their resolution must be documented.
o Each issue must be assigned to a named individual for resolution.
o Open issues must be reviewed weekly by the project manager.
Project Change Request Management

o Purpose: To control the impact of change on project costs and schedules.
o A Project Change Request (PCR) is a request during the life of a project to change a
completed project deliverable.
o PCRs must be documented.
o Before a PCR is investigated, the investigation cost must be approved by the project
manager.
Page 235 of 283
Before a PCR is accepted, the cost, schedule implications and other impacts of the PCR must
be approved by the project manager.
Quality Management
o Purpose: To ensure project products are fit for purpose.
o There must be a Quality Plan that describes how the project team will assure the quality of
the project's products.
o The project manager must ensure that quality assurance tasks are properly executed.
o The project manager is accountable for the quality of all project products.
Tracking and Control

o Purpose: To ensure project commitments are met.
o Tasks started and tasks completed and hours worked on each task must be captured weekly
from every team member.
o The project manager must be informed weekly of progress vs plan.
o The project manager must report status and outlook-to-completion to the project sponsor
monthly.
Stage and Project Completion

o Purpose: To ensure formal completion and to learn from experience.
o The project manager must ensure that the completion criteria specified in the Stage
Agreement have been achieved before declaring the stage completed.
o A team Lessons Learned meeting must be held at the end of each stage.
o Lessons learned must be documented and copied to Project Support.
Project Support
o Purpose: To help project managers.
o Before each project stage begins, the project manager must have plans, estimates and the
Stage Agreement reviewed and approved by Project Support.
o In addition, projects designated as 'key' by the Board must include at least one Project
"Health Check" Review in the project plan.
o The findings and recommendations of a Project "Health Check" Review must be
communicated to the project sponsor.
Deviation
o Purpose: To allow deviation from these Rules.
o Projects costing under R10K will not be audited against these Rules. However, compliance
with the spirit is highly recommended.
o For projects costing over R10K deviation from these Rules must be authorised by Project
Support. Deviation will be authorised simply and quickly where compliance with a Rule would
clearly not add value in a specific project situation.
Appendix 2: Project Definitions: Essential information

All projects must have the following basic information:
Background, overview, objectives, costs
why is project being done
what are major aims
summary of costs and benefits

Scope, sub-projects, releases, deliverables
content of each sub-project and release
major deliverables & who will sign off
Page 236 of 283
Approach, staging, timetable
waterfall, RAD, etc.
management stages & go/no go points
milestones
Measurements of completion & success
what will mark completion of project
how will success be measured
Project organisation
organisation chart showing names
list each person's key responsibilities
Resources
summary of resources, business, IT, etc.
stage agreement will commit in detail
Risks, dependencies and assumptions

what could cause project failure
actions to manage
How the project will be managed

reporting: who, what, when, to whom
issue management process
change control process
Appendices
items not in scope
rejected solution alternatives
Appendix 3: Project Scope Template

Project Name
Author
Group
Date Started
Background to the Proposed Work
Objectives
Scope
Deliverables
Business Benefits
Assumptions
Constraints
Risks
Other Areas of Business Affected
Major Dependencies
Stakeholders
Resources
Outline Estimates of Time and
Cost
Page 237 of 283
Appendix 4: Project Initiation Template

Project Initiation Document (PID)
Background
Context
Origins
How we got where we are

Project Definition
Vision
Outcomes
Objectives
Deliverables
Method of approach
Scope
Constraints
Exclusions
Interfaces (how the project fits into overall organisation management and relationships with partners)
Assumptions
Initial Business Case
Needs assessment
Benefits Users (who)
Numbers
Marketing and access
Other players (voluntary and statutory)
Sustainability
Initial Project Plan
Assignments (tasks)
Timings
Estimated
effort
Budget
Quality Plan
How products will be tested (Monitoring, performance indicators)
Evaluation
Risks
Contingency Plan
Project Organisation Structure (People, roles etc.)
Project Controls (Running the project)
Exception Process (Under what circumstances we make what changes when things go wrong who decides)
Appendix 5: Risk Checklist - Small Projects

For small projects a simple checklist like this serves to focus the team's attention during a risk
assessment meeting. Note that the last question is the most important one.
Small Project: Risk Check List
1.
Is the project dependent upon things beyond the project manager's control?
2.
Are necessary IT skills assigned to the project?
3.
Are empowered, skilled user resources assigned?
4.
Might people leave during the project?
5.
Is the project business critical or very visible?
6.
Will business requirements change during the project?
7.
Is the team familiar with the techniques and technologies they are going to
use?
8.
Is the project amending something which is stable and good quality?
9.
Is there an adequate project plan?
10. What else could cause difficulties for the project?
Page 238 of 283
YES
NO
Appendix 6: Risk Checklist - Large Projects
Realise what risks you face: Before any project stage begins gather in a room people representing
all functions involved in the project.
Brainstorm: what could cause difficulties/failure in the project? Having brainstormed, go through this
checklist to see if it highlights anything the brainstorm missed. When answering a question, if you
don't know, answer 'no'. Any 'no' implies some risk. You must judge how much: a risk that would
cause project failure and is likely to happen is a high risk! This checklist is an aide memoire and not a
miracle cure for risk.
Identify risk reduction actions: In the meeting identify how risks can be eliminated, reduced or
managed. Or, assign each risk to one person for action after the meeting. Project Support may have
records of how previous projects have successfully addressed the risks you face.
Speak to the sponsor: Ensure the project sponsor understands and accepts remaining, significant
risks. Significant means quite likely to happen and big impact if they happen.
Keep risks under review: Monitor risk status during the project, take action to keep risks at bay,
report on risk status. You may want to assign the management of each risk to a member of the team.
Share experience: Get Project Support to update this checklist to add risks which you have
identified but which aren't on this checklist. Tell Project Support how you managed risks successfully
so that this experience can be made available to other project managers.
Note: before a multi stage project you may want to conduct two risk assessments: one for the whole
project as far as you can foresee it, and one for the stage you are about to begin.
BUSINESS CASE
1
2
3
4
5
6
7
8
7
8
9
NO
YES
NO
Is there a written cost/benefit analysis for the project?

Is the business case quantified
Does the business case include all project costs (e.g. user time, training)
Have Finance/Internal Audit validated the business case
Has the Board approved the business case
Has project funding been approved
Is there a commitment to re-evaluate the business case before each project
stage
Does the project manager believe the project is justified
BUSINESS BACKING
Lack of support may result in resource shortages, slow decision making
and unjustified criticism
1
2
3
4
5
6
YES
Is there a project sponsor

Does the sponsor have authority to resolve all project conflicts
Is the sponsor accountable for the project's success or failure
Is the sponsor accountable for delivery of the project's benefits
Will the same person sponsor the project from start to finish
Too senior a sponsor may result in a lack of interest - is the sponsor's
seniority appropriate for the project
Will heads of functions involved in the project sit on a project steering
committee
Do all functions involved (business areas, IT, etc.) support the project
Does the project manager believe the project has sufficient business backing
Page 239 of 283
10
11
12
13
If external parties are involved (e.g. consultants) does the business see these
external parties as worth their fees
If the project is a joint venture (e.g. between 2 companies) is there a single
sponsor
Are clear project completion and success criteria agreed by the business
Is there a one sentence project goal which everyone buys in to (write it below)
COMPANY CULTURE
A company that does not understand projects can have problems when
undertaking them.
1
2
3
4
4
5
6
7
8
9
10
3
4
YES
NO
YES
NO
Is the project similar in size to any previous, successful project

Is the project similar in nature to any previous, successful project
Is company policy in the area addressed by the project likely to remain stable
throughout the project
Has a project of this size been successfully completed in a similar timescale
before
Express the IT effort of the (sub) project in months. Find the square root. Is
the project's planned duration greater than the square root of the IT effort
If the project is modifying an existing system/process/etc. is that system or
process well understood, of good quality and stable
If the end date or budget is fixed, is the project manager empowered to adjust
the project scope
Is the project not dependent upon anything beyond the project manager's
control
Have sub-contractors' management and quality processes been audited
If the project is business critical, will extraordinary measures be taken to
ensure its success (full time resources, executives on call to project manager,
fast track approval for funds & people, etc.)
MANUFACTURING PROCESS
If the project is unwieldy, or the project team do not understand what has
to be done and when during the project, many problems and errors will
result.
1
2
NO
Does the company understand that project authorities override company

organisation, seniorities and authorities
Does the company understand that a project hierarchy is a temporary
structure in which more senior employees may report to more junior
employees
Will people from different functions (marketing, customer service, IT, etc.) be
able to work together co-operatively as a team
Is the company able genuinely to empower project team members to make
decisions on behalf of their part of the company
PROJECT TYPE & ENVIRONMENT

Projects of a new or unfamiliar kind can cause unexpected and unfamiliar
problems.
1
2
3
YES
If the total project is large, will delivery be broken into a number of releases
Will the scope of the release about to begin be determined during project
definition
Are all releases/sub-projects less than 10 months from the end of project
definition to cutover into live use
Will business requirements be defined, in detail, before starting to design
Page 240 of 283
5
6
7
8
9
10
11
12
13
14
solutions to those requirements

Will business volumes be estimated as part of the requirement analysis step
Does every member of the project team understand the 'manufacturing'
process to be used in the project
Are there clear standards to which each project deliverable will conform
Has the content of each project deliverable been determined (e.g. what will
be in the User Functions Design document)
Have you agreed who will sign off and accept each project deliverable
Is the project using processes, techniques and technologies that have been
used before within the company
Is the project using processes, techniques and technologies that are in use
elsewhere
Do those who will use the project's outputs (the 'users') understand the perils
of change during a project
Will the project manager be measured on the quality of what the project
delivers
If the project is installing a package, has the business agreed in principle to
re-engineer their business processes to match what the package does
ROLES AND RESPONSIBILITIES

All involved in the project must understand their responsibilities, be
empowered and be available.
1
2
3
4
5
6
7
8
9
10
11
12
13
3
4
5
6
7
NO
YES
NO
Is there a project organisation chart

Is each project role filled
Are each person's responsibilities and accountabilities defined
Has each person agreed to perform their role
Is someone responsible for the Health and Safety of the project team
Has the project manager managed a project of this nature before
Is a project user manager in place who is empowered to resolve inter-user
disputes
Does one person have the responsibility of signing off and accepting projects
outputs e.g. user functions design on behalf of the users/customer
Have the team leaders lead teams before
Is the project manager full time on the project
Are the team leaders full time on the project
Will the project manager remain in place for the whole project
In the project manager's opinion are roles properly defined and accepted, are
those people empowered to perform their roles, and will they really be
available
PROJECT TEAM
First, list all the skill groups you will need (e.g. business analysts,
specific business knowledge, internal audit, architects, etc.), then copy
this page so you have a page for each skill group.
1
2
YES
Will enough resource be available

Are representatives (e.g. of business areas) empowered to make decisions
on behalf of those they represent
Will the people be full time on the project
Have the people got appropriate experience
Have the people done similar project tasks before
Are the people employees (as opposed to contractors)
Do you know the names of the people who will be assigned to the project
Page 241 of 283
8
9
10
11
Will the project team get on with each other

Will all team members stay until the end of the project, or at least until the
project no longer needs them
In the opinion of the project manager do we have the right quantity and
quality of people assigned to the project in order to make it a success
Have the project manager and key team members attended a course that
teaches how to manage projects (such as the project management course
run by hraconsulting) as opposed to a course that teaches a methodology
such as Prince 2
ESTIMATING AND PLANNING

Unrealistic estimates and plans will obviously cause major difficulties.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
4
5
6
7
8
9
10
11
NO
YES
NO
Are estimates the result of detailed research, as opposed to finger-in-the-air

guesstimates
Has the actual cost of previous projects been used when estimating this
project
Is contingency for risks included in the estimate
Is a change budget included in the estimate
Are holidays, education and sickness allowed for in estimates and plans
Are quality checks included in estimates and plans
Is time allowed for supervision of less experienced team members
Has the quality of anything already delivered by the project been good
Has each member of the project team signed their project plan to confirm
they can achieve it
Is there a clear statement of how the quality of deliverables will be checked
and measured
Has the plan been independently reviewed, e.g. by Project Support
Is it understood that knowing how to plan a project is not the same as
knowing how to use a planning tool
Is the project manager accountable for actuals matching estimates
Has the project manager produced the estimate, as opposed to inheriting it
from someone else
Is the project manager confident that the stage, or project, will end up costing
roughly the amount now being quoted as the estimate
PLAN
If the plan does not contain all necessary activities and update authority
is unclear the plan may fall into disuse.
1
2
3
YES
Will the plan be revised as you go along

Is it clear who can change what in the plan without higher approval
Is every member of the project team aware of where they fit into the overall
plan
Does the plan include team meetings
Will every project output undergo a quality check
Does the plan include the production of technical and user documentation
If the team is in more than one location are good communication mechanisms
in place
Does the plan include activities designed to 'sell' the project to its customers
Does the plan include team lessons learned meetings at the end of each
stage
Will the plan be displayed publicly
Does the plan include implementation activities
Page 242 of 283
MANAGEMENT AND COMMUNICATION

If management and reporting mechanisms are not in place before the
project starts, confusion can result.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
7
8
NO
YES
NO
YES
NO
Is the project manager's view of the risks shared by senior management

In the project manager's opinion, what is the one thing most likely to cause
project failure? Does the sponsor share this opinion
OTHER RISKS
You might wish to list here any risks which you have identified which are
not on the checklist. No checklist will ever contain all the risks any given
project will face
1
YES
Are implementation activities included in the project plan

Do the users know when implementation will be
Are the users ready, willing and able to change working practices
Are plans in place to change working procedures
Is user training included in the project plan
Does someone have responsibility for managing the realisation of project
benefits
Are plans in place to establish a help desk
Is someone responsible for calling a post implementation review of the
business case
RISK PERCEPTION
If others do not share your assessment of the risks you might not get
support in reducing them.
1
2
NO
Will the project team all be located together

If there could be conflict between factions, are team building events planned
Is it clear who will report what when and to whom
Is there an agreed process for resolving issues
Will business requirements remain firm and unlikely to change
Is there an agreed change evaluation and approval process
If there are several sub-projects, are there processes for managing cross
sub-project issues and changes
If external suppliers are involved, have they agreed to report their status,
progress and outlook regularly
Will project progress be reported to the eventual end user
Will objective, numerical data be included in status reports
Will outlook-to-completion be revised each time project status is reported
Will the status of significant risks be reported upon
Will team leaders ensure work claimed as complete by their team really is
complete
Will the project manager receive detailed plan vs actual data from team
leaders each week, including quality management data
Will the project manager be located close to or amongst the project team
IMPLEMENTATION
There is not much point delivering project outputs if people are not ready
to use them
1
2
3
4
5
6
YES
At the end of several sections has been a question 'in the opinion of the
Page 243 of 283
project manager...'. Is there clearly one person, the project manager, who has
been answering those questions
If no, the project has a major risk: no real project manager. Please tell the
project sponsor. If there is no clear project sponsor either, take a long
vacation.
Appendix 7: Change Request Sample Form

CHANGE REQUEST FORM
Project Name:
Issue No:
Short Description of Issue:
Raised By
Date Raised:
Description of Issue:
Resolution Comments:
Closed By:
Date Closed:
Issue Closing Agreed By:
Date:
Page 244 of 283
Appendix 8: SWOT Analysis Template

SWOT Analysis Template State what you are assessing here. Please note that these criteria examples
relate to assessing a new business venture or proposition. Many listed criteria can apply to other
quadrants, and the examples are not exhaustive. You should identify and use any other criteria that are
appropriate to your situation.
Market developments?
Competitors' vulnerabilities?
Industry or lifestyle trends?
Technology development and innovation?
Global influences?
New markets, vertical, horizontal?
Niche target markets?
Geographical, export, import?
Tactics: eg, surprise, major contracts?
Business and product development?
Information and research?
Partnerships, agencies, distribution?
Volumes, production, economies?
Seasonal, weather, fashion influences?
Disadvantages of proposition?
Gaps in capabilities?
Lack of competitive strength?
Reputation, presence and reach?
Financials?
Own known vulnerabilities?
Timescales, deadlines and pressures?
Cashflow, start-up cash-drain?
Continuity, supply chain robustness?
Effects on core activities, distraction?
Reliability of data, plan predictability?
Morale, commitment, leadership?
Accreditations, etc?
Processes and systems, etc?
Management cover, succession?
CRITERIA
Opportunities
CRITERIA
CRITERIA
Threats
Advantages of proposition?
Capabilities?
Competitive advantages?
Unique selling points?
Resources, Assets, People?
Experience, knowledge, data?
Financial reserves, likely returns?
Marketing - reach, distribution, awareness?
Innovative aspects?
Location and geographical?
Price, value, quality?
Accreditations, qualifications, certifications?
Processes, systems, IT, communications?
Cultural, attitudinal, behavioural?
Management cover, succession?
Philosophy and values?
Strengths
Weaknesses
CRITERIA
Political effects?
Legislative effects?
Environmental effects?
IT developments?
Competitor intentions - various?
Market demand?
New technologies, services, ideas?
Vital contracts and partners?
Sustaining internal capabilities?
Obstacles faced?
Insurmountable weaknesses?
Loss of key staff?
Sustainable financial backing?
Economy - home, abroad?
Seasonality, weather effects?
Appendix 9: Reasons for Potential Project Failures & Successes

POTENTIAL PROJECT FAILURES
POTENTIAL PROJECT SUCCESSES
Some projects fail. The most common reasons are

listed below.
To increase the chances of success, projects

should have the following:
Following a method without thinking or

planning.
Clear and well-managed processes.
A clearly defined purpose and limits.
Being too confident of success.
Not enough contribution from those with an

interest.
Shared understanding of the intended

outcomes.
Realistic objectives.
Unrealistic expectations.
Good management of risks and problems.
Poor communication.
Thorough planning.
Poor project specification.
Page 245 of 283
Not enough resources.
Too few experienced people involved in the

project.
Too much reliance on one person.
Failure to manage risks and problems.
Timely decision-making supported by short,

clear lines of reporting.
Strong leadership.\
Commitment and support from client and

sponsor.
A trained and experienced project manager,

who is suited to the particular project.
A trained and experienced project team.
Clearly defined jobs and responsibilities.
Good communications.
Appendix 10: Project Management Associations

ASSOCIATION
WEBSITE
Advanced Projects Institute

American Society For the Advancement of Project
Management
Association for Project Management
Australian Institute of Project Management
European Institute of Advanced Project & Contract
Management
EXtreme Project Management
International Project Management Association
Japan Project Management Forum
KLR Consulting PMO Offic
www.advanced-projects.com
www.asapm.org
Project Management Institute

Project Management Institute - United Kingdom
Project Management Institute Information Systems Special
Interest Group
Project Management Institute Special Interest Group
Risk Analysis And Cost Management
Risk Services & Technology
Software Program Managers Network
Students Of Project Management
www.apm.org.uk or www.apmgroup.co.uk
www.aipm.com.au
www.epci.no
www.cutter.com/freestuff/epmr0102.html
www.ipma.ch/
www.enaa.or.jp/JPMF/inter_liaison/index_e.html
www.klr.com/PMO.htm
www.pmi.org
www.pmirep.org/
www.pmi-pmosig.org/
www.pmi.org/chap/uk/
www.pmi-ssig.org/
www.metsig.org
groups.yahoo.com/group/pmitroubled/
www.racm-inc.com/
www.risktrak.com
www.spmn.com
www.ltugcom.org/SOPM/
Appendix 11: Due Diligence Questions

Financial Statements
Detailed income statement, cash flow and balance sheet (annual reports) for the past three years
and the current year to date. Plus forecasts for as many years as you may have.
Page 246 of 283
All supporting schedules to the above financial statements for the periods listed.
These schedules should be split by major product line, if available. There should be separate
schedules for local and international markets.
Accounts receivable per major customer for the past three years.
Physical inventory summary or detailed breakdown of inventory (raw materials, work in process,
labour and overhead) for the past three years.
Accounts payable by vendor for the past three years.
Listing of accrued expenses for the past three years.
State tax returns for the past three years.
Marketing
Customer order reports. This is split up per customer and product line for a period of at least three
years.
Listing of shipments by customer and product line for the past three years and the current year to
date.
Listing of outstanding customer contracts and outstanding customer bids for the domestic, export and
international divisions.
Description of all manufacturer's representative organizations, agreements and commission

schedules.
List of buying sources: domestic, export and international.
List of customers, contracts and outstanding payments.
Products, services, sales and pricing strategies
Personnel
Management and shareholder structures, plus group organogram
Local
International
All employment contracts or agreements.
All bonuses, deferred compensation, share option schemes, profit sharing and retirement
programmes.
All pension plan documentation, including actuarial reports, tax returns and funding requirements for
the past three years.
Schedule of hourly wage rates and number of personnel at each rate.
Organisation chart of salaried personnel.
Contracts and Agreements

All contracts or agreements with:
Page 247 of 283
Vendors and customers
Employees
Unions
Other third parties
All recent (within three years) appraisals of property, machinery and equipment.
A list of machinery and equipment. Please provide information on:
Assets owned
Financed
NAV of assets
Values of assets (depreciated and net)
All outstanding insurance claims.
All patents, copyrights and license agreements.
All lease or purchase agreements for machinery and equipment, vehicles and property.
Legal descriptions of all property, including deeds, title reports and title insurance documentation,
together with documentation of any lien thereon.
List and description of all outstanding litigation or anticipated litigation.
Is Union contract transferable? If yes, then description of mechanics of making transfer, such as
required approvals.
Appendix 12: Main Board & AltX: Differences
Profit record
Shareholder spread
Minimum capital
Escrow shares
Page 248 of 283
MAIN BOARD
ALTx
A satisfactory three-year
profit record, the last year
must show a pre-tax profit of
R8 million. Exceptions are
Mining companies and
Property companies,
provided that property
companies can show that the
performance of the
underlying properties
complies.
No profit record required.

At this time, the ALTx market
is not keen on venture capital
operations, but has not ruled
them out. A company that is
merely an idea is unlikely to
be accorded a listing. This
market is not intended for
applicants who qualify for the
main board.
A minimum of 500 public

shareholders, holding a
minimum of 20% of the
issued share capital.
A minimum of 100 public

shareholders, holding a
minimum of 10% of the
issued share capital.
R25 million in tangible or

professionally valued net
assets. Revaluations of
assets must be accompanied
by a valuation that is less
than six months old from a
valuer competent to value the
type of asset concerned.
R2 million in tangible or
professionally valued net
assets. Revaluations of
assets must be accompanied
by a valuation that is less
than six months old from a
valuer competent to value the
type of asset concerned.
There are no provisions for

escrow shares. All shares
50% of the shares held by

the directors may be sold
Link to JSE
Announcements
MAIN BOARD
ALTx
held by the founder, promotor

or controlling shareholder
may be sold immediately on
listing (obviously subject to
market conditions).
immediately on listing
(obviously subject to market
conditions) and the balance
must be held in escrow and
can only be sold as to half of
the balance when results for
the remainder of the current
financial year and one more
year have been audited.
The remainder (i.e. the last
quarter) can only be sold a
further one year later.
All listed companies are

required to have an
appointed Sponsor at all
times. Provisions exist for a
change in Sponsor. There
are only indirect provisions
for terminating the listing of a
company that does not have
a Sponsor.
Companies are required to
publish a number of types of
announcement in
newspapers published in
English and one other official
language as well as on the
Securities Exchange News
Service (SENS). These
announcements normally
include: abridged listing
particulars; interim and
preliminary results (if
applicable); cautionary
announcements; trading
updates; acquisition
announcements; rights issue
announcements; and
dividend announcements.
Directors induction
programme
There is no requirement for

directors to attend the
Directors induction
programme.
Financial director
Can be appointed by the

company without reference to
the Sponsor.
Directors
Profit forecast at time

Page 249 of 283
Require four directors.

Recommended to comply
with the King Code on
Corporate Governance
areas of non-compliance
must be detailed. King Code
requires more non-executive
directors than executive
directors. If the Sponsor is a
director, another sponsor
must also be appointed for
transactions.
No profit forecast is required.
All listed companies are

required to have an
appointed Designated
Advisor at all times.
Provisions exist for a change
in Designated Adviser, but
listing will be summarily
terminated if a company is
without a Designated Adviser
for two months.
All announcements must be

published on SENS and do
not need to be published in
the press.
All directors must attend the

Directors induction
programme.
The appointment needs to be
signed off by the Designated
Adviser.
25% of the board must be

non-executive. The
Designated Adviser can be a
director without being
disqualified to act as
Designated Adviser. The
Designated Advisor must
attend all board meetings.
The company must provide

the JSE with a profit forecast
MAIN BOARD
for the remainder of the

current year and one
additional year. This does
not have to be published.
of listing
Presentation to JSE
Shareholding by
Sponsor/Designated
Adviser
No presentation required.
The Sponsor may hold

shares in the company, but if
his holding is in excess of
10%, another Sponsor must
be appointed for transactions.
Health warning
No health warning required.
Issues of shares for

cash
General authority to issue

shares for cash enables the
company to issue up to 15%
in any one year.
Revised listing
particulars
Related party
transactions
ALTx

publish revised listing
particular statements if they
issue more than 30% of their
share capital in a three-month
period.
Any transaction with a related

party which involves greater
than 0.25% of the companys
market capitalisation.
Require shareholder approval
and a fair and reasonable
statement by an independent
financial adviser.
Full presentation to the ALTx

Listing Advisory Committee
prior to being allowed to
proceed with the listing
process.
The DA may hold up to 20%
of the shares in the company
without being rendered
unable to act as Designated
Adviser at all times.
A warning statement
regarding the risks of
x
investing in an ALT listed
company and the importance
of the Designated Adviser to
the company, must be on all
published documentation.
General authority to issue
shares for cash enables the
company to issue up to 50%
in any one year.
publish revised listing
particular statements if they
issue more than 50% of their
share capital in a threemonth period.
Any transaction with a related
party which involves greater
than 10%. If it involves
between 10% and 50%, the
Designated Adviser may
issue the fair and reasonable:
shareholder approval is
required. Above 50%, the
fair and reasonable must be
issued by an independent
financial adviser.
Shareholder approval is
required.
Appendix 13: Benefits Of Listing On The JSE Ltd

The following information is supplied for the benefit of the board of directors in order for them to consider
the various aspects of listing.
Main advantages
Page 250 of 283
The listing process, which necessitates a valuation of the company requiring input from
management, is beneficial to the company as management is simultaneously required to focus on
the define the companys strategic direction.
Should the company require further capital it is able to raise funds via a private placement ,
preferential offer, public offer, a rights issue or a combination thereof, which will immediately
strengthen the balance sheet.
Existing shareholders are often able to benefit financially through the repayment of shareholder loans
or the realisation of a portion of their shareholdings at the date of listing or shortly thereafter.
The companys shares are traded in a regulated market, thereby establishing a daily share pricing
mechanism, which measures the companys value on a ongoing basis.
Acquisitions of assets are facilitated through the issue of new shares or other securities. A well-rated
company will trade on a high price-earnings ratio, which enables the relatively cheap acquisition of
assets when shares are issued in consideration therefore.
Mergers and joint ventures with other listed and unlisted companies are more easily implemented.
The raising of funds via rights offers or, where possible, the issue of shares for cash, is more readily
implemented than is possible for an unlisted company.
A listing lends a certain transparency to the companys business affairs, which is looked upon
favourably by all of the companys stakeholders including creditors, bankers, shareholders,
employees and customers and usually results in improved credit ratings and financing availability.
Relations with international and national business interests are likely to improve due to the
perception that the company has nothing to hide as evidenced by its willingness to list and subject
itself to public scrutiny.
The establishment of a share incentive scheme provides motivation for the employees to add value
to the business, thereby increasing their own wealth through an increased share price.
Main disadvantages
The company must comply fully, and at all times, with the rules and regulations of the JSE and the
Securities Regulation Panel (the SRP) and the requirements of the Companies Act (No 61 of 1973),
as amended, which requires the input of both management and the companys advisers and may
lead to the consequent generation of large volumes of documentation.
Initial listing costs, albeit once off, are high.
The company is exposed to public scrutiny, resulting in increased media interest and greater outside
demands on management time.
The company must seek JSE, SRP and, where necessary, shareholder approval for substantial
future acquisitions, disposals, issues of shares, etc.
The company is subject to more vigorous financial reporting requirements.
A company with a wide shareholder spread is vulnerable to a hostile take-over.
The costs of appointing transfer secretaries, printing financial statements and paying advisers fees
can prove to be significant.
Page 251 of 283
Shareholder control is usually diluted from the date of listing.
METHODS OF ACHIEVING A LISTING

The following methods of achieving a listing are available to the company:
A. A listing whereby application is made for an initial listing of the entire issued ordinary share
capital of a company or a part thereof. In this instance the following alternatives are available to
a company:
An introductory listing where no capital is raised and the company satisfies the JSE spread
requirements: Requires a pre-listing statement.
A listing combined with either the raising of capital or the offer of shares for sale. The
following options are available to the company:
A public offer only: Requires the preparation and registration of a prospectus.
A private placing only: Requires the preparation and registration of a prospectus.
A combined public offer and preferential offer: Requires the preparation and
registration of a prospectus.
An offer of sale of shares: Requires the preparation and registration of a prospectus.
B. A listing whereby a listed company, usually a cash shell, acquires assets in consideration for
the issue of shares resulting in a change of control and an offer to minority shareholders. A
revised listing particulars statement is required as well as a circular to shareholders. The listing criteria
for the assets injected into the listed vehicle are the same as for a direct listing.
Appendix 14: Case Study Phase Two: Agenda
AGENDA RE PHASE 2: OPTION DETERMINATION AND STRATEGY

DATE: ________________
Submitted to: __________
The agenda is split into two three, namely corporate structure/accounting, legal issues and data required
to complete Phase 3: Business Plan.
Corporate Structure/Accounting
Aim:
The creation of CarverTel Consultants Limited

This will be the listed AltX company
The following information requirements need to be discussed to achieve the above.
General information required reformation of new company
Addresses
Contacts (new email addresses)
Telephone
Place of business: where will the new company be based?
Corporate and nature of business
A NEW WEB SITE
Holding Company Profile and Organagram will be set out once the following structures have been
agreed to.
Page 252 of 283
Company structure
The new company will acquire Carver B Consultants and ProKomTol.

o
A fair valuation method has to be adopted. Various options will be discussed and the project
manager recommends that at least two systems must be used, i.e. Discounted cash flow +
price earnings.
The medium of the two could be used as the ultimate valuation of the business. Shareholder
profile will then follow.
Both Carver B Consultants and ProKomTol must agree on the valuation methodology and
sign agreements to that effect. The exact same system will then be used for each company.
Discussions on how to handle goodwill, shareholder loan accounts and accounting

issues set out in the due diligence will be agreed to prior to the valuation being
conducted.
Decisions will also be made relating to loan accounts.
Shareholder Profile:
o
Breakdown of current values per person, given the final valuation of the new merged
company.
A decision must be made as to whether each shareholder will have an equal share of the new
company or leave the valuation as they stand.
Consideration must be given to the creation of a Share Incentive Scheme for staff and clients.
Use of Preference shares for staff, BEE or raising additional funds from the market.
Management Profile: breakdown of the proposed board of directors: MD/chairman and other
positions.
o
Remember that 25% of the board must be non-executive
Employees:
List of employees for Carver B Consultants and ProKomTol, amd merged company.
Will the holding company pay all expenses, or will each division run autonomously?
Employment contracts
It is crucial that, once the business plan has been completed, employees are notified
and assured that their positions are secure (if not, retrenchment must be properly
undertaken).
ACCOUNTING
Updated Management Accounts. The same timeframes are needed for Carver B Consultants and
ProKomTol, i.e. final 2007 figures and interim 2007/8 financials.
Page 253 of 283
Secretarial documentation: share registers, articles of association, memorandums and any special
resolutions limiting borrowing powers, transfers etc.
o
These will be for the current companies and for the new holding company.
Source documentation of all short & long term liabilities; including banking loans, leases, directors
loans, security provided both personal (directors) and from a company perspective, notorial bonds
registered over assets etc.
Updated asset registers and any urgent capital replacements required
Latest tax assessment
Monthly cash flow requirements of each director - ball park R30k, R50k or R100k? This will be used
to cut costs and issue the remainder as stock based compensation.
Management forecast for the new holding company.

o
AltX requirements:
Current year forecast: to end-February 2008
One full year forecast: to end-February 2009
LEGAL ISSUES
Schedule 21 declarations by the directors

Shareholder agreements
Registration of the new company, including all relevant articles of association etc
Open bank account for the new company
Decide on and appoint the board of directors. All documentation must be signed and submitted
Decide on corporate governance
Appoint corporate governance committee
Obtain a list of all other directorships held by the directors
Decide on and appoint and get signed letters of agreement from:
o
o
o
o
o
o
Company Consultants (accountant advisor can be included)

Corporate advisors
Legal team that will undertake the listing
Designated Advisors (for listing) that will undertake the listing
Accounting house that will undertake the listing
Obtain brief CVs from each of the directors (current and for the listed company)
Give notice of a general meeting to pass a resolution regarding a proposed listing

Update all company secretarial work
Adoption of Articles of Association for the company that is to list
Details of immovable property owned and leased from third parties
Draft contracts in respect of:
o Employment of any individuals; and
o Employment of any consultants.
A number of legal issues will only be required during Phase 4: Listing documentation and prospectus,
such as share capital and share to be issued. At this stage a share register will be set up with a
Registrar.
Page 254 of 283
OTHER ISSUES
Complete a nature of business and prospects sections for the business plan that can also be used in
the prospectus.
Discuss BEE there needs to be a plan in place, but negotiations can be completed after the listing.
A strategic methodology has to be drafted for the business plan.
Long term plans should be set out in general terms, i.e. planned acquisitions, new product
development and growth plans.
Page 255 of 283
GLOSSARY
Acceleration Clause: Clause causing repayment of a debt, if specified events occur or are not met.
Acceptance Criteria: The criteria by which a product or system is judged at Acceptance Test.
Usually derived from commercial or other requirements.
Acceptance Date: Time limit given to a prospective shareholder to accept an offer of shares in a
"rights" issue.
Acceptance Test: Final functional testing used to evaluate the state of a product and determine its
readiness for the end-user. A gateway or milestone which must be passed.
Account: A trading period whose dates are fixed by the stock exchange authorities.
Accountability: To ensure that a result is achieved, usually through the effort of others.
Accounting Policies: principles, bases, conventions, rules and procedures adopted by management
in preparing and presenting financial statements.
Accounts Payable: Bills which have to be paid as part of the normal course of business
Accounts Receivable: Debt owed to your company from credit sales
Accumulated Depreciation: Total accumulated depreciation reduces the book value (formal
accounting value) of assets. The value of an asset is reduced each month by a predetermined
amount and time frame. An asset worth R100, depreciated by R10 per month, would be written off
over 10 months.
Accuracy rating: A high, medium, or low rating that depicts the level of confidence the team has in
an estimate.
Acid Test: A ratio used to determine how liquid a company is. It is determined by subtracting shortterm assets from accounts receivable and inventory, which is then divided by short-term liabilities.
Ad hoc: member Attendance at team meetings is by invitation only.
Affinity diagram: A team-based tool for identifying and organising ideas.
Aftermarket Performance: A term typically referring to the difference between a stock's Offering
Price and its current market price.
Agenda: Notice of a meeting that states meeting location, time and date of the meeting and the
items to be discussed.
Agent: where a member acts on behalf of a client and has no personal interest in the order.
AIM: The UK-based AltX version, called the Alternative Investment market.
All or Nothing: means the full order must be executed immediately or, if it is not possible to do so, the
order must be routed to the speciasl terms order book.
Page 256 of 283
Allotment Letter: Formal letter sent by a company to the investor to confirm that it will allocate him
shares in a new issue.
Alpha: The first version of product where all of the intended functionality has been implemented but
interface has not been completed and bugs have not been fixed.
AltX: The new Alternative Exchange launched in South Africa in October 2003.
American Depositary Receipts (ADRs): These are offered by non-US companies who want to list
on a US exchange. Rather than constituting an actual share ADRs represent a certain number of a
company's regular shares.
Analyse: The first phase in many developmental and delivery methodologies. The Analyse phase
involves examination of the proposal to determine the requirements and what is to be addressed by
the project.
Arbitrage: a purchase or sale by a member on his/her own account of securities on one stock
exchange with the intent to sell or buy those securities on another stock exchange to profit by the
difference between the prices of those securities on such stock exchanges.
Asset Swap: a transaction which complies with all the requirements of the South African Reserve
Bank in respect of an asset swap.
Asset Turnover: Sales divided by total assets. Important for comparison over time and to other
companies of the same industry.
Assumptions: Statements describing situations that are taken to be true.
At Best: An order to be transacted in a manner that will, in the discretion of the member executing
the order, achieve the best price for the client.
At Market: an order to be transacted immediately against the best opposite order in the order book
at the time of making such entry.
Authorised/Issued Share Capital: While the authorized share capital is the maximum number of
shares a company is permitted to issue over time, the issued share capital is the actual number of
shares in issue. These figures are specified in pre-incorporation agreements (memorandum and
articles of association). Investors can find these figures in a company's annual report.
Bad Debts: An amount payable by debtors, which the firm determines is irrecoverable.
Balance Sheet: A statement that shows a company's financial position on a particular date.
Bankers Acceptances: A bill of exchange, or draft, drawn by the borrower for payment on a
specified date and accepted by a chartered bank. Upon acceptance, the bill becomes, in effect, a
post-dated certified cheque.
Bankruptcy: A legal procedure for formally liquidating a business carried out under the jurisdiction of
courts of law.
Baseline: A snapshot at a particular point in time of part of a project plan. A schedule baseline is a
snapshot of the schedule at that point in time. Can be compared over time.
Bear Sales: the sale of listed securities of which the seller is not the owner at the date of sale.
Page 257 of 283
Bear Trend: When supply of shares outstrips demand and prices start to fall. If this trend continues
for a number of weeks, the general sentiment becomes bearish and prices continue to fall.
Benefits Realisation Review: The process of reviewing the extent of realized benefits once the
solution has been delivered and implemented. Measured benefits are compared with those originally
proposed in the Business Case.
Benefits Tracking: The process of quantitatively measuring over a period of time the extent of
realized benefits once the solution has been delivered and implemented.
Best Efforts: This term is used to describe a deal in which underwriters only agree to "do their best"
in selling shares to the public. An IPO is more commonly done on a Bought or Firm Commitment
basis in which the Underwriters are obligated to sell the allotted shares.
Beta: The first version of a product where all of the functionality has been implemented and the
interface is complete but the product still has problems or defects.
Bid (Buyer's Price): offer to buy a number of securities at a certain stated price.
Bid, Not Offered: When shares are sought, but none are available. The opposite would be "offered,
not bid."
Big-Bang: The implementation of a new system all at once, differs from incremental in that the
transition from old to new is (effectively) instantaneous
Black Box Testing: Testing a product without knowledge of its internal working. Performance is then
compared to expected results to verify the operation of the product.
Blank Cheque: A company that indicates no specific industry, business or venture when its
securities are publicly offered for sale and the proceeds of the offering are not specifically allocated.
Bond: Usually a fixed-interest security under which the issuer contracts to pay the lender a fixed
principal amount at a stated date in the future and a series of interest payments, either semi-annually
or annually. Interest payments may vary throughout the life of the bond.
Book Value: The net amount of an asset shown in the books of a company, i.e. the cost of
purchasing a fixed asset less the depreciation on that asset.
Bookkeeping: The process of collecting, classifying, recording and summarizing a business's

financial transactions in what are known as journals and ledgers.
Bottom Up: Building or designing a product from elementary building blocks, starting with the
smaller elements and evolving into a lager structure.
Brainstorming: A process for generating ideas.
Break-Even Point: The unit sales volumes or actual sales amounts that a company needs to equal
its running expenses rate and not lose or make money in a given month. Break-even can either be
based on regular running expenses, which is different from the standard accounting formula based
on technical fixed expenses.
Broker: The name given to a natural person recognised by the official stock exchange. Institutions
will, from 1995, be able to become corporate members.
Brokerage: commission charged by a member for the purchase or sale of securities.
Page 258 of 283
Broker's Note: a note which a member is required to send to a client recording the details of a
purchase or sale of securities.
Budget risk: The potential problems that could cause the team to overspend the budget.
Budget: Planned expenditure and funds allocated for a project.
Bull Trend: When demand for shares outstrips supply and prices start to rise. If this trend continues
for a number of weeks, the general sentiment becomes bullish and prices continue to rise.
Burden Rate: Refers to personnel burden, the sum of employer costs over and above salaries,
including employer taxes and benefits
Business process: A set of steps that turns inputs into repetitive outputs. One of the ways, besides
projects, that work is accomplished.
Business Case: A document detailing the justification for the business progressing with the project.
Business Owner: The person/s in the organisation that will take ownership of the projects outputs
and use them for the benefit of the organisation.
Business Requirements Specification: A document that states specifically the business needs that
the projects outputs must satisfy. It is basically the what aspect of the project.
CAPEX: Capital Expenditure typically includes purchase of new equipment.
Capital Assets: Long-term assets, also known as Fixed Assets (plant and equipment).
Capital Expenditure: Spending on capital asset (also called plant and equipment, or fixed asset).
Capital Input: New money being invested in the business. New capital will increase your cash, and
will also increase the total amount of paid-in capital.
Capital Structure: Usually refers to the structure of ordinary and preference shares and long term
liabilities.
Capital Turnover: Annual sales divided by average stockholder equity (net worth) (i.e. total sales for
each R1 of equity).
Capital: This is also known as total shares in issue, owner's equity or shareholders' funds.
Capitalisation: The total amount of debt and equity issued by a company.
Cash Budget: A plan or projection of cash receipts and disbursements for a given period of time. It is
essential for the determination of cash deficiencies or excess cash balances.
Cash Conversion Cycle: The period of time it takes for a company to pay cash for a product, add its
value to the product and then receive cash from the sale of that product.
Cash Equivalents: Instruments or investments of such high liquidity and safety that they are virtually
equal to cash.
Cash Flow: A statement which shows the net difference between cash received and paid during the
company's operating cycle.
Cash: The bank balance, or checking account balance, or real cash in bills and coins.
Page 259 of 283
Cash-flow Forecast: An estimate of the timing and amount of a company's inflow and outflow of
money measured over a specific period of time; typically, monthly for one to two years, then annually
for an additional one to three years.
Change log: The means by which a project leader tracks the status of change requests.
Change management: A structured process for making changes to the project plan.
Change request: A request from inside or outside the project to amend the project plan.
Change Control: The set of practices around effectively managing changes to the project so that
they are raised, assessed, prioritised and implemented efficiently and with known impact on the
project.
Charter: The output of the initiation phase. It outlines the expectations and constraints that the team
will use when they plan the project.
Close-out Stage: The final project management phase in which the project is evaluated, feedback is
elicited, and lessons learned are captured.
Close-out report: The output of the close-out phase. It includes the final status report, evaluation
and feedback documents, lessons learned, and recommendations for improving the project system.
Closing Price: the last sale price or a higher bid or lower offer price for a particular security.
Collection Period (Days): The average number of days that pass between delivering an invoice and
receiving the money.
Collections Days: See Collection period
Commission: The brokers charge a fee for buying and selling shares, which is brokerage or
commission earned on a deal.
Commissions Percent: An assumed percentage used to calculate commissions expense as the

product of this percentage multiplied by gross margin.
Conceptual View: A very high-level summary of what the solution will look like once it is
implemented. It can be presented as a diagram.
Consensus: Agreement within a group that everyone can live with a decision.
Constraint: Something that the team is not allowed to do or resources that are not available to the
project.
Contingency: Reserve resources (time, effort, or money) that are set aside because of the
unpredictability of the future.
Convertible & Redeemable - Preference Shares: An alternative mechanism to ordinary shares. It

enables companies to issue other shares, which can either be bought back from investors or
converted into ordinary shares at a latter date.
Corporate Finance Transaction: a transaction which is entered into in writing and requires public
notification in the press in terms of the listings requirements of the JSE.
Page 260 of 283
Cost of Sales: The costs associated with producing the sales. In a standard manufacturing or
distribution company, this is about the same as the costs for people delivering the service, or
subcontracting costs.
Cost risk: The same as budget risk. The potential problems that could cause the team to overspend
the budget.
Countermeasure: An activity or deliverable that will prevent or reduce a risk.
Credit Risk: Risk that a borrower may default on obligations, thus a danger that repayment will not
take place.
Creditors: People or companies that you owe money to. This is the old name for accounts payable.
Criteria: The factors used to make a decision.
Critical Path: The minimum set of tasks which must be completed to conclude a phase or a project.
The path through the schedule in which there is no slack. The critical path is the longest path through
the schedule and it determines the final delivery date in the project.
Crossed Market: where a bid price is higher than the offer price for a security
Cum Or Ex-Dividend: After a company has declared a dividend, it would close its books to start
paying dividends. The share will be marked ex-div, which means that any new shareholder will be
omitted from the past year's dividend pay out. Before the company declares a dividend payout, the
share will be assumed to include possible dividends or to be cum-div.
Current Assets: Those assets which can be quickly converted into cash and include accounts
receivable, stock and debtors book. These are often called liquid assets.
Current Debt: Short-term debt, short-term liabilities.
Current Liabilities: A company's short term debt, which must be paid within the firm's operating
cycle, i.e. less than one year.
Customer acceptance criteria: The criteria the customer will use to determine if he or she is
satisfied with the final deliverable.
Customer evaluation: An assessment by the customer, after the final deliverable has been
delivered, of his or her level of satisfaction with the project.
Customer need: The problem that the final deliverable will help the customer resolve.
Customer requirements: Specific features or functions that the customer wants from the final
deliverable.
Deadline: The date for delivery of a deliverable that is set by someone outside the project team,
usually the sponsor or customer.
Deal Breaker: A significant issue relating to proposed financing between the prospective investor
and the entrepreneur that must be resolved in order to close the deal.
Debentures: A bond which is not secured by fixed assets.
Debt And Equity: The sum of liabilities and capital. This should always be equal to total asset.
Page 261 of 283
Debtors: People or companies that owe your company money. It is the old name for accounts
receivable.
Decision options: The choices available before a final decision is made.
Deliverable: An item produced by a project or part of a project that is tangible and objectively
verifiable.
Deliverables schedule: The schedule that shows the delivery date for each of the projects
deliverables and the interdependencies between them.
Deliverables staff effort: The internal effort required to create the deliverables for the project.
Delivery date: The date a deliverable is scheduled to be turned over to the next customer in the
technical process.
Demand Loan: A loan that must be repaid in full on demand.
Depreciated Replacement Value: The value of an asset with reference to the cost of replacing the
asset with a new asset of similar utility minus an amount reflecting the depreciation of the existing
asset.
Depreciation: An accounting and tax concept used to estimate the loss of value of assets over time.
For example, cars depreciate with use.
Dilution: Reduction in per share participation in net earnings and ownership through an increase in
issued stock.
Directive project management: The old management approach in which the project manager did
the planning, delegated tasks to team members, monitored the project, and then shut it down.
Discount Rate: A rate of return used to convert a monetary sum, payable or receivable in the future,
into present value.
Discounted Cash Flow (DCF): Techniques for establishing the relative worth of a future investment
by discounting (at a required rate of return) the expected net cash flow from the project.
Discounting: The process of finding the present value of a series of future cash flows. Discounting is
the reverse of compounding.
Divestiture: Sale of part of a company. It is the opposite of merger.
Dividend Coverage: Number of times a company's dividend is covered by earnings available to pay
it.
Dividend Yield: ratio of the latest dividend to the cost or market price of a security expressed as a
percentage.
Dividends: Money distributed to the owners of a business as profits.
Double Top: This technical assessment is formed when a stock advances to a certain price level
only to retreat from that level, and then rally again back to that level. The up moves are accompanied
by high volume and the recession from the top comes on receding volume.
Due Diligence Review: The investigatory and review procedures carried out by strategists, accounts
and lawyers,
Page 262 of 283
Due Diligence: A reasonable investigation conducted by the parties involved in preparing a

disclosure document to form a basis for believing that the statements contained therein are true and
that no material facts are omitted.
Duration: The length of calendar time required to complete a project or part of a project.
Earned Value Analysis: A technique for determining the value delivered by a project to date
compared with what it was planned to deliver.
Earnings Yield: ratio of net earnings per security to the market price expressed as a percentage.
Earnings: Also called income or profits, earnings are the famous "bottom line": sales less costs of
sales and expenses.
Earnout: method of structuring a transaction whereby the ultimate purchase price depends in part on
the future performance of the business being acquired.
EBIT: Earnings before interest and taxes.
EBITDA: Earnings before interest, income taxes, depreciation and amortization
Economic Value Added (EVA): After-tax net operating profit minus cost of capital.
Effort: The measure of the amount of work required to complete a project or part of a project.
Empirical Approach: Valuation approach whereby the value of a company is determined by

reference to open market transactions involving similar companies or by reference to value
relationships implied in the stock price of publicly traded companies.
End customer: The customer that will ultimately use the product or service being developed. The
end user.
End user: The person(s) who uses a product, service, or process.
End-user requirements: The performance characteristics of the final product, service, or process
that are requested by the end user.
Equity Buyback: The investors' percentage ownership of a company that can be re-acquired by the
company, usually at a predetermined amount.
Equity Kicker: The term usually refers to the situation where an investor has subordinated debt in a
company and, in return for a lower interest late, the investor is given the option to convert some of
the debt into equity at a future date.
Equity: Business ownership; capital. Equity can be calculated as the difference between assets and
liabilities.
Escrow: An agreement put into the custody of another party until certain conditions are fulfilled.
Estimate: A calculated guess of the size, cost and duration of a future project.
Evaluate: A phase in some project methodologies in which the success of the project in meeting its
objectives is measured and reported.
Page 263 of 283
Exchange Risk: The risk associated with an asset or liability denominated in a foreign currency. It is
vulnerable to the movement of exchange rates.
Execution Stage: The stage in the project management process in which the deliverables are
created and their progress is tracked.
Executive Summary: A concise summary of an investment proposal that describes a company's

background, products or services, financial needs, financial requirements, management capabilities,
market description and financial data.
Exit Options: A variety of options available to investors to recover their invested capital and the
return on their investment.
Expectations: What the client is hoping will be accomplished.
Expected Return: The total amount of money (return) an investor anticipates to receive from an
investment.
External costs: Expenses for the project that originate outside the organisation.
External customer: A customer who resides outside the organisation.
Facilitation: The act of helping a person or group to work through a process.
Feature/Scope creep: The relentless tendency of a project to self-inflate and take on more features
or functionality than was originally intended. Also known as scope creep.
Features: Specific attributes of final deliverables.
Fill Or Kill: the full order must be executed immediately or otherwise cancelled
Final deliverable: The final output from the execution stage of the project that is delivered to the
project customer.
Final status report: The last status report for the project, completed after the project client has
accepted the final deliverable.
Financial Notes: Information explaining financial figures (balance sheet, income statement and cash
flow).
Fiscal Costs: Running costs that take time to wind down: usually rent, overhead, some salaries.
Technically, fixed costs are those that the business would continue to pay even if it went bankrupt. In
practice, fixed costs are usually considered the running costs.
Fiscal Year: Standard accounting practice allows the accounting year to begin in any month. Fiscal
years are numbered according to the year in which they end. For example, a fiscal year ending in
February of 1992 is Fiscal year 1992., even though most of the year takes place in 1991
Fixed Assets: Includes all fixed (immovable) assets, namely property, vehicles, machinery and
equipment. It cannot usually be converted into cash within the firm's operating cycle.
Fixed Expenses: Cost of doing business, which does not change with the volume of business.
Examples might be rent for business premises, insurance payments, heat and light.
Fixed Rate Loan: Loan for a fixed period of time with a fixed interest rate for the life of the loan.
Page 264 of 283
Flipping: This is when an investor has acquired an IPO at its Offering Price and sells it immediately
for a quick gain soon after it starts trading on the open market. A practice discouraged by
underwriters, that can lead such investors to unfavourable relationships with their underwriters with
future IPOs.
Floating Charge: Charge or assignment on a company's total assets as security for a loan on total
assets without citing specific assets.
Floating Rate: A situation where the interest rate or rate of exchange is determined solely by market
forces.
Forecast: Future-oriented financial information prepared using assumptions, all of which reflect the
entity's planned courses of action for the period covered, given management's judgment as to the
most probable set of economic conditions.
Foreign Exchange: Claims in a foreign currency payable abroad, including bank deposits, bills,
cheques. Foreign exchange rates refer to the number of units of one currency required to buy
another.
Forming stage: The first stage of team development. It is when people are getting to know one
another.
Front-end Fees: Fees paid when, for example, a financial instrument such as a loan is arranged.
Front-end Loading: Charges or fees that are greater at the start of a loan or investment contract
than in its later stages.
Functional manager: The person accountable for a department or a set of resources. Also known
as a resource manager.
Funding Consolidation: The process of replacing short-term debt with long-term securities (shares
or bonds).
Funding Costs: The price of obtaining capital, either borrowed or equity, with intent to carry on
business operations.
Gantt chart: A schedule that visually shows the duration for each deliverable or activity.
Going Concern: A company which is operating, i.e. has not stopped producing goods or providing a
service and one which has not been placed under liquidation or curatorship.
Goodwill: An intangible asset reflected in balance sheets, which indicate an excess over market
value for assets paid by the firm.
Gross Geographic Product: A statistic which shows the remuneration received by the production
factors (land, labour, capital and entrepreneurship) for their participation in production of goods and
services in a defined area.
Gross Margin Percent: Gross margin divided by sales, displayed as a percentage. Acceptable
levels depend on the nature of the business.
Gross Margin: Sales less cost of sales.
Head and Shoulders: This technical pattern is typically characterised by one intermediate top (left
shoulder), followed by a second top higher than the previous top (head), and a third rally that fails to
Page 265 of 283
exceed the head (right shoulder). The neckline is drawn connecting the reaction lows (support). The
pattern is completed when prices break below the neckline and the sell signal is given.
Historical data: Data collected from past projects.
Horizontal Analysis: The process of comparing consecutive financial statements by examining the
increases or decreases between the periods in terms of absolute rands and percentages.
Hurdle Rate: A predetermined benchmark rate of return. If the rate of return expected from the
project or investment falls below the benchmark, the projected investment will no longer be accepted.
The hurdle rate should be the marginal cost of capital adjusted for the project's risk.
Hypothecation: The pledge of property and assets to secure a loan. Hypothecation does not
transfer title, but it does provide the right to sell the hypothecated property in the event of default.
Icebreaker: A tool that is used to help people feel more comfortable in a group.
Immediate Deal: a transaction in a listed security where settlement is to take place the next
business day.
Impact analysis: The assessment of what effect something will have on the project plan.
Implement: The phase of a project involved with delivering the solution to the Business Owner.
Income Statement: A statement showing net income or loss for a specified period.
Incremental development: The development or a product in a piece-by-piece fashion, allowing a

gradual implementation of functionality without having the whole thing finished.
Initial team: The team originally selected to be on the project.
Initiation: The first project management phase. In this phase the overall direction and constraints for
the project are set.
Input/output chain: The workflow of interconnected or inter-dependent deliverables that creates the
final deliverable.
Input: A supply that is used in a process.
Interdependencies: The dependencies that exist in any system, where one team member depends
on another for certain inputs or to receive certain outputs.
Interest Expense: Interest is paid on debts, and interest expense is deducted from profit as
expenses
Interim deliverable: A deliverable that is produced in the technical process before the production of
the final deliverable.
Internal costs: Expenses for the project that are cross-charged by a department inside the
organization.
Internal customer: A customer that is inside the organization.
Inter-relationship digraph: A team-based tool that helps a team identify root causes.
Page 266 of 283
Inventory Turnover: Sales divided by inventory. Usually calculated using the average inventory
over an accounting period, not an ending-inventory value.
Inventory Turns: Inventory turnover (above).
Inventory: This is another name for stock. Goods in stock, either finished goods or materials to be
used to manufacture goods.
Issue: An event that is currently threatening the project and requiring attention.
Issues list: A list to record issues that must be resolved or action items that are not significant
enough to put on the project schedule.
Issues Management: A set of practices designed to effectively identify, prioritize and monitor issues
and manage them through to resolution.
Jobbers: These are the market's share merchants. They deal only with brokers and other jobbers
(i.e. not with dealers) and their main function is to maintain a market by quoting a price.
Kick off: Typically the first meeting of the project team, when the project is officially launched.
Kinesthetic learners: People who learn best by doing or sensing.
Labour: In Business Plans the word "labour" often refers to the labour costs associated with making
goods to be sold. This labour is part of the cost of sales, part of the manufacturing and assembly. In
economic terms, labour often denotes the sale of a skill to produce a good or service.
Large project: A project with more than 10 team members.
Lessons-learned list: The compilation of what has been learned during a project as a result of both
successes and failures.
Letter Of Acceptance: The investor may receive such a letter if the company accepts his application
for shares.
Leverage Ratio: A financial ratio that measures a firm's debt burden. The debt, times interest earned
and fixed charges coverage ratios are leverage ratios.
Leverage: The relationship between interest-bearing debt and equity in a company (financial
leverage) or the effect of fixed expense on after-tax earnings (operating leverage).
Liabilities: Debts; money that must be paid. Usually debt on terms of less than five years is called
short-term liabilities, and debt for longer than five years in long-term liabilities.
Liaison: A person on the project team assigned to communicate with a stakeholder.
Limit Order: an order which may only be effected at prices equal to or better than the price on the
order.
Liquidity: A company's ability to pay short-term debt with short-term assets
Listing: official granting of a listing of a company's shares on the JSE.
Local Counter-party Transaction: a transaction where a member trades as a principal with a

person in South Africa other than a member.
Page 267 of 283
Long Term Assets: Assets like plant and equipment that are depreciated over terms of more than
five years, and are likely to last that long too.
Long Term Interest Rate: The interest rate charged on long-term debt. This is usually higher than
the rate on short-term debt.
Long Term Liabilities: This is the same as long-term loans. Most companies call a debt long term
when it is on terms of five years or more.
Management Leveraged Buyout: The situation when the management of a company purchases all
the company's shares or assets. Usually, the company's assets become security for the loans
necessary to make the purchase.
Management Of Investments: the management of investments on behalf of a client, by a member

or an approved person.
Management: Individuals in an entity that have the authority and the responsibility to manage the
entity. The positions of these individuals, and their titles, vary from one entity to another and, to some
extent, from one country to another depending on the local laws and customs. Thus, when the
context requires it, the term includes the board of directors or committees of the board that are
designated to oversee certain matters (e.g. audit committee).
Market Capitalisation: Used to denote a company's size and is calculated by multiplying a

company's issued share capital by its current share price.
Market Indicators: statistics that give an overall picture of how the market is performing.
Market Maker: a member which negotiates dealings in blocks of securities
Market Risk: The part of a security's risk that cannot be eliminated by diversification.
Marketable Securities Tax (MST): the tax imposed in terms of the Marketable Securities Act of
1948 in respect of every purchase of marketable securities through the agency of or from a member
at the rate of 0.25% of the consideration for which the securities are purchased.
Marketable Securities: All instruments legally permitted to trade on the JSE. These include shares
(ordinary and preference), gilts, futures and options.
Materials: Included in the cost of sales. These are not just any materials, but materials involved in
the assembly or manufactured of goods for sale.
Maturity Date: Date on which a debt is due for payment.
Mentor: A close personal contact, usually in your industry, who has a network of contacts in the
investment community and can assist in achieving your objectives.
Method: A system for getting something done.
Mezzanine Debt: Non-conventional debt that has a greater element of risk than secured debt, but
less risk than equity.
Milestone schedule: The schedule used to communicate the dates that major accomplishments in
the project will be completed.
Page 268 of 283
Milestone: A major accomplishment of the project. A significant point in a project schedule which
denotes the delivery of a significant portion of the project. Normally associated with a particular
deliverable.
Minority Shareholders: Shareholders who by virtue of their percentage ownership of the company
do not have voting control of the company.
Minutes: Notes taken during a meeting that summarize discussions and agreed actions.
Monopoly: When one company controls and dominates a particular company.
Mortgage: Debt instrument by which the borrower (mortgagor) gives the lender (mortgagee) a lien
on property as security for the repayment of a loan
Mourning stage: The last stage in the team-development process.
Multi-voting: A team-based tool for selecting one or more options for a decision.
Negative Covenant: A promise not to do certain things.
Net Cash Flow: This is the projected change in cash position, an increase or decrease in cash
balance.
Net Income: The level of profit in a business after the deduction of income taxes, depreciation,
operating expenses and other expenses. It is also known as after-tax profit or net profit.
Net Present Value (NPV): A method of ranking investment proposals. NPV is equal to the present
value of future returns, discounted at the cost of capital, minus the present value of the cost of the
investment.
Net Profit: The operating income less taxes and interest. The same as earnings, or net income.
Net Realizable Value: Selling price of an asset minus the expenses of bringing the asset into a
saleable state and expenses of the sale.
Net Working Capital: Total of all current assets minus the total of all current liabilities of
Net Worth: This is the same as assets minus liabilities, and the same as total equity.
Networking: Making use of contacts, associates and friends.
Non-assignable: Restriction in a contract limiting the ability of a shareholder to transfer the rights,
benefits or obligations pursuant to that contract.
Non-compete: Generally refers to a clause in a contract that restricts a person from starting a similar
business or working for a competitor. It is normally time and area specific.
Odd Lot: any quantity of securities which is less than a round lot (Krugerrands do not have odd lots).
Offer (Seller's Price): price at which a dealer is prepared to sell securities on the market.
Offering Price: This is the price set by the sponsor, at which the company's stock is sold to the first
round of investors.
Page 269 of 283
Offering Range: This is the price range which the company expects to sell its stock. This can be
found on the front page of the Prospectus. As with everything traded, market conditions and demand
dictate the final Offering Price.
Oligopoly: When a few companies controls and dominates a particular market.
Opening Price: This is the fist price that the company's stock trades on its first day of trading.
Order: an instruction
Ordinary Shares: Commercial paper issued to investors to raise capital. Investors hold these shares
as part owners in the firm.
Other Short-Term Assets: These are securities and business equipment .
Other ST Liabilities: These are short-term debts that don't cause interest expenses. For example,
they might be loans from founders or accrued taxes (taxes owed, already incurred, but not yet paid)
Output: A product that is produced as a result of a process.
Overheads: Running expenses not directly associated with specific goods or services sold, but with
the general running of the business
Oversight: The act of high-level monitoring to assure that a project is on track.
Over-the-Counter Market (OTC): A market made up of dealers who make a market for those
securities not listed on an exchange. The over-the-counter market is made between buyers and
sellers over the telephone, rather than the electronic market found on the JSE.
Paid-In Capital: Real money paid into the company as investments. This is not to be confused with
par value of stock, or market value of stock. This is actual money paid into the money as equity
investments by owners.
Paper Profit: A surplus income over expense, which has not yet been released, i.e. share prices
which have increased above the price at which they were bought, but not yet sold.
Par Value: The nominal value of a share and is an arbitrary amount placed on the share by the
company.
Parking lot: A meeting-management tool that provides a place to collect ideas or concerns that are
not part of the immediate discussion.
Participative project management: The new approach to managing a project in which the team
collaborates with the project leader to create a project plan, monitor and track the project, and close
down the project.
Payment Days: The average number of days that pass between receiving an invoice and paying it
Payroll Burden: Payroll burden includes payroll taxes and benefits. It is calculated using a
percentage assumption that is applied to payroll. For example, if payroll is R1,000 and the burden
rate 10 percent, then the burden is and extra R100. Acceptable payroll burden rates vary by market,
by industry and by company.
Phase gate: Go/no go decision points at the end of each project management stage.
Phase: A set of activities within the project management process.
Page 270 of 283
Plan: A document that describes how something should be accomplished.
Planning Stage: The second stage of the project management process in which a plan for how the
project will be executed is developed and approved.
Plant and Equipment: This is the same as long-term assets, or fixed assets, or capital assets.
Portfolio: a schedule, normally computer generated, listing the relevant details in respect of the
securities held by an investor.
Post-Implementation Review: A review conducted sometime after the completion of a project in

order to determine whether the project met its objectives; usually abbreviated to PIR.
Predecessor: A deliverable or activity that must be done before the next deliverable or activity can
be completed.
Price Earnings (P/E) Ratio: the market price of securities divided by its earnings. It expresses the
number of years' earnings (at the current rate) which a buyer is prepared to pay for a security.
Primary Market: Where shares are distributed at the Offering Price to investors.
Principal Transaction: a member trades with a counterparty or another member.
Private Placement: An offering of a limited amount of shares or units, in which the recipients receive
restricted stock from the issuer.
Process: A set of steps that transforms an input(s) into an output(s).
Product Development: Expenses incurred in development of new products; salaries, laboratory

equipment, test equipment, prototypes, research and development, etc.
Product Development Life Cycle: A methodical approach to designing and delivering new
products.
Product: A tangible or intangible good produced via a process.
Profit Before Interest & Taxes: This is also be called EBIT, for Earnings Before Interest and Taxes.
It is gross margin minus operating expenses
Project management staff effort: The amount of time that people on the project team will spend in
project management activities such as attending meetings, writing reports, planning, and so on.
Project management: The application of knowledge, skills, tools, and techniques to meet or exceed
customer expectations from a project.
Project objectives: The purpose of the project. The significant accomplishments that the project
must achieve.
Project plan: A complete plan for how the project will be executed. The output of the planning
phase.
Project priorities: The ranking of the triple constraints for the projectscope versus schedule
versus budget.
Page 271 of 283
Project team members: The people on the main project team.
Project Board: A group of people ultimately responsible for a projects success through monitoring
its progress, reviewing its continued relevance to the organisations objectives and overcoming
institutional barriers. In some organisations, may be referred to as a Steering Committee.
Project Brief: See Project Definition.
Project Definition: A document describing succinctly the project objectives, scope, summarized
costs and resource requirements. In some organisations, may be referred to as the Project Brief or
Terms of Reference.
Project Manager: The person selected by the organisation to manage the project resources and
activities in order to deliver the agreed project outputs.
Project Sponsor: A senior person within an organisation that has ultimate responsibility for the
success of a project through overcoming organizational barriers and advocating for the project. They
may devote resources to the project and in some cases is the Business Owner.
Project: A set of interrelated activities managed in a coordinated way and designed to deliver a
unique product or service within a given time frame and resources.
Projection: Future-oriented financial information prepared using assumptions that reflect the entity's
planned courses of action for the period.
Prospectus: This document is an integral part of a documentation that must be filed with the JSE. It
defines, among many things, the company's type of business, use of proceeds, competitive
landscape, financial information, risk factors, strategy for future growth, and lists its directors and
executive officers.
Prototype: A simple model of a product which is used to resolve a design decision in the project.
Published Financial: Financial statements and financial information made public.
Purchase Agreement: A legal document recording the final understanding of the parties with
respect to the proposed transaction.
Range: A numerical spread from lowest to highest. This is typically used to represent the staff effort
and spending estimate numbers.
Ratchet Clause: A clause in a contract that adjusts the rights of the parties to the contract on the
completion of mutually agreed upon performance criteria.
Rate of Return: Return on invested capital (calculated as a percentage). Often an investor has, as
one investment criterion, a minimum acceptable rate of return on an acquisition.
Real Property: Real estate, including land and buildings.
Receivable Turnover: Sales on credit for an accounting period divided by the average accounts
receivable balance.
Recourse: The right to receive payment in the event a person defaults on a loan. Recourse could
give the lender the ability to take possession of the borrower's assets.
Redundant Assets: Assets that are not required for the ongoing operation of the business and could
be withdrawn without affecting future earning potential.
Page 272 of 283
Registration: A new shareholder is registered when his name is placed on the role of shareholders
for that specific company.
Renunciation Date: The company sets a date by which the shareholder has to decide whether he
will take up the rights issue.
Replacement Value: Cost of acquiring a new asset to replace an existing asset with the same
functional utility.
Representations: Statements made by either party with respect to certain elements of the proposed
transaction that, if proven untrue, may give the other party the right to claim for damages from the
party making the warranty.
Requirement: A statement of need from a project stakeholder which identifies a required attribute of
the system or product to be delivered
Research and Development Incentives: Government programs to promote research and

development.
Residual Value: Typically estimated based on the present value of the after-tax cash flow expected
to be earned after the forecast period.
Resistance: When stocks go up, they tend to reach a point where investors think they are
overvalued and sellers of the stock outnumber buyers. This causes the price of the stock to stop
dead in its tracks. It cannot go higher because there are no buyers. This point is called resistance.
Resource managers: Also known as functional managers. They provide the resources, primarily the
people, to work on the project.
Resource planning: The plan for who will be involved in the project, how much time it will take, and
what it will cost.
Resource: People, materials, tools and systems needed during a project.
Restricted Liquidity: Inability of an individual or company to convert an asset into cash, or cash
equivalent, without significant cost.
Retained Earnings: A figure which shows the sum of a company's net profit less dividends paid to
shareholders.
Return On Assets: Net profit dividend by total assets. A measure of profitability.
Return on Equity: A ratio used to show how profitable a business is to the shareholders.
Return On Investment: Net profits dividend by net worth or total equity, yet another measure of
profitability. Also called ROI.
Return On Sales: Net profits dividend by sales, another measure of profitability.
Return on Investment: The financial benefit resulting from a project once the cost of the project is
deducted from the financial gain.
Reverse Head and Shoulders: This is the same pattern as a head and shoulders except that it has
turned upside down and indicates a trend change from down to up. A buy signal is given when prices
carry up through the neckline.
Page 273 of 283
Re-work: Doing the work over because the work was not done right the first time.
Rights Issues: There are a number of methods which a company can use to increase the size of it
share capital. If it decides to offer its existing shareholders first option on the issue, it is called a
"rights" issue. The dealers would note that such an issue is in progress as it would be quoted as
cum-capitalisation and after completion of the issue it would be noted as ex-capitalisation.
Risk assessment: The process of identifying, analysing, and preventing risks from occurring.
Risk identification: The process of brainstorming what potential problems might occur in the project.
Risk impact: The effect the risk would have on the project if it occurred.
Risk probability: The likelihood that the risk will occur.
Risk rating: The level of risk that the team determines is in the project.
Risk Management: A set of practices designed to effectively identify, prioritise and monitor risks and
plan for their mitigation.
Risk: An event that could possibly occur and which would have an impact on the project if it
happens.
ROI Return On Investment: a ratio which compares the monetary outlay for a project to the
monetary benefit. Used to show success of a project.
ROI: Return on investment; net profits dividend by net worth or total equity, yet another measure of
profitability.
Round Lot: the standard unit of trade - in all equities : one hundred shares
Sales Break-Even: This sales volume at which costs are exactly equal to sales
Sales On Credit: Sales on credit are sales made on account, shipments against invoices to be paid
later.
Schedule risk: The potential problems that could occur that would prevent the team from meeting its
deadline dates.
Schedule: The dates of completion for deliverables or activities mapped against the projects
timelines.
Scope boundaries: The fence that is placed around the scope of the project to delineate what is
inside and outside the project scope.
Scope description: A written explanation of features and functions of the final deliverable.
Scope plan: The part of the project plan that relates to scope. It includes the scope description of the
final deliverable, customer acceptance criteria, scope boundaries, and a stakeholder list.
Scope risk: Potential problems that could prevent the team from meeting the customers acceptance
criteria.
Scope: A clear description of the breadth of a project; what is in and what is out.
Page 274 of 283
Scrape Value: An amount left after an asset has been fully depreciated, i.e. If an asset of R115 is
depreciated by R10 per month over 11 months, the scrape value would be R5
Secondary Market: Better known as the Stock Market, where shares are openly traded.
Securities: includes stocks, shares, debentures (issued by a company having a share capital),
notes, units of stock issued in place of shares, options on stocks or shares or on such debentures,
notes or units, and rights thereto, and options on indices of information as issued by a stock
exchange on prices of any of the aforementioned instruments.
Seed Financing/Capital: Generally refers to the first contribution of capital toward the financing
requirements of a start-up business.
Sensitivity Analysis: Technique used to determine the effects on net income or cash flow due to
changes in assumptions (i.e. "what if" analysis).
Service: The act of one person doing for another.
Settlement Value: Rand amount of the final payment in a lease.
Settlement: Procedure for brokers to close off their books on a particular transaction. The client is
expected to pay for his new shares on or before the settlement date and he, in turn, can expect to be
paid (on selling shares) within the same period. (also called the Settlement Period).
Share Capital: Total shares authorized to be issued, or actually issued, by a company.
Shareholders: Owners of one or more shares in a company.
Short Term Assets: Cash, securities, bank accounts, accounts receivable, inventory, business
equipment, assets that last less than five years or are depreciated over terms of less than five years.
Short Term Notes: This is the same as short-term loans. These are debts on terms of five years or
less.
Short Term: Normally used to distinguish between short-term and long-term, when referring to
assets or liabilities. Definitions vary because different companies and accountants handle this in
different ways. Accounts payable is always short-term assets. Most companies call any debt of less
than five-year terms short-term debt. Assets that depreciate over more than five years (e.g. plant
and equipment) are usually long-term assets.
Shotgun: A clause in a shareholders agreement whereby if one party offers to buy out the other at a
certain price, the other party has, within a limited period, the right either to accept the price or buy the
offeror out at the same price.
Sinking Funds: A required annual payment designed to amortize a bond or an issue of preferred
shares. The sinking fund may be held in the form of cash or marketable securities, but generally the
money put into the fund is used to retire some of the securities in question each year.
Sizing: A preliminary guess with a wider degree of tolerance than an Estimate. The tolerance could
be as wide as 50%.
Slack time: Free time that exists between the completion of a predecessor and the start of a
successor.
Small project: A project with 10 or fewer team members.
Page 275 of 283
Spending budget: The approved spending estimate.
Spending estimate: The projected costs of the project.
Spending limit: The maximum amount of money that can be spent on the project.
Splitting Of Shares: At times a share could become too expensive for the private investor, at which
time the company may decide to split or sub-divide the shares into smaller denominations. The aim is
often to make the shares more tradeable and, at times, this increases the share price on positive
sentiment.
Sponsor evaluation: The evaluation of the project by the sponsor.
Sponsor: The person who acts as a liaison between the project leader and the management team,
providing oversight to the project.
Spread: the differential between a bid and an offer price.
Staff effort: The amount of time people inside the organization will spend on the project.
Staff-effort budget: The approved staff-effort estimate.
Staff-effort costs: The commercial rate for each person or sub-project multiplied by the staff-effort
estimate for that person or subproject.
Staff-effort estimate: The projected amount of time that each person or sub-project will need to
spend to complete the project.
Staff-effort limit: The maximum amount of time people inside the organization can spend working
on the project.
Stag: An investor who buys shares in a pre-listing or rights offer with the intention of selling those
shares at a profit as soon as trading starts.
Stage gates: Go/no go decision points within the technical process for a project.
Stakeholder Group: Stakeholders that have similar interests in a project.
Stakeholder: Any person that may have an interest in the process, outputs or outcomes of a project.
Standby Fee: A fee charged on the unused portion of the credit under a revolving credit or line of
credit arrangement.
Starting Year: A term to denote the year that a company started operations
Statement of Changes in Financial Position: A financial document that presents the increases or
decreases in funds of a business for all its accounts broken down under three major headings:
operating activities, financing activities and investing activities.
Statement of Retained Earnings: A financial document that shows how much of the net income of a
business has been retained over a given period of time, and how much has been paid out to the
owners.
Status report: Reports issued during the execution phase of the project that denote if the project is
on track or not.
Page 276 of 283
Steering Committee: A group of people ultimately responsible for a projects success through
monitoring its progress, reviewing its continued relevance to the organisations objectives and
overcoming institutional barriers. In some organisations, may be referred to as a Project Board.
Stock Dividend: A dividend paid in shares as opposed to cash.
Stock Exchanges Control Act Of 1985 (As Amended): an Act of Parliament in terms of which
stock exchanges in South Africa are governed. The Act is administered by the Financial Services
Board.
Subordinated Debt: A non-conventional financing instrument where the lender accepts a reduced
rate of interest in exchange for equity participation.
Sub-project leader: The person who leads the sub-project team through the project management
process.
Sub-project team: The group of people who complete the work of a sub-project.
Sub-project tree: The organisational chart for the project that shows sub-projects, deliverables
within each subproject, and accountability for each subproject.
Sub-project: A subsection of the main project responsible for producing a set of deliverables.
Successor: A deliverable that comes immediately after a predecessor deliverable.
Support: Over time, a stock tends to become attractive to investors at specific prices. When a stock
starts to decline to one of these prices, investors tend to come in and purchase the stock, thereby
halting its decline. When buyers outnumber sellers, the price of the stock tends to go up. This point at
which buyers enter the market is called "support."
Sustainable Growth Rate: The rate of increase in sales a company can attain without changing its
profit margin, assets to sales ratios, debt to equity ratio or dividend payout ratio. It is the rate of
growth a company can finance without excessive borrowing or a new stock issue.
Syndication: A method of selling an investment through the use of a group of companies or

investors.
Tax Rate Percent: As assumed percentage applied against pre-tax income to determine taxes.
Taxes Incurred: Taxes owed but not yet paid.
Team contract: An agreement developed by the team that defines the guidelines that the team will
follow as they work together as a team.
Team process: The process that helps the team work through the stages of team development.
Team Leader: A person assigned to manage a team in order to produce a discrete set of
deliverables within a project.
Team-based tools: Tools that are specifically designed to enhance team participation and that
incorporate the three different sensory learning styles: auditory, visual, and kinesthetic.
Test: The process of checking the outputs of a project against a predetermined set of agreed criteria.
Page 277 of 283
Tick Size: the specified parameter or its multiple by which the price of a security may vary when
trading at a different price from the last price, whether the movement is up or down from the last
price.
Timeline: A length of the entire project, broken down into days, weeks, or months.
Top Down Building: or designing a product by constructing a high level structure and then filling in
gaps in that structure.
Total quality: The management technology that addresses customer focus, prevention, and
assurance of quality.
Tracking project progress: The act of determining if the project is on track to meet the
commitments outlined in the project plan.
Triple constraint: The three interdependent variables in a project: scope, schedule, and cost.
Undepreciated Capital Costs: The tax definition of the value of an asset that is eligible for tax
depreciation.
Undercapitalization: Situation in which a business does not have sufficient equity in its capital
structure.
Unencumbered: Property free and clear of all liens (creditors' secured claims).
Unit Variable Cost: The specific labour and materials associated with single unit of goods sold.
Does not include general overhead.
Units Break-Even: The unit sales volume at which the fixed and variable costs are exactly equal to
sales
Variance: The difference between what actually occurred and what was planned or projected to
occur.
What If Scenarios: Analysis of the economic effect of possible future situations, such as economic
downturns, loss of key customers, changes in interest rates or price levels, or new competitors or
technologies.
Withdrawn/Postponed: From time to time a company will decide that market conditions are out of
favour and not conducive to a successful IPO. There are many reasons why a company will decide to
Withdraw its IPO. Among these reasons are: a simple lack of willing investors at that time, market
volatility, or the emergence of a bear market.
Work process: A set of steps that produces an output or deliverable.
Work Breakdown Structure: A tabular or graphical hierarchical break down of the project work into
related tasks
Working Capital: The excess of current assets over current liabilities. This represents the amount of
net non-fixed assets required in day-today operations.
Write-Off: Debt that cannot be collected and finally written-off as bad. The debt is a loss to the
company, and the greater the level of bad debts, the less likely an entrepreneur will be able to obtain
bank financing. Maintaining bad debts to a minimum is seen as the ability of a company to run
efficiently and to have efficient systems in place.
Page 278 of 283
REFERENCES
Angus, Robert B. Gundersen, Norman A, and Cullinane, Thomas P. Planning, Performing, and
Controlling Projects: Principles and Applications. New Jersey. Prentice Hall. 2003
Bolles, Dennis and NetLibrary, Inc. Building Project Management Centres of Excellence. New York:
AMACOM. 2002.
Bucki, Lisa and Chefetz, Gary. Managing With Microsoft Project 2002. Premier Press. 2002
Cagle, Ronald B. Blueprint For Project Recovery: A Project Management Guide: The Complete
Process For Getting Derailed Projects Back On Track. New York: AMACOM. 2003.
Charvat, Jason. Project Management Methodologies: Selecting, Implementing, And Supporting

Methodologies, And Processes For Projects. New York: Wiley. 2003
Cobb, Nancy B. The Project Management Workbook: Field-Proven Strategies for Managing Your
Greatest Asset. New York: McGraw-Hill. 2003
Cohen, Dennis J and Graham, Robert J. The Project Manager's MBA: How to Translate Project
Decisions Into Business Success. San Francisco, Calif: Jossey-Bass. 2001
Crawford, J. Kent. The Strategic Project Office: A Guide To Improving Organizational Performance.
New York: Marcel Dekker. 2002
Deeprose, Donna and NetLibrary, Inc. Project Management. Oxford, U.K: Capstone Pub. 2002
Devaux, Stephen A. Total Project Control: A Manager's Guide To Integrated Project Planning,
Measuring And Tracking. New York: Wiley. 1999
Dinsmore, Paul C and NetLibrary, Inc. Winning In Business with Enterprise Project Management.
New York: AMACOM. 1999
Dobson, Michael Singer. Project Management for the Technical Professional. Newtown Square, Pa:
Project Management Institute. 2001
Eckes, George. Six Sigma Team Dynamics: The Elusive Key to Project Success. New York: John
Wiley. 2003
Englund, Randall L. Graham, Robert J. Dinsmore, Paul C, and NetLibrary, Inc. Creating the Project
Office: A Manager's Guide To Leading Organizational Change. San Francisco, Calif: Jossey-Bass.
2003
Fisk, Edward R. Construction Project Administration. New Jersey: Prentice Hall. 2003
Flannes, Steven and Levin, Ginger. People Skills for Project Managers. Vienna, Va: Management
Concepts. 2001
Fleming, Quentin W. Project Procurement Management: Contracting, Subcontracting, Teaming.

Flyvbjerg, Bent. Bruzelius, Nils, and Rothengatter, Werner. Megaprojects and Risk: An Anatomy of
Ambition. United Kingdom, New York: Cambridge University Press. 2003
Page 279 of 283
Forsberg, Kevin. Mooz, Hal, and Cotterman, Howard. Visualizing Project Management: A Model for
Business And Technical Success. New York: Wiley. 2000
Frame, J. Davidson. Project Management Competence: Building Key Skills For Individuals, Teams,
And Organizations. San Francisco: Jossey-Bass. 1999
Gould, Frederick E and Joyce, Nancy. Construction Project Management. New Jersey: Prentice Hall.
2003.
Greer, Michael. The Manager's Pocket Guide to Project Management. Amherst, Mass: HRD Press.
1999
Hallows, Jolyon E. The Project Management Office Toolkit. New York: American Management
Association. 2002
Haugan, Gregory T. Project Planning And Scheduling. Vienna, Va: Management Concepts. 2002
Heerkens, Gary. Project Management. New York: McGraw-Hill. 2002
Heldman, Kim. Project Management Jumpstart. San Francisco, Calif: SYBEX. 2003
Hornjak, Boris. The Project Surgeon: A Troubleshooter's Guide to Business Crisis Management.
Newtown Square, Pa: Project Management Institute. 2001
Keeling, Ralph. Project Management: An International Perspective. New York: St. Martin's Press.
2000
Kerzner, Harold and NetLibrary, Inc. Project Management: A Systems Approach to Planning,
Scheduling, And Controlling. New York: John Wiley. 2001
Kliem, Ralph L and Anderson, Harris B. The Organizational Engineering Approach to Project
Management: The Revolution In Building And Managing Effective Teams. Fla. St. Lucie Press. 2003
Knutson, Joan. Project Management For Business Professionals: A Comprehensive Guide. New
York: John Wiley. 2001
Laufer, Alexander and Hoffman, Edward J. Project Management Success Stories: Lessons Of
Project Leaders. New York: Wiley. 2000
Levine, Harvey A and NetLibrary, Inc. Practical Project Management: Tips, Tactics, and Tools. New
York: J. Wiley. 2002
Levy, Sidney M. Project Management In Construction. New York: McGraw-Hill. 2002
Lewis, James P. Project Planning, Scheduling, And Control: A Hands-On Guide To Bringing Projects
In On Time And On Budget. New York, N.Y: McGraw-Hill. 2001
Lientz, Bennet P and Rea, Kathryn P. Breakthrough Technology Project Management. San Diego:
Academic Press. 2001.
Magliolo, J. A Guide to AltX: Listing on South Africas Alternative Exchange. Cape Town. Zebra
Press. 2004
Magliolo, J. Become Your Own Stockbroker. Cape Town. Zebra Press. 2005
Page 280 of 283
Magliolo, J. Jungle Tactics: Global Research, Investment & Portfolio Strategy. Johannesburg.
Heinemann. 2002
Magliolo, J. Richer than Buffett: Day Trading to Ultra-Wealth. Cape Town. Zebra Press. 2007.
Magliolo, J. Share Analysis And Company Forecasting, Struik Zebra Press. Cape Town. 1995
Magliolo, J. The Business Plan: A Manual for South African Entrepreneurs. Cape Town. Struik Zebra
Press. 1996
Magliolo, J. The Corporate Mechanic: The Analytical Strategists Guide. Cape Town. Juta. 2007
Magliolo, J. The Millionaire Portfolio. Cape Town. Struik Zebra Press. 2002
Maitra, Amit K. Internet Solutions for Project Managers. New York: Wiley. 2000
Martin, Paula K. Tate, Karen, and NetLibrary, Inc. Getting Started In Project Management. New York:
Wiley. 2001
Miller, Roger. Lessard, Donald R, and IMEC Research Group. The Strategic Management Of Large
Engineering Projects: Shaping Institutions, Risks, And Governance. Cambridge, Mass: MIT Press.
2001
Miranda, Eduardo and NetLibrary, Inc. Running the Successful Hi-Tech Project Office. Boston:
Artech House. 2003
Murch, Richard. Project Management: Best Practices for IT Professionals. Upper Saddle River, NJ:
Prentice Hall. 2001
Newell, Michael W and NetLibrary, Inc. Preparing For the Project Management Professional. New
York: 2002
O'Toole, William. Mikolaitis, Phyllis, and NetLibrary, Inc. Corporate Event Project Management. New
York: Wiley. 2002
Pinto, Jeffrey K. Trailer, Jeffrey W, and Project Management Institute. Leadership Skills for Project
Managers. Newton Square, PA: Project Management Institute. 1998
Potts, David. Project Planning and Analysis for Development. Boulder, CO: Lynne Rienner
Publishers. 2002
Project Management Institute. A Guide to the Project Management Body of Knowledge. Newtown
Square, Penn., USA, 2000
Project Management Institute. Project Management Experience and Knowledge Self-Assessment

Manual. Newtown Square, Pa: Project Management Institute. 2000
Rad, Parviz F and Levin, Ginger. The Advanced Project Management Office: A Comprehensive Look
at Function And Implementation. St. Lucie Press. 2002
Richman, Larry. Project Management Step-By-Step. New York: Amacom. 2002
Russell, Lou. Project Management For Trainers: Stop "Winging It" And Get Control Of Your Training
Projects. Alexandria, VA: ASTD. 2000
Page 281 of 283
Schuyler, John R. Risk and Decision Analysis in Projects. Newtown Square, Pa: Project
Management Institute. 2001
Seebacher, Uwe G. Template-Driven Consulting: How to Slash More Than Half Of Your Consulting
Costs. New York: Springer. 2003
Shackelford, Bill. Project managing e-learning. Alexandria, VA: ASTD. 2002
Shuster, H. David. Teaming For Quality: The Right Way for The Right Reasons. Newton Square, PA:
Springer, Mitchell L. Program Management: A Comprehensive Overview of the Discipline. West

Lafayette, IN: Ichor Business Books. An imprint of Purdue University Press. 2001
Stevenson, Nancy. Microsoft Project 2002 for Dummies. Indianapolis, 2002
Thomsett, Michael C. The Little Black Book of Project Management. New York. 2002
Turner, J. Rodney and Simister, Stephen J. Gower. Handbook Of Project Management. Aldershot,
England, 2000.
Verzuh, Eric. The Portable MBA in Project Management. Hoboken, N.J: Wiley. 2003
Webb, Alan and Webb, Alan. Project Management For Successful Product Innovation. Brookfield,
VT: Gower. 2000
Webster, Francis Marion and Project Management Institute. PM 101 According to the Olde
Curmudgeon: An Introduction To The Basic Concepts Of Modern Project Management. Newtown
Square, Pa: Project Management Institute. 2000
Williams, Terry and NetLibrary, Inc. Modelling Complex Projects. Chichester, West Sussex, New
York: Wiley. 2002
Wysocki, Robert K. McGary, Rudd, and NetLibrary, Inc. Effective Project Management: Traditional,
Adaptive, Extreme. Indianapolis: Wiley Pub. 2003
Yardley, David. Successful IT Project Delivery: Learning the Lessons Of Project Failure. Boston, MA:
Addison-Wesley. 2003
Yescombe, E. R. Principles of Project Finance. San Diego: Academic Press. 2002
Page 282 of 283
INDEX
Page 283 of 283

tmp13C TMP

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

tmp13C TMP

Diunggah oleh

Hak Cipta:

Format Tersedia

The Guerrilla

Jacques Magliolo, 2007

The Guerrilla Principle: Winning Tactics for Global Project Managers

The Guerrilla Principle: Winning Tactics for Global Project Managers

By the Same Author

The Guerrilla Principle: Winning Tactics for Global Project Managers

The Guerrilla Principle: Winning Tactics for Global Project Managers

PREFACE: SETTING THE SCENE

Lessons Learned: General

ABOUT THE AUTHOR

GUERRILLA PRINCIPLES & THE CASE STUDY

STAGE 1: UNDERSTANDING THE BASICS & PROJECT INITIATION

Common Mistakes: Getting Started

CHAPTER 1: PROJECT DEFINITION & AGREEMENTS

CHAPTER 2: DEFINING KEY ROLES

CHAPTER 3: PREREQUISITES FOR SUCCESS

CHAPTER 4: DEVELOPING PROJECT STAGES

CHAPTER 5: ASSESSING PROJECT VIABILITY

CHAPTER 6: INITIATION & SCHEDULES

Case Study Commentary: Stage 1

STAGE 2: PROJECT PLANNING

Lessons Learned: Planning

CHAPTER 7: PLANNING A PROJECT

CHAPTER 8: PRIORITISING OBJECTIVES

CHAPTER 9: A PHASED APPROACH

CHAPTER 10: ASSESSING CONSTRAINTS

CHAPTER 11: THE TASK LIST

CHAPTER 12: COMMITTING & MANAGING RESOURCES

CHAPTER 13: ORDER & CRITICAL PATH ANALYSIS

CHAPTER 14: SETTING DEADLINES

CHAPTER 15: VALIDATING THE PLAN

Case Study Commentary: Stage 2

The Guerrilla Principle: Winning Tactics for Global Project Managers

STAGE 3: PROJECT EXECUTION, CONTROL & MONITORING

Lessons Learned: Project Execution

CHAPTER 16: ROLE PLAYERS & TEAM BUILDING

CHAPTER 17: THE FIRST MEETING

CHAPTER 18: LEADING EFFECTIVELY

CHAPTER 19: MAKING TEAM DECISIONS

CHAPTER 20: MANAGING INFORMATION, COSTS & PROFITS

CHAPTER 21: COMMUNICATION, HEALTH CHECKS & PROJECT SUPPORT

CHAPTER 22: PROJECT PROGRESS SCHEDULING, TRACKING & CONTROLLING

CHAPTER 23: HOLDING REVIEW MEETINGS

CHAPTER 24: THE CASE METHOD OF DECISION MAKING

CHAPTER 25: RISK MANAGEMENT

CHAPTER 26: DEALING WITH CHANGE

Case Study Commentary: Stage 3

STAGE 4: PROJECT COMPLETION & POST-MORTEM

Lessons Learned: Project Closure

CHAPTER 27: QUALITY, SPEED & CLOSURE

CHAPTER 28: FINALISATION & THE POST-MORTEM

CHAPTER 29: : SELF ASSESSMENT FOR PROJECT MANAGERS

Case Study Commentary: Stage 4

Appendix 1: Project Management Rules

Appendix 2: Project Definitions: Essential information

Appendix 3: Project Scope Template

Appendix 4: Project Initiation Template

Appendix 5: Risk Checklist - Small Projects

Appendix 6: Risk Checklist - Large Projects

Appendix 7: Change Request Sample Form

The Guerrilla Principle: Winning Tactics for Global Project Managers

Appendix 8: SWOT Analysis Template

Appendix 9: Reasons for Potential Project Failures & Successes