+A Guide To The Pmdpro1
+A Guide To The Pmdpro1
22 April 2010
Acknowledgements
This guide would not have been possible without the wise advice and diligent oversight of the
PM4NGOs Working Group. Organizational members of the working group who have supported
PM4NGOs in its work include World Vision International, Oxfam GB, CARE International,
Catholic Relief Services, CAFOD, Plan International, Mercy Corps, CARE, The Nature
Conservancy, Habitat for Humanity International and ACCION international.
The document was developed through the support of a variety of experts who contributed to the
creation, review and editing of the guide. Among these experts, we extend special thanks to
Chris Cattaway, Roger Steele, Bernie Leadbeater, John Fisher, John Davidson, Alan Harpham,
Liz Berryman and Katalin Hanniker whose contributions were invaluable. We also extend our
thanks to the many people who helped map the content of the Guide to the PMD Pro1 to the
certification examinations question banks, including Felipe Chaparro, Lynne Curran, Eric
Verzuh, Anna Kondakchyan, Gretchen Regehr, Rodolfo Siles, Geoff Reiss, Guy Sharrock,
Amos Doornbos, Robert Sweatman, Marie-Laure Curie, David Palasits, Simon Early, Vadim
Usvitsky, Caren Conner, Marian Abernathy, and Terri Ise. Additionally, we recognize the
support of the staff and volunteers associated with the Project Management Institute
Educational Foundation, whose support was central to the creation of the learning materials
associated to the Guide.
We are also indebted to many organizations whose documents and materials were referenced
and adapted for use in the PMD Pro1 Guide. We would especially like to acknowledge Catholic
Relief Services for its invaluable ProPack series, World Vision International for the Learning for
Evaluation and Planning (LEAP) documents, and the European Commission for Aid Delivery
Guidelines, from which case study materials were used extensively in this document.
Furthermore, thanks to the International Institute for Learning, True Solutions Inc. and the
Versatile Company for their generous provision of learning materials and support. A complete
list of references can be found at the end of the document.
Lastly, this activity would not have been possible without the inspiration and support of Richard
Pharro and his team at the APM Group. It was only through their financial, organizational and
technical support that this effort was possible.
John Cropper, Eric Berg, Michael Culligan and Leah Radstone
Page i
Table of Contents
Introduction
iii
Section One
1. The Project Manager
Section Two
1. Project Identification and Design
11
2. Project Initiation
34
3. Project Planning
41
4. Project Implementation
56
66
79
85
88
Page ii
Introduction
The Guide to PMD PRO1 provides an introductory, platform-independent exploration of the
principles and terminology of project management within the context of the international
development sector. It is intended for an audience that includes:
Project managers and team members who are new to project management;
Project managers and team members who are new to the international development
sector;
International development sector professionals who intend to pursue professional
credentials in project management;
Consultants/contract staff operating in the international development sector.
Section Two:
The Phases of the Project Life Cycle
o Project Identification and Design
o Project Initiation
o Project Planning
o Project Implementation
o Project Monitoring, Evaluation and Control
o End-of-Project Transition
Decisions regarding the scope of the PMD Pro1 content have been made based on two
principle assumptions.
Assumption One: Project managers in the development sector share many
fundamental challenges, despite the unique organizational cultures in which they
work.
It is widely acknowledged that the work of development organizations can vary considerably and
that each organization is unique. These differences are a result of many factors, including:
Organizational history
Administrative systems
Donor relationships
Project implementation strategies
Monitoring standards
Program considerations (agriculture, health, microfinance, housing, education)
Page iii
Cultural norms
Geographic areas of operation
Operational context (relief, reconstruction, development, advocacy)
Nevertheless, while there are significant differences between organizations, they all share one
thing in common a culture of management that pervades their work. Development
organizations write project proposals, recruit project officers, implement projects, monitor project
progress, evaluate project impact, and attract support by showcasing project success.
This observation forms the basis of the first underlying assumption of the PMD Pro1 is that
organizations, because of their shared culture of project management, also share common
challenges, risks, and opportunities that can be addressed through improved project
management practices. The PMD Pro1 explores these commonalities, examining the
foundational skills that are will be of practical relevance to project managers regardless of the
specific context in which they work.
Assumption 2: Project managers in the development sector can learn from the
best practices of their colleagues working in other sectors.
The pervasive culture of projects is central to the way development organizations do their work.
This culture of project management is not limited to the field of international development:
sectors such as construction, software development, public works, extractive industries and
others also manage the majority of their work through projects. The international development
sector, like these other sectors, shares the challenges related to:
o delivering project results in the context of time, budget, quality, scope, risk and benefit
constraints;
o managing projects that are often implemented via contractors, sub-contractors and
vendors; and
o identifying potential risks and establishing systems to avoid and address these risks and
ensuring that the intended project benefits are delivered.
Nevertheless, while the culture of project management pervades many sectors, several
characteristics make project management in the international development sector unique and,
at times, especially challenging. For example:
International development projects are responsible not only for delivering outputs, but
also for delivering outcomes that promote social change and behavior change that lead
to improvements in the well-being of the projects target populations.
Page iv
Projects are completed on time, on budget, and within the scope and quality prescribed
by the project implementation plan despite the complex and challenging contexts
within which they are managed.
Beneficiaries receive optimum value from project investments and projects achieve the
objectives and goals to which they aspire.
Projects adapt flexibly to the difficult environments in which they work (i.e. insecurity,
scarce resources, high risks, multiple stakeholders), managing changes that enhance
the ability of the project to achieve its results.
Projects meet the accountability commitments to beneficiary communities, donors and
other key stakeholders.
Page v
Starting from this definition, the project manager is responsible for ensuring the overall success
of the project. This does not mean, however, that the project manager is personally responsible
for completing the project work. In fact, this is seldom the case in the development sector.
Instead, the responsibility of the project managers is to ensure that the work of the project is
carried out. To perform this responsibility, project managers will need to:
Work closely with an array of stakeholders to complete the work of the project. These
stakeholders might include members of the project team, implementing organizations
(governmental, non-governmental and others), contractors, community groups and
others. These stakeholders must work together to design, implement and control all
aspects of the project. Like many sectors, project managers in the international
development sector often are required to manage stakeholders with whom they have no
formal hierarchical relationship. It is not unusual for stakeholders within a single project
to have different ethnicities, languages, cultures and even nationalities. The challenge
of managing groups within this context can be especially difficult.
Design and assign work packages of work to others, monitor their performance and
check the interfaces between them and other work packages.
Ensure that team members understand what they need to do, when it is due, and when
the project manager needs to intervene.
Resolve internal conflicts among the project team. It is ultimately the project manager
who is accountable if a project team has poor morale and is missing deadlines.
Competencies of Effective Project Managers
As one would expect, the skill level a project manager needs to effectively manage a project will
vary in accordance to the size, complexity and risk of the project. Take, for example, the two
projects outlined below:
Page 1
Size
Complexity
Project One
$US 5,000
Objective: Build three
latrines
Activity:
- light construction
Project Two
$US 930,000
Objective: Rehabilitate community health system
Activities:
- construction
- training
- procurement systems
- behavior change
Calendar: three years
Communications:10 communities, ministry of health,
donors, implementing partners
Personnel: Local NGOs, community health workers,
government ministry staff
Quality Norms: multiple standards
Currency fluctuations
Political instability
Funding sources are unreliable
Procurement challenges
Clearly, the two projects above differ substantially in terms of size, complexity and risk.
However, despite these differences, both would benefit from a project-based approach in order
to ensure that:
Nevertheless, while projects of all sizes can benefit from a project-based approach, that does
not mean that all project managers can competently manage any project regardless of size,
complexity and risk. Project managers will need to gain experience and deepen their
knowledge, attitudes and skills in all project management competency areas as the projects
they manage progressively evolve in terms of their complexity, value and risk.
So what are the competencies (knowledge, skills, attitudes and behaviors) that project
managers require to manage successful development projects? While multiple competency
Page 2
models exist for project managers, the PMD Pro1 model organizes competencies into four
areas:
Technical these are often referred to collectively as the science behind project
management. Can the project manager identify, select and employ the right tools and
processes to ensure project management success?
Leadership/Interpersonal often referred to collectively as the art of project
management. For example, how does the project manager communicate, inspire, and
resolve conflict?
Personal/Self-Management the project manager's ability to self-manage. For
example, can the project manager effectively prioritize, manage time and organize work?
International Development Specific the ability to apply the technical,
leadership/interpersonal and personal/self-management competencies in the context of
international development projects. For example, can the project manager identify,
select and employ the right tools and processes that are unique and specific to the
international development sector needs and also within the cultural context of the
project?
In addition to these four general competency areas, project managers should also possess the
competency to work effectively within the culture of their own organization. Can the project
manager navigate his/her specific organizations management framework, organizational
culture, business processes/systems and human resources networks? The organizations
culture defines its identify (brand) and distinguishes it from other organizations managing similar
projects.
Illustrative Elements for Each of the Four Competency Areas
Competency Area
Technical
Illustrative Elements
Leadership/InterPersonal
Proactively manage scope to ensure that only what was agreed is delivered,
unless changes are approved through scope change management
Comprehensively identify the activities required to ensure that project
deliverables are achieved
Manage the overall schedule to ensure work is assigned and completed on time
and within budget
Define and collect metrics to give a sense of how the project is progressing and
whether the deliverables produced are acceptable
Identify, track, manage and resolve project issues
Proactively disseminate project information to all stakeholders
Identify, manage and mitigate project risk
Establish procurement systems to manage materials, contracts and project
logistics.
Ensure that project deliverables are of acceptable quality
Vision the big picture of a project within an organization portfolio
Champion the project (promoting buy-in)
Communicate vision setting reasonable, challenging and clear expectations
for people, and holding them accountable for meeting those expectations
Provide timely and helpful performance feedback to team members
Facilitate team building so that people work together well, and feel motivated to
work hard for the sake of the project and their other team members
Page 3
Personal/SelfManagement
International
DevelopmentSpecific
To succeed, project managers need to develop their competencies in each of these four areas.
As project managers' responsibilities increase from relatively simple projects to more complex
projects, the requisite knowledge, skills and behaviors in each of these competency areas will
need to increase commensurately. Furthermore, one of the most nuanced abilities that project
managers develop over time is the art of knowing what alternatives exist to address a challenge
(budget over-runs, team conflicts, ambiguous roles, shifting schedules, unanticipated risks) and
identifying which competency (tool/skill/process) would be most appropriate to address the
unique needs of each situation.
Managing Projects, Managing Programs and Managing Portfolios
Within the development lexicon, the terms projects, programs and portfolio are used frequently.
The definitions of these terms, however, are seldom consistently used and in many cases the
terms are used interchangeably. In the absence of a rigorous definition of these terms, the roles
and responsibilities of the project manager as they relate to each of these levels of management
are unclear and subject to misinterpretation.
Page 4
Project management is the discipline of planning, organizing and managing resources to bring
about the successful delivery of specific project goals, outcomes and outputs. The primary
challenge of project management is to achieve all of the project goals, outcomes and outputs,
while honoring the preconceived project constraints related to scope, budget, schedule and
quality. The project manager is responsible for ensuring the overall success of the project and
seeing that deliverables arrive on time, on scope, on budget and within acceptable quality
levels.
Program management is the process of managing a group of related projects in a coordinated
way to obtain benefits and control not available through managing them individually. Programs,
unlike projects, are often managed via centralized management which aims to coordinate a
group of projects to achieve the programs strategic objectives and benefits.
Program management is especially important within the development sector because projects
managed via a coordinated program have the potential to realize change (or benefits) that
would be impossible if they were managed separately. Some areas of potential program
alignment include:
1. Geographic Area Projects often work side by side in the same region or throughout
the country, and one of the central concerns of a program manager will be how the
resources of multiple projects working in the same geographic area can be leveraged to
have a greater impact than each would have in isolation. Most frequently, programs
work in a single country, although opportunities exist for multi-country or global
programs.
2. Sector Intervention Areas While projects generally tend to work in a single sector
with a shorter time frame, programs often encompass multiple sectors and work within a
longer time frame.
3. Objectives By coordinating the goals and objectives of multiple projects through a
coordinated program, an organization has greater potential to achieve the higher level
goals towards which it strives.
4. Funding It is not uncommon for single organizations to work with multiple donors in a
single geographic or sectoral area. By coordinating projects in a single program,
organizations can leverage more from its resource base of funding sources.
5. Target populations Organizations often overlap between targeted populations for
projects in different sector areas (health, water, education, etc.). Coordinating these
projects in a program allows the organization to link them via common indicators and
shared resources.
6. Management While the staff of individual projects will focus on implementing the
activities that contribute directly to the outputs and outcomes within their scope, at the
program level, managers will focus on the challenge of coordinating projects, best
leveraging resources of multiple projects, and increasing the impact of the program.
Page 5
Portfolio management oversees the performance of the organizations collection of project and
programs. Portfolios are generally managed by a senior team at the highest level of an
organization or a specific business unit of an organization (regional office or headquarters).
Portfolio management is not concerned with day-to-day project tasks; but focuses instead on
selecting, initiating and managing the overall collection of projects in a way that addresses the
strategic objectives of the organization. Portfolio management often includes choosing which
projects not to do, which to start earlier, or which to stop doing in order to optimize the strategic
fit of the projects being undertaken to fulfill the organizations mission.
Most often, portfolio management is not the responsibility of the project manager. However, this
does not mean that project teams do not need to concern themselves with issues related to
portfolio management. The resources available to invest in projects are often limited or scarce,
and various parts of the organization may be in competition for those resources. The portfolio
management process therefore attempts to prioritize and balance opportunities and risks
against demand and supply for resources in such a way that the organizations objectives are
met. Given this competition for limited resources, project managers and their teams should be
able to articulate where their projects:
Page 6
Section 1: Chapter 2
The Project Life Cycle in the International Development Context
The Project Life Cycle
Many development organizations have developed models that outline their interpretation of the
life cycle of their projects. These project life cycle diagrams, although similar in terms of their
phases and intended purpose, generally differ in terms of design and terminology.
While recognizing that project life cycles differ between development organizations, the PMD
Pro1 concurs that the underlying value of project life cycle models (regardless of their particular
design) is that they serve as a framework that helps to:
1. define the phases that connect the beginning of a project to its end;
2. identify the processes that project teams must implement as they move through the
phases of the project life cycle;
3. illustrate how the project management life cycle can be used to model the management
of projects; and
4. model how projects work within an environment of constraints, where changes to any
one constraint will result in consequential changes to the other project parameters.
For that reason, the Guide to the PMD Pro1 subscribes to a generic project life cycle model for
development projects. That model serves as the framework for the contents of this guide. This
generic project life cycle model is not meant to replace other models, nor serve as a standard
for the sector. Instead, it is a learning aid that helps explain the phases of project life cycle
management, the relationships between these phases and the responsibilities of project team
Guide to the PMD Pro1
Page 7
members through the entire project cycle. The PMD Pro1 generic project life cycle model
includes six phases:
Page 8
Project Design As a result of the challenging environments in which they work and
the complexity of the problems which they aim to address, international development
organizations tend to invest in tools, processes, systems and skills for program and
project design. These investments aim to increase their capacities to assess situations;
analyze data, identify theories of change, formulate objectives, and explain the
underlying logic that might include multiple inter-related projects. These processes often
take place before the official approval of a project and, in some organizations, are
treated as a separate project, with its own set of phases. More frequently, however, the
project identification and design phase becomes a process group of its own and is a
project phase area in itself.
In fact, these areas of project management are of such importance into the culture of project
management that they are known by the acronym DM&E, project Design, Monitoring and
Evaluation. This heavy emphasis on project DM&E in development projects is positive in many
ways. It reflects the commitment of organizations in the sector to fully understanding the
problems they address, the logic behind their intervention and the systems with which they
measure their progress. The heavy emphasis on project DM&E also underscores the
particularly strong capacity international development organizations have in these three areas (a
capacity that is often more deeply developed in the development sector than it is in
organizations managing projects in other sectors).
Nevertheless, while strong DM&E are necessary elements of the project life cycle, they are not
sufficient to assure project success. To succeed, projects must be managed through an
approach that is both balanced and integrated. Organizations must develop their capacity in
each of the project life cycle phases.
This same observation holds for any scenario where a project disproportionately focuses on one
area which is consider of particular importance, while under investing in other critical phases of
the project life cycle. For example, a project could skip over the identification and design phase,
and jump directly into project planning. Other projects might be exceptionally well designed and
planned, but not executed with comprehensive rigor and control.
Page 9
result in seriously challenged projects largely due to a failure to manage the entire project life
cycle through a balanced approach.
The Importance of an Integrated Project Management Approach:
While the project management life cycle is presented as a series of discrete phases with welldefined interfaces; in practice the phases interact and overlap throughout the project life cycle.
For example, the Project Planning and Implementation phases are designed to form a circular
feedback process while the Monitoring, Evaluation and Control phase is ever present in the
background of each project life cycle phase, forming the iterative checkpoint against which all
project actions are compared.
The iterative nature of integrated project
management is central to the project learning
cycle. Based on the Deming cycle, a four-step
problem-solving process typically used in
business process improvement (which follows a
plan-do-check-act sequence), the steps in the
learning cycle correspond to the processes
involved in the phases of the project management
life cycle. For example, the Project Planning
processes corresponds to PLAN; the Project Implementation processes corresponds to ACT;
and the Monitoring and Evaluation processes corresponds to MONITOR, and the Controlling
processes (and updates to the project plan) correspond to LEARN.
Page 10
Section 2: Chapter 1
Project Identification and Design
During the project identification and design phase, project teams and stakeholders
(beneficiaries, implementing partners, and community groups) work together collaboratively and
systematically to:
1.
2.
3.
4.
One of the reasons the project identification and design phase is of such great importance is
because it provides the most cost-effective opportunity to answer fundamental questions about
the project parameters. Where will the project work? Who are the beneficiaries? What are the
deliverables? What is the intervention logic? What are the major risks associated with the
project? What is the underlying project approach/strategy? As the project moves forward in its
Page 11
life cycle there will be other opportunities to revisit these questions. However, once project
implementation begins (staff are hired, activities begin, budgets are allocated, and deliverables
start to become tangible) the cost of changing these project parameters increases and these
changes, in turn, become much harder to manage. Therefore, it is important that the project
manager gather and process data to inform these decisions during the project identification and
design phase and that the general approach to this phase is one that is open to creative
exploration, brainstorming, visioning and debating of strategy.
The project identification and design phase also provides an opportunity early in the project life
cycle for the project team to begin creating the norm of broad participation in its approach and
interactions. During this phase, the project team can introduce participatory approaches aimed
at defining problems, identifying alternatives, deciding strategy and plotting the project logic.
While participatory approaches to project design and development can require more time and
resources, the ultimate results will benefit from the following advantages:
Stakeholders have the opportunity to take control of their own development process.
The ultimate project design will be stronger than it would have been without participation.
Page 12
A sense of ownership exists among communities and stakeholders for the ultimate
project plan and its implementation.
Definitions of need, whether explicit or implicit, are rationing devices that determine who gets
what. Nevertheless, people, as individuals and as members of social and interest groups, have
radically different ideas about what should be defined as a need and what should not. Often,
peoples judgments of need are highly subjective and beyond objective agreement. However, if
needs are vague and ill defined, the intervention will be compromised. While these reflections
on needs identification might seem theoretical, at their core they have real practical significance
and implications particularly for the poor and vulnerable families who stand to gain the most
from successful projects.
Much of the discussion around needs identification evolves from Jonathan Bradshaws 1972
work which identifies four methods of defining and measuring needs:
Felt needs are defined by the individuals or the communitys own perception of need
and any discrepancy between their situation and what they believe it ought to be. A felt
need is likely to be subjective and could be better described as a want. Felt need is
necessarily affected by the knowledge and expectations of the individual, which may be
unrealistic and/or unaffordable. For example, mothers might express displeasure with
the mess and sickly conditions that result from lack of hygienic sanitation but might be
unaware of alternatives that exist to change the current state.
Expressed needs are defined as a felt need that has become a demand from an
individual or a community. Expressed needs refer to what can be inferred about
Page 13
community needs by observation of the community's use of services (like long waiting
lists). For example, families might not only be displeased by the mess and sickly
conditions that result from lack of hygienic sanitation but are now beginning to adopt
systems to dispose of household waste (latrines) and refuse (garbage pits).
Bradshaws thinking on needs identification continues to be influential, relevant and useful.
However, the criteria values should not be used uncritically. As organizations explore a
communitys needs, they will inevitably confront the challenge of ensuring that the needs
identification process is accurate and honest. Often individuals and groups already have an
idea, based upon their observations and experiences, about what type of project or service is
preferred by a particular international development organization. Development organizations
need to guard against dynamics where the incentives lead individuals and groups to present
their needs in ways that are more likely to fit the international development organizations
priorities to ensure that they are selected for participation and benefit. For example, if an
international development organization is known to primarily support water projects, then project
participants are more likely to express their problems and solutions in ways that they anticipate
will fit the potential interventions preferred by that development organization a water project.
Assessments broadly explore a wide number and variety of issues and provide information that ,
when analyzed, will inform priorities and identify interventions that will address the challenges in
a target area. Assessment is an essential first step in the design of a project and is most
commonly associated with the beginning of project design activities. However, assessment
can/should also be conducted when expanding or changing the scope of an existing project.
Regardless of when they take place in the project life cycle, assessments can take many forms,
including (but not limited to) the following:
collecting socio-economic information on the target community (and other stakeholders);
Guide to the PMD Pro1
Page 14
Gathering and analyzing assessments helps organizations reach decisions about whether a
project is needed and what type of project might be most suitable, along with the potential
project deliverables and resources required to achieve them. While assessment is conducted in
the preparation of a project design, it should also enable communities to better understand their
own reality and to explore possibilities they exist to collaborate with other organizations. As
mentioned previously, projects are often implemented through an array of partners, sometimes
fully managed by local partner organizations. The assessment process has the potential to
contribute to both the capacity-building of the implementing organization and to support their
ability to develop project strategies themselves.
When conducting project assessments, three types of data may be used:
Page 15
Care should be used to select the most appropriate (and cost-effective) tools and approaches to
collect information. While conventional wisdom indicates that primary data collection and
quantitative data approaches are preferable to secondary sources and qualitative data, in
practice it is clear that there is a place for multiple data sources and mixed methods in almost
every assessment process.
While primary data collection can be specifically targeted to the precise needs of a proposed
project, collecting primary data can also take a lot of time and money and involve many people.
For this reason, many organizations recommend that the first round of assessment rely primarily
on secondary data, and that subsequent rounds use primary data collection approaches to fill in
the gaps which are not covered by secondary data.
Furthermore, while perceptions often suggest that qualitative data has less rigor than
quantitative data, quantitative approaches often run the risk of raising expectations among local
communities and partners, and can be especially costly. Qualitative data assessments, in turn,
can be rigorous if planned and implemented with expertise, and can uncover revealing insights
into the reasons behind the trends that are identified through secondary and quantitative
approaches.
In the end, a combination of secondary and primary methods (including both qualitative and
quantitative tools) in the same assessment can provide a more comprehensive, integrated
Page 16
picture from which to make decisions. Before starting any assessment, one needs to ask How
will this data be used? If there is no acceptable answer to the question, do not proceed. Time
and resources are too valuable to be wasted in useless exercises. Regrettably, many
assessment exercises have collected extensive primary data which have produced large and
minimally used reports. These reports are a poor use of organization resources, can be an
intrusion on the lives of stakeholders, and create false expectations that can damage important
partner relationships.
As a first step, assessments are performed to broadly explore a wide number of issues to aid in
providing information that will inform priorities. Analysis processes are then conducted to more
deeply probe each of the prioritized issues so that the right information will become available to
guide the rest of the design. More specifically, development projects tend to focus on three
categories of analysis:
1. Stakeholder analysis
2. Problem analysis
3. Objectives analysis
Stakeholder Analysis
The first step in the analysis is to complete a stakeholder analysis. The stakeholder analysis
involves:
Page 17
While there are many tools that contribute to the stakeholder analysis process, two in particular
are especially useful:
Venn diagrams are created to analyze and illustrate the nature of relationships between
key stakeholder groups. A Venn diagram is developed through the perspective of a
single project stakeholder (or a group of project stakeholders.) Each circle in the
diagram identifies a stakeholder involved in the project. The size of the circle used can
help indicate the relative power/influence of each stakeholder, while the spatial
separation is used to indicate the relative strength or weakness of the working
relationship/interaction between different groups/organizations. Venn diagrams are
commonly used as a participatory planning tool with target groups to help them profile
their concept of such relationships.
The image below provides an example of the use of a Venn diagram to identify the power and
influence of multiple stakeholders involved in fishery management in a community that borders
a river. Note that the Venn diagram is portrayed through the perspective of one of the
stakeholder groups, in this case, fishing families. The size and location of the Industry X circle
indicates it is very influential but remote. Using the same logic, the Environmental Protection
Agency is remote and clearly aligned to interests of the industry. Fishing cooperatives
represent the interests of the fishermen and have a close relationship with retailers. The small
size of the circle representing the Fisheries Department indicates it has little influence.
Page 18
The Stakeholder Analysis Matrix uses the outcomes from the Venn diagram (or other
stakeholder influence mapping tools) to further identify, elaborate and communicate the
interests, capacity and potential actions of project stakeholders. Unlike the Venn
diagram, the matrix allows a further narrative that provides additional data concerning
stakeholders, their interests, their influence and potential actions to address the
stakeholder interests.
The table below provides a stakeholder analysis matrix for the fishery management project
introduced in the Venn diagram above. The matrix helps identify ways to engage stakeholders
appropriately so that they can participate meaningfully at all stages of the project life cycle. For
example, the table identifies potential risks to project success that comes from poorly regulated
textile industries. Recognizing this possible threat, the project design team can take steps to
better ensure project success perhaps by meeting with textile industry leaders to negotiate
solutions, or to identify ways to involve them in the project.
Page 19
Stakeholder and
basic
characteristics
Capacity and
motivation to bring
about change
Possible actions to
address stakeholder
interests
Fishing families
20,000 families, lowincome earners, smallscale family
businesses, organized
into informal
cooperatives. Women
actively involved in fish
processing
Maintain and
improve the means
of livelihood
Pollution is affecting
volume and quality
of catch
Family health is
suffering,
particularly children
and mothers
Keen interest in
pollution-control
measures
Limited political
influence, given
weak organizational
structure
Support capacity to
organize and lobby
Implement pollution
Identify and develop
alternative income
sources
Textile Industry
Medium-scale industrial
operation, poorly
regulated and no
unions. Well connected
with ruling party. Poor
environmental record
Maintain/increase
profits
Some concern
about public image
Concern about
costs of
environmental
regulations
enforced
Raise their
awareness of social
and environmental
impact
Mobilize political
pressure to
influence industry
behavior
Strengthen and
enforce
environmental laws
Households
45,000 households
discharge waste and
waste water into river
also used as source of
drinking water and
fishing
Aware of textile
industrys pollution
and impact on water
quality
Want to dispose of
own waste away
from household
Want access to
clean water
Limited
understanding of
the health impact of
their own
waste/waste water
disposal
Appear willing to
pay for improved
waste management
services
Raise awareness
among households
of the implications
of their own waste
disposal practices
Work with
communities and
government to
address water and
sanitation issues.
Environmental
Protection Agency:
Etc.
Etc.
Etc.
Etc.
Page 20
learn more about the strengths/weaknesses of the organizations staff, financial systems,
infrastructure, physical plant, logistics systems, strategic planning, leadership, etc.
Data Analysis
The chances are that the data collected through project assessments have already led the
project team and its stakeholders to focus on what appears to be a central group of key issues.
The data analysis process provides an opportunity to further examine, confirm or adjust this
initial thinking.
A variety of techniques and tools exist to conduct data analysis. Each is designed for a specific
purpose and the project team should select their techniques/tools based on the intended
objective of the analysis exercise. For example, if the task at hand aims to organize or classify
assessment information, a different analysis tool will be required than would be the case if the
objective were to promote more critical thinking by project stakeholders.
An illustrative list of the different analysis tools available to project managers (and examples of
the purposes to which they might be employed) is found in the table below:
Objective
Organize information
Prioritize assessment data
Tool
Vulnerability matrices
Mind mapping
Affinity diagrams
Ranking exercises and matrices
Gap assessment analysis
Mapping
Group discussions
Focus Groups
Workshops
Force field analysis
Problem trees
Each of the analysis tools in this table is important and useful. In practice, however, it is unlikely
that a project team will use all of the analysis tools in each and every project it implements.
Furthermore, it is not within the scope of this document to examine all of the analysis techniques
and tools in depth. Project Managers, however, should feel comfortable:
identifying the different tools that exist that can be used to accomplish the different
objectives that are a part of problem analysis;
choosing the best tool for each problem analysis objective; and
developing (over time) the skills and behaviors needed to use the different problem
analysis tools with a variety of groups.
Page 21
Problem Analysis
Nevertheless, while it is out of the scope of the PMD Pro1 to explore all the data analysis tools
in depth, there is one tool that merits further examination the problem tree. There are several
reasons why the problem tree is especially important when discussing problem analysis in the
context of development projects:
While the problem tree is not the only tool used to conduct problem analysis, it is one of
the most widely used tools among international development organizations.
The output of the problem tree tool is often used as an input when completing the next
steps in the project identification and design process.
The problem tree provides a simplified but robust version of reality, identifying not only the core
problem to be addressed, but also the effects of the core problem, and the underlying issues
and root causes that contribute to the current state.
Problem trees begin with a starter problem that can be either identified via an open brainstorm
process with stakeholders or pre-identified, based on preliminary analysis of existing
information. Once the starter problem is identified, the process of elaborating the subsequent
problem tree is completed (preferably via a participatory group process) using these
instructions:
Problems which are directly causing the starter problem are put below (causes)
Problems which are direct effects of the starter problem are put above (effects)
The guiding question behind the logic of the problem tree is What causes that? If there are two
or more causes combining to produce an effect, they are placed at the same level in the
diagram. Cause-effect arrows are used to connect the levels of the problem tree.
The graphic below illustrates a problem tree of the causes and effects of deteriorating river
water quality. Note that this diagram is a simplified representation of the situation and it is not
uncommon for problem trees to have multiple cause and effect levels surrounding the core
problem. As a result, problem trees often become extremely complex and expensive to
develop.
Page 22
While this section focuses on the use of the problem tree technique for problem analysis, it
should be noted that a viable alternative to a problem-based approach is the appreciative
inquiry technique. Appreciative inquiry is a positive, assets-based alternative that seeks to
identify/analyze the strengths (past and present), successes and potentials as a basis for
moving forward. Development organizations frequently use appreciative inquiry as a facilitation
technique that focuses on the resources and opportunities that exist among communities, rather
than emphasizing the shortages, challenges and barriers that impede development.
Objectives Analysis
Once the problem analysis (or appreciative inquiry process) is complete, the next challenge is to
identify the objectives of the eventual project. As is the case with all steps in the assessment
and analysis processes, there are multiple tools that can be used to complete the objectives
analysis process.
Page 23
One of the simplest approaches to objectives analysis is the objectives tree. In its simplest
form, the objectives tree is a mirror image of the problem tree where each statement in the
problem tree is transformed into a positive objective statement. While the problem tree displays
cause and effect relationships, the objective tree shows the means-to-end relationships. Once
again, using the example of deteriorating water quality, the problem tree would become an
objectives tree that resembles the following:
In practice, objectives analysis is seldom as simple as the objectives tree process would
suggest. While the objectives tree might outline a clear and comprehensive intervention
strategy for a project, it is seldom the case that an organization can implement all the activities
outlined in the tree. At this point, the development organization should consider three critical
strategic questions:
Which elements of the objectives tree will be included in the project intervention?
Which elements will not be included in the scope of the project?
What are the criteria which will be used to make these decisions?
Page 24
These questions will inevitably prove difficult and organizations will be confronted with
numerous alternatives. They will need to make concrete decisions regarding the scope of the
project. Where will the project intervene? What services will be provided? Who will be served?
Consensus on these questions may be elusive and the decision-making process has the
potential to become quite complex and contentious. Consequently, it is important that the
project team clearly identify and prioritize the multiple considerations that come into play when
deciding what will be included in the eventual project, and what will be left out. Generally, these
criteria can be grouped according to the following categories:
Category
Illustrative Criteria
Needs Prioritization
What branches/roots within the problem tree and objectives tree have received
the highest level of emphasis during the assessment/analysis?
Which branches/roots appear to have the highest potential for impact?
External Program
Considerations
Who else is working in the proposed area of intervention? What are their
program strengths? What existing activities complement the objectives tree
analysis?
Appropriateness
Institutional Capacity
Resource Availability
Is funding available?
Is there potential for growth?
What opportunities exist to leverage resources?
Financial/Economic
Feasibility
Technical Feasibility
and Sustainability
Internal Program
Considerations
What are the strategic priorities for your organization in the Region? Country?
Other?
What are the program strengths of your organization?
What priorities does your organization have with regard to geography?
Beneficiaries? Other?
Portfolio
Considerations
Does the project fit within the larger portfolio of projects in the organization?
Page 25
Note that the categories above can be organized into two groups. The first group of categories
(needs prioritization, external program considerations, appropriateness, institutional capacity)
uses the information collected through the needs assessment and analysis activities to decide
whether/how an organization will intervene. These categories examine whether there are
priority needs that must be addressed; whether there are other programs providing
complementary services; whether there implementing partners who have the capacity to
execute the project; and whether the proposed activities are appropriate.
Once it is clear which proposed project objectives meet the criteria in the table above, the highlevel project design can be put in place. As indicated previously, not all branches and roots in an
objectives tree will be included in the project. Those areas that do not meet the criteria will fall
out of the intervention mix.
Returning to the river water quality example, in that scenario the components of the project
design was influenced by a number of considerations that included:
Based on these considerations, the decision was made for the project design to focus on
hygienic sanitation facilities and increased awareness of the dangers of waste dumping. This
strategic decision is illustrated thorough the alternatives tree which communicates the
outcomes, objectives and goals (see the lighter colored boxes in the image below) which the
Page 26
organization intends to pursue. The alternatives tree also communicates which elements will
not enter into the scope of the project (the darker colored boxes in the image).
There are a number of variations of logical frameworks models that are used in the development
sector. Many of these models use different terms to identify the project deliverables. Some
Page 27
identify goals and objectives, others identify Results and Outcomes. Similarly, there is no
consensus on the number of levels in a logical framework matrix. Some organizations
subscribe to a four-levels matrix, others have five.
The table below serves as a resource for comparing the logical framework models of several
international donors and development organizations. The table is especially effective when
identifying differences in the number of levels in each model, and variances in the use of
terminology.
Goal/Impact
Program Goal
Overall Objective
Overall Goal
Purpose/Outcome
Project Final Goal
Project Purpose
Intermediate Goal
Component Objective
Intermediate Objective
Specific Objective
Purpose
Goal
Purpose
Strategic Objective
Intermediate Result
Impact/Goal/Development Objective
Outcome/Purpose
Program Goal
Project Goal
Outcome
Output
Output
Expected Result
Output
Output
Output
Output
Output
Work Program/Task
Activity
Input
Activity
Input
Activity
Input
Activity
Input
Activity
Input
Process/Activity
Input
Activity
Input
Nevertheless, while there are variations between logical framework models with regard to the
terms and their structure, they are all intended to serve the same underlying purpose. Logical
frameworks are intended to serve as:
systematic tools for organizing the project thinking and identifying relationships between
resources, activities, and project results;
a visual way of presenting and sharing the project intervention logic;
a tool to identify and assess risks inherent in the proposed project design; and
a tool for measuring progress through indicators and sources of verification.
While there are many versions of project logical frameworks, the PMD Pro1 certification
subscribes a four-level model of logical framework that employs the following vocabulary:
Page 28
1. Activities are actions taken through which inputs (financial, human, technical, material
and time resources) are mobilized to produce the deliverables (training, constructing,
etc.) of a project for which staff can be held accountable and which, when aggregated,
produce outputs.
2. Outputs are tangible deliverables resulting from project activities. They include
products, goods, services and changes (e.g. people trained with increased knowledge
and skill; quality roads built) that aggregate and contribute to outcomes.
3. Outcomes are what the project expects to accomplish at the beneficiary level (e.g. use
of knowledge and skills in actual practice over time; transportation of goods on
constructed roads over time) and contribute to population-level changes (reduced
malnutrition, improved incomes, improved yields, etc.) that aggregate and help bring
about accomplishment of goals and impact over time.
4. Goals are the highest level desired end results or impacts (transformation,
sustainability, livelihood, well-being etc.) to which the project contributes (the ultimate
objective in many logical frameworks)
Having defined the project goal, outcomes, outputs and activities the next question posed is
What external risks (outside the project's control) could potentially interfere with the projects
causal logic? At each level of the logical framework, there are external factors that may affect
the success of the project. For example, if there is another year of drought, the seeds may not
germinate and so the output (a harvest) may not be realized. Or, if children are getting diarrhea
because of poor drinking water, they may eat more, but they will remain malnourished.
These important external factors should be noted under the assumptions column. You may not
be able to do anything about some of the risks (it is unlikely that a local NGO could stop a war
from breaking out), but it is important to anticipate possible problems. The list of risks and
assumptions may also help to explain why a project did not achieve all of its objectives.
The assumptions define the horizontal logic of the matrix, creating an if-then relationship that
maintains that if the assumptions in each level of the framework hold true then the projects
vertical development pathway is likely to succeed, as illustrated in the following graphic:
Page 29
After objectives have been established and associated risks and assumptions identified, the
final element of the logical framework are the indicators of achievement and means of
verification for each level of the logical framework.
Indicators depict the extent to which a project is accomplishing its planned inputs, outputs,
outcomes and goals. They communicate in specific, measurable terms the performance to be
achieved at each level of change. Indicators also help to remove vague and imprecise
statements about what can be expected from project interventions, measuring them in terms of:
Page 30
Guidelines for indicator development at each logical framework level are listed in the following
table:
Elements
Indicator Guidelines
Once again, returning to the example of the river water quality project, a simplified logical
framework matrix for that project would resemble the table below.
Description
Goal
Improved health of
under-fives
Improved health of
river ecosystem
Improved quality of
river water
Indicators
Incidence of water-borne
diseases reduced by 30%
by 2012, specifically
among low-income
families who live by the
river
Source of
Verification
Municipal hospital
and clinic records
collected by mobile
health teams
Assumptions
Clean river water is
a key determinant of
<5 health status
The Clean River
legislation is
introduced by the
EPA
Page 31
Outcomes
Reduced volume
of fecal waste
discharged into
river
Outputs
Reduced volume
of household
refuse directly
dumped into the
river system
Concentration of e. coli
reduced by 20%
(compared to levels in +
2003) and meets national
health and sanitation
standards by 2012
60% of household fecal
waste is disposed of via
latrines or sewage
connections
Description
Indicators
Quality latrines
constructed and
being used by
community
members
Number of latrines
completed
Number of latrines passing
quality check
Number of women, men,
girls & boys using latrines
regularly
Monthly water
quality surveys
conducted by the
EPA and the River
Authority
Annual sample
survey conducted by
the municipality
between 2009 and
2012
Source of
Verification
Up river water
quality remains
unchanged
Waste water
treatment meets
national standards
Fishing cooperatives
meet obligations to
establish waste
collection systems
Assumptions
Inventory data
reported on the sixmonth progress
report
Raised awareness
will assure latrine
adoption and
continued usage
Activities
Key informant
interviews
Etc.
Etc.
Etc.
Deliver public
sanitation
awareness
campaign
Mobilize
communities for
latrine construction
Prepare
engineering
specifications for
latrines
Locate optimal
sites for latrine
construction
Degree of client
satisfaction with proposed
latrine sites
Etc.
Etc.
Event attendance
records (sign-in
sheets)
Copy of plan verified
Ministry of Public
Works approval form
Map of sites with
rationale statements
documenting client
inputs
Etc.
Etc.
Page 32
Section 2: Chapter 2
PROJECT INITIATION
Nevertheless, regardless of the specific process employed, a formal initiation process provides
a number of benefits:
Generally, initiation processes are most commonly associated with the formal initiation of project
activities. Consequently, within the context of the Project Life Cycle image, it is portrayed as a
discrete phase that falls between the Project Identification/Design Phase and the Project
Planning phases. However, initiation processes can also be established to initiate a particular
Guide to the PMD Pro1
Page 33
phase of a project. Take for example, the Project Identification and Design phase. In the
development sector, organizations often expend extensive amounts of resources (staff,
consultants, money, transportation) conducting assessments, analyzing data and developing
project proposals all before the project is formally approved. Consequently, it is advisable that
initiation processes be established to assure that organizational resources are not spent
exploring a potential project that does not have sponsorship, available resources, or in the
absence of clarity on what steps need to be taken, to move forward in the project identification
and design phase.
Most importantly, in the absence of formal project initiation processes, a project runs the risk of:
Wasting time, money, personnel capacity and organizational capital pursuing a project
that ultimately lacks commitment and support from key decision makers and/or ties-up
resources that could be used to better effect on other projects;
Demoralizing those who have worked hard to produce the proposal;
Creating false expectations and hopes on the part of project participants, teams in the
field and organizational partners;
Damaging the credibility and reputation of the organization.
Page 34
Each of these stakeholders mentioned above will be evaluating the project according to
a different set of criteria and each has some level of authority over go/no-go decisions.
The criteria that might be considered through this initiation process might include:
Managing a large group of stakeholders often takes considerable time and runs the risk
of communications challenges. However, there are also advantages to having so large
a group of stakeholders involved in project go/no-go decisions namely that it ensures
that there is a robust analysis of the concept, resulting from many perspectives, and it
helps assure that there is collective ownership for the project once it begins
implementation.
The number and variety of initiation processes in a single development organization can be
confusing and a source of risk. It is important to document the various initiation scenarios so
that project team members are clear with regard to the decision gates required for each
scenario and project. Despite this complexity and risk, however, the advantages of moving
through progressive decision gates are the following:
Page 35
It maps out the process through which a project needs to be vetted in order to ensure
that it has the support (both internal and external) that is required for the project to
ultimately be approved.
It helps ensure that the organization does not invest extensive amounts of time, money,
personnel capacity and organizational capital in developing project proposals that lack
commitment and support from key decision makers (donors, implementing partners,
decisions makers internal to the agency).
At each of these go/no-go decision gates, the project team develops documents that serve as
initiation deliverables. These initiation deliverables serve as the inputs upon which go/no go
decisions are made.
Page 36
Decision Gate 1: Initial Internal Authorization. In the Delta Project Scenario, the
team needs to solicit internal authorization to expend resources to assess and analyze
data related to community need, stakeholder capacity and potential project logic models.
The initiation deliverable required to receive this green light comes in the form of the
Project Concept Paper, which provides the information required to internally authorize
exploratory assessment and analysis and potential proposal development.
Decision Gate 2: Initial External Authorization. The next step in the Delta Projects
initiation process is to explore whether there is initial support from the donor for the
proposed project idea. In this scenario, the organization develops an Expression of
Interest document to submit to potential donors. This document (which serves as the
initiation deliverable for the initial external authorization of the project) is intended to
serve as a high-level overview of the project and is not supposed to be expansive in
depth or detail. The document should be developed in a relatively short time period
using limited resources, and is intended to start a conversation with regard to the highlevel design of the project, and to receive feedback for the project BEFORE considerable
resources are devoted to develop a more expansive project proposal.
Decision Gate 3: Donor Funding Approval. In the Delta River Project Scenario, the
primary initiation deliverable required to receive external funding approval for the project
is the project proposal.
paper and the expression of interest, is designed to receive approval for a request for
funding for a project. It should be clear and precise in describing the project outcomes
and include sections describing the project logic, the project monitoring plan, the project
implementation schedule and the project resource requirements.
The project proposal development process can vary considerably depending on the size
of the project, the donor requirements, the context of the intervention (emergency, nonemergency, etc.) and the amount of documentation which was already developed during
the project identification and design phase. For example, during the project identification
phase, many projects will have already developed a comprehensive logic expressed in a
logical frameworks vertical and horizontal logic allowing them to speed through
Page 37
proposal development. Other projects that will not have completed a thorough logical
framework will need to develop a proposal. Large projects often need weeks or months
to prepare requiring significant time to develop budgets, and employing a range of
consultants (internal and/or external to the organization) to help in identifying the project
activities, resources and timeframes.
The Project Charter identifies documents and communicates the parameters of the project.
The project charter can take on various formats, but generally it serves to ensure that there
is shared understanding of, and commitment to, the project parameters among key project
stakeholders and sponsors (both internally and externally). The parameters of a Project
Charter are usually written from a relatively high-level perspective and include:
Project Purpose including a statement of the need the project will address.
Project Deliverables articulating the scope of the project, including the project
goal, outcomes, and major outputs.
Project Risks identifying potential problems/risks that the project might encounter.
Page 38
The project charter should also include statements with regard to the tolerances set
regarding project deliverables (and their quality), schedule, cost and risk. Furthermore, an
initial statement on exception handling processes should be established for when the project
exceeds a tolerance in any of these areas.
It is important to recognize that the decision gate sequence for the River Delta Case Study
represents just ONE of MANY sequences that could exist for a development project. For
example, some donors require the submission of a letter of interest before you are approved to
develop a project proposal. In this scenario, the letter of interest would represent yet another
decision gate.
Furthermore, some organizations do not include the project design activities for a project within
the context of the project life cycle. In these situations, the project identification and design
processes comprise a completely separate project (with a full and distinct project life cycle). In
this scenario, the project design would be complete, and there would be no requirement for an
Assessment and Analysis Authorization decision gate in the initiation process.
The important message to consider when discussing decision gates is ensuring that the project
team is clear about the importance of getting the necessary stakeholders on board.
Revisiting the Initiation Process throughout the Project Life Cycle
Once a project is formally initiated via the charter document, conventional wisdom would argue
that the initiation phase is complete. However, this is not the case. As a best practice, project
teams should revisit the initiating process at the start of each phase (or at major benchmarks in
the implementing process) to keep the project focused on the need that the project was
originally undertaken to address, and to ensure that the context and assumptions that initially
led to the approval of the project still exist. This is especially important for large or complex
projects.
Some organizations and/or donors require that annual implementation plans be submitted for
their multi-year projects, outlining operations for each year of the project. These annual
implementation plans serve not only to ensure that the project work estimates are accurate and
relevant, but also serve as decision points. The review and approval process for the annual
Page 39
plans serves as an opportunity to verify that the assumptions which served as the foundation of
the project, as well as to confirm the availability of required resources, assess the external
project context/risks, and monitor the vertical logic of the project. Based on the results of this
review, a decision is then made whether or not the project should continue, or whether the
project should be delayed, revised or discontinued.
Repeating the initiating processes during subsequent project phases also enables the project to
be halted if the need no longer exists or if the project is deemed unable to satisfy that need (or if
more beneficial uses for the projects resources exist). While it would be natural to consider that
a halted project is a failure, it is important to remember that a halted project will succeed in
ensuring that additional resources, time and money are not allocated to a project for which there
is no longer a need, or whose implementation is no longer feasible.
Page 40
Section 2: Chapter 3
Project Planning
It is important, however, not to confuse the project proposal, the project logical framework, or
other documents developed during project identification and initiation phases with a project plan.
These documents differ substantially in terms of the format, purpose, audience, level of detail,
participation, timing, and schedule constraints.
Page 41
Take, for example, the project proposal. The table below outlines differences between the
project proposal and the project implementation plan in terms of the purpose, format, and level
of detail (note that a similar comparison could be made between the project logical framework
and the project implementation plan).
Purpose
Format
Level of
Detail
Participation
Audience
Timing and
Schedule
Project Proposal
To obtain approval and funding for
the project, emphasizing clear,
concise, communication of ideas
that sell the project to funding
stakeholders
Format is often determined by
donor requirements or agency
stakeholders responsible for
investment decisions
Often limited in level of detail due
to the purpose, format, anticipation,
schedule and timing of proposal
Often written by a small team as a
result of time constraints that limit
participation
Focused on donors and
stakeholders who distribute
resources
Often written under tight time
constraints, sometimes months (or
even years) prior to implementation.
Nevertheless, while there are considerable differences between the purpose, process and
content of a project proposal and a project implementation plan, many development
organizations use the project proposal as an implementing plan. This is especially the case
where the proposal format is based on donor-driven requirements that result in proposals that
approximate project plans in terms of length and level of detail. Beware even the most
expansive project proposals (and many can exceed 100 pages in length), still have weaknesses
that limit their effectiveness in terms of planning for project implementation.
Page 42
1.
2.
3.
4.
The indirect work of the project is often overlooked or underemphasized during the creation of
the project logical framework, the project proposal and other initiation deliverables. The indirect
work, however, is indispensible to project success. Examples of these planning required to
complete the indirect work of the project include:
Project Coordination Planning How will the different stakeholders work together?
What are the norms for collaboration? Are roles and responsibilities clear?
Project Communication Planning How will the project team update stakeholders?
When are progress reports due? What communication mechanisms will be used? Who
is responsible for communications?
Project Procurement Planning What process and systems exist for acquiring
equipment and materials? What procurement benchmarks need to be met in order for
the schedule to succeed?
Project Human Resources Management Planning What is needed to hire, brief,
manage and train project staff?
Project Monitoring and Evaluation Planning Who is responsible for collecting data,
processing data, analyzing data, documenting results and communicating messages?
When will these activities take place? How will data be used?
Project Control Planning What procedures need to take place to change the project
implementation plan? Who has authority to make changes? How will they be
documented? Are there compliance requirements that constrain the project teams
ability to make changes to the project scope, budget or schedule?
Project Transition Planning What steps need to be taken at the end of the project?
What activities need to take place for administrative and contract closure? Will the
project be phased over to other stakeholders? If so, what investments need to take
place to ensure the handover is successful?
Page 43
As indicated previously, the format of implementation plans can vary considerably. In some
cases, the elements of the comprehensive plan are all included in a single project
implementation plan document. In other cases, the project implementation plan is made up of
multiple documents. In these scenarios, the core project plan is complemented by separate
plan(s) that provide a deeper level of detail on a specific area of project planning. For example,
a project might have both a core implementation plan AND a specific plan for Project Monitoring
and Evaluation. Similarly, depending on the size, complexity and risk of a project, a team might
choose to have separate documents that specifically address Project Procurement, Project
Communications, Project Human Resource Management, etc. Each of these plans should be
consistent with (and linked to) the other documents that make up the comprehensive project
implementation plan.
Implementation Planning is Detailed
Regardless of the format of the project implementation plan, it is important that the plan be
detailed. Plans should be adequately decomposed (to decompose means to separate or break
down project deliverables into smaller elements, components or parts), so that the people
responsible for completing the work of the project are clear about what needs to be done, when,
with what resources, and according to what parameters. The project implementation plan
should attempt to decompose the work into manageable units the size of which is determined
predominantly by the risk, complexity and value of the task, and the competency of those to
whom its management will be delegated by the project manager.
The intention of the project implementation plan is to provide a model of the project. It provides
the project team members a low-risk, low-cost environment to build out project alternatives;
identify what if scenarios; and consider alternative approaches BEFORE project resources
have been expended and before time has passed.
While some argue that the project logical framework and/or the project proposals are acceptable
implementation models, these documents seldom provide a sufficient level of detail to
implement a project. The documents are written for different purposes altogether. Logical
frameworks are designed to model the project logic. Project proposals are written with the aim
of obtaining project approval and funding resources. By comparison, the purpose of project
implementation plans is to serve as a comprehensive and detailed model map for the successful
implementation of the project. To accomplish this purpose, comprehensive project plans must
Page 44
provide details regarding all the activities and resources required to complete both the direct
and indirect work of the project.
Examples where project implementation plans tend to provide much more detail than project
proposals include the planning for much of the indirect work of the project:
Project Proposals are often developed by small teams of people. Given that the
audience of project proposals are usually the stakeholders that have authority over
funding decisions (external donors or groups internal to the organization), the project
proposal development team is often more focused on how best to sell the project and
is staffed by people who are best at writing and navigating the proposal submission
process. This can result in a diminished focus on communication and collaboration with
key stakeholders in the proposal development process.
Page 45
For all these reasons, it is important that the project teams take advantage of the opportunity
that the project implementation planning process offers to engage stakeholders more
extensively and comprehensively than was possible during the project identification and design
phase of the project.
The project planning process should involve all appropriate stakeholders, depending upon their
influence on the project and its outcomes. Participation in the planning process has multiple
advantages, including:
1. Stakeholders have skills and knowledge that can be leveraged when developing
accurate estimates regarding budgets, time requirements, levels of effort, and other
resources required for completing the work of the project.
2. Project stakeholders are often in the best position to identify potential project risks and
make plans to mitigate their impact.
3. Providing an opportunity for new staff or partner staff to be oriented through detailed
planning even if they did not participate in the original project design work. This helps
ensure a common understanding of the outcomes, outputs and activities and contributes
to the initial team-building dynamic.
4. Stakeholders involved in the project planning process are more likely to assume
leadership, ownership and buy-in of project implementation activities.
Implementation Planning Embraces Iteration
Once the project has been formally initiated, the planning process provides the opportunity to
double-check that the proposals scope of activities, schedule, staffing and budget are up-todate and accurate. In the development sector, as in the private and public sectors, there is
often a delay between the original design and project start-up. As a result, project proposals
and project logical frameworks are often months, or even years, old before the project activities
begin. In comparison, project implementation plans are developed only after the project is
formally initiated and can be conducted based on the most recent information regarding
changes in risks and external circumstances (like the impact of changing currency rates on
project implementation). This helps to ensure that the implementation plan is up-to-date and
accurate.
Page 46
Furthermore, throughout the project, it is important to treat the implementation plan as a living
document, not one that is static and unchangeable. Notice that the generic project life cycle
diagram expressly represents the project planning phase as part of a loop with the
implementation phase. The activities in the implementing phase are continually providing
insights and learning that informs and updates the project implementation plan. Similarly, the
information you collect from the monitoring, evaluation and control processes also influences
and improves the project plan.
Over time, changes to the project implementation plan help provide greater detail on schedule,
costs, and resources required to meet the defined project scope. This iterative process of
providing increasing levels of detail to the project implementation plan over time is often called
rolling wave planning. Iteration, by definition, is the act of repeating a task a second, third or
more times to achieve a desired result.
Nevertheless, while the iterative nature of project planning is very positive, it is also important to
ensure that any changes to the project implementation plan over the life of the project are:
In the development sector, there are two commonly adopted approaches to controlling changes
to the implementation plan:
1. Project changes (cost, time, quality or otherwise) are documented and communicated
through a control process that keeps key stakeholders updated about changes and any
associated issues.
2. Projects subscribe to a planning model that includes periodic updates of implementation
plans (yearly or otherwise). Using this approach, agencies revisit the project
implementation plan at the beginning of each project period to:
Page 47
to update and revise the activities, timelines and resources of the project to ensure
that they accurately reflect the current project situation and external operating
context.
Subsequent chapters in Section Two of the guide will explore a number of additional tools and
techniques that can be used for project coordination planning (the RACI Matrix), human
resource planning, communications planning (the communication plan), project monitoring and
evaluation planning, and end of project transition planning.
Project managers in the development sector who are interested in learning more about
additional tools and techniques related to project implementation planning are encouraged to
continue their professional development through the pursuit of an internationally recognized
project management credentials. These professional certifications (PMIs CAPM/PMP, the
OGCs Prince2 Foundation/Practitioner, or comparable) further examine the knowledge, skills
and attitudes required to successfully plan projects in all areas of project implementation.
Using the WBS to Define Project Scope
In a project, the term scope can refer to:
product scope the full set of features and functions that characterize project results;
or
project scope the work required to deliver project results according to their specified
features and functions.
During the Project Identification and Design Phase and the Project Initiation Phase considerable
work will have been completed to identify the product scope. At the time of beginning a
Planning Phase many projects have already produced an objectives tree, a logical framework, a
concept paper and a relatively well elaborated project proposal. Combined, these documents
are likely to have sufficiently defined the product scope, including goals, objectives, outcomes
Page 48
and outputs. While even greater detail is likely to be added to the product scope during the
course of the Planning Phase, development sector organizations will have already done a
relatively good job of identifying and documenting the parameters related to product scope.
On the other hand, while the Project Identification and Design Phase and the Project Initiation
Phase may provide a relatively well developed product scope, there will typically have been less
emphasis on the project scope. During the planning phases, the project scope must be defined
and described in detail so that project stakeholders can execute the work required to
successfully deliver project outcomes and outputs.
The WBS (or Product Breakdown Structure in PRINCE2) is the principle tool that project
managers use to plan the project scope. The WBS is a hierarchical decomposition of the work
of a project. Put simply, the WBS arranges the project scope in an outline or hierarchy of work
packages. The WBS can be used to:
Page 49
The graphic format is good for showing the relative levels of the work and how smaller
components of the project roll up into larger ones. For presentation purposes, this format also
facilitates adjusting the depth of detail that is appropriate for various audiences.
In the end, preferences that the project team and the stakeholders have for interpreting
information are most likely to influence the WBS format. Some people can process data more
easily when they view it graphically; others prefer lists. It is sometimes a good idea to create
both: an indented format to guide a team with greater detail, and a graphic diagram for briefing
senior management and contractors.
WBSs can also differ significantly in their number of levels. While there are no rules that identify
the number of levels, the WBS must be detailed enough so that the sub-deliverables can be
successfully controlled and monitored. Furthermore, the WBS should be comprehensive,
including all activities required for project success, including management activities that are
Page 50
frequently omitted in project proposals and logical frameworks (project start- up, project
planning and control, stakeholder training, communications, reporting, and project closure.)
A further use of the WBS after its construction can be to group work packages into contract
packages and to produce a Contract Breakdown Structure. This applies both to work packages
delegated to external stakeholders as well work packages implemented by internal resources
that are not in the direct project hierarchy. Each work package should be totally clear with
regard to its required inputs, what outputs are expected, the duration of the package, the
earliest and latest start and finish, and the accountability norms for its delivery to the project
manager. The project manager can then focus on the interfaces. Who needs what from whom
to get their package(s) started? What is the effect of a delay in delivery on other packages
awaiting outputs as the inputs to their package(s)?
Scheduling Project Activities
Delivering projects on time is one of the biggest challenges faced in project management and
schedule issues are the main reason for conflicts on projects. Project scheduling is often
perceived as a single process that is conducted simultaneously when the project calendar is
developed. Schedule planning, however, includes a series of distinct processes, where each
process employs unique tools/techniques. The steps in the schedule planning process include:
Page 51
The image below illustrates a simplified network for a latrine project. Some of the messages that
can be interpreted from the design of the diagram include:
The project team must wait for the latrine cap to be built before it can be installed.
The project team does not need to await completion of the latrine cap before digging the
latrine hole.
The training activities can be completed independently of the latrine construction
activities.
Time If there is a very tight timeframe, the project may choose to dedicate high levels
of staff, materials and capital equipment to meet time constraints. Conversely, if the
Page 52
timeframe is loose, the project may choose to dedicate lower levels of resources
allocated to an activity.
Budget If money is in short supply, the project might choose to invest in a low cost
resource mix. For example, more manual workers and less machinery are a preferable
low-cost alternative. This resource decision, however, will extend the duration of the
latrine excavation activities.
Regulations In some countries, projects are constrained by labor laws that limit work
schedules (hours per day, days per week, holidays per year, family leave policies).
These regulations influence resource availability and consequently duration estimates.
Page 53
Now the network diagram is complete and can be used to help the project team identify:
The Projects Critical Path The critical path is the series of tasks that determines the
minimum amount time required to complete project activities. In the latrine project
example, the critical path is the series darkly shaded tasks. This sequence of tasks
represents the longest path between the projects start and its end (in this case 25 days).
The Project Float (or Lag) In project management, float or slack is the amount of time
that a task in a project network can be delayed without causing a delay to project
completion date (total float). In the latrine project example, there is zero float on the
critical path. However, the latrine cap construction activities could be delayed up to 11
days without impacting the project schedule. Similarly, the training activities could be
delayed by up to 23 days without impacting the project schedule.
Schedule Development
Based on the estimate generated through the previous steps, the project team can now develop
a project schedule. Within the development sector, the preferred tool for project schedule
development is the Gantt chart. A Gantt chart uses bars to graphically represent the schedule
of project activities, including their start date, end date, and their expected durations. Gantt
charts have the advantage of being relatively easy to read and to use for presentations.
The complexity and comprehensiveness of the Gantt Chart will vary. The broader, more
comprehensive activities of a project can be scheduled via a summary Gantt Chart, with details
being further elaborated on a detailed schedule.
Page 54
ACTIVITIES
1.1.
1.1.1
1.1.2
1.2
1.2.1
1.2.1.1
1.2.1.2
1.2.1.3
1.2.2
1.3
1.3.1
10
11
Page 55
12'
Within the implementation phase the project manager, working with the project team, is
responsible for the following activities:
Launching the project
Coordinating roles and responsibilities
Directing and managing project implementation
Managing communications
Managing the project team
Managing issues and risk
Managing organizational capacity.
Launching the Project
The purpose of the project launch is to:
When identifying the stakeholders with whom the project team should communicate at the
project implementation, special attention should be given to identify individuals and groups who
are critical to the project success. These stakeholders might include community members,
government officials (both political officials and ministry employees), and other development
organizations working in the project intervention area.
Page 56
Concept Note
Who is
responsible?
Who is getting
things done?
Doing the work
associated to
the task?
Lead
Project Manager
Assist
Implementing
organization
Who is
accountable?
Who signs off on
the deliverable
associated to the
task?
Who needs to be
consulted?
Who needs to be
actively solicited for
input?
Project Manager
Technical Advisor
for Sanitation
Who needs to
be informed?
Who needs to
be kept abreast
through copies
of reports, email, etc.
Ministry of
Health (MOH)
officials
Page 57
Design
Assessment
Analysis
Logical
framework &
M&E Planning
Proposal
Writing and
Submission
Lead
Project Manager
Assist
Implementing
NGO
Implementing NGO
Technical Advisor
Project Managers
Local Employers
Project participants
Local MOH officials
Donor
MOH officials
(national level)
Lead
Project Manager
Assist
Implementing
NGO
Implementing NGO
Technical
Advisor for AIDS
Project Manager
HQ Business Team
Project
Participants
Detailed
Program
Planning
Lead
Project Manager
Implementing
NGO
Implementing NGO
Project Manager
Local employers
MOH officials
(national level)
Implementation
Lead
Project Manger
Implementing
NGO
Implementing
NGO,
Project participants,
Project Manager
Project participants
Local MOH officials
Technical Advisor
for Sanitation
Donor
Program officer
Monitoring and
Evaluation
Lead
Program Officer
Donor
Project participants
Project officer
Regional Technical
Advisor
MOH officials
(national level)
Donor
Once developed, the RACI matrix is shared with project stakeholders in order to help ensure an
understanding, and expectations, of project roles and responsibilities. It is then used to
manage the contributions of stakeholders throughout the project life cycle.
Managing Project Implementation
The day-to-day work of project implementation is to lead and manage the implementation of the
project, ensuring that the project implementation plan and its associated documents are
delivered according to plan, are monitored closely and are revisited as issues and risks are
identified. Within the professional discipline of project management there are tools, skills and
processes that exist to help project managers develop comprehensive and appropriate
documents that are essential to the successful implementation of the project.
A few of the many original reference documents used to lead and manage project
implementation are listed below. Note that the number and variety of documents implemented
during this phase vary by organization, donor and project.
1.
2.
3.
4.
Page 58
Page 59
The project teams work has already made significant progress in steps 1 and 2 through the
stakeholder analysis and RACI activities. Steps 3 and 4 of the communications planning
process, however, need to be thought through more extensively. Choosing the right
communications vehicles involves identifying which communications method matches the
projects messages and stakeholders. As a guide, here are several questions to ask when
determining which mechanisms to use for project communication:
Which mechanism or vehicle will increase the likelihood that the message will be actually
received, understood and acted upon?
How much information will be included and at what level of detail?
Which mechanism is most appropriate for the type of message?
Which mechanism does the stakeholder prefer?
What level of interaction is required (one way or two way)?
Purpose
Audience
Author
Assigned
To
Communication
Vehicle
Frequency
Page 60
Acquiring Project Staff As part of the function of managing the team, the project
team leader must be clear on the systems for identifying staff candidates, interviewing
candidates, identifying selection criteria and making final selections of project staff.
Identifying Project Staff Assignments Project staff assignments are the list of
project duties, roles and responsibilities for team members. Staff assignments are often
used during the monitoring and controlling process to evaluate individual team members.
Documenting Project Organization Charts Project charts represent the reporting
relationships among the project team.
Developing Project Staff What skills are needed? What are the training needs? Are
there certification requirements? What are the compliance issues?
Conducting Performance Assessments Performance assessments are the
documented formal or informal assessment of the project team members performance.
After analyzing the information, project managers can identify and resolve problems,
reduce conflicts, and improve overall team work.
Promoting a Highly Productive Team Environment As the leader of the project
team, the project manager must actively work to identify issues and conflicts and work
creatively to resolve these issues.
Many of the activities involved in managing the project team (implementing the project staffing
plan, acquiring staff, identifying staff assignments, documenting organizational charts) are
technical in nature often described as the science of managing the project team. The skills,
attitudes and behaviors required to promote a highly productive team environment, however,
depend on the project managers ability to move beyond the science of project management
and engage in the art of the discipline. In order to promote a highly productive team
environment, the project manager must be skilled in communicating vision, encouraging shared
ownership, moving agendas within and outside the organization, and managing situations where
there is no direct hierarchical authority.
Managing Issues
Even projects that are comprehensively planned, fully resourced and meticulously executed will
encounter issues. An issue is a risk that has now occurred (the topic of risk management will be
discussed in the next chapter). An issue might be an unresolved decision, situation or problem
that will significantly impact the project. The project manager needs to be ready throughout the
project implementation phase to apply resources to address and resolve these issues.
Issues Management is a collaborative endeavor. Consequently, everyone on the project team
is responsible for the following:
Page 61
job of the project manager to establish an environment in which each team member is in
a position to resolve as many issues as possible at their level).
Escalating important issues to the Project Manager as soon as possible.
As an issue manager, the Project Manager needs to manage all four basic processes in the
issue management process:
1. Issue Identification and Tracking Identifying outstanding questions, decisions and
other problems before they adversely affect the project. As such, the issue identification
and tracking process is closely related to the topic of risk management (which is
explored in the Monitoring, Evaluation and Control chapter of this document.) Thus, the
implementation phase and the Monitoring, Evaluation and Control phases are tightly
linked and normally work in parallel.
2. Issue Analysis Understanding the issue sufficiently to consider future consequences
of action plans made to resolve it.
3. Issue Communication Communicating issues and their resolution to the right level of
the organization to get them resolved, or to prevent them from escalating into risks.
4. Issue Control The project manager is responsible for establishing an environment
where the project team and implementing partners can carry out actions to ensure
issues are resolved in a timely and effective manner.
The issue control process is closely related to project monitoring, evaluation and control (see
the next section) and should include establishing and tracking a plan for getting issues resolved.
The most important control tool is the issues log, which summarizes the issues, their current
status and who is currently responsible for addressing them. The issues log can take on a
variety of technical forms from paper to a fully integrated database. A sample format can be
found below.
Issue Log
Issue
Reference
Report
ed By
Description
Date
Reported
Assigned
To
Date
Assigned
Status
Status
Date
Page 62
By the end of the project there should be no outstanding issues left to resolve. This does not
mean that every issue can be dealt with during the project. It may be that some concerns cannot
be dealt with and appropriate responses should be made to those concerned. Other issues may
be deferred, or addressed in a future project. Bear in mind that a perfect issues management
system may be expensive, if not unachievable. It is normal to accept a reasonable level of
imperfection, based on calculations of the trade-offs between value versus cost, benefit, risk
and time.
Managing Organizational Capacity
Within the context of the project implementation process, the project team and any
implementing stakeholders need to have the capacity (technical, material, financial,
administrative and managerial) to implement the project strategy and its related activities. As
indicated in Chapter 1 of this section, many organizations conduct organizational capacity
assessments during the Project Identification and Design phase. When managing the
organizational capacity of implementing stakeholders, these assessments can be used as a
baseline for managing capacity issues. The project team should keep three questions in mind
as they manage the organizational capacity of stakeholders:
What materials (vehicles, computers, other) financial, human and managerial capacities
already exist and are they sufficient to implement the proposed project strategies?
Which of these capacities already exist but need to be increased or expanded to
implement the proposed project strategies?
Are there additional capacity-building objectives that need to be included in the project
design?
When managing organizational capacity, care should be taken to comprehensively address the
entirety of the support, administrative and logistic system required for successful
implementation, including:
Page 63
One method used to identify and manage organizational capacities is called spider diagrams.
The spider diagram resembles a web, where each of the axes of the the web correspond to an
element of organizational capacity. The axes can include any number of elements, including
(but not limited to) leadership, relationships, organizational focus, good governance, etc. The
axes of the spider diagram are adaptable, and should reflect whatever is important with regard
to the capacities required for the project.
The image below is a spider diagram which measures the organizational capacity of an
implementing partner involved in the River Delta Project. This completed spider diagram can
serve the following purposes:
Page 64
Page 65
Section 2: Chapter 5
Project Monitoring, Evaluation and Control
Even projects with exceptional planning, optimal resources and rigorous implementation will not
automatically achieve their desired results. Throughout the project life cycle,
challenges/problems/issues will arise and it is the responsibility of the project manager to keep
control of the project to the end. Fortunately, there are indispensible tools that assist the project
managers efforts to ensure that the project are tracked, measured and controlled.
These tools can generally be organized into four categories:
Page 66
It is important to remember that the project implementation plan is a model of how the project is
expected to progress. The Monitoring, Evaluation and Control processes continually compare
actual performance to the project implementation plan (variance analysis). When variance is
found, the project teams needs to analyze the cause of the variance, identify potential corrective
actions, and implement changes to realign the model (project implementation plan) with the
reality of the project context. Changes are first made to the project plan so that consequential
implications on other aspects of the project can be considered. When the project team and other
stakeholders are confident that the proposed actions will have the desired effect, the revised
project plan is approved and communicated. Work then continues according to the revised
plan.
Both these questions are best answered by revisiting the structure of the logical framework. You
will recall that the PMD Pro1 subscribes to a four-level model of the logical framework while
recognizing that other models exist.
Monitoring activities primarily correspond to the lower two levels of the project logical framework
(activities and outputs) and also correspond to the inputs required to execute the project
activities. These activities differ from evaluation activities in their purpose, frequency and
approach. The table below provides a summary of the what, why, when and how of project
monitoring:
Project Monitoring in the Development Sector
What
Why
Page 67
When
How
Project evaluation activities primarily correspond with the upper two levels of the logical
framework (outcomes and goals). Data at the outcome level is collected and analyzed less
frequently and often requires a more formal intervention (often by technical advisors or external
evaluators) to show project results. The frequency with which this information is monitored is a
project management decision and depends on the resources (money, time and staff) that the
project plans to invest at this level of data collection and analysis. While project evaluation
activities might include reviews of progress at the first two levels of the logical framework
(activities and outputs), the more ambitious (and fundamental) objective of the evaluation will be
to measure the outcome and goal levels of the logical framework.
Project Evaluation in the Development Sector
What Gathering and analyzing information to determine:
- Progress towards delivery of activities/outputs; and
- Contributing to achievement of outcomes/goals
Why
To measure project effectiveness
To determine whether outcomes have been achieved
To learn how well things are being done
To learn lessons for future improvement
When Periodically (the frequency depends on the resources the project is willing to invest)
typically there are midterm, end-of-project and post project evaluations
How
Internal evaluation
External evaluation
Note: Even though project monitoring and evaluation have been presented as unique, the two
measurement approaches meet, merge and overlap at the intersection of outputs and outcomes
in the logical framework. It is sometimes appropriate to monitor outcome level indicators and, at
other times, to include output level indicators in evaluation processes.
With regard to the question of why project evaluation is central to project management in the
international development sector and less prioritized in other sectors, recall that the project
logical framework approach is unique to the international development sector. Few project
managers working in other fields assume responsibility for changes at the outcomes and goals
Page 68
levels, so they normally assess projects by monitoring the input, activity and output levels
letting others assess whether their projects deliver the impact at the outcomes and goal levels.
2. Schedule and
budget
3. Staff/partners
4. A Full CRSAF
Data Cycle
5. Data
Management
6. Link to the
next level
Clearly defined
Baselined
Systematically measured
Time and money are allocated for monitoring tasks
Schedule details processes for data collection, review, summary, analysis,
and feedback
Clearly identified monitoring responsibilities
Competencies
Plan monitoring activities with the community
Build capacity of community members on community-based monitoring
systems
Use participatory monitoring techniques
Gather and verify monitoring data
Process monitoring data
There is a full cycle from data collection to discussion of results with partners
C = Collection
R = Review
S = Summary
A = Analysis
F = Feedback
Procedures exist and are used to ensure integrity of data
Proper storage of data
The project monitoring system is linked to the next level in the system
Page 69
Page 70
Indicators
Info Needed
Sources of
Data
Methods of
Data
Collection
Who
Collects
Frequency
of
Collection
Users
Goal
Outcomes
Outputs
Activities
Inputs*
* Note that some monitoring and evaluation plans not only track the progress against the activities, outputs, outcomes
and goals that are consistent with the project logical framework, but also monitor the inputs that are required to
implement project activities.
The primary purpose of indicators at the output and activity levels is to ensure the day-to-day
operations of the project are on track. It is important that indicators include a check that the
output has been produced to the specified/acceptable quality and is complete, as well as simply
confirming its existence. Potential problems are identified so that corrective action can be taken
when necessary, and quality maintained. Monitoring these indicators provides feedback to
implement corrective or preventive actions to bring the project into compliance with the project
management plan or, if necessary, to modify the project management plan appropriately.
Agriculture Example
Number of farmer groups
farmers created
- competence of trainees
Activities Tasks or
Microfinance Example
Number of clients
receiving and correctly
using credit
Number of clients
participating in savings
programs
Number of staff visits to
Water Example
Number of new
water systems
installed and
properly functioning
Number of
Page 71
actions taken to
implement project
interventions
farming communities
Number of training
sessions organized
villages
Number of bank training
sessions
- competence of trainees
communities
organized for water
system installation
Agriculture Example
% of families who produce
enough food to cover lean
periods
Decreased % of
malnourished children
Microfinance Example
Increase in net
household income
Positive change in
household consumption
patterns
% of families adopting
improved techniques
% of hectares covered with
improved techniques
% of households with
increased working
capital
Water Example
Reduced morbidity
and mortality from
water related
diseases
% of households
using safe water
supply
Increase in per
capita consumption
of water
*Note While projects are expected to contribute to the achievement of the goal level indicators, it is NOT
the responsibility of the project to achieve (or to monitor) the goals.
What is the acceptable level of cost and complexity for data collection?
The cost and complexity of data collection can vary considerably based on the
method of collection used to collect the information. The graph below provides a
comparison of multiple data collection methods (quantitative and qualitative) in terms
of cost and complexity.
While there are many considerations (budget, resources, staff, donor requirements,
etc.) to keep in mind when selecting the most appropriate data collection methods for
Page 72
project monitoring, the primary determinant for monitoring the project (cost and
complexity) should be improvements that will result from better data.
Risk Management
Description
Indicators
Means of
Verification
Assumptions
Goals
Outcomes
Outputs
Activities
Page 73
Project risk is the possibility that something may go wrong, or at least not turn out as planned.
Risks are different for each project, and risks change as a project progresses. Project-specific
risks as they might appear in the assumptions column of the logical frameworks could include
the following:
Does the government policy/priority support the project strategy and goals?
Are there new investments/developments in the project area that could impact project
objectives?
Will changes in the socio-cultural context affect the project?
Are there changes in the political/security situation?
Is the economic situation stable (exchange rates, banking systems, devaluation risks)
What are the relationships with key stakeholders like?
Could the project lose key employees?
Are vendor availability and skills reliable?
The goal of risk management is to gain control over these risks; and to identify, analyze and
respond to risks in a cost-effective way. Risk management seeks to maximize the probability
and consequences of positive events and to minimize the probability and consequences of
adverse events. In practice, project risk management focuses on the following questions:
Preparing a project-level risk management strategy helps ensure that the process is effectively
carried out. Key elements of the project risk management process include the following:
Risk identification (identifying and documenting all the risks that can affect the project);
Qualitative risk analysis (determining the consequences of identified risks on project
objectives);
Quantitative risk analysis (assigning numeric probabilities to risks and their impact on
project objectives);
Risk response planning (deciding what actions are needed to reduce or remove threats,
particularly high-probability, high-impact ones); and
Risk monitoring and control (responding to risks as they occur and ensuring proper risk
management procedures are being followed).
Page 74
Once identified, risks should be managed using a combination of the following strategies:
Risk Avoidance Do not do (or do in a different way) some portion of the scope that
carries high-impact and/or a high probability of risk if project objectives can still be
accomplished. Examples: limit the geography if a certain area is problematic; or reduce
the number of delivered items, such as latrines, if the project is short of building
materials.
Risk Transference Shifting the risk (or sharing the risk) for some aspect of project to
another party through a contract, insurance or other means. Example: logistics
contracts in an insecure area are sub-contracted to private vendors with more
knowledge and experience of the area.
Risk Mitigation Taking specific actions to reduce the probability and/or impact of a
potential risk. Example: institute a security system that prevents unauthorized access to
project building material storage areas.
Risk Acceptance If a risk is assessed as reasonable, an organization can choose to
not take action right now and commit to monitoring the situation to see whether
probability and impact remain acceptable. Example: a community may acknowledge
that they face a risk of seasonal mudslides, but choose to live with the probability and
consequences of a mudslide rather than attempt to avoid, transfer, or mitigate them.
Risk is present throughout the entirety of the project. Therefore, it would seem intuitive that risk
be managed during every project life cycle phase. In practice, however, projects tend to invest
in risk identification and risk management early in the project design cycle and then fail to
monitor and manage these risks as the project evolves. International development projects
often identify a limited list of project risks during the development of assumptions for the project
logical framework, but fail to recognize the importance of continuing to manage risk as the
project moves through subsequent life cycle phases.
All too often, project managers and team members get caught up in the day-to-day tasks of
implementing new projects and forget the critical need to step back and reassess probable risks
or to be alert to any new risks that have arisen and ensure that additional steps are taken to
avoid or mitigate risks as necessary.
In the absence of continuing, iterative risk management, project managers will find themselves
in a situation where project risks are assessed as being out of the control of the project and fail
to proactively manage the risks whether they be bad weather, political disruptions,
procurement problems, exchange rate fluctuations, or any of the many other risks endemic to
international development projects. Risk identification is ongoing, not just at the start of the
project.
Page 75
Finally, while risk exists throughout the life of a project, the probability that impact will occur, and
the impact of potential risks, can vary considerably depending on the project life cycle phase of
the project.
Early in the project life cycle, risk probability (the likelihood a risk will occur) is higher, mainly
due to the number of unknown factors and uncertainties that exist. As the project moves
through the life cycle, however, risk probability decreases as the number of uncertainties and
unknown factors diminish. Risk probability over the project life cycle is illustrated in the
following graphic, where risk probability is inversely related to the progression of time.
While risk probability is higher during the early phases of projects, the impact of risk is likely to
be less severe at that time. This is in part because during the early stages of the project, there is
much less to lose as a result of project risk. Project investments have been relatively low and
there is much more flexibility to make changes and deal with risk. Conversely, as the project
moves into the later phases, the impact of risk becomes much more serious. In effect, the
project has much more to lose. This is attributed to the fact that, as time passes, significant
resources have likely been already sunk into the project. Furthermore, there is less flexibility in
dealing with risk later in the project, and more resources may be needed to resolve problems.
The following image illustrates the inverse relationship of risk probability and risk impact as the
project progresses through the life-cycle processes.
Page 76
Page 77
It is important that the implications a change may have on all sections of the project
management plan be properly considered before the change is implemented. This will usually
require a review by experts familiar with each of the areas (scope, cost, schedule, risk,
procurement, etc). When it is agreed that the proposed change is beneficial and that the
implications are acceptable, the change should be approved, usually by the project manager or
by the project sponsor, depending on the scope and scale of the change and their limits of
authority. When the change is approved, the revised project plan should be communicated to
the entire project team so that everyone now works to the same (revised) plan. Donors often
specify whose approval is required to make certain types of changes to a project plan after it
has been approved.
Page 78
Section 2: Chapter 6
End of Project Transition
A project, by definition, is a temporary endeavor, having a defined beginning and end (usually
constrained by date, but possibly by funding or deliverables). The temporary nature of projects
differentiates them from normal business operations of an organization (or on-going
operations, which are repetitive, permanent or semi-permanent functional work to produce
products or services). In the international development field, however, it is not unusual to find a
project that has been in operation for years with one phase of the project continuing the work
of the previous phases. This observation underscores that reality that the end of a project in the
international development sector is often more aptly characterized as a transition phase rather
than as a strictly defined project closure. In practice, there are four end-of-project transition
scenarios that exist for development projects. These four scenarios are presented in the table
below:
Page 79
*Termination could also include phasing over or transferring the project activities to a local
partner, institution or community.
Unfortunately, while project transition is of great importance, it is often overlooked and/or underresourced. With pressures to move on to new projects and reassign staff members to other
activities, the most practical way to ensure a complete project closure is to include it in the
project plan. Note that this phase is typically called closure in project management literature.
When planning for the end of the project, the project manager should focus on five major
responsibilities:
1. Articulate and Execute the Endof-Project Transition Strategy
An end-of-project transition plan describes how a project intends to withdraw resources while
ensuring that progress towards goals will continue. A transition plan may include several
scenarios or contingencies that address risks and may also allocate additional resources when
it may not be possible to exit entirely. The international development sector considers transition
especially important because of their concern that impacts be sustained after the project has
ended. Most international development organizations also pursue sustainability as a central
component of their internal values and external image.
Page 80
plan for the ongoing sustainability of the project is the Transition Planning Matrix as detailed
below, which is highly recommended.
Component
1. Plan for
transition from
earliest stages
of ID and
Design
2. Develop
partnerships
and local
linkages
3. Build local
organizational
and human
capacity
Mobilize local
and external
resources
4.
5. Stagger phase
out of various
activities
Key Questions
Guiding Principles
Challenges
Ongoing project
review and revision
Balancing firm
commitments with flexibility
Transparency;
especially funding
relationships to
evolve after
transition
Build on existing
capacity if possible
Create environments
to support capacities
Procure resources
locally where possible
Increasingly bring
external resources
under local control
Flexibility; staggering
sequence may
change upon
implementation
Prevent slippage of
projects intended
results by including in
extended, expanded
or redesigned project
The project implementation team meets to crosscheck work completed against the
project implementation plan. There may be, for example, activities that were delayed
early in the project and never performed later.
Meet with the key stakeholders (donors, community groups) to:
Review accomplishments against the project plan, and then get their acceptance
documented by some kind of formal acknowledgement or acceptance.
Page 81
Make sure they are satisfied, not just with the technical aspects of the project, but
also with the overall outcomes (this is often as much about perception as it is about
the existence of outputs and achievement of outcomes).
organization will perennially reinvent the wheel each time a decision is made to pursue a similar
project. Donors are often interested in assuring that learning is disseminated throughout the
sector to ensure that new projects benefit from learning generated by other projects they have
funded. Nowadays, NGOs often publish evaluation reports, and databases exist which include
thousands of evaluation reports from many different organizations.
A learning review, also called an After Action Review, is a simple, quick and versatile learning
activity that can be used to identify and record lessons and knowledge arising out of a project.
Page 82
Learning reviews are relatively straightforward to organize and implement. During the review,
questions are asked that help participants understand what was planned versus what actually
happened:
The advantage of a learning review is that it can collect useful information relatively quickly and
without expending extensive resources. The facilitation of the review is intended to be quick,
open and not focused on deep thinking and discussion. The primary intent is to inform
decisions on operations, policy, or strategy related to ongoing or future program interventions.
An evaluation, as compared to a learning review, is often far more formal, collecting information
that will permit judgments about the projects overall success and value. Common evaluation
questions include:
Did the project succeed at accomplishing the outcomes, goals and impact desired?
Was the project relevant, effective and efficient?
Does the project have the potential to be sustainable in its operations and impact?
Is the theory expressed in the logical framework upheld?
Organizations must choose what evaluation approach they intend to implement based on their
learning objectives. Two evaluation approaches that are extensively used in the international
development sector are the final evaluation and ex-post evaluation. A final evaluation, often
mandated by a funding agency or required by a development organizations own policy, would
be conducted towards the end of project. An ex-post evaluation examines project impact at a
defined period of time after project completion, sometimes a year after the official close of the
project. Sometimes called a sustainable impact evaluation, an ex-post evaluation measures the
extent to which project outcomes and impacts have been realized through participant
ownership. Ex-post evaluation findings can be an especially useful way of using evidence to
advocate an improved development approach. For example, an ex-post report was used by
one international development organization to help convince a donor to support numeracy and
literacy training within a microfinance program.
5. Celebrate Accomplishments
Guide to the PMD Pro1
Page 83
Mirroring the purpose of the project launch described as part of the project initiation phase, a
project manager should appropriately celebrate and formally acknowledge the project transition
by:
recognizing the efforts of team members;
acknowledging the contributions of key stakeholders to the project; and
expressing appreciation to individuals and groups who were critical to the project
success.
Recognition of the project accomplishments within the organization and to the outside world
may also help facilitate positive public relations and prepare the way for future business
opportunities.
Page 84
Appendix 2
Glossary of Terms
Activities
The actions taken through which inputs (financial, human, technical, material
and time resources) are mobilized to produce deliverables (training,
constructing, etc.) of a project for which staff can be held accountable and
which, when aggregated, produce outputs
Asset-based
A simple, quick and versatile learning activity that can be used to identify and
record lessons and knowledge arising out of a project
Assumptions
Baseline
Blooms Taxonomy
Capacities
Certificate
Competencies
Concept Note
Credential
Critical Path
The sequence of activities that represents the longest path between the start of
the project and the projects end
Decision Gate
Major control points used to conclude and accept the products for a particular
phase of the project and to move on to the next phase
Decompose
DM&E
Page 85
Gantt Chart
Goal
Initiation
The process of describing and deciding to begin a project and authorizing the
Project Manager to expend resources, effort and money
Impact
The significant effect or longer-term result (identified with the outcomes and
goal levels in many logical frameworks)
Inputs
The resources the project must mobilize and apply to project activities (human
and financial resources, equipment, etc.)
International
Development
Organization
Issue
A risk that has now occurred. It can take the form of an unresolved decision,
situation or problem that will significantly impact the project
Iteration
The act of repeating a process for a second, third or more times to achieve the
desired goal, target or result
Network Diagram
Outcomes
What the project expects to accomplish at the beneficiary level (e.g. use of
knowledge and skills in actual practice over time; transportation of goods on
constructed roads over time) and contribute to population-level changes
(reduced malnutrition, improved incomes, improved yields, etc.) that aggregate
and help bring about accomplishment of goals and impact over time
Outputs
Portfolio
Portfolio Management
Program
Project
Page 86
Project Charter
A document that describes the project at a high level of detail and which is
used to authorize the Project Manager to begin work
Project Control
Project
Implementation Plan
Project Management
Project Manager
The responsible person who plans organizes and manages resources to bring
about the successful completion of specific project goals, outcomes and
outputs.
Project Proposal
A clear and concise offer that seeks approval from a potential funder for
delivery of products and/or services in response to donor requests or
anticipated needs
Risk
Rolling Wave
Planning
Product Scope
The full set of features and functions that characterize project results
Project Scope
The work required to deliver project results according to their specified features
and functions
Stakeholders
Any person or group who has a vested interest in the success of the project
can include clients, sponsors, family, friends and the general public
WBS
Page 87
Appendix 2
Reference List
Blackman, Rachel, 2003, Project cycle management, Teddington: Tearfund.
Boston University Corporate Education Center, Project Management Competency
Development Process.
Britton, Bruce, Heaney, Deborah, Sterne, Rod, 2001, The Partnership Toolbox, London:
WWF.
Council of Europe and European Commission, 2000, Project Management T-Kit, Strasbourg:
Council of Europe publishing.
Dearden, Philip N., 2001, Programme and Project Cycle management (PPCM): Lessons from
DFID and other organizations, Tokyo: CIDT.
Deming, W. Edwards, 1986,. Out of the Crisis, Boston: MIT Center for Advanced Engineering
Study.
Department for International Development (DFID), 2002, Tools for Development version 15,
DFID, Impact Assessment & Project Management Cycle (PMC).
Emergency Capacity Building Project (ECB), 2007, Impact Measurement and Accountability in
Emergencies The Good Enough Guide. London: Oxfam Publishing.
Erwin, James, Smith, Michael L., Role & Responsibility Charting (RACI).
European Commission, 2004, Aid Delivery Methods volume 1 Project Cycle Management
Guidelines, Brussels: European Commission.
Foundation Terre des Hommes, 2001, Project Cycle Handbook, Le Mont-sur-Lausanne:
Foundation Terre des Hommes.
Gardner, Alison, Greenblott, Kara, Joubert, Erika, 2005, What We Know About Exit Strategies
Practical Guidance For Developing Exit Strategies in the Field, C-SAFE Regional Learning
Spaces Initiative.
GB Equal Support Unit, A Project Cycle Management and Logical Framework Toolkit A
practical guide for Equal Development Partnerships, Herefordshire: Local Livelihoods Ltd.
Geyer, Yvette, 2005, Project Management, Pretoria: IDASA.
GTZ, Manual of Project Management for Development Practitioners.
International Fund for Agricultural Development (IFAD), Participatory Approaches for an
Impact-Oriented Project Cycle
International Fund for Agricultural Development, 2002, A Guide for Project M&E, Rome:
IFAD.
Levine, Carlisle J., 2007, Catholic Relief Services (CRS) Guidance for Developing Logical
and Results Frameworks, Baltimore: CRS.
Lipczinsky, Malte, 1996, Getting to Know PEMT, Berne: SDC, Evaluation Section.
Page 88
McMillan, Della E., Willard Alice, 2006, Preparing for the Evaluation Guidelines and Tools for
Pre-Evaluation Planning, Baltimore: CRS.
Mercy Corps, 2005, Design, Monitoring and Evaluation Guidebook, Portland: Mercy Corps.
Novartis Foundation for Sustainable Development, Project Management Handbook, A
Working Tool for Project Managers.
Pataki, George E., Dillon, James T., 2003, McCormack Michael, Project Management,
Guidebook Release 2, New York: New York State Office for Technology.
Picard, Mary, 2001, Course Materials for the Design, Monitoring and Evaluation (DME)
Course, Kosovo: CARE.
Plan International, 2002, Project Management Methodology
Project Management Institute. 2004. A Guide to the Project Management Body of Knowledge:
PMBOK Guide Third Edition.
Rugh, J. 2002, Comparisons between Terminologies of Different Donor Agencies for Results/
Logical Frameworks, Atlanta: CARE International and InterActions Evaluation Interest
Group.
Saldanha, Cedric D., Whittle, John F., 1998, Using the Logical Framework for Sector Analysis
and Project Design: A Users Guide, Manila: Asian Development Bank.
Siles R. 2004, Guidelines for Planning, Implementing and Managing a DME Project
Information System. Atlanta: CARE.
Standish Group. 1995. The Chaos Report. Boston: The Standish Group.
Stetson, G. Sharrock, and S. Hahn, 2004, Propack The CRS Project Package: Project Design
and Proposal Guidance for CRS Project and Program Managers. Baltimore: CRS.
Stetson, S. Hahn, D. Leege, D. Reynolds and G. Sharrock, 2007, Propack II The CRS Project
Package: Project Management and Implementation Guidance for CRS Project and Program
Managers. Baltimore: CRS.
The Centre for Development and Population Activities, 1994, Project Design for Program
Managers, Washington, D.C.: The Centre for Development and Population Activities.
United Nations Environment Programme, 2005, UNEP project manual: formulation, approval,
monitoring and evaluation.
VCP, 2003, Facts for Projects (draft version).
Verzuh, Eric, 2008, The Fast Forward Project Management-Third Edition, New Jersey: John
Wiley & Sons, Inc.
Wheelwright, S.C., Clark, K.B. 1995, Leading Product Development: A Senior Manager's
Guide to Creating and Shaping the Enterprise, New York: Free Press.
Wideman, Max, 2001, Project management Simply Explained A Logical Framework to Help
Your Understanding, Vancouver: AEW Services
World Bank, 2006, Managing the Implementation of Development Projects New Edition.
World Vision Development Resource Team, 2007, Learning through Evaluation with
Accountability and Planning: World Visions Approach to Design, Monitoring and Evaluation
(LEAP) Second Edition, Washington, DC: World Vision International.
Page 89
World Vision Development Resource Team, 2009, LEAP Lexicon Second Edition,
Washington, DC: World Vision International.
Youker, Robert, 1989, Managing the project cycle for time, cost and quality: lessons from
World Bank experience, Butterworth & C. (Publishers) Ltd.
Page 90