Proposal Writing

Program Management Manual
January 2012
Table of Contents
Chapter 1: Introduction and Contextual Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Certification Requirements for Mercy Corps Program Management Personnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. What is Program Management?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. The Program Manager’s Role and Generally-Accepted Knowledge/ Competency Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Chapter 2: The Program Lifecycle and Minimum Standards Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Definition of Each Phase within Mercy Corps:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Key Aspects of the Program Management Lifecycle at Mercy Corps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Minimum Standards Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Mercy Corps Internal Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Chapter 3: The Program Identification and Design Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Introduction to New Program Development at Mercy Corps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Identification of Program Ideas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Funding Opportunity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Assessment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Program Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Program Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.7 Proposal and Budget Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 4: The Set Up and Planning Phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1. Program File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2. Stakeholder Management Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Program Work Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 End of Program Transition Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5 Program Technical Requirements and Partnerships Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6 Work Breakdown Structure (WBS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.7 Team Requirements and Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.8 Program Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.9 Program Budget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Chapter 5: The Program Implementation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. Launching the Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2. Managing Program Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3. Program Tracking and Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4. Manage Program Human Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5. Managing Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.6. Managing Organizational (Portfolio) Capacities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Chapter 6: Monitoring and Evaluation (M&e). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1. Introduction to M&E at Mercy Corps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2. M&E in Program Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3. M&E at Program Set Up and Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.4. M&E at Program Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Chapter 7: End-of-program Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.1. Types of Program Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2. Updating and Communicating the End-of-Program Transition Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3. Donor Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Annexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Annex 1: Stakeholder Register Template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Annex 2: Is / Is Not Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Annex 3: Tip Sheet: Creating a Work Breakdown Structure (WBS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Annex 4: Tip Sheet: Creating a Schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Annex 5: Tip Sheet: Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Annex 6: Example Process: Creating an Activity Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Annex 7: Sample Kick-Off Meeting Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Annex 8: Sample Baseline Schedule Tracking Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Annex 9: Program Team Training Needs Assessment Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Annex 10: Program File Contents Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
mercycorps.org < Table of Contents

Acronyms and Abbreviations
BVA. . . . . . . . . . . . . . . . . . Budget vs. Actuals

CD. . . . . . . . . . . . . . . . . . . Country Director
CDP. . . . . . . . . . . . . . . . . . Capacity Development Plan
CoP. . . . . . . . . . . . . . . . . . Chief of Party
CPI . . . . . . . . . . . . . . . . . . Cost Performance Index
CV. . . . . . . . . . . . . . . . . . . Curriculum vitae
DM&E. . . . . . . . . . . . . . . . Design, Monitoring and Evaluation
DoP. . . . . . . . . . . . . . . . . . Director of Programs
FAM . . . . . . . . . . . . . . . . . Field Administration Manual
FFM . . . . . . . . . . . . . . . . . Field Finance Manual
GAIT. . . . . . . . . . . . . . . . . Grant and Award Information Tracker
GIS . . . . . . . . . . . . . . . . . . Geographic Information System
HF. . . . . . . . . . . . . . . . . . . High Frequency
HR. . . . . . . . . . . . . . . . . . . Human Resources
ICT. . . . . . . . . . . . . . . . . . . Information and Communications Technology
INGO. . . . . . . . . . . . . . . . . International Non-Governmental Organization
IT. . . . . . . . . . . . . . . . . . . . Information Technology
M&E. . . . . . . . . . . . . . . . . Monitoring and Evaluation
MOU. . . . . . . . . . . . . . . . . Memorandum of Understanding
NCE. . . . . . . . . . . . . . . . . . No Cost Extension
PALM. . . . . . . . . . . . . . . . Procurement, Administrative and Logistical Management
PM. . . . . . . . . . . . . . . . . . . Program Manager
PMBOK. . . . . . . . . . . . . . Project Management Body of Knowledge (Guide of the Project Management Institute)
PMD Pro. . . . . . . . . . . . . Project Management for Development Professionals (guidebook and certification by
PM4NGOs)
PMI. . . . . . . . . . . . . . . . . . Project Management Institute
PMO. . . . . . . . . . . . . . . . . Program or Project Management Office
PMP. . . . . . . . . . . . . . . . . Project Management Professional (PMI certification) OR Program Management Plan
(similar to an indicator plan)
POps. . . . . . . . . . . . . . . . . Program Operations
PRINCE. . . . . . . . . . . . . . Project Management in Controlled Environments
PWP. . . . . . . . . . . . . . . . . Program Work Plan
HQ. . . . . . . . . . . . . . . . . . . Headquarters
RACI matrix . . . . . . . . . . Responsible, Accountable, Consulted & Informed
RFA . . . . . . . . . . . . . . . . . Request for Applications
RPD. . . . . . . . . . . . . . . . . . Regional Program Director
SoW . . . . . . . . . . . . . . . . . Scope of Work
SPO. . . . . . . . . . . . . . . . . Senior Program Officer
SWOT. . . . . . . . . . . . . . . . Strengths, Weaknesses, Opportunities & Threats
ToR. . . . . . . . . . . . . . . . . . Terms of Reference
ToT. . . . . . . . . . . . . . . . . . . Training of Trainers
TSU. . . . . . . . . . . . . . . . . . Technical Support Unit
VHF. . . . . . . . . . . . . . . . . . Very High Frequency
WBS. . . . . . . . . . . . . . . . . Work Breakdown Structure
Mercy Corps exists to alleviate suffering, poverty and oppression by helping people
build secure, productive and just communities. Mercy Corps helps people turn the
crises they confront into the opportunities they deserve. Driven by local needs, our
programs provide communities in the world’s toughest places with the tools and
support they need to transform their own lives.
< Table of Contents mercycorps.org

Chapter 1
Introduction and Contextual Information
Chapter 1: Introduction and Contextual Information

1.1. Introduction
Why Do We Need the Program Management Manual?

The risks of poor program performance – reduced impact, fraud, reputational damage, lost opportunity – are
great. Good program management saves time and increases impact and accountability. It can free country
teams from costly mid-implementation “fixes”; spare us from reinventing the wheel; ease mid-program staff
transitions; and liberate time to pursue ideas, innovate and build strategic partnerships. Through our programs
we are held accountable to communities, donors and the world.
Programs are at the heart of Mercy Corps’ strategy of community-led, market-driven activities in pursuit of our Vision
for Change. This manual and supportive toolkit on Mercy Corps’ Digital Library are designed to assist our field and
headquarters teams and partners to effectively and efficiently manage programs from the Program Identification and
Design Phase through the End of Program Transitions.
Mercy Corps’ core business consists of designing and implementing programs. The Mercy Corps Strategic
Roadmap and regional and country strategies link Mercy Corps programs to our Mission to alleviate suffering,
poverty and oppression by helping people build secure, productive and just communities across the globe. To
meet strategic objectives, Mercy Corps pursues contextually appropriate programs, recognizing that sound program
design and management are the basic building blocks of successful performance. Mercy Corps programs adhere
to principles of accountability, participation and peaceful change, as we believe these principles form the basis for
healthy interactions between stakeholders. We commit to accountability for what we implement (program design)
and how we implement (program management), through transparent, inclusive, disciplined and ethical program
management. Good program management is about delivery and quality – it is about bridging the gap between
strategy and results and ensuring that carefully designed targets are achieved within the time and budget allocated.
Effective program management is an imperative.
The Status of the Program Management Manual within Mercy Corps’ Policy Framework
This manual constitutes a policy, similar to the Field Finance Manual, Field Procurement Manual, or Field Administration
Manual. The contents of the Minimum Standards Checklist described in Chapter 2 are required for any
program over $250,000. These requirements are supplemented by certain
program management certification requirements, as described in section
1.2. The policy applies to any new programs (starting in Fiscal Year 2013,
from 1 July 2012) that meet the aforementioned criteria. This manual provides
Co
e
resources and instruction for meeting the Minimum Standards as well as

Tim
st
additional recommendations for successful program management.

($
Quality
&
This manual is a supplementary document to A Guide to the Project Management

for Development Professionals (PMD Pro) which clearly explains the definitions,
)
processes and requirements. This manual is designed as a “how to” guide for Scope
program management processes in the Mercy Corps context.
The manual is backed by the Program Management Toolkit, which is available
on Mercy Corps’ digital library. The Program Management Toolkit provides templates, forms, tip sheets, examples
and other tools for the processes and Minimum Standards included within this manual. In some cases, chapters are
supplemented by templates, forms, or tools, which are also included within the Toolkit and hyperlinked in footnotes.
The Toolkit will continue to be developed with new resources as the Program Management Manual is adopted
throughout the agency and should be consulted regularly for the most up to date resources to support program
management at Mercy Corps.
Other widely referenced standards are PMI’s PMBOK: The Guide to the Project Management Body of Knowledge1 and PRINCE2: Project
Management in Controlled Environments1.

Chapter 1
Introduction and Contextual Information
What is PMD Pro and How Does it Relate to This Manual?

The Guide to PMD Pro provides an introductory, platform-independent exploration of the principles and
terminology of project management within the context of the international development sector. The Guidebook
was developed through contributions of a variety of international development organizations and with the support
of the Project Management Institute (PMI).2 It is accompanied by a professional certification series.
Mercy Corps has adopted the PM4NGOs A Guide to the PMD Pro and certifications as the foundation for Program
Management at Mercy Corps. This Mercy Corps Program Management Manual adapts the guidance within PMD
Pro to the Mercy Corps environment and is designed to be used in concert with A Guide to the PMD Pro.
1.2. Certification Requirements for Mercy Corps Program Management

Personnel
The following certification requirements apply to Mercy Corps team members in positions considered critical for
program management success:
Team member Certification Requirements Timing

Any team member holding a Project PMD Pro1 Within six months of assuming the
Manager, Program Manager, Chief first relevant position with Mercy
of Party(CoP) or senior operations Corps4
position, as well as Country
Directors.
Any team member working as a PMI’s “PMP” (Project Management Within 18 months of assuming the
Project Manager, Program Manager, Professional) certification -or- first relevant position within Mercy
Program Director, Head of Office, PRINCE2’s Practitioner Corps6
Chief of Party for a program Certification;
exceeding US$1 million in value;
any Director of Programs PMD Pro2 and PMD Pro3
certifications5, which first require
PMI or PRINCE2 certifications, are
optional
PMI is cross-disciplinary not-for-profit membership association for the project management profession which has developed globally-
recognized standards and credentials for project management.
Please refer to http://ngolearning.org/pm4ngos/pages/PMD%20Pro1%20Prep.aspx for details. PMD Pro consists of a guidebook and
professional certifications, which aim to optimize international NGO project investments by enabling project managers to be reflective,
professional practitioners who learn, operate and adapt effectively in complex project environments.
Examples: 1) A former Project Officer is appointed for the first time as a Project Manager within Mercy Corps, managing a new 2 year,
$250,000 nutrition project – she has six months from the day of her appointment as Project Manager to complete the PMDPro1 certification;
2) a new team member, who has several years of program management experience with other agencies but is not certified, joins
Mercy Corps as a Program Manager of an 18-month, $750,000 market development project – he has six months from the day he joins Mercy
Corps to complete the PMDPro1 certification.
At the release of this manual, PMD Pro certification is available from PM4NGOs at level one which tests knowledge and comprehension of
the project management concepts. Level two will test the candidate’s ability to analyze, apply and adapt these concepts and is anticipated
for release during the first quarter of 2012. Level 3 is expected to follow.
Examples: 1) An experienced, but uncertified, team member is appointed as a Program Manager for a 3-year, $15 million food security
project – she has eighteen months to obtain either a PMP certification from Project Management Institute (PMI) or a PRINCE2 Practitioner
certification from PRINCE2 (PRojects IN Controlled Environments). Thereafter, it is her decision whether or not to pursue a PMDPro2
and/ or PMDPro3 certification, which requires PMP or PRINCE2 qualifications as a pre-requisite. 2) A first-time Director of Programs is
appointed for a country portfolio with an annual value of $4 million – he has eighteen months to obtain either PMP or a PRINCE2 Practitioner
certification, after which time pursuit of a PMDPro2 or PMDPro3 certification is optional.

Chapter 1
Mercy Corps’ Commitment to Local Partnership
1.3. What is Program Management?
What is Program Management?

“Program Management” refers to the process of applying skills, knowledge and tools to identify requirements,
address needs, incorporate the concerns of stakeholders, and balance the competing demands of time, cost, and
scope (sometimes called the “triple constraint”) to achieve incremental benefits through the integrated management
of multiple projects, each of which is designed to produce a unique product, service, or result.
Program management is different from “business processes,” which refer to ongoing operations, such as accounting,
fleet management, recruiting, office management, procurement, representation and similar. Good “business
processes” should be applied to operations, often in support of a portfolio of strategy and programs, while good
“program management” should be applied to programs. These are distinct, but highly complementary practices.
Why Does this Manual Use “Program” Instead of “Project”?
Many of the processes described in this manual apply to “projects” as described in various “project management”
literature and global standards. However, Mercy Corps – and other International Non-Governmental Organizations
(INGOs) – most often refer to our initiatives as “programs,” and we use the title “Program Manager” for the managers
of these initiatives. This manual primarily uses the term “program,” as individual grants or cost centers at Mercy Corps
most often encompass a “program” or collection of projects managed together to bring about incremental benefits.
The Minimum Standards presented in Chapter 2 are required at the “program” level. The processes outlined in this
manual and in PMD Pro may be applied at both the program level and to the component projects within.
Global Standard Terminology Mercy Corps Context

Project A project is defined as a “temporary endeavor The unique products, services, or results
undertaken to produce a unique product, that collectively make up a program. At
service, or result.” “Project management” the discretion of the Project Management
refers to the practice of planning, organizing, Office, the policies in this manual may
and managing resources to bring about the also apply to individual projects within the
delivery of goals, outcomes, and objectives. program.
Program A program consists of multiple projects One or more awards or interventions with
that are managed together to bring about a common purpose, to which a single
incremental benefits. “Program management” manager is assigned. The policies in this
processes are quite similar to project manual fundamentally apply to the level
management processes, but program at which a single Program Manager is
management also concerns itself with the assigned; in the Mercy Corps context, this
integration of more than one project into a person might be called a “Project Manager,”
cohesive effort that achieves “incremental “Program Manager,” “Program Director,” or
benefits.” “Chief of Party.”
Portfolio A portfolio is a collection of projects, A Mercy Corps country portfolio or
programs, and other work (business headquarters business unit.
processes, or operations) that are grouped
together to achieve strategic objectives.
Project or A “PMO,” or Project or Program Management The “Director of Programs” function and
Program Office, is the office that manages shared his/ her team, or equivalent (“Head of
Management resources between different projects and Department”). In some cases different titles,
Office (PMO) programs, identifies methodologies and such as “Program Coordinator,” are used.
standards, coaches and mentors Project and At times, the Country Director, Country
Program Managers, manages compliance, Representative or equivalent may also fill this
and facilitates communication. function.
The term “global standards” is used throughout this manual as a catch-all phrase to encompass Project Management Institute (PMI) tools,
including but not limited to the Project Management Body of Knowledge (PMBOK); Project Management in Controlled Environments
(PRINCE2) tools; and, Project Management for Development Professionals (PMD Pro) tools.

Chapter 1
Mercy Corps’ Commitment to Local Partnership
Examples of Portfolios, Programs and Projects at Mercy Corps are depicted in the table below:
Field Example Notes

Portfolio Mercy Corps Ethiopia
Program Revitalizing Agricultural/ Pastoral Incomes Processes in this manual are recommended;
and New Markets (RAIN) processes on Minimum Standards Checklist
are required
Manager Chief of Party (CoP) CoP is ultimately accountable for ensuring
Assigned that the policy requirements are fulfilled
Project(s) – Training of Selected Farmers in High At the discretion of the CoP and PMO, the
Impact Crop Production Technology processes in this manual may be applied to
these projects, or may apply to the program
– Collective farmer marketing of crops level only
– Linking farmers to financial services
PMO Director of Programs and his/ her team,
Ethiopia
1.4. The Program Manager’s Role and Generally-Accepted Knowledge/

Competency Areas
The Program Manager is the person assigned by Mercy Corps to achieve program objectives. The Guide to PMD Pro
describes the competencies required of good Program Managers in the development sector. These are referenced
here so that users of this manual are familiar with the requirements, but for details please refer to PMD Pro, Section
1: Chapter 1.
The required Program Manager competencies include:
• Technical
• Leadership/ Inter-personal
• Personal/ Self-management
• International Development-specific (that is, specific to the sector, context, and cross-cutting themes in
question)
Mercy Corps Program Managers are expected to continuously strive for excellence in all four of the above competency
areas.

Chapter 2
The Program Lifecycle and Minimum Standards Checklist
Chapter 2: The Program Lifecycle and Minimum Standards

Checklist
Many NGOs have developed models that outline their interpretation of the lifecycle of their programs. Mercy Corps’
model is based on the model used by PMD Pro. Mercy Corps has slightly adapted the PMD Pro model by combining
two phases (Program Set Up and Program Planning) into one phase (Program Set Up and Planning) and defining
Monitoring and Evaluation as a process spanning all phases (see Chapter 6). At Mercy Corps, and throughout this
manual, we present the four distinct phases and the M&E Process. Use of this terminology provides a common
reference point within Mercy Corps when discussing programs with management, operations and finance staff, and
within the program team.
Every program has a definite start date and end date, yet the specific activities and deliverables that take place in
between vary from one program to the next. The Program Lifecycle serves as a framework that helps to:
• Define the phases that connect the program from beginning to end
• Identify the processes that teams must implement as they move through the phases of the program lifecycle
• Illustrate how the program management lifecycle can be used to model the management of programs
• Model how programs work within an environment of constraints, where changes to any one constraint will result
in consequential changes to the other parameters
Monitoring & Evaluation
Program Program Planning End of

Identification Set Up Program
and Design Implementation Transition
Adapted from PMD Pro – which is adapted from the Project Management Institute’s
(PMI) Project Management Body of Knowledge (PMBOK) Guide.
Decision Gate
2.1. Definition of Each Phase within Mercy Corps:
Program phases are convenient divisions within a program lifecycle where primary work focus changes. This often
involves different partners or stakeholders and different skill sets. Persons responsible for management of the
program may be different at different phases. Minimum Standards within Mercy Corps require the completion of
certain tasks during each phase as per the Minimum Standards Checklist. The Minimum Standards for each phase
also appear at the beginning of each phase’s chapter within this manual. Deliverables and processes required for
each phase are described in detail in the relevant chapters of this manual.
• Program Identification and Design: During this phase, teams and stakeholders work together to identify
program ideas; collect assessment data; analyze the assessment data; develop the program logic; create
proposals or preliminary program scope statements with summary budgets and high level program plans.
• Program Set Up and Planning: During this phase, the Program Work Plan is prepared. The Program Work
Plan is a map of the program, identifying the detailed activities, budget and the schedule required to deliver the
direct program results.
A Guide to PMD Pro.

Chapter 2
• Program Implementation: During this phase, the program is launched and implementation takes place.
Program launch involves setting up the basic program files, team structure and communicating the work plan.
Implementation involves managing, adjusting and tracking activities, communications, quality, risk, organizational
capacity and coordinating the roles and responsibilities of stakeholders.
• Monitoring and Evaluation (M&E) Process: Throughout a program, it is monitored and evaluated as
necessary. Processes conducted as part of M&E compare program performance to the original proposal
objectives and indicators, as well as to the Program Work Plan. Variances found against plans allow for adjustment
during any phase of the lifecycle of the program.
• End-of-Program Transition: During this phase, the end of program transition strategy as articulated in the
Program Work Plan is updated and executed, while “final 90 days” and other close-out and transitional processes
are carried out.
2.2. Key Aspects of the Program Management Lifecycle at Mercy Corps

• Mercy Corps encourages a balanced approach towards each phase. Though not equal in their duration nor resource
requirements, each phase is important and adequate time and resources should be allocated for every phase.
• Phases are not always linear: phases overlap, are at times integrated, and are often iterative. Each program is
different. It is often common to start two phases simultaneously. For example implementation of a previously planned
community assessment may be initiated as the detailed planning starts on a separate aspect of the program.
• As depicted in the diagram, the ‘planning’ components of Program Set Up and Planning phase are in a continuous,
iterative loop with the Program Implementation phase. This is what is sometimes referred to as “progressive
elaboration” in project and program management standards.
• The processes in all other phases are continually reinforced and assessed through monitoring & evaluation.
Information gathered via monitoring should be applied to inform planning and future decision-making.
! 2.3. Minimum Standards Checklist

These Minimum Standards represent a requirement for programs with budgets of $250,000 and over. Standards for
programs with budgets less than $250,000 are at the discretion of the portfolio manager. The Minimum Standards
must be applied at the program level (the point at which a single Program Manager is assigned), but can also be
applied at the project level within larger programs.
Mercy Corps’ Program Management Manual is intended to aid program teams to be responsive to changes in their
context and proactive in ensuring programs remain on track and relevant. While the Minimum Standards outlined below
must be honored, some of the required standards will be met in different ways for programs of varying size, urgency
and complexity. Program Managers and their supervisors should use sound judgment to determine how each minimum
standard will be met within a particular program. Challenging environments demand flexibility, ingenuity and patience in
addition to sound program designs, carefully developed program work-plans, and quality execution.
This list of Minimum Standards corresponds to the chapters of this manual. More information for each of these
standards can be found within the corresponding chapter. These are necessary steps within Mercy Corps’ program
management framework.
Minimum Standards Checklist

Program Identification and Design (Chapter 3)
A. Written assessment or problem analysis exists, based on primary or secondary data (note: this can be
contained in the proposal documentation, or can be a separate assessment document)
B. A list of external stakeholders participating in initial consultations is available
C. Program Logical Framework exists
D. Lead designer has checked for lessons learned from similar programs globally
E. Program proposal with summary budget (sometimes called preliminary program scope statement)
exists

Chapter 2
Set Up and Planning (Chapter 4)

A. Program File is created
B. Program Work Plan (PWP), exists, with the following minimum contents:
C. Key program parameters, coming from preliminary program documents
D. Work Breakdown Structure (WBS)
E. Program Schedule
F. Coded Program Budget
G. End-of-Program Transition Plan
H. Technical, Cross-cutting Theme, and Sub-grant/ Partnership Planning is conducted. Supply Chain and
Contracting, Personnel, Operations and Security Planning is conducted
I. Program Organizational Chart exists
Implementation (Chapter 5)
A. Program Work Plan (PWP) is approved and regularly updated
B. Program Kick-Off Meeting is conducted, and minutes are available
C. Program Team Coordination Meetings take place at least once per quarter with documented minutes
D. Program progress reports (narrative and financial) exist and include progress toward indicator targets
E. Scheduled and ad hoc reports and updates are communicated to stakeholders
F. Actual Program Schedule (within PWP) is updated against the Baseline Schedule by Program Manager
and submitted to supervisor on a monthly basis
G. Descriptions of deliverables exist, and quality assurance checks are carried out at least twice per
program year
H. Budget vs. Actual reports for the Program Budget are prepared monthly, and projections against the
Program Budget are prepared quarterly
I. Program Team receives copies of, and is oriented on: Proposal & Logical Framework, M&E plan,
Program Work Plan, Kick-Off Meeting minutes and relevant parts of the Program Budget and Grant
Agreement. Program Team is oriented on administration and finance procedures (FAM, FFM, FPM),
and roles & responsibilities for contractors and partners
J. Program Team is recruited; roles, responsibilities, and required skills have been articulated; Position
Descriptions exist; Training Needs Assessment is carried out
K. Program Team member performance is assessed and documented by Program Manager within three
months of program start, and annually thereafter
Monitoring & Evaluation (Chapter 6)

A. Indicator Plan exists (Planning Phase)
B. Key program M&E events (at a minimum, baseline, evaluation, and routine monitoring) have been carried
out, and reports of these events exist (Implementation Phase)
C. Basic M&E data management system exists (Implementation Phase)
D. Final Evaluation report exists (Implementation Phase)
End-of-Program Transition (Chapter 7)

A. Written End-of-Program Transition Plan exists
B. “Final 90 day” meeting has taken place, and minutes exist
C. Contract/ sub-grantee status reviewed and finalization plans specified
D. Deliverables to be transitioned to external stakeholders have been handed over, and handover
documentation exists
E. Lessons learned have been documented, and have been sent to the Senior Program Officer (SPO) and
Technical Support Unit (TSU)
F. End-of-Program Transition has been clearly communicated to the Program Team, beneficiaries, host
government counterparts, and partners
G. Program File is complete
H. Final report is completed and donor close-out requirements are met

Chapter 2
2.4 Mercy Corps Internal Resources

Mercy Corps has field-tested tools and policies that can be useful resources during each phase of the Program
Lifecycle and with the required Minimum Standards. Many such tools are referred to throughout this manual and
have been compiled into the Program Management Tool Kit which is available within Mercy Corps’ Digital Library.
In addition to the in-county teams, the Program Management, Technical Support Unit, Program Operations (POps),
Design, Monitoring and Evaluation, Leadership and Organizational Effectiveness, Strategic Response and Global
Emergencies (SRGE), Operations and Procurement, Administrative and Logistical Management (PALM) teams
within Mercy Corps’ global structure are valuable human resources that field teams can and should consult with for
additional guidance.
10 < Table of Contents mercycorps.org

Chapter 3
The Program Identification and Design Phase
Chapter 3: The Program Identification and Design Phase

Program Identification and Design
S S S S S S
PROCE SS
Identify Analyze Develop Develop

Program Ideas Funding Assess Analyze Program Proposal
Opportunities Logic & Budget
T T T T T T
Introducing Prompting Info Needs VENN Diagram DM&E Proposal
Mercy Corps’ Questions to Matrix and Stakeholder Guidebook Tool Kit
Vision for Analyze Funding Analysis Matrix and Online
Change Opportunites Training
T T T T T
Strategic Proposal Tool SWOT Analysis Logical Proposal
U S E F U L TO O L S
Planning Kit: Assessment Problem Tree Framework Development

Tools and Tools and Solution Template and Minimum
Techniques Ranking Indicator Standards
Menus
T T T T
Proposal DM&E Tip Sheet Mission Metrics Budgeting
Pre-positioning #11: Data Indicator Guide
Tools Analysis Guidelines
T S T
Local Review Proposal
Partnerships Lessons Learned Composition
Guide and Best Guide
Practices
P R O D U CT S
OOOO
List of Written Proposal
Program
External Assessment (Preliminary
Logical
Stakeholders or Problem Program Scope
Framework
Consulted Analysis Statement)
S Process Step
T Tool
O Output or Product Minimum Standards are Red Italic
mercycorps.org < Table of Contents 11

Chapter 3
Minimum Standards for the Program Identification and Design Phase:

� Written assessment or problem analysis exists, based on primary or secondary data (note: this can be
contained in the proposal documentation, or can be a separate assessment document) (see 3.4)
� A list of external stakeholders participating in initial consultations is available (see 3.4)
� Program logical framework exists (see 3.6)
� Lead designer has checked for best practices and lessons learned from similar programs globally (see 3.6)
� Program proposal with summary budget (sometimes called preliminary program scope statement) exists
(see 3.7)
About This Chapter

Program Identification and Design is the first phase of the Program Life Cycle in which Mercy Corps teams and
stakeholders work together. This chapter describes the key steps of Program Identification and Design that can
help to ensure good programmatic results. These are described below, divided into the following categories: 3.1)
Introduction to New Program Development at Mercy Corps; 3.2) Identification of Program Ideas; 3.3) Funding
Opportunity Analysis; 3.4) Assessment; 3.5) Analysis; 3.6) Program Logic; and, 3.7) Proposal and Budget
Development.
3.1 Introduction to New Program Development at Mercy Corps

New programs can be developed through existing teams discovering new needs or a response to a Request for
Application or Call for Proposals. The process steps of Program Identification and Design that lead to a proposal or
preliminary program scope statement are iterative, and in many cases overlapping. The order depicted in the Chapter
3 diagram represents one of many sequences for how the process flows, which will vary based on a program’s
identification and design needs. The level of time and effort required to complete each phase of the process will
also vary depending on the size and complexity of the program being identified and designed. An important aspect of
each phase described below is consultation with stakeholders, which is critical to ensuring the suitability and viability
of program ideas and the support of those to be engaged and affected by the program’s outcomes.
Resources available
This manual introduces a range of tools to support simple to more complex forms of Program Identification and Design,
noting the Minimum Standards for the Program Identification and Design phase. Mercy Corps’ New Initiatives team
has created a Proposal Tool Kit10, including Mercy Corps’ Proposal Development Minimum Standards11, Proposal
Pre-Positioning Overview and Tools12 and the Proposal Composition Guide13, which are available on the Digital
Library and include details and tools for many of the processes within Program Identification and Design, and in
particular the Proposal and Budget Development process.
A preliminary program scope statement details a program’s activities in a manner similar to a basic proposal and is required in instances in
which a program proposal has not been developed.
10 Proposal Tool Kit: https://mcdl.mercycorps.org/gsdl/cgi-bin/library?a=p&p=ptk
11 Proposal Development Minimum Standards: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=proposal+development+minimum+standards
12 Proposal Pre-Positioning Overview and Tools: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=Pre-positioning+tool+kit
13 Proposal Composition Guide: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=proposal+composition+guide

Chapter 3
3.2 Identification of Program Ideas

Needs Identification & Alignment
The process of identifying a program idea begins with the identification of needs and opportunities. In the case of
a country in which Mercy Corps has existing programs this is often done through periodic reviews of the existing
country or regional portfolio and strategic plan. This process often reveals areas of need outside the scope of
the existing portfolio or opportunities for complementary work that can contribute to related objectives. Any newly
identified needs and opportunities should be reviewed and further formalized when carrying out a country’s annual
planning process or other complementary strategic planning processes. In the case of a prospective country in
which Mercy Corps is considering developing new programs, an initial assessment visit to gather information about
needs, existing activities and capacities, donor interests, etc. is important for informing program idea identification.
Input and participation from a variety of stakeholders – such as community leaders, local organizations, donors and
government officials - helps to determine new program ideas that are well targeted, viable and have community
support. Clearly demonstrating input and active participation of a variety of stakeholders, including beneficiary
communities and local partners in particular, can also be critical criteria of donors in the assessment of proposals.
Local Partnerships: A Guide for Partnering with Civil Society, Business, and Government Groups is a helpful tool
for identifying and building promising partnerships, beginning with identification of program ideas and continuing
through all phases of program management. Tools that can be useful for analyzing stakeholder information include a
Strengths, Weaknesses, Opportunities and Threats (SWOT) analysis, a Venn diagram and a Stakeholder Analysis.
Examples of these tools can be found in the Overview of Strategic Planning Tools and Techniques14 document, page
10 of the DM&E Guidebook15, page 17 of A Guide to the PMD Pro and on the Digital Library. Such tools are useful
in narrowing focus to where there is an intersection between existing assets in the target community, unmet needs,
donor interests and Mercy Corps’ unique capabilities, and then prioritizing such intersections so that new program
ideas are strategic and focused in areas having the greatest chances of success. The table below highlights things
that are important to consider when looking for intersecting points of opportunity.
Points of Alignment
Agency Mission Statement Vision for Strategic Relevant Regional
(see Mission Change Roadmap Strategy
Metrics)
Country Country Program Existing Existing In- Programming Local capacity
Specific Goal and Geographic country Core Principles17 & Partnership
Objectives) Concentrations Competencies16 Opportunities
In addition, the Proposal Pre-Positioning Overview and Tools can help in preparing to pursue funding as program
ideas are identified. Positioning strategies promote the agency’s relevant strengths, diminish perceived weaknesses,
and assist in assembling a strong future proposal. 16 17
14 Overview of Strategic Planning Tools and Techniques: https://mcdl.mercycorps.org/gsdl/cgi-

bin/library?e=d-000-00---0agency--00-0-0--0prompt-10---4------0-1l--1-en-9999---20-mchome---00031-011-0-0utfZz-8-00&a=d&c=agen
cy&cl= CL1.1.2.4.3.3&d=HASHc1783b3c70e610d82db3cf
15 DM&E Guidebook: https://mcdl.mercycorps.org/gsdl/docs/DM-E FINAL Guidebook 3final.pdf
16 Core competencies are sectors in which a country program has programming experience and expertise
17 Principles are the fundamental ways a country program has committed to working, for example using technology, in partnership with the
private sector, using advocacy, etc.

Chapter 3
Stakeholders
Stakeholders are persons or organizations whether in the public, private or civil sector, whose interests may
be positively or negatively affected by Mercy Corps’ decisions, actions and ensuing results. Stakeholders can
be both internal and external to Mercy Corps. Examples of stakeholders include: Mercy Corps team members,
community groups, households, donors, the private sector, host country government, media, partners, and
colleague agencies. In a program context, stakeholders are persons or organizations that are actively involved in
the program and whose interests may be positively or negatively affected by the performance or completion of
the program. Stakeholders may have very different interests, capacity and influence based on gender and power
relationships in the community18. Each program phase and/or sub-project may include unique stakeholders, and
it is the responsibility of the Program Manager and PMO to identify the stakeholders at each phase, communicate
their anticipated level of participation and/or responsibility and manage expectations19.
3.3 Funding Opportunity Analysis 18 19
Responding to a Request for Applications (RFA)/Call for Proposals

The issuance of a call for proposals from a donor can trigger new program idea identification, or the refinement of
an existing program idea. Having advance knowledge of such funding opportunities and acting on it (see guidance
offered in the Proposal Pre-positioning Overview and Tools), greatly improves the quality and competitiveness of a
program design and proposal. In anticipation of, or upon release of a call for proposals, a funding opportunity should
immediately be evaluated to determine if it is an appropriate mechanism for realizing an identified program idea and
that the necessary resources for doing so are available. The Prompting Questions to Analyze Funding Opportunities20
can help in carrying out this evaluation. Should a decision be made to pursue the funding opportunity, the subsequent
processes of program design should be carried out.
Decision Gates
The discovery and development of a new program is time and resource intensive. Due to a variety of constraints not
all new ideas will be developed into new programs. In order to track and determine feasibility and pursuit of a new
opportunity, a program idea will typically go through a set of decision gates.
Mercy Corps Decision Gates for New Program Development
The decision to pursue a new program opportunity or not almost always comes down to a balancing of resources
required and the probability for success of one opportunity, versus competing agency priorities and other funding
or programming opportunities. While developing a new program does not always include developing a proposal
for a donor, developing new program opportunities always requires human and financial resources, so resource
allocation decisions must be made. To the extent that a country team (Portfolio Management) possesses capacity to
pursue a new program opportunity without significant external support, the decision to pursue or not resides within
the management structure of the country team, inclusive of the Regional Program Director (RPD). To ensure the
country implementation team has a viable strategy for meeting necessary requirements, programs with co-financing
requirements and sub-contracts must be approved prior to proposal submission by the Senior Vice President of
Programs and the Chief Financial Officer, and in the case of Scotland office supported programs, the Deputy
Executive Director.
In instances - such as large and highly competitive donor solicitations - where a Mercy Corps response requires
several additional dedicated proposal developers (i.e. TSU) to be competitive, additional buy-in and support from
headquarters management is necessary. Requests for additional support should be communicated through the
Regional Program Director, keeping the Program Operations team informed. Final decisions about how such
additional resources are assigned ultimately will involve the RPD, the Senior Vice President for Programs and the
Vice President for Strategic Development. The Program Operations team often helps with facilitating this decision
18 Mercy Corps’ “Gender Policy Procedures” is under development as of the release of this manual and is expected to be available on Mercy
Corps’ Digital Library in early 2012.
19 PMBOK, page 23, Chapter 2.
20 Prompting Questions to Analyze Funding Opportunities: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=prompting

Chapter 3
making and also provides other key support to proposal development, which may include facilitating headquarters’
technical and cost proposal reviews, writing proposal sections or leading proposal development.
Identification of External Stakeholders Holding Authority over Go/ No-go Decisions
While in most cases the go/ no-go decision resides primarily within Mercy Corps, there are instances where external
stakeholders or factors can dictate whether or not Mercy Corps is able to effectively fulfill the role defined under a
programming opportunity. Factors potentially impacting our ability to pursue a funding opportunity include:
• Political restrictions or limitations on NGOs working in the target region / country.
• Mercy Corps’ credibility and reputation with local government or beneficiary communities.
• Mercy Corps’ ability to forge vital win-win partnerships with other key local and international organizations
operating in the same programmatic space.
• Requirements for co-financing or match funding for a program and the need for commitments from external
sources prior to proposal submission.
In every instance, efforts should be made early to map out areas where support from external actors is required to
avoid investment of significant agency resources in vain.
3.4 Assessment
Effective program designs are preceded by the identification
of unmet needs, understanding of root causes leading to the An assessment should not be confused with
identified problems, and identification of the causal relationships a baseline survey. An assessment is broad
that lead to these problems. The proposal lead must also be reaching, gathering data on needs from a
aware of capacities and lessons learned from similar programming. variety of stakeholders during the Program
Needs analysis should be carried out in consultation with Identification and Design phase. For further
local stakeholders and include an identification of what assets details on baseline surveys, which pertain to
exist within the target community and what relevant unique the Monitoring and Evaluation Process, see
capabilities Mercy Corps can offer, while also factoring in donor Chapter 6.
interests. Development of a new program idea typically follows
an analytical process of assessment (data collection), program
analysis (problem and objectives analysis), and ends in program logic (logframe). Proper analysis enables a team to
understand and communicate the high-level constraints and requirements of the new program. The existence of a
written assessment or problem analysis, based on primary or secondary data is a Minimum Standard
for Program Management at Mercy Corps. The next few sections describe this process.
What and Why
An assessment to inform the development of a new program can vary in its scope depending on what information is
already on hand, the amount of time available for gathering information, and the availability of resources for conducting
assessment activities.
As noted in the A Guide to the PMD Pro21, an assessment should gather a broad range of information about needs
that either confirms the suitability of the initial project idea or points to adjustments that should be made. This
information will be considered in the following analysis phase of developing a project idea. Upon completion of
the assessment, a summary of information gathered must be on record and may be incorporated into the proposal
document.
Scope of Work and Selection of Methodology
A Scope of Work (SoW) for an assessment should state its purpose and what questions it aims to answer. The
Info Needs Matrix (Sample can be found in the Program Management Tool Kit on the Digital Library) can be used
to identify information requirements, and Annex 5 of the Psychosocial Needs Assessment done in Gaza in 201022
contains an example of a detailed SoW, appropriate for a more complex assessment. A SoW should identify key
21 Section 2: Chapter 1, page 14
22 Psychosocial Needs Assessment done in Gaza in 2010: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&t= 0&c=all&h=dtt&q=gaza+psychosocial+assessment

Chapter 3
stakeholders to consult with and methods to be used in gathering data. If responding to a donor solicitation, the
RFA or Call for Proposals should also be consulted when identifying the type of information needed. For unsolicited
proposals, brainstorming around the initial idea can generate a list of data to collect that will better define the needs,
constraints and opportunities. Most assessments use a variety of methods which include secondary research, key
informant interviews, surveys and focus group discussions.
The specific information to be gathered will vary from and depend on the targeted sector(s). PMD Pro references
several tools that can be used for assessments23 as does the Mercy Corps Assessment Tools24 section of the Digital
Library, which contains a variety of survey tool examples for various sectors. The relevant TSU technical team(s) can
provide useful input and recommendations for the most useful tools in designing the assessment.
Secondary Research
Secondary or desk research can produce important data detailing context and needs and can be done with relatively
few resources. It should be the starting point of data collection, with primary research being pursued in areas lacking
in documented research or needing greater depth of information. When conducting secondary research, a matrix
such as the Literature Review25 example in the Proposal Pre-positioning Overview and Tools can help in organizing
information gathered for easy reference during the analysis and proposal development phases.
Engagement of Target Community and Partners
Target community and local private, public and/or civil society partners’ input into an assessment verifies an accurate
understanding of local needs, constraints and opportunities. Involving these stakeholders also provides an opportunity
to empower local actors and create ownership of the program’s benefits. It is important to consider gender and
power dynamics in communities when using participatory methods. For example, in order to ensure full community
participation, separate male/female information gathering sessions may be required. There are a variety of assessment
tools that facilitate the target community’s participation in the process such as focus group discussions, household
surveys and key informant interviews. Local partners can often facilitate access to marginalized stakeholders when
access is difficult and help to expand assessment efforts. Efforts should be made to ensure that methods used
adequately solicit input from groups frequently marginalized in communities, such as youth, women, persons with
disabilities, etc. These stakeholder consultations must be documented to facilitate future contact by
the Program Implementation team as a Minimum Standard for Program Management at Mercy Corps.
One format for documenting this information is to utilize the Assessment Contacts Documentation Tool26.
3.5 Program Analysis

Tools for Analysis
There are a variety of tools that can be used to understand, synthesize and analyze data gathered through
assessments and desk research. In addition to the analysis tools referenced in PMD Pro, Mercy Corps’ ASSETS
Guidebook27 contains additional tools as well as further instructions for applying some of the PMD Pro referenced
tools, including: the Problem Tree, Solution Ranking, SWOT Analysis and the Venn Diagram. The DM&E Tip Sheet
#11: Data Analysis28, is a helpful resource for analyzing primary data. As noted in PMD Pro, selecting the right tool
will depend on the objective of the analysis, the type of data collected, and the person(s) carrying out the analysis.
23 Section 2: Chapter 1, page 16

24 Mercy Corps Assessment Tools: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?e=d-000-00---0progdev--00-0-0--0prompt-10---4------0-1l--1-en-9999---20-mchome---00031-011-0-0utfZz-8-00&a=d&gc=2&
cl= CL1.2.1#CL1.2.1
25 Proposal Pre-positioning Overview and Tools: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=Pre-positioning+tool+kit
26 Assessment Contacts Documentation Tool: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&t= 0&c=all&h=dtt&q=Assessment+contacts
27 ASSETS Guidebook: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&t= 0&c=progdev&h=dtt&q=assets+guidebook
28 DM&E Tip Sheet #11: Data Analysis: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=dme+tip+11+data

Chapter 3
Categories of Analysis
Ultimately the analysis process should lead to a goal statement for the project that in some way addresses the
root causes of the problem. In determining the goal statement, a variety of factors should be considered that
inform the project’s scope. These include:
Stakeholders: Existing Priorities: Proposal Feasibility:
PMD Pro summarizes the Local stakeholder priorities will Parameters: In looking at root
key points to consider impact the feasibility of various When responding causes of problems
when identifying interventions. Important to consider to a Request for and considering
stakeholders; analyzing are those needs deemed most Applications or Call ways to address
their interests and critical by the target community, as for Proposals there them it is important
mapping stakeholder well as what the local government are often areas of to keep in mind what
influence. A mapping tool, or other relevant agencies intend to focus specified by is feasible, financially
such as the Venn Diagram focus on. Similarly, Mercy Corps’ the donor that must and technically, as
can help in understanding global priorities, regional and be taken into account well as consider
various interests and country strategies and organizational and which will often the potential for
their relevance to capacities should be factored into dictate the types of sustainability and the
addressing the identified the analysis, along with key Mercy underlying issues environmental impact
problem. Don’t forget to Corps design factors such as the the project must of approaches being
disaggregate quantitative facilitation of public, private, and address. considered.
data by gender and age civic sector partnerships, and the
during the assessment promotion of community-led, market-
and analysis processes. driven approaches.
3.6 Program Logic

Upon gathering assessment information and analyzing the data, the development of the program logic leading to
a Logical Framework (logframe) will follow. This is a principle tool that provides a framework from which to start
planning a program (outputs, schedule, and budget). The existence of a program Logical Framework is a
Minimum Standard for Program Management at Mercy Corps.
Developing a Logical Framework, or Logframe
As noted in PMD Pro, the formats used for logframes vary but have a common intent in serving as the basis for
reflecting all the major steps in the life of a project or program and ensuring that each is logically connected.
Mercy Corps has a standard logframe template29, that can be used when no other format is specified by a donor.
However, alternative logframe formats can be used as per the donor requirements. Other donor templates30 are
posted on the Digital Library.
Identify Program Goal, Objectives, Outputs, Activities SMART Objectives
and Indicators31
To ensure its clear when an objective
The Fundamentals of Project Design chapter of the Design Monitoring is successfully achieved it is important
& Evaluation Guidebook32 details the process, with illustrative examples, for all objectives to be SMART:
for taking a goal-oriented approach to designing a program. It begins Specific
(following the assessment work described above) with determining the Measureable
desired impact of the program, which addresses the root cause(s) of Achievable
an identified problem. This leads to the program’s Goal. Next, the key Relevant
changes required in the target population in order to achieve that impact Time-bound
are identified, which become the program’s Objectives. Subsequently,
29 Mercy Corps standard logframe template: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=Standard+Mercy+Logical+Framework+Template
30 Logframe templates: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=dme+example+tool+logframe
31 Mercy Corps’ process for developing a logframe, our standard format and some terminology varies from what is described in PMD Pro.
While not entirely incompatible, it is recommended that Mercy Corps employees generally follow the process presented in Mercy Corps’
Design, Monitoring & Evaluation Guidebook for consistency across the organization.
32 Design, Monitoring and Evaluation Guidebook: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=DME+guidebook

Chapter 3
the program designer will need to determine what goods and services are needed to bring about these changes,
these are the program Outputs. Finally, the actual Activities to be carried out in order to produce the required
outputs need to be determined. Once these aspects of the program are clear, Indicators that measure the program’s
success must be selected. A Design Checklist in the DM&E Guidebook is a good reference, reflecting best practices
for preparing a program logframe
Efforts should be made at this phase to select indicators that can be aligned with Mission Metrics33, Mercy Corps’
system to measure macro-level results, to track progress against our mission.
As an intermediary step, particularly should the initial formulation of a program design precede the release of a
solicited Request for Applications, and as the details for determining specific Activities and Outputs are still being
determined, a Results Framework can help in starting to form the Project Logic34.
Consult with Relevant TSU and Program Support Teams (sector specialist, DM&E,
New Initiatives, etc.)
The proposal lead must also ensure that they consult relevant Mercy Corps resources and team members (Digital
Library, TSU, POps) to ascertain any lessons learned from similar past Mercy Corps programming. Reviewing
lessons learned and best practices is a Minimum Standard in designing program logic, because it
prevents a situation in which Mercy Corps team members ‘reinvent the wheel’ unnecessarily. The relevant sector
specialists in the TSU and DM&E team can offer useful resources and guidance as a logframe is developed. It is
often useful to work with the designated POps Program Officer to identify appropriate sector specialists that can
support this review. Sector specialists are aware of research done in the sector to identify best practices as well as
lessons learned from other projects implemented by Mercy Corps. This can lead to useful information regarding
approaches that have and have not proven successful. They are also aware of standard indicators for a sector that
can lead to the selection of appropriate indicators for the program. In addition, the DM&E team’s review of the
logframe can provide feedback on the logic of the design and the appropriateness of the identified indicators.
To benefit from this support it is recommended that those developing a program communicate the anticipated
technical needs with their HQ program officer(s) who can contact relevant members of the TSU early in the design
phase, requesting that they set aside time to help in the development and/or review of a logframe and, subsequently
the proposal.
3.7 Proposal and Budget Development

When a Call for Proposal is being responded to, much of the work described above may already be done or may
need to occur in addition to responding to the solicitation. This next section describes the specifics of developing
the proposal.
Making a Proposal or Scope Statement Development Plan
The amount of effort involved in the preparation of a proposal will vary depending on its size and the requirements of
a donor. Typically the process involves a number of tasks that need to be accomplished in a short amount of time by a
team of individuals contributing different parts to the overall final documents. In order for this to be done successfully
the process needs to be well organized from the start. The following are key steps towards getting organized, spelled
out in Mercy Corps’ Proposal Development Minimum Standards35, and which have tools on the Digital Library to help
in carrying them out. The size of the effort required will dictate how complex the planning process needs to be, but
all proposal development should start out with at least a simple plan:
• Assemble a proposal development team and assign roles and responsibilities. The Proposal Team: Roles and
Responsibilities36 document lists common functions that the Proposal Team Leader, HQ Program Officer and
Country Director (or other relevant Portfolio Manager) should review upon deciding to prepare a proposal,
determine which are of relevance and assign responsible parties.
33 Mission Metrics Indicator Guidelines: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&t= 0&c=all&h=dtt&q=mission+metrics+guidelines
34 Alternative Mercy Corps Logical Framework Format with Results Framework template: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=Excel+Logframe+Format
35 Proposal Development Minimum Standards: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=proposal+development+minimum+standards
36 Proposal Team: Roles and Responsibilities: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=Proposal+Team+Roles

Chapter 3
• Prepare a proposal development plan37 that indicates an overall calendar and all the tasks necessary for
completing the proposal, due dates and the person(s) responsible – this is usually done by the Proposal
Team Leader and will often include activities described above (assessment, analysis, etc).
• Have a kick-off call with the team to review the proposal development plan, specific tasks and work assignments.
A sample agenda for such a call can be found in the Proposal Tool Kit of the Digital Library38.
Proposal Development Team Members
Proposal and/or program scope statement development must involve a team comprised of the right mix of individuals
familiar with the existing country program, local needs and capacities, relevant technical area(s), finance and donor
requirements. Who these individuals are and how many are involved will vary from one proposal to another depending
on its size, its strategic importance, the complexity of the program being designed and the resources available at a
given time.
At the start, a proposal team leader will be identified. This is often a Program Manager, Director of Programs (head
of PMO) or Country Director (head of Portfolio Management). In the case of large proposals a New Initiatives or
other TSU team member may lead the proposal. The team leader in most cases will be assisted by someone with
expertise in the sector(s) on which the program will focus. This could be a member of the field team and/or may
involve someone from the relevant Technical Support Unit. More complex proposals will require additional staff to
assist with coordination of the proposal preparation, collection of data, negotiation of partnerships, etc. In countries
with existing Mercy Corps programs the Finance Manager will lead in developing the budget. In addition, a team of
reviewers should be identified which typically includes the Country Director, Country Operations Manager, Regional
Program Director, a HQ Program Officer, a relevant member of the TSU, and the HQ Regional Finance Officer. It
may include other HQ support teams, such as DM&E or PALM for specific sections of the proposal.
Partners
Early on, the Proposal Development Team should determine whether any partnerships are required in order to
successfully implement the program activities, as well as be competitive in our application for funding to implement the
desired program. Local Partnerships: A Guide for Partnering with Civil Society, Business, and Government Groups
provides useful guidance and tools for establishing, fostering and managing partnerships. The Guide also contains
Mercy Corps’ Principles of Partnership, which are essential for structuring and framing collaborative relationships.
The negotiation of the role of each partner can be time consuming which should be taken into account and built
into the proposal development work plan. A teaming agreement template39 and sample letters of commitment that
can be useful during the negotiation process, alongside the Principles of Partnership, can be found in the Proposal
Tool Kit. Teaming Agreements should be prepared with all partners to assure a clear and common understanding of
roles and responsibilities of participating organizations. They should reflect the exact understanding between the
organizations to avoid confusion and delays at program start up. They are also a helpful reference as sub-agreements
are drafted during the set-up and planning phase.
Key Personnel Identification
Frequently RFAs or Calls for Proposals require the identification of one to five “key personnel” within a proposal. In
these cases it is critical to begin recruitment immediately as the steps require, which include: 1) drafting a position
description; 2) advertising; 3) screening of applicants; 4) interviewing of top candidates; and 5) negotiation of a
job offer, followed by 6) formatting of CVs and drafting of relevant sections of the proposal narrative, which require
a month or more to complete. In the Recruitment section of the Proposal Tool Kit are tips40 and templates41 for
drafting
37 Proposal Work Plan Template: https://mcdl.mercycorps.org/gsdl/cgi-

bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=Proposal+Work+Plan+Template
38 Proposal Kick Off Call Sample Agenda: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=Proposal+Kick-Off+Call+Agenda
39 Proposal Teaming Agreement Template: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=Teaming+Agreement
40 Position Description Instructions for HQ and Expat Staff: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=agency&h=dtt&t= 0&q=position+Description+instructions
41 Position Description Templates: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=agency&h=dtt&t= 0&q=position+Description+template

Chapter 3
Position Descriptions and Letters of Commitment for staff42 and contractors43 as well as a sample CV format for
USAID44. Where there is no requirement to specify key personnel such a level of effort is not necessary, but it can
be useful to give consideration to a program’s staffing needs as it is designed to inform the subsequent planning
phase.
Narrative Draft
Mercy Corps’ Proposal Composition Guide45 describes ten tips for writing a clear, concise and convincing proposal.
The drafting of the narrative should begin with a well-designed program that is responsive to the donor’s solicitation
and the assessed need. It is important, therefore, that at the start the writer has 1) a program logframe that has
been reviewed by the proposal team; and 2) a copy of the RFA or Call for Proposals which often contains very
clear instructions for length, format, outline, etc. These documents provide the framework for the narrative. Help
and examples can be found in the Technical Proposal Writing and Reviewing and the Sector Information Packets
sections of the Proposal Tool Kit
Budget Draft
As with the narrative, the instructions in the RFA or Call for Proposals should be closely consulted when preparing the
budget. Guidance for developing a program budget can be found in the Budgeting Guide Presentation46. A Mercy
Corps standard budget template47 should be used for the initial draft and, if required, then modified to conform to a
donor’s budget template. The budget is typically developed by the Finance Manager for the country, in consultation
with other members of the program design team. Although further, more detailed budget planning work is required in
the Set Up and Planning phase, the creation of a budget is always recommended in the Program Identification and
Design phase as well, even in rare cases when it is not required by a donor.
All costs associated with the program should be included in the budget. Where not required, including match48 or
co-financing in the budget is discouraged due to the added administrative burden. Those proposals that require
retention and/or co-financing must submit an Expression of Interest49 for approval by the Regional Program Director,
the Senior Vice President for Programs in Portland and, in the case of Scotland office supported grants, the Deputy
Executive Director in Edinburgh.
The budget should be cross-checked with the proposal narrative to ensure the documents align, as well as be
reviewed by the HQ Regional Finance Officer. The Digital Library has a Budget Review Check-list50 to help in
reviewing the budget.
42 E xclusive Letter of Commitment for Key Staff: https://mcdl.mercycorps.org/gsdl/cgi-

bin/library?a=q&r=1&hs=1&c=agency&h=dtt&t= 0&q=letter+of+commitment+staff
43 Consultant Letter of Understanding (Proposal Stage): https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=agency&h=dtt&t= 0&q=letter+of+commitment+contractor
44 USAID CV Example: https://mcdl.mercycorps.org/gsdl/cgi-bin/library?a=q&r=1&hs=1&c=agency&h=dtt&t= 0&q=USAID.*cv
45 Proposal Composition Guide: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=proposal+composition+guide
46 The Budgeting Guide Presentation is under development at the release of this manual and will be included in the Program Management Tool
Kit on the Digital Library.
47 Proposal Budget Templates: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=agency&h=dtt&t= 0&q=proposal+budget+template
48 What You Need To Know About Match: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=agency&h=dtt&t= 0&q=what+match
49 E xpression of Interest from Mercy Corps Country Offices to Apply for Grants with Retention and/or Co-financing Requirements: https://
mcdl.mercycorps.org/gsdl/cgi-bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=retention+co-financing+requirements
50 Budget Review Checklist: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&c=agency&h=dtt&t= 0&q=Budget+checklist

Chapter 3
Proposal Production and Submission

Developing, writing, reviewing and finalizing a proposal takes significant effort and time. All of this must be allowed
for when taking on the development of a new proposal. Other tools available are:
• Proposal Review Tips51 offers suggestions for making feedback practical and useful
• Appendix A of the Proposal Composition Guide offers a Sample Proposal Outline
• Proposal and Donor Guidelines section of the Proposal Tool Kit
A proposal or preliminary program scope statement with a summary budget is a Minimum Standard
of Program Management at Mercy Corps.
Final Steps
Following the submission of a proposal, it is important that a few final steps are completed, including: 1) ensuring an
HQ program officer makes a Grant and Award Information Tracker (GAIT) 52 entry that summarizes the application
made; and 2) submitting the proposal to the Digital Library. In addition, an electronic file should be kept containing
all assessment data gathered, including contact information for interviewees, organizations, etc. (such as the
Assessment Contacts Documentation Spreadsheet) and handover notes with key details about decisions made
during the design process that would be of relevance to the team implementing the program, should the proposal
be successful. These activities should be included in the proposal development work plan, specifying who the
responsible party is for carrying out these final important steps.
51 Tips for Proposal Reviewers: https://mcdl.mercycorps.org/gsdl/cgi-

bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=tips+proposal+reviewers
52 Grant & Award Information Tracker (GAIT) is a web application developed by Mercy Corps to track real-time program and financial
information on grants and other awards. The system is also used for gathering information for Past Performance Reports as well as
generating a variety of financial and program reports. The information inside GAIT is updated through the joint efforts of both the HQ Finance
and HQ Program departments.

Chapter 4
The Set Up and Planning Phase
Chapter 4: The Set Up and Planning Phase

Program Set up Planning
OS S S S S S S
PROCE SS
Plan
Plan Create End of Technical & Create Work Plan for Team Create Create
Create Cross-Cutting
Stakeholder Program Breakdown Requirements Program Program
Program File Them Needs &
Management Transition Plan Structure & Structure Schedule Budget
Partnerships
TTTTSTTT
Local Partnerships
Program File Stakeholder Program A Guide for Break-Down Functional Creating a Creating an
Requirements Register Management Sequence & Analysis Schedule Activity Budget
Partnering with
Estimate Duration
Template Manual: Civil Society, of Program &
Chapter 7 Business, Project Tasks
& Government
U S E F U L TO O L S & I M P O R TA N T S T E P S
TTTTT
Subgrant Creating a Work Sample Position Risk Mercy Corps
Management Breakdown Descriptions Management Coding
Manual Structure Tip Sheet Methodology
(WBS)
TS T
Country / Sector
specific technical Plan for DM&E-in-a-Box:
guides & Supply Chain DM&E at Project
standards (DL, Contracting, Start-Up
technical specialist Operations &
& TSU resources) Security
TT T
Gender Policy Supply Chain MS Project
& Procedures & Contract software
Requirements
Table
T S
Operational &
Security Plan
Requirements Communications
Table
T S
Office-in-a-Box
Plan Quality
Assurance
O O
P R O D U CT S
Program Program
Organizational Work Plan
Chart
S Process Step
T Tool

Chapter 4
Minimum Standards for the Set Up and Planning Phase:

� Program File is created (see 4.1)
� Program Work Plan (PWP) exists, with the following minimum contents (see 4.3):
� Key program parameters, coming from preliminary program documents
� Work Breakdown Structure (see 4.6)
� Program Schedule (see 4.8)
� Coded Program Budget (see 4.9)
� End of Program Transition Plan (see 4.4)
� Technical, Cross-cutting Theme, and Sub-grant/ Partnership Planning is conducted (see 4.5)
� Supply Chain and Contracting, Personnel, Operations & Security, and Planning is conducted (see 4.6)
� Program Organizational Chart exists (see 4.7)
Monitoring and Evaluation Minimum Standards for the Set Up and Planning Phase:
� Indicator Plan exists (see 6.3)
About This Chapter

The Set Up and Planning phase follows the identification & design phase. It is the phase in which the designed
program is planned, prior to implementation. The program management steps in the Set Up and Planning phase
are not necessarily linear – some of them will take place iteratively within the Program Implementation phase adding
more planning detail and reacting to Monitoring and Evaluation feedback. It is expected that planning starts in the
Set Up and Planning phase and is regularly conducted throughout Program Implementation in response to new
information, risks, opportunities, assumptions and constraints, and while initial activities will be planned in great detail
at the start of a program, later activities will be progressively elaborated during implementation.
This chapter describes the key program management steps during the Set Up and Planning phase. These are
described below: 4.1) Program File; 4.2) Stakeholder Management Plan; 4.3) Program Work Plan; 4.4) End of
Program Transition Plan; 4.5) Technical Requirements and Partnerships Plan; 4.6) Work Breakdown Structure;
4.7) Team Requirements and Structure; 4.8) Program Schedule; 4.9) Program Budget. Please note that initial
start-up activities such as recruitment and Kick-Off Meetings take place in the Program Implementation phase (see
Chapter 5), and for that reason are not covered here.
4.1. Program File

The Set Up and Planning phase is entered into after a program that has been identified and designed has been
approved for funding and is ready to move ahead. At this point, when it is confirmed that the program will move
ahead, a Program File should be created – please refer to Mercy Corps’ Program Document Retention Policy53. The
initial documents in this file will be the proposal, budget, assessment documentation, and stakeholder lists prepared
during the Set Up and Planning phase (see Chapter 3 for details). During the Set Up and Planning phase, this file
will be populated by key planning documents as they are created. Note that creation of this Program File is a
Minimum Standard for Program Management at Mercy Corps.
It is likely that the Program File will also contain additional information such as success stories, the Stakeholder
Register (see Chapter 4 and 5), additional Monitoring and Evaluation documents (see Chapter 6), a Risk Matrix
(see Chapter 4), ad hoc communication to stakeholders (see Chapter 5), and communications materials (see
Chapter 5). Ultimately, the items to be added to the Program File over and above the minimum requirements can
be decided by the PMO and/ or Portfolio Management with guidance from the HQ Program Officer.
It is imperative that the Program File in the field and the Grant File kept at HQ by the finance team over-lap perfectly
on the agreement, modifications, change letters, log-frame, budget, and progress reports. Additionally, please refer
to the program document retention policy for guidance on which documents need to be retained at HQ in addition
to in the field. Also refer to Chapter 17 of the Field Finance Manual: Record Keeping and Archiving54, The Field
Procurement Manual55 and the Human Resources Management section of the Field Administration Manual56,
53 The Program Document Retention Policy is under development as of the release of this manual.
54 Field Finance Manual Section 17 – Record Keeping: https://mcdl.mercycorps.org/gsdl/docs/Section 17 - Record Keeping.pdf
55 Field Procurement Manual: https://mcdl.mercycorps.org/gsdl/docs/field procurement manual 2006.pdf
56 Field Administration Manual: https://mcdl.mercycorps.org/gsdl/docs/Field Administration Manual.pdf

Chapter 4
particularly regarding responsibilities for retention of original documents. If a document outlined in the Program File
pertains to an original kept by finance, the requirement is to include a copy of the document in the Program File.
The following list outlines the minimum records required to be retained in hard copy files. Where possible, the soft
copy file structure and content should mirror the official program hard copy file. This list is not all inclusive and items
not listed should be referred to your HQ Program Officer for guidance. 57
Program File Contents Checklist

Identification & Design57
See Annex 10 for a printable checklist
1. Assessments (see Minimum Standards checklist)

a. Written assessment or problem analysis (can be included in proposal document or can be a separate
assessment document)
2. External stakeholders list
a. List of external stakeholders (with contact information) participating in initial consultations
b. Community selection written rationale
c. Partner identification written rationale
3. Proposal or Preliminary Scope Statement
a. Final submission approved by donor
b. Logical Framework
c. Summary Budget
4. Documentation of the review of lessons learned and best practices
Set Up And Planning
1. Agreements
a. Final signed program agreement with donor
b. Agreements of Understanding – communities/partners/government (Memorandum of
Understanding (MOU), letters of support, etc.)
c. Modifications and amendments to program agreement
d. Official communications with donors, including requests (NCE, key personnel, waivers, etc.) and
approvals
2. Work Plan (see Minimum Standards checklist)
a. Key program parameters, coming from preliminary program documents
b. Work Breakdown Structure (WBS)
c. Program Schedule
d. Coded program budget
e. End of Program transition plan
57 The documents within Identification & Design should be drafted during the Identification and Design Phase. As a Program Manager will likely
not have been assigned at this stage, the documents should be retained by the HQ Program Officer. When a program is approved, the HQ
Program Officer will send an electronic package with the Identification and Design documents to the program team in the field.

Chapter 4
Implementation
1. Meeting Minutes
a. Kick-Off Meeting minutes
b. Program Team Coordination Meeting Minutes (quarterly)
c. External stakeholder meeting minutes
2. Reporting
a. Program reports submitted to donor (interim, annual and final)
b. Internal Program Progress reports
i. Means of verification such as beneficiary lists, attendance sheets, survey data, etc.
c. Updates to Program Work Plan
d. Issues Log (recommended)
e. Risk Register (recommended)
3. Sub-grants (see sub-grant manual and Grant File for more info)
a. Approved proposal and coded budget
b. Sub-grant agreement
c. Memorandum of Understanding
d. Program reports (interim, annual and final)
4. Deliverables58
a. Descriptions of Deliverables (Documentation of planning)
b. Verification of execution / proof of assistance received
c. Reports of quality assurance checks
5. Human Resources
a. Organizational chart (Personnel and Job Files are retained with HR)
b. Consultants
i. Consultant agreement
ii. Scope of Work
iii. Final deliverables / output
c. Training Needs Assessment
1. Indicator Plan / Performance Monitoring Plan (PMP)

a. Deviations formally documented and plan updated
2. M&E Event Reports (baseline, endline, and routine monitoring)
3. Evaluation Report (mid-term and final)
4. M&E Data Management System Reports
5. M&E Data Sources disaggregated by sex and age
a. Surveys
b. Beneficiary lists – activity, location, names, etc
c. Attendance sheets – trainings, meetings, etc
d. Pre- and post- tests from trainings
e. Routine monitoring reports (projects & sub-grants) CONTINUED ON PAGE 26
58 Requirements will vary based on intervention type. Please refer to the Program Document Retention Policy and Procedures for detailed
information on requirements.

Chapter 4
End-of-Program Transition
1. End-of-Program Transition Plan (written & approved)

a. Proof of communication to internal team members as well as external stakeholders
b. Sub-grant end of program closure documentation and formal acceptance of work performed
2. “Final 90 Day” Meeting Minutes
3. Handover report to external stakeholders
a. Handover of deliverables documented (includes infrastructure)
4. Lessons learned written document
Please note, all correspondence with donors, communities, partners, government, both formal and informal,
should be printed and filed under the relevant topic folder. Each numbered category should include a folder for
correspondence. For questions or guidance on this, please contact your HQ Program Officer.
4.2. Stakeholder Management Plan

A program is successful largely when the needs of the stakeholders have been met. During the Program Identification
and Design phase, potential stakeholders were identified, consulted, and listed (please refer to Chapter 3 for details).
During the Set Up and Planning phase, this list of stakeholders should be reviewed, and any additional internal
or external stakeholders should be added. For larger or more complex programs, the Program Manager should
consider developing a Stakeholder Register (see Annex 1), which is utilized during the Program Implementation
phase (see Chapter 5 for details) to pro-actively manage stakeholder expectations and communications. In all
programs, stakeholder management should be done proactively throughout the program cycle.
Once you understand who the stakeholders are, the next step is to ascertain their needs and interests. The best
way to do this is often by conducting stakeholder interviews or focus groups. Take time to draw out the true needs
that create real benefits. In some cultures, it may be necessary to hold separate focus groups with male and
female stakeholders and/or with different age groups to ascertain the different needs and interests of each group.
Understanding stakeholder interests in and potential influence on the program and planning early for the management
of stakeholder expectations can help the program team to avoid problems in the future and to benefit from positive
stakeholder influences. Use of a Stakeholder Register is a recommended step in the Set Up and Planning phase for
complex programs.
4.3 Program Work Plan

The remaining sections of this chapter focus on processes involved in the development of the Program Work Plan
(PWP). Successful Program Implementation is largely determined by the planning. Creating a PWP is critical. Often
planning is ignored in favor of starting work because of a sense of urgency. However, many fail to realize the value
of program planning in saving time, money and reducing problems during implementation. It also serves to bring the
team together so everyone understands their roles and collectively works towards the program objectives. Often, a
“work plan” is thought of to be a simple gantt chart or schedule. However, effective PWPs are much broader and
encompass planning for all aspects of program management. Coming out of the Program Identification and Design
phase there may be a high-level PWP already developed. Depending on the complexity or risk areas of a specific
program, large portions of the PWP will require further detailing by the PMO and available program team. Dedicated,
focused time of key stakeholders to the development of the PWP can enable a quicker planning process without
compromising comprehensive planning nor the required level of detail.
What is a Program Work Plan? Who creates it? What Should it Contain?
A Program Work Plan (PWP) inclusive of Key program parameters, coming from preliminary program
documents, a Work Breakdown Structure (WBS), a Program Schedule, a Coded Program Budget,
and an End-of-Program Transition Plan is a Mercy Corps Minimum Standard for Program Management
at Mercy Corps. It is a document or set of documents that sets out program requirements and activities for multiple
stakeholders – but critically the Program Team, including support staff, the PMO and formal partners – to work and

Chapter 4
track against. Hence as much as possible, the Program Team, PMO, partners and any support personnel should
participate in the PWP creation. If a particular role is not available at the time of PWP creation, the PMO should
identify a substitute for the anticipated role and develop its requirements within the program.
The level of complexity of the PWP can be decided
by the PMO and Portfolio Management: in some 1. Implementation planning is comprehensive;
cases, a very basic PWP that consists only of a WBS 2. Implementation planning is detailed;
(see 4.6.), Program Schedule, key M&E event plans, 3. Implementation planning emphasizes participation;
a Coded Program Budget, and an End-of-Program 4. Implementation planning prioritizes iteration.
Transition Plan may be sufficient; with complex – From A Guide to the PMD Pro
programs with multiple projects, stakeholders and
partners, much more may be required. The table below summarizes elements that are sometimes included in PWPs
for the consideration of each PMO, and denotes which of these elements are minimum requirements in Mercy Corps’
context:
Content Mercy Corps Minimum Standard Requirement?

Program Title Yes (from proposal or preliminary program scope
statement, see Chapter 3)
Start Date/ End Date Yes (from proposal or preliminary program scope
statement, see Chapter 3)
Constituent Projects and Sub-Projects No, but recommended for more complex programs
Donor(s) and Donor Compliance Requirements Yes (from grant agreement(s))
Program Tracking/ Reporting Codes No – discretion of PMO
Reporting Requirements Yes (from grant agreement(s) and Stakeholder Register
– see Chapter 3, 4, and 5)
Program Team Yes (see Chapter 4 and Chapter 5)
Key Support Personnel No, but recommended
Key Skills Needed Yes (see Chapter 5)
Delineation of Team/ Partner Roles & Responsibilities Yes (see Chapter 5, and also from proposal or
preliminary program scope statement, see Chapter 3)
Key Operational and Support Requirements (supply Yes (see Chapter 4)
chain, contracting, operations, security)
Stakeholder Register No, but recommended for more complex programs
Sectors and Technical Requirements Yes (from proposal or preliminary program scope
statement, see Chapter 3, and from technical planning
in Chapter 4)
Locations Yes (from assessment and proposal or preliminary
program scope statement, see Chapter 3)
Logical Framework Yes (see Chapter 3)
Key M&E Event Plans Yes (see Chapter 6)
Beneficiaries and Targeting Yes (from proposal or preliminary program scope
statement, see Chapter 3, but will likely require
additional planning)
Cross-Cutting Themes Yes (see Chapter 4)
Work Breakdown Structure (WBS) Yes (see Chapter 4)
Program Schedule Yes (see Chapter 4)
Baseline Schedule with initial critical path Yes (see Chapter 4 and Chapter 5)
CONTINUED ON PAGE 28

Chapter 4
Is/ Is Not Matrix59 No, but recommended (see Annex 2)

Risk Management Plan No, but recommended for more complex programs
End of Program Transition Plan Yes, (generally partially contained in proposal, see
Chapter 3, but must also be developed in the Set
Up and Planning phase, elaborated in the Program
Implementation phase, and finalized in the end of
program transition phase – see Chapter 7)
Coded Program Budget Yes (see Chapter 3 and Chapter 4)
59
Of the minimum aspects of the PWP mentioned above, most are self-explanatory, or are summarized elsewhere in
this document, in the annexes and in the A Guide to the PMD Pro. A typical Program Planning Workshop agenda
is summarized below:
Attendees:
List names and titles (include cross-functional representation, key external experts, key partners and community
stakeholders)
Reference Documents:
Mercy Corps Proposal, Grant Agreement, Budget, other documents as available
Agenda:
Day 1 morning – Day 2 morning – Day 3 morning –
Review Proposal & Logframe Create initial WBS Create Schedule
Brainstorm Is/Is Not Matrix Assign task ownership Discuss issues/concerns
(see sample in Annex 2) Develop WBS hierarchy
Review M&E Plans
Review Budget
Day 1 afternoon – Day 2 afternoon* – Day 3 afternoon –
Brainstorm Risks Develop dependencies Determine what additional
Develop Risk Matrix Estimate task duration functional plans are required
Determine Major Milestones Determine next steps
Plan Early for High Risk Areas

Planning is required for all aspects of a program; cutting across all functions (see figure above). Through planning
there is a higher probability that adequate time, money and resources will be allocated to achieve the desired
logframe objectives and outputs. Planning cuts across all functions human resources, procurement, administration,
logistics, security, compliance, monitoring and evaluation, technical and cross cutting themes. Depending on the
program, some elements have higher risks with greater impacts if detailed plans are not developed early enough in
the program lifecycle. Each program has specific areas of concern, however included in this chapter are common
problem areas, where careful planning can have large benefits for program efficiency and effectiveness.
4.4 End-of-Program Transition Plan

It might seem counter-intuitive, but it is important to start thinking about End-of-Program Transition during the Set Up
and Planning phase, and to include a preliminary End-of-Program Transition Plan in the PWP. There is no particular
format for this plan, but it should describe both the administrative close-out processes and the programmatic
transitional processes required – since this is discussed in Chapter 7 and is not repeated here. The End-of-Program
Transition Plan is preliminarily developed during the Set Up and Planning Phase, iterated or refined during the
Program Implementation phase, and executed during the End-of-Program Transition phase. A written End-of-
Program Transition Plan is a Minimum Standard for Program Management at Mercy Corps and is
further discussed in Chapter 7.
59 When specifying the program scope, an “Is/ Is Not Matrix” may be helpful to help various stakeholders understand what the program is and
is not designed to do. See Annex 2.

Chapter 4
4.5 Program Technical Requirements60 and Partnerships Plan

In the Set Up and Planning phase it is important to specify what technical skills are required to implement the
program. Resulting tasks and time estimates will later be integrated into the Work Breakdown Structure (WBS, see
4.6.) and Program Schedule (see 4.7.) within the Program Work Plan. Planning for technical requirements,
cross-cutting theme needs and partnerships and sub-grants is a Minimum Standard for Program
Management at Mercy Corps. Common technical sectors for Mercy Corps include food security and livelihoods,
public health, nutrition, water/ sanitation, agriculture, economic recovery and development, governance, climate
change, disaster risk reduction, and emergency response, although other technical sectors feature in Mercy Corps
programming as well. It is beyond the scope of this manual to describe the technical aspects of sector-specific
programming, because these vary greatly by sector, but the table below provides an example. Guidebooks, tip
sheets and lessons learned documents for most sectors can be found on the Digital Library. Regional or local
technical specialists, colleague agencies and TSU are also good resources for planning technical requirements for
your program or project. Remember that the technical requirements will also inform the ‘description of deliverables’
required in the Program Implementation phase (see Chapter 5).
Program Activity Area Skills Requirements Inputs

Community-based • Understanding of • Information, Education • Public health specialist
nutrition, hygiene, and Essential nutrition and Communication to assist with design of
sanitation awareness actions; Essential Materials key messages
campaigns hygiene and sanitation • Training materials for • Artist to design IEC
actions community facilitators materials
• Community Mobilization • Community mobilization • Training designer
Skills training to design training
• Training Abilities • Training of Trainers curriculum and deliver
(ToT) ToT
• Community mobilization
trainer
Food Distribution • Warehousing and • Warehousing and • Warehousing and
distribution skills transportation transport facilities
• End-use monitoring capabilities • Food assistance
• Understanding • End-use check forms; specialist to design
of caloric intake end-use check training forms, conduct training
requirements • Ration calculators;
training on caloric
requirements
Plan for Cross-Cutting Themes

In the Set Up and Planning phase it is important to specify what cross-cutting themes must be integrated into
Program Implementation. Resulting tasks and time estimates will later be integrated into the WBS and Program
Schedule. Similar to other technical requirements, resources for planning the cross cutting themes can be found
on the Digital Library or through technical specialists, either locally or on the TSU Common cross-cutting themes
include youth, gender, urban, community mobilization, governance, peace building, environment, and HIV/ AIDS. It is
beyond the scope of this manual to describe the cross-cutting themes, because these vary by program, but the table
that follows provides an example.
60 Technical requirements refer to the sector expertise required to effectively implement a program. For example, a maternal and child health
program may require public health expertise and a water and sanitation program might require expertise in water systems engineering and
waste management as well as public health.

Chapter 4
Example Cross-Cutting Theme Planning Matrix

Cross-Cutting Theme Skills Requirements Inputs
Gender • Program Team must • Gender-sensitive • Gender-specific
understand gender participatory methods, program policies within
issues as they pertain including separate Program Charter (if
to the program male/ female focus available), or set by
and its beneficiary groups in some cases PMO
communities, and • Disaggregated • Gender-related program
must understand how Stakeholder Register by requirements integrated
gender translates to gender into WBS
practical activities • 50% of Program Team • Orientation of Program
during Program must be women Team by gender
Implementation specialist
• 50% of community
training participants
must be women
• 50% of the officers
of community based
organizations formed or
strengthened must be
women
• Disaggregated
program Monitoring
and Evaluation data by
gender
Partnerships and Sub-Grant and Memorandum of Understanding (MoU) Requirements

Most Mercy Corps programs are implemented with partners or sub-recipients, which require formal sub-grant
agreements or partnership agreements. Other programs require non-financial MoUs with collaborating partners.
When initiating a program, it is important to finalize partnership requirements and estimate the time required to draft,
negotiate, review, and assign sub-grant agreements and MoUs. Sub-grants over $100,000 or sub-grants to US
registered NGOs must be drafted with the involvement of the HQ-based Finance, Training and Compliance team.
Likely, partners will be integral in planning the implementation of the program and thus these partnerships need to
be forming as the Set Up and Planning phase is occurring. Many teams find that successful partnerships are those
highly task-focused, where all partners are actively engaged in delivering tangible and practical results. Mercy Corps’
Local Partnerships: A Guide for Partnering with Civil Society, Business, and Government Groups is an essential
resource for forming and managing partnerships with Mercy Corps’ 10 Principles of Partnership highlighted within
the Guide. The Sub-grant Management Manual should guide partnerships involving the transfer of resources. Both
guides can be found in the Program Management Toolkit on the Digital Library
While the contractor relationship is very straightforward (namely, contractors are contracted to carry out a certain
task for a certain fee), the partner relationship is more complex, because Mercy Corps and the partner may wish to
engage in partner capacity development, which requires monitoring, mentoring, and, in many cases, formal training.
For these partnerships, it may be beneficial to development a Capacity Development Plan (CDP – see Local
Partnerships Guide). These capacity building tasks and requirements should be integrated into the PWP with the
information available. More detail may need to be added later, but in this manner time and resources can be allocated
for use at an unknown later time.
4.6 Work Breakdown Structure (WBS)

The Work Breakdown Structure is a hierarchical tree used to organize the activities of a program into related tasks.
A program is divided into projects or components, and these are then divided into sub-projects or sub-components,
and then into tasks or work packages, which is the lowest level of work. The work package feeds into various levels of
summary tasks and activities that eventually support the project objectives. WBS is described in greater detail with

Chapter 4
examples in PMD Pro. In addition, the steps for developing a WBS can be found in Annex 3: Tip Sheet for Creating
a Work Breakdown Structure (WBS).
The WBS is generally created prior to or in conjugation with the creation of the Program Schedule. The program
team and any internal or external stakeholders preferably create the WBS and schedule through a participatory
Program Planning Workshop. This workshop may be quite abbreviated for small and straightforward programs, or
may require considerable amounts of time and a relatively large number of people for large or complex programs.
Development of a Work Breakdown Structure as a component of the Program Work Plan is a Minimum
Standard for Program Management at Mercy Corps.
Plan for Supply Chain, Contracting, Operations and Security
For a program requiring supply chain (procurement, warehousing, distribution, transportation) and contracting of
goods and services, understanding these requirements and the time and risks of that procurement is a large portion
of making this type of program successful. Time requirements for finalizing these contracts and sub-agreements
should be discussed with responsible support personnel and incorporated into the Program Schedule, ensuring
adequate lead time to allow Mercy Corps’ standard sub-grant business processes (as per the Field Finance Manual)
and contract business process (as per the Field Procurement Manual) to be followed.
A significant mistake is not considering supply and contracting in the planning phase. In a program requiring
procurement, the tendering of a contract, lead time of delivery, and impact if delivery of poor quality occurs can be
1/3 to 1/2 of a program’s schedule. Planning, implementing and monitoring supply chain is key in these types of
programs. Points for program teams to consider are summarized in the table below:
Tips for Supply Chain and Contract Requirements

Procurement
Estimate time required for procurement training of Program Team in the early part of the Program
Implementation phase
Estimate tasks and time requirements start-up procurement in the early part of the Program Implementation
phase
Estimate time requirements for large tenders under the program
Determine preferred supplier agreements that will be needed, if any
Determine applications for waivers that will be needed, if any
Storage/Warehousing
Estimate time required for warehousing training for the Program Team
Determine if warehouse leases will be required
Estimate total space requirements for program goods and supplies, and then increase these by 25%
Determine whether the program includes any “kits” that can be assembled early in the Program
Implementation phase
Estimate stock levels and stock turnaround time
Set procedures for physical counts
CONTINUED ON PAGE 32

Chapter 4
Distribution
Consider likely distribution procedures, and time requirements

Consider likely distribution documentation that will be required
Estimate time required for distribution training for Program Team
Estimate staffing requirements to execute distribution procedures
Consider optimal packaging of program materials
Consider routine program supplies that will be required
Transportation
Determine vehicle needs and discuss lease vs. purchase decisions. Estimate time requirements to acquire
fleet – and secure waivers or prior approvals as required.
Estimate time requirements for registration, insurance, and provision of vehicle equipment.
Determine need for preferred supplier arrangements for fuel, maintenance.
Determine driver staffing needs
Estimate time required for driver security training
Setting up security for a new program can be a time and cost intensive process. Often these requirements must be in
place before programmatic work can start. Not doing so can significantly affect the success of the program. Mercy
Corps Field Security Manual and the office’s Security Focal Point, in established country offices, are essential
resources for planning security requirements. Some points to consider are also summarized in the table below.
Tips for Operational and Security Requirements

Operations Staffing
Initially, base operations staffing levels on the “ideal case”

For any program requiring more than office supplies in the supply chain, plan for a dedicated officer or
assistant
For any program requiring warehousing, plan for supervisory and labor requirements.
For any program requiring heavy maintenance or construction work, plan for appropriate technicians
Office Space and Supplies
Determine the number of Program Team members requiring quiet or secure space vs. those requiring “hot
desk” space only
Investigate office space availability and cost, including modular temporary solutions
Estimate time required for office-set up, ICT equipment set-up, and power back-up
Determine maintenance requirements
Security
Determine the need for a security assessment

If assessment is needed, estimate time and cost requirements
Determine physical security needs of both staff and property
Estimate timeframe required to implement security measures
Investigate legality and licensing of redundant communications capacity (VHF, HF, Satellite Equipment)
Conducting supply chain and contracting, personnel, operations and security planning is a Minimum
Standard of Program Management at Mercy Corps.

Chapter 4
4.7 Team Requirements and Structure

According to global project and program management standards, the Program Team is “acquired” (formed, or
recruited) during the Program Implementation phase. This is sometimes confusing, since it is difficult to think about
initiating and planning a program without a Program Team. However, here it is important to remember that many
aspects of the Set Up and Planning phases may be carried out by the PMO and Portfolio Management, before a
Program Manager and Program Team are assigned. In other cases, a Program Manager and possibly key program
team members might be assigned and lead some aspects of planning, but the remaining team members might not
be recruited until later.
Since the majority of the Program Team is “acquired” in the Program Implementation phase, the important step in the
Set Up and Planning phase is for the PMO to determine the right mix of team members and skills and the appropriate
organizational structure. The identification of required skills can aid the recruitment process, and can also be used as
the basis for a Team Member Training Needs Assessment (see Chapter 5). Ideally, the PMO should create position
descriptions with qualification requirements in the Set Up and Planning phase, so that in the Program Implementation
phase these position descriptions can simply be reviewed and updated prior to recruitment (see Chapter 5). During
the planning phase these positions should be designated in the schedule and roles and responsibilities matrix in
anticipation of the work they will perform.
Organizational Structure and its Relationship to Program Management
In planning the appropriate program team it is important to understand what the organizational structure is or what
should be used. Each portfolio manager and PMO must decide on the right kind of structure for the purposes of
the portfolio, because each has its own strengths and weaknesses. It is beyond the scope of this manual to go into
detail about these structures, but the PMO should research structural options, discuss which structure is most
conducive to program success without compromising other business processes, should discuss the structure, the
rationale for the structure, and the relationship between the structure and the program with the Program Manager
and the Program Team. The organizational structure should also consider existing programs and how the new staff
with interact.
No matter what type of organizational structure will be best fitted for managing a particular program, in assembling
organizational structures one common task is critical: A clear description of roles and responsibilities and reporting
lines for each member of the organization and partner involved with the program. This translates into clearly written
position descriptions, clear reporting structure and clearly defined approval authorities. Each program must have a
Program Organizational Chart that visually depicts the working and reporting relationships between team members,
and between the Program Team and the broader portfolio. A clearly defined Program Organizational Chart
for each program is a Minimum Standard for Program Management at Mercy Corps.
As the program progresses, the organizational structure may also evolve, so the Program Organizational Chart
should be regularly updated. It is important to share the updated Program Organizational Chart with staff and
partners so everyone understand the lines of reporting. It is the responsibility of the Program Manager and the PMO
to enforce these reporting lines and to ensure there is clear communication within the team.
4.8 Program Schedule

Once the WBS has been created to the desired level of detail, and once task owners have been identified and
documented, it is the time to create a Program Schedule.
Creating the schedule is a valuable team building activity. Through discussing who is delivering what, to whom, and
if tasks can be done at the same time or one after the other allows team members to gain mutual understanding and
consensus of the sequencing of Program Implementation. Valuable risk mitigation discussions help to identify tasks
which are dependent on external factors and interventions that can help to minimize potential negative impacts on the
program. Collaborative scheduling with available team members, program support staff and partners will also help
the Program Manager to define and schedule internal and external communications and ensure that modalities and
frequency for quality assurance are given sufficient consideration from the very beginning.
The finalized initial Program Schedule is called the “baseline schedule.” This is used at the program Kick-Off
Meeting with relevant stakeholders to set schedule expectations and understanding. During implementation, this

Chapter 4
schedule is tracked and modified as needed. It is tracked using % completion of tasks, and evaluated against
the original baseline with its interim and major milestones for providing a measurement of success at any point in
the program. The Program Schedule is a “linked” schedule that specifies the dependencies between each work
package or activity in the Work Breakdown Structure. Having a linked schedule is important because this allows the
schedule to adjust itself each time actual start dates and actual finish dates for tasks vary from planned start dates
and planned finish dates. Development of a Program Schedule as a component of the Program Work
Plan is a Minimum Standard for Program Management at Mercy Corps.
Schedule Tools
Complex programs will benefit from scheduling with the use of project management software, such as MS Project,
which assists program teams to identify dependencies and track progress against the baseline schedule.
When creating a schedule, inserting milestones can be a useful tool for tracking major points of program progress
while giving the Program Team smaller successes (“incremental benefits”) on which to focus rather than the entire
program’s goal. Milestones are significant events, which mark completion of a phase or subproject and can be used
to group major components of a program. The top levels of the WBS are a good source for milestones.
Critical path is another schedule tool, which focuses the Program Team on priorities. The Critical Path is the route
through which the program tasks take the shortest amount of time to complete and is easily identified by MS Project.
If a single task on the critical path is delayed, it means all the tasks behind it are delayed. There is no slack time,
float or extra days, therefore unlike other tasks, delays in tasks on the critical path can delay the delivery of the entire
program. Using this tool the Program Manager can prioritize a critical path task over another, reducing delays in the
program without having to track all detailed tasks all the time.
The steps for developing a schedule can be found in Annex 4: Tip Sheet for Creating a Schedule.
Risk Management Planning
Risk management is an important part of program management. Every program has risks that threaten to cause
program failure. Program risk management involves firstly identifying the risks that impact your program. Although
often overlooked, it is important to identify as many risks to your program as possible, and be prepared if something
bad happens. It’s best to get as many people involved in the risk identification process as possible. Examples of
common programmatic risks include:
• Proposal time and cost estimates too
optimistic Identify Risks
New Risks
• Stakeholder review and feedback cycle too 1. Identify Potential Risks
2. Review previous low-priority risks
slow
• Unexpected budget cuts Know Risks
• Lack of resource commitment slows work
• Currency fluctuations disrupt budget availability Develop Response Plans
or accuracy of projections
1. Define each risk, icluding the
• Political instability causes government partners probability and potential negative
impact
to hinder community cooperation 2. Develop a response for
• Security risks block traditional transportation high-priority risks
routes or stakeholder participation Risk management plan Risk management plan
Risks can be tracked using a simple risk matrix. Add

each risk you have identified to your risk matrix; write Establish Reserves Continuous Risk Mgmt.
down what you will do in the event it occurs, and what
1. Allocate risk contingency for 1. Monitor for new risks
you will do to prevent it from occurring. Next, analyze known risks 2. Report status at regulat intervals
the risks. Risk analysis can take many forms, however, 2. Establish management reserve
for unknown risks
3. Upon a risk event:
they usually revolve around providing answers to three – Execute response plan
– Update entire plan
questions:
Reserves Updates to risk management plan
Work with
Finance Support

Chapter 4
1. What is the probability of the risk event occurring?

2. What would be the impact on the program if the risk event were to occur?
3. What steps can be taken to minimize the impact of the risk event if it did happen?
Answering the third question provides your risk mitigation strategy for each risk. You then need to decide for each risk
who will implement the strategy, with which resources and by when. See the Risk Management Tip Sheet in Annex
5 for steps of risk management planning.
Review your risk log on a regular basis, adding new risks as they occur during the life of the program. Remember,
when risks are ignored they don’t go away.
Risk Management is an iterative activity performed throughout the entire duration of the program. In essence the
Program Manager is a risk manager. The PMO and Program Team should be constantly anticipating what could
impact the program and how to avoid or mitigate those impacts keeping the project moving forward, as per the
“Managing Issues” section of Chapter 5. An initial Risk Assessment should be done in the proposal phase so high
probability and severe risks can be incorporated into the proposal plan (contingency or mitigation planning). This
initial Risk Assessment should now be re-assessed in the planning phase, when there is more information and a
larger cross-functional team is available for input.
Plan for Quality Assurance
Descriptions of individual program deliverables form the basis for quality assurance. Descriptions of deliverables are
created by the Program Team throughout the Program Implementation phase, on an as needed basis, not all at once.
Examples of descriptions of deliverables include:
• Training agendas, materials, and facilitators’ notes for trainings
• Design drawings and Bill of Quantities for infrastructure
• Scope of Work or Terms of Reference for technical consultancies
• Approach and process documentation (for example, a community mobilization process, or nutrition rehabilitation
process, or a farmers’ capacity building process)
Ensure that a relevant Program Team member is assigned to develop each of these descriptions of deliverables, and
that these are approved by the Program Manager as they are developed.
All programs require quality checks either through an M&E process or through quality assurance checks or both.
During the course of implementation, quality assurance checks should be conducted, and should be included within
the Program Schedule in the PWP, and should be carried out by someone outside of the direct Program Team.
An example of what is described above is summarized in the table below:
Deliverables 1,000 latrines

Description of Deliverables Standard latrine drawing and Bill of Quantities
Quality Assurance Checks Visits during and after construction to confirm the total number of latrines
(physical verification), and the actual design of the latrines as compared to the
planned design within the description of deliverables
Plan for Monitoring and Evaluation (M&E)
Monitoring and Evaluation Processes compare program performance to the objectives and indicators in the original
proposal, as well as to the Program Work Plan and Indicator Plan. M&E data are actively used through the Program
Implementation phase to track that the program is achieving desired results. If there are unacceptable variances,
Monitoring and Evaluation results can be used to make adjustments to program plans through a change process
(see Chapter 5). Based on the degree of change, elements of the PWP may need to be updated to reflect the new
actions.
Planning for effective M&E begins in the Program Identification and Design phase by incorporating SMART
objectives (see section 3.6) and well thought-out indicators into the program logframe. Implementation plans are
then developed in the planning phase. A well-developed M&E plan can take time to develop and the design should

Chapter 4
begin as soon as possible to then enable implementation planning and integration into the Program Work Plan as
early in the process as possible. Effective evaluation planning should begin at this phase, with appropriate budgeting
and staffing for M&E and allocation of time in the PWP. The following components make up the M&E Plan, additional
information for each can be found in Chapter 6 and DM&E-in-a-Box61.
Indicator Plan: The indicator plan will enable planning (time, budget, human and other resources required) for
any required M&E work. This plan should be done before the WBS process so that the resulting requirements
can be reflected in detail in the WBS and then integrated into the Program Schedule. Include Mission Metrics
indicator alignments in the indicator plan.
&E Schedule: Include monitoring as a key management activity and make resources available to carry it out,
M
including roles and responsibilities, budgeting time for baselines, regular data collection, review and reporting,
and midterm and final evaluations. Include key management and implementation tasks, persons responsible
and clear targets for achieving them so that we can track performance over time. The M&E Schedule should be
integrated into the broader Program Schedule.
4.9 Program Budget

At the Set Up and Planning phase, the proposal budget created in the Program Identification and Design phase
requires additional work in order to provide the level of detail necessary to plan and manage program activities.
Program budget planning consists of three distinct parts:
1. Additional detailed breakdown of the proposal budget
2. Financial coding of the detailed budget.
3. Creating activity level budgets.
Parts 1 and 2 above are related to overall budget management, and occur prior to beginning implementation. This
should be done by the Program Manager with the support of the Finance Manager and the Program Team. Part 3
is the creation of budgets for individual activities implemented under a program and are generally prepared by the
Program Team as the individual activities are identified. Initial activity budgets can be prepared in the Set Up and
Planning phase, with additional activity level budgeting continuing during implementation. However, it is important
that activity budgets be prepared and approved well in advance and in coordination with relevant operations staff to
ensure sufficient time for implementation of logistics requirements.
Additional Detailed Breakdown of the Proposal Budget.
Proposal budgets are generally not prepared at the level of detail required to assign budget responsibilities and
monitor actual expenses against the budget. Requirements in the Set Up and Planning phase include:
• Divide the budget between “program costs” and “support costs.” This division is used to assign separate
budget responsibility for program costs and support costs.
• Divide the budget among offices supporting and implementing the program. Each budget line needs to be
assigned to a specific office. This includes program activity costs.
• Show budget amounts by month for the first year of implementation, and annually for the remaining years of
implementation.
See “Creating Detailed Grant Implementation Budgets” document on the Digital Library62.
61 DM&E-in-a-Box: https://mcdl.mercycorps.org/gsdl/cgi-bin/library?a=p&p=dme
62 The Creating Detailed Grant Implementation Budgets Tip Sheet was under development at the release of this manual.

Chapter 4
Financial Coding of the Detailed Budget

After the detailed budget from the Program Identification and Design phase has been broken down to provide
additional detail, the “coded” budget is created by assigning financial codes to each individual line of the budget.
How the budget is coded determines how expenses are classified in the financial software. This level of detail
provided by the coding determines what management reports can be provided to the Program Manager or PMO by
Finance.
The Finance Manager and the Program Manager or PMO should work together to determine the coding structure
that will be used for the activity, task, or work package accounting code dimensions, called the “Activity” dimension
in Mercy Corps’ financial software. A unique code should be assigned to each individual activity.
For specific instructions on coding the budget see the Mercy Corps Coding Methodology63 . Development of a
Coded Program Budget as a component of the PWP is a Minimum Standard for Program Management
at Mercy Corps.
Creating an Activity Budget
Activity budgets are detailed budgets with lines for each activity by the individual types of costs needed to be
incurred for activity implementation. Generally these are in alignment with the ‘work package’ levels of the Program
Schedule or Work Breakdown Structure.
Often, when a proposal budget is being created (see Chapter 3), program activity costs are shown as lump sum
amounts with little, if any detail, on how they will actually be spent. Activities budgets are a subset of these lump sum
budget lines and provide the detail of what the estimated individual costs are to implement the activity.
Creating an activity budget can occur during the Set Up and Planning phase, or can be an on-going action when the
detailed costs related to implementing an individual activity are often not known at the start of a program. Steps for
creating an activity budget (these steps are done at the same time, instead of in a linear sequence) include:
1. Identify each step necessary to implement the program activity.
2. Identify types of costs associated which each step.
3. Identify number of units needed for the particular cost.
4. Estimate unit cost.
5. Create the budget
An example of steps to take in creation of an activity budget, see Annex 6: Example Process for Creating an Activity
Budget.
63 Mercy Corps Coding Methodology: https://mcdl.mercycorps.org/gsdl/docs/Mercy Corps Coding Methodology.pdf

Chapter 5
The Program Implementation Phase
Chapter 5: The Program Implementation Phase

Implementation
S S S S S
Launch
Program
Manage
Implementation
Track & Adjust
Manage Human
Resources
Manage
Issues
S Manage
Organizational
Capacities
S S T S T S
Program Issues Log
PWP Approval Conduct Team Assess
Performance Orient Program
& Regular Coordination Infrastructure
Work Plan Team
Updates Meetings & Procedures
T T T T S S
RACI Matrix Stakeholder Risk Team Member
Perform Create
Register Register Training Needs
Change Strategic
Assessment
Management Alliances
T S S T T
Sample Kick Quality Performance Local
Report to Assurance
Off Meeting Management: Partnerships
and Update Checks of
Agenda Instructions & Guide
Stakeholders Descriptions of Documents
Deliverables
T T T
Actual vs.
Mercy Corps Baseline Field
Report Writing Schedule Administration
Guide Reports and Manual
Critical Path
Tracking Sheet
S S
Carry out
Cost Control
Manage Team
Transitions
T
Budget vs.
Actual reports
and CPI
OO TO
Procurement
Kick-Off PDs &
Program Master List &
Meeting Training Needs
Reports Activity Budgets
Minutes Assessment
OO O
Program
Team Approved
BVAs
Performance & Updated
with Projections
Assessments PWP
38
S T
Process Step
< Table of Contents
Tool
mercycorps.org
Chapter 5
Minimum Standards for the Program Implementation Phase:

�� Program Work Plan (PWP) is approved and regularly updated (see 5.1)
� Program Kick-Off Meeting is conducted, and minutes are available (see 5.1)
� Program Team Coordination Meetings take place at least once per quarter with documented minutes (see
5.2)
� Program Progress reports (narrative and financial) exist and include progress toward indicator targets
(see 5.2)
� Scheduled and ad hoc reports and updates are communicated to stakeholders (see5.2)
� Actual Program Schedule (within PWP) is updated against the Baseline Schedule by Program Manager
and submitted to supervisor on a monthly basis (see 5.3)
� Descriptions of deliverables exist, and quality assurance checks are carried out at least twice per program
year (see 5.3)
� Budget vs. Actual reports for the Program Budget are prepared monthly, and projections against the
Program Budget are prepared quarterly (see 5.3)
� Program Team receives copies of, and is oriented on: Proposal and Logical Framework, M&E plan,
Program Work Plan (PWP), Kick-Off Meeting minutes and relevant parts of the Program Budget and
Grant Agreement. Program Team is oriented on administration and finance procedures (FAM, FFM, FPM),
and roles & responsibilities for contractors and partners (see 5.4)
� Program Team is recruited; roles, responsibilities, and required skills have been articulated; Position
Descriptions exist; Training Needs Assessment is carried out (see 5.4)
� Program Team member performance is assessed and documented by Program Manager within three
months of program start, and annually thereafter (see 5.4)
Monitoring & Evaluation Minimum Standards for the Implementation Phase

� Key program M&E events (at a minimum, baseline, end-line, and routine monitoring) have been carried
out, and reports of these events exist (see 6.3 & 6.4)
� Basic M&E data management system exists (see 6.4)
� Evaluation report exists (see 6.4)
About This Chapter

The Program Implementation phase follows the Identification & Design and Set Up and Planning phases. It is the
phase in which the designed and planned program is executed and tracked. The program management steps in
the Program Implementation phase are not necessarily linear –many steps will take place in an iterative manner
furthering the detail of program planning and using monitoring, evaluation and quality control feedback.
This chapter describes the key program management steps during the Program Implementation phase. While much
of the work that is done during the Program Implementation phase is about technical performance (that is, specific to
a sector or sectors), there are certain program management processes that can help to ensure good programmatic
results across all sectors. These are described below, divided into the following categories: 5.1) Launching the
Program; 5.2) Managing Program Implementation; 5.3) Program Tracking and Adjustment; 5.4) Managing Program
Human Resources; 5.5) Managing Issues; and, 5.6) Managing Organizational Capacities. Implementation relies
heavily on the Program Work Plan (PWP) developed in the Set Up and Planning phase (see Chapter 4), which
should be regularly updated throughout the Program Implementation phase.
5.1. Launching the Program

Approval of Program Work Plan (PWP)
The first step of the Program Implementation phase is for portfolio management and the PMO to approve the Program
Work Plan that was developed in the Set Up and Planning phase. If a Program Manager has been appointed at this
point, they will also be involved in this step; however, in some cases, the Program Manager will not be recruited
until after the Program Implementation phase has begun. The purpose of PWP approval is to confirm that those
responsible for creating an enabling environment for program success are in agreement with the program’s plans.

Chapter 5
At this point, the reviewers should also ensure that tasks for cross-cutting themes and program support have been
incorporated into the PWP during the Set Up and Planning phase, and that lessons learned documentation from
previous, similar Mercy Corps interventions has been considered. Approval of and updates to the Program
Work Plan must be provided in writing and must be included in the Program File as a Minimum
Standard for Program Management at Mercy Corps.
Review Assignment of Individuals to Tasks within Program Work Plan (PWP)
When the Program Work Plan is created in the Set Up and Planning Phase, members of the Program Team –
and, in some cases, external stakeholders such as contractors and partners – are assigned to individual tasks
within the PWP. Early in the Program Implementation phase, The Program Manager should review and update
these assignments to ensure that they remain current with the planned program team composition and the staffing
structures of partners and contractors, or are adjusted to reflect changes that have occurred.
If a stakeholder register was created in the Set Up and Planning phase (recommended for more complex programs) it
should be reviewed and updated. Any new stakeholders that have emerged since the register was initially developed
should be added. Consider using a RACI Matrix to help manage stakeholders. Further information and a sample
RACI Matrix can be found in the A Guide to the PMD Pro.
Conduct Kick-Off Meeting
Once the PWP is approved, a Kick-Off Meeting should be held. Ideally, this should be done with the full Program
Team after they have been hired, including finance, operations and PMO team members, as well as key external
stakeholders such as partner agency leadership. It is important to ensure that team members who join the team after
this meeting are fully oriented to the key program documents and the PWP. Important emphasis during the Kick-
Off Meeting should be placed on establishing a common understanding and acceptance of the logframe, and the
baseline schedule, milestones and critical path. As well, the Kick-Off Meeting is a good time to establish accepted
team behavior and setting of cultural standards, which can also be used as training points when new team members
arrive so expectations are understood. It is important to set guidelines for how a team will function on a regular basis;
weekly, monthly, and quarterly. The Program Manager must define what the reporting structures are, how items will
be communicated, what regular meetings will be held, what mechanisms will be used for quality assurance and how
changes will be handled. Please refer to Annex 7 for a Sample Kick-Off Meeting Agenda. Minutes of the Kick-
Off Meeting must be included in the Program File as a Minimum Standard for Program Management
at Mercy Corps.
It is important to ensure team members feel comfortable to ask questions and understand the range of documents
created for program management purposes. Cultural differences may exist and should be considered. While some
cultures heavily rely on documents in written form, others may see greater value in verbal communication and may not
see the value in the longer-term PWP. It is up to the Program Manager and the PMO to negotiate these differences
and find balance so team members are not overwhelmed with the documentation; have clarity in their role and
responsibilities within the program; and feel like they can effectively contribute to program thinking.
5.2. Managing Program Implementation

Schedule and Conduct Regular Coordination Meetings
Regular coordination meetings, which begin with the Kick-Off Meeting and an early meeting to clarify roles and
responsibilities, should be conducted during the course of the Program Implementation phase. Topics covered in
these coordination meetings should include program progress, technical updates, stakeholder management, cost
management, Monitoring and Evaluation tasks and results, program transition strategy, and potential programmatic
or contextual issues and changes that may influence program scope or require pre-approval or justification. The
PMO and Program Manager should determine the frequency of these meeting. Program Team Coordination
Meetings must take place at least once per quarter (every three months) as a Minimum Standard for
Program Management at Mercy Corps. Coordination of sub-teams may occur with much greater frequency,
for example weekly implementation status meetings. It is recommended that team meetings include key program
support staff (logistics, administration, finance, heads of office, etc.) and partners in addition to the direct program
team. In some cases it is useful to invite other stakeholders at the discretion of the Program Manager. It is a good
strategy to circulate an agenda prior to the meeting so team members come prepared to discuss specific program

Chapter 5
information. These meetings also offer an opportunity to do culturally appropriate team building exercises to strengthen
communication and trust and reinforce feelings of team membership and enjoyment within the workspace.
Implement Communications
During the Set Up and Planning phase, communications requirements were identified and included in the PWP and
stakeholder register (recommended for complex programs). Below are descriptions of typical reporting performed
during the Program Implementation phase.
Cross-check Reporting Schedule within Grant Agreement and PWP: Most programs are associated with one or
more awards (grants), which generally come with grant agreements that specify donor reporting requirements.
Mercy Corps’ Report Writing Guide provides useful in-depth guidance for structuring and writing monitoring reports,
including a sample reporting format64. This is also a good time to enter Mission Metrics alignment and scheduled
report dates in the Mission Metrics65 Data System.
In some countries, organizations are required to share program updates with the host country government. During
the planning phase, the Program Manager should cross-check that all internal, host country government and other
stakeholder reporting requirements have been incorporated into the PWP within the Program Schedule, and that
adequate information gathering, writing and review time for each report is allocated. The Program Manager
must ensure that professional quality program progress reports that include progress toward
indicator targets are filed regularly as per the requirements and that all reports exist with proof
of their submission within the Program File as a Minimum Standard for Program Management at
Mercy Corps. All data and events that are reported in the program progress reports should be easily verifiable from
the contents of the program file.
Prepare Fact Sheet and Appoint a Spokesperson: In some cases, at the discretion of portfolio management, the PMO
and Program Manager may wish to prepare a program fact sheet (a one-page document summarizing the program
for external communication purposes) and/ or appoint a program spokesperson (generally the Program Manager,
but sometimes another position-holder for large or complex programs) to streamline external communications and
public relations.
Define Communication Expectations of Each Stakeholder; Report Accordingly: The communication expectations
of each stakeholder should be included in the PWP and in the Stakeholder Register where applicable (see Chapter
4) and communication should be carried out accordingly. For example, a dispersed Program Team may require
weekly updates; host country government stakeholders may require a report every six months; donors may require a
report every three months; and, beneficiary groups and headquarters stakeholders may require ad hoc reports. The
Program Manager may also wish to consider scheduled or ad hoc reporting of program highlights or achievement of
milestones, to all key stakeholders, which is sometimes a good way to manage program communications proactively.
It is a Minimum Standard for scheduled and ad hoc reports and updates to be communicated to
stakeholders and documented in the Program File with reference dates for Program Management at
Mercy Corps.
5.3. Program Tracking and Adjustment

During the Set Up and Planning phase many plans are created and incorporated into the PWP, which is then used
in the Program Implementation phase to guide the team in anticipation of achieving successful outcomes. A major
role of the Program Manager during implementation is the incremental (day-by-day) tracking and adjustment of the
PWP to ensure continued success. The purpose of tracking is to look for variation or drifting away from the plan,
especially the program parameters, schedule and budget. If the variation becomes great enough, the Program
Manager and team must make adjustments. This may require small changes in activities or set up of a significant
re-planning effort, which can have program-wide impacts. Typical tracking areas detailed below include tracking the
schedule, analysis of M&E data, quality assurance, cost control, supply chain tracking, monitoring and mentoring of
partners and risk tracking.
64 MC Report-writing Guide: https://mcdl.mercycorps.org/gsdl/docs/Report%20Writing%20Guide%20DME.pdf

65 Mission Metrics Indicator Guidelines: https://mcdl.mercycorps.org/gsdl/cgi-
bin/library?a=q&r=1&hs=1&t= 0&c=all&h=dtt&q=mission+metrics+guidelines

Chapter 5
Tracking the Schedule

Weekly or as appropriate, the Program Manager should update the Program Schedule by updating program tasks
completion status. Especially for complex programs, it is recommended that Program Managers do this in Mercy
Corps’ recommended project management software (MS Project), and share the updates with the Program Team
and the PMO on a regular basis. It is critical that schedule updates be proactively shared and clearly understood by
the Program Team. In the event that the updated Program Schedule shows significant variance between the baseline
or expected schedule and actual schedule, the Program Manager, the Program Team, and the PMO may need to
discuss corrective action (see Manage Issues). The Program Manager must update the actual schedule
against the baseline schedule and provide to their supervisor on a monthly basis an updated schedule
shown against the original baseline schedule as a Minimum Standard for Program Management at
Mercy Corps.
Using the Critical Path for Tracking: During the schedule tracking process, the critical path is used to prioritize team
work, ensuring that priority activities are being worked on at any particular time. The critical path, as seen in Chapter
4, refers to the shortest path of planned activities until the end of the program. This is important because delays in
the critical path will lead to delays in the overall program. A Program Manager is able to use this tool to make the
most efficient use of a team’s time.
Tracking of the critical path and larger schedule is done most easily through the use of software such as Microsoft
Project which has the capability to provide reports against the baseline schedule. For instances where this is done
manually, Annex 8: Sample Baseline Schedule Tracking Sheet may be helpful.
Analysis of M&E Data
M&E data can be a useful check to ensure that the program is on track to achieve outcomes as well as double-
checking achievements against the schedule. See Chapter 6 for more information.
Carry Out Quality Assurance
During the course of implementation, quality assurance checks must be conducted. As described in Chapter 4,
the descriptions of deliverables are the basis against which quality assurance checks are conducted. Descriptions
of deliverables must be developed as individual activities become known (training workshop, construction project,
etc.) during the Program Implementation phase. Quality assurance checks should be scheduled within the Program
Schedule, and should be carried out by someone outside of the direct program team (ideally by the PMO or HQ-
based Program Officer and an appropriately trained evaluator), together with the Program Manager. As a Minimum
Standard for Project Management at Mercy Corps, Descriptions of Deliverables must be developed
and quality assurance checks must be carried out at least twice per program year. During quality
assurance checks, actual deliverables should be checked against planned descriptions of deliverables, and any
discrepancies should be reported to the program team, PMO, and portfolio management so that corrective action, if
required, can be taken. In some cases, the PMO or Program Manager may wish to prepare checklists to make quality
assurance checks easier. Quality Assurance is different to routine monitoring in that it focuses on comparisons the
quality of actual outputs to the descriptions of deliverables as opposed to measurements of established program
indicators.
Carry Out Cost Control
During the course of
implementation, monthly CPI Example:
Budget vs. Actual Reports
must be prepared and The CPI is the ratio between money spent and time elapsed. A Program Team
analyzed and projections is 8 months into a 24-month, $600,000 program. This means that 33% (8/ 24)
should be prepared of the program duration has elapsed.
at least quarterly as a The Budget vs. Actual report as of the 8th month shows expenditures against
Minimum Standard for the Program Budget of $150,000, or 25% ($150,000/ $600,000).
Program Management
at Mercy Corps. Generally CPI is calculated by taking the percentage of the budget spent and dividing it
these are prepared as a by the percentage of the time elapsed (25%/ 33%), or 0.76. Since this is less
Finance function, and analyzed than 1, action to accelerate expenditure should be considered.
by: Finance, the Program

Chapter 5
Manager, relevant members of the Program Team, the PMO and, in some cases, Portfolio Management. Budget vs.
Actual Reports compare actual expenditures to the original budget – as drafted during the identification & design
phase and finalized during the Set Up and Planning phase.
When a Budget vs. Actual Report is filed, a Cost-Performance Index (CPI) should be calculated (see example to
the right). This simply takes the ratio between the percentage of time elapsed and the percentage of money spent.
To the extent possible, the CPI should be at or near one (1), meaning that the percentage of money spent and time
elapsed are roughly equal. In cases where it is either significantly greater or less than one, the Program Manager
should discuss the reasons and potential corrective action with the PMO and the Program Team. It is important to
review the CPI of sub-grantees through their financial reports in the same way and to discuss causes and necessary
adjustments with the partner if the CPI is too far from 1. Many more options for correcting budget variances exist
when they are caught early in the program as opposed to at the end, so regular cost control is very important. A CPI
that is too high or too low can be a useful indicator of program progress.
Every three months, at a minimum, quarterly budget projections should also be prepared and analyzed by the Program
Manager with support from the Finance Manager. These are an expanded version of Budget vs. Actual Reports, in
that they add a forecast column to the most recent Budget vs. Actual Report to predict total program expenditures
against the original budget. All outstanding financial commitments and plans for operational and program expenses
should be incorporated into the forecast. The office’s Procurement Master List and all existing activity budgets should
be considered in the forecast. At this time, if forecasts project over-expenditure or under-expenditure, corrective
action is required.
Track and Carry Out Supply Chain Requirements
The PWP should include a procurement plan with the roles and responsibilities clearly defining who is responsible
and accountable for each major supply chain transaction required to implement the program, including members of
the Program Team, Logistics/ Procurement and the Finance Department. During the Program Implementation phase,
the Program Manager and other stakeholders must ensure that these procurement transactions, sub-grants, and
contracts are executed as per program requirements, the Program Schedule, donor regulations, the Mercy Corps
Sub-Grant Manual and Mercy Corps’ procurement and financial policies. Joint supply chain planning workshops
and coordination meetings with all relevant stakeholders should be held regularly throughout implementation. The
Procurement Master List can be a useful tool upon which to structure communications and monitoring of progress.
Mentor and Monitor Program Partner(s)
The PWP with roles and responsibilities should clearly define the deliverables and delineation between Mercy
Corps and its partners. It is critical during the Program Implementation phase, that the Program Manager track
the requirements and deliverables of these partners against documented requirements. This can be done during
coordination meetings, through the M&E plan and via Quality Assurance checks. To the extent possible, the nature
of the partnership and its relationship to program scope should be clarified during the Program Identification and
Design phase, however, during implementation iterative and detailed collaborative planning workshops may need
to occur regularly as more information becomes available. Further guidance for M&E with partners can be found in
Mercy Corps’ Local Partnerships Guide.
Track Program Risk
During the Set Up and Planning phase a risk assessment and analysis, followed by recommended risk mitigation
measures, will be developed for some programs. During the Program Implementation phase, the Program Manager
and PMO should ensure that risk reduction measures are being followed, and should track the risk environment to
inform any necessary adjustments or course corrections. A risk register could be a useful tool for this process.
5.4. Manage Program Human Resources

Acquire and Orient Program Team
Depending on the status of the portfolio prior to the Program Implementation phase of a given program, the Program
Team may or may not already be in place. Many team members may be acquired throughout the life of a program.
If the Program Team is not already in place, the following must be carried out at the beginning of the Program
Implementation phase: re-assess staffing needs (initial needs should have been determined during planning), based

Chapter 5
on program objectives and tasks; create or update Position Descriptions for each team member; and, recruit the
Program Team. For all of these processes, steps outlined in the Field Administration Manual66 should be followed,
supplemented by Human Resources policies at the country portfolio and headquarters levels. Hiring the right staff
to meet the program needs is a critical factor for the success of your program. For this reason, extra care should be
taken to ensure that staff not only meet the experience and technical requirements of the job but also fit the culture
you aim to build within your team. Most programs will benefit from team members who are pro-active communicators,
are motivated by the program objectives and agency mission, are positive influences on their peers, are proactive
at resolving issues, are open and collaborative and respectful of the backgrounds, beliefs and the roles of other
stakeholders. Recruitment should incorporate strategies for assessing the most important skills and attributes
required. 67
Consider what type of program team will best be able to reach and work with stakeholders in a culturally
appropriate manner. For example, a project aiming to increase access to potable water for communities in Sudan
would benefit from at least one female community member who can easily reach the Sudanese women who are
the main water managers and users. This will positively impact both the quality and usefulness of the project.
It is important that all Program Team members have access to information and share a common vision and
understanding of the program. A lack of information can lead to poor performance or time and energy being spent on
activities outside the program or operational scope. As well, team members who are not well informed and included
in information dissemination from the beginning and throughout implementation may feel disenfranchised from the
team and experience lower levels of motivation and commitment.
Once recruited, Program Team members should be oriented to Mercy Corps and country program culture, strategies,
and operating procedures; and take part in a program-specific orientation. As a Minimum Standard for Program
Management at Mercy Corps, the Program Team must receive copies of, and be oriented on: Proposal
and Logical Framework; PWP; Kick-Off Meeting minutes and relevant parts of the Program Budget
and Grant Agreement. Program Team must be oriented on administration and finance procedures
(FAM-Field Administration Manual, FFM-Field Finance Manual, FPM-Field Procurement Manual, and
in-country policies), and roles & responsibilities for contractors and partners. When large numbers of
staff are hired at the same time, a workshop to provide an overview of the program and related documents can be an
effective way of orienting new team members to the program. A standardized introduction to the program should be
developed when staff will be hired over an extended period to ensure all staff receive a full program orientation.
Conduct Team Member Training Needs Assessment
Based on the required skills identified during Set Up and Planning, a team Training Needs Assessment should be
conducted by the Program Manager. The findings of this assessment form the basis for facilitating the provision of
training and mentoring to enhance team member skills. The Training Needs Assessment also helps to demonstrate
the Program Manager’s and the agency’s genuine interest in the staff’s professional development and desire for
them to succeed. Mercy Corps values the learning and teaching capacities of all staff, so Program Managers are
encouraged to identify opportunities for peer-to-peer learning and mentoring and for fostering a culture of learning
and teaching as everyone’s responsibility. Please see Annex 9 for a recommended Program Team Training Needs
Assessment format. For each position on the Program Team, this format identifies skills required, existing, needed
skills, and the means and timeframe of skill acquisition recommended. Even the most qualified team members will
benefit from focused and intentional professional development planning.
As a Minimum Standard for Program Management at Mercy Corps, the Program Team is recruited;
roles, responsibilities, and required skills are articulated; Position Descriptions Exist; and a Training
Needs Assessment must be carried out.
66 Field Administration Manual: https://mcdl.mercycorps.org/gsdl/docs/Field Administration Manual.pdf

67 Gender Programming at Mercy Corps: Findings from the Global Gender Assessment, see page 3: https://mcdl.mercycorps.org/gsdl/docs/
2010GenderAssessmentSummary.pdf

Chapter 5
Conduct Team Member Training and Mentoring

Once the needed skills and follow-up actions required are identified using a Team Member Training Needs Assessment,
the Program Manager should coordinate – or should designate a Program Team member to coordinate – training
and mentoring as required over the recommended time frame to augment in the Training Needs Assessment for
Program Team members. As a reminder, it will always be difficult to implement a successful program if the team
members do not have the required skills, so the importance of this step should not be underestimated. Whenever
team members can teach other team members a sense of cooperation and peer learning is created, which can be
beneficial to the performance and development of the team.
Assess Team Member Performance
Performance Management is an on-going process involving communication, documentation and discussion throughout
the year and is not limited to the formal annual evaluation. A probationary or annual evaluation formally documents,
in summary form, discussions during the review period (see Field Administration Manual for more information on
performance management at Mercy Corps). As a Minimum Standard, Performance of all Program Team
members must be formally assessed and documented at the following intervals: a) At the 3-month
mark of any new program; and, b) annually thereafter, as per Mercy Corps’ Performance Management
Tools (see Office in a Box for formats). Note that the three-month review period of Program Team members on
new programs is important because it allows risks and strengths within the Program Team to be realized early, and
adjustments to be made accordingly, which can increase the likelihood of program success. The Program Manager
is accountable for performance management of all Program Team members, whereas the PMO is accountable for
performance management of the Program Manager.
Handover During Transition in Program Manager or Program Team
In the event that a Program Manager or key program team member leaves the program during the Program
Implementation phase, the new Program Manager or key program team member must receive orientation in Mercy
Corps and country level strategies and policies. As well, the handover should include orientation in the PWP,
the Program Organizational Chart, the status of program team skills-building and performance management, key
information on strategies and technical aspects of the program and cross-cutting themes, and key program progress
indicators such as the latest budget vs. actual report, the latest CPI calculation, the latest budget forecast, the latest
updated Program Schedule, the proposal and logical framework, results of quality assurance checks and M&E
results and any specific donor and/or reporting requirements. Equally important is to prepare for anticipated and
unanticipated leaves of key staff by ensuring that substitutes have been identified and oriented to carry forward work
during these periods.
5.5. Managing Issues

What is an “Issue”?
In program management global standards, the term “issue” generally refers to a risk that has been realized and
is affecting the staff or program. However, it may also refer to other events or problems that require corrective or
mitigation actions to address large variations against schedule or budget. PMD Pro refers to issues as unresolved
decisions, situations or problems that will significantly impact the project. Issues can arise from within the program
team or from external actors.
Timely Escalation of Issue to Program Manager
During implementation, the program team must be sure to raise any issues to the Program Manager as soon as
possible, which will allow the Program Manager to discuss the issue with the program team and the PMO and make
any necessary adjustments. Delays in informing the Program Manager about issues will negatively affect Program
Implementation. It is recommended that the Program Manager maintain an issue log and actively use the issue
log in team meetings and in meetings and communications with the PMO to track and communicate the status of
issues and their impact upon the program (see A Guide to the PMD Pro section on Managing Issues for additional
information)
In some cases, staff will not want to discuss issues with the Program Manager, so it is the responsibility of the
Program Manager to be in-tune with team dynamics and find subtle, sensitive ways to understand the situation. Issues

Chapter 5
may arise from internal competition that creates negative dynamics. By being a pro-active manager that engages and
listens to staff concerns and cultivates a positive work environment, these issues can often be mitigated.
During the Kick-Off Meeting it is important to set the culture of the team to be one of bringing issues into the open,
emphasizing that it is then they can be worked on. Issues are brought to light not to place blame, but to move forward
in a corrective manner. Developing this type of trust within a team is a key part of the Program Manager’s work.
Define and Carry Out Corrective or Mitigation Actions
In the event that an issue is escalated to the Program Manager, the Program Manager should lead a process to
define and carry out any corrective or mitigation actions required to address the issue. These actions should be
clarified to the program team, external stakeholders, and the PMO, and should then be implemented.
Update PWP Based on Issue and Corrective Actions
It will generally be necessary to update the PWP (at a minimum, the Program Schedule and perhaps the budget) to
reflect new tasks that have been or will be implemented to correct or mitigate issues. New corrective or mitigation
tasks should be added to the Program Schedule, and a new Schedule should be circulated to stakeholders.
Update Relevant “Deliverables” Based on Issue
Issues that have arisen may have implications for “deliverables” developed earlier. The entire program should be
reviewed so that any deliverable impacted by an issue that has arisen will be updated so as to avoid a repetition of
the issue as similarly affected deliverables (outputs) are created.
Change Management
At times a program is faced with an issue that requires a significant change in the program. These are issues that
are so large they reset the basic program assumptions, impacting and significantly changing the schedule, budget,
and/or program final outcomes. When this occurs it is critical to follow an agreed upon “Change Management”
process which involves the program team’s agreement on the best course of action, impacts and modifications
of all planning tools (PWP) and documentation (schedules, budgets, procurements plans, etc), and approval by
stakeholders and required personnel including PMO, Country Director and potentially donors if necessary.
5.6. Managing Organizational (Portfolio) Capacities

Assess Program Operational Infrastructure (assets, vehicles, facilities, technical, etc.) vs.
Requirements
The program operational infrastructure may be beyond the immediate control of the Program Manager and thus likely
a risk which should be tracked. Building on the support and operations requirements determined in the Set Up and
Planning phase and later discussed in the Program Kick-Off Meeting, portfolio management and the PMO should
assess program operational infrastructure needs versus the actual infrastructure. Here “operational infrastructure”
refers to practical operating needs such as office facilities and equipment, information and communications technology
(ICT) equipment and requirements, program technical or security equipment, vehicles, and other support needs.
Based on the program needs, the PMO and Portfolio Management should assist the Program Manager to augment
operational infrastructure as required and as the Program Budget or portfolio budgets permit. In some cases, budgets
will not support needed upgrades, and in these cases the Program Team will need to adjust plans.
Assess Organizational Procedures (HR, procurement, security, sub-granting) vs.
Requirements
The PMO and Portfolio Management should assess organizational procedures (such as human resource
management, procurement, warehousing, security, and sub-granting) to ensure that they are adequate for the
demands of a particular program. In most cases, existing Mercy Corps organizational procedures should be
sufficient for the program in question, but certain programs will require upgrades. For example, a program operating
in a new complex security environment may require improved security protocols; or, a program requiring particularly
large implementation partnerships may require adjustments in sub-granting procedures. If improvements in existing
procedures are required, the PMO and portfolio management should assist the Program Manager in making the
necessary upgrades to organizational procedures.

Chapter 5
Create Strategic Alliances (Internal, External)

Partnerships are often identified and developed during the Program Identification and Design and the Set Up and
Planning phases. However, in some cases, programmatic success can be supported by additional internal or external
alliances that are beyond the immediate control of the Program Manager. For example, a strategic alliance with a host
country government agricultural research station may greatly improve the probability of success for a food security
program; or, a partnership with a colleague international humanitarian relief and development agency may assist
an emergency response and recovery effort. Similarly, internal alliances (with other programs, or with neighboring
portfolios, or with other departments) may be required to ensure program success. In these cases, it is the role of the
PMO and Portfolio Management to assist the Program Manager in creating the necessary strategic alliances. Mercy
Corps’ Local Partnerships Guide can be a useful tool for establishing and fostering strategic alliances with local civil
society, government and business entities.

Chapter 6
Monitoring and Evaluation (M&E)
Chapter 6: Monitoring and Evaluation (M&E)

Identification & Design Set Up & Planning Implementation End of Program Transition
S S S S
Create
Conduct and
Conduct Indicator Plan Disseminate
Document
Assessment (Align with Evaluation
Baseline
Mission Findings
Assessment
Metrics)
S S S S
Analyze Collect Document &
Plan Budget
S U P P O R T E D BY T H E D M & E - I N - A - B OX
Assessment Monitoring Data Disseminate

and Staff
Data and Regular Lessons
for M&E
Quality Checks Learned
S S S S
Analyze Enter
Develop Plan for M&E
Monitoring Data Program Results
Logical in PWP, including
– Compare Actual to Mission
Framework WBS and
Results to Metrics
schedule
Targets Database
S S S
Develop Data
Budget Collection and Report
for M&E Management Monitoring Data
Tools and
Processes
S
Use Data to
Refine Program
Plans – Perform
Change
Management
S
Conduct and
Document
Evaluation(s)
OOOOOOOO
Progress
Written
M&E Data reports include Final Lessons
Logical Assessment or M&E Event
Indicator Plan Management progress toward Evaluation Learned
Framework Problem Reports
System indicator Report Documentation
Analysis
targets
S Process Step

Chapter 6
Minimum Standards for Program Monitoring and Evaluation (M&E):

�� Indicator Plan exists (Planning Phase) (see 6.3)
� Key program M&E events (at a minimum, baseline, end-line, and routine monitoring) have been carried out,
and reports of these events exist (Implementation Phase)(see 6.3 & 6.4)
� Basic M&E data management system exists (Implementation Phase) (see 6.4)
� Evaluation report exists (Implementation Phase) (see 6.4)
About This Chapter

The Monitoring and Evaluation process works together with all phases of the Program Lifecycle. Processes compare
program performance to the original proposal, as well as to the Program Work Plan and Indicator Plan.
This chapter describes the key program management steps included in program monitoring & evaluation. While
much of M&E is specific to the technical sector in question, there are certain program management processes that
can help to ensure good articulation of programmatic results. These are described below, divided into the following
categories: 6.1) Introduction to M&E at Mercy Corps; 6.2) M&E in Program Design; 6.3) M&E at Program Set Up
and Planning; and, 6.4) M&E at Program Implementation.
6.1. Introduction to M&E at Mercy Corps

Value of M&E
Why invest in strong M&E? Experiences confirm that programs investing significantly in M&E can benefit from:
• increased program quality and management capacity;
• ability to make informed adjustments;
• motivation and transparency for staff and partners;
• increased leverage with donors and greater prospects for expansion; and
• local buy-in and sustainability.68
Linkages with M&E Chapter in A Guide to the PMD Pro
The A Guide to the PMD Pro provides an excellent orientation to
M&E within the context of program management. Mercy Corps’ Mercy Corps’ Key Steps to Effective
M&E approaches are mostly consistent with PMD Pro, with a M&E
few caveats:
• Budget for M&E.
• Mercy Corps views Monitoring and Evaluation as distinct • Staff for M&E.
activities, with distinct sets of tools, methods and best • Incorporate M&E in project workplan.
practices for each. The sub-sections in this chapter
reflect this distinction. • Conduct DM&E workshop at project
start-up.
• As referenced in Chapter 3 of this manual, the Mercy • Develop an indicator plan.
Corps logframe format and terminology is slightly different • Develop data collection and
from PMD Pro. Data source information is captured in the management processes.
Mercy Corps indicator plan, which is similar to the M&E
• Conduct regular meetings to reflect on
plan in PMD Pro terminology.
data.
• Mercy Corps believes that program objectives should be • Make the logframe a living document.
SMART (Specific, Measureable, Achievable, Relevant • Report results to beneficiaries and
and Time-bound) and include quantitative targets where stakeholders.
possible. Indicators should be direction-neutral and not
• Conduct baselines and final evaluations
include the targets directly in them.
for all projects.
68 M&E Value Proposition: https://mcdl.mercycorps.org/gsdl/docs/Developing%20Value%20Proposition%20ME.pdf

Chapter 6
This manual complements the PMD Pro chapter by providing additional details on how to implement M&E, including
guidance and tools for M&E planning and monitoring and evaluating programs, in the Mercy Corps context.
Resources Available
Key sets of resources to assist managers and staff in conducting M&E in the field include:
• D
M&E Guidebook69 and associated online training70 for basic DM&E concepts, tools and terminology. DM&E
Guidebook Supplement71 for more technical detail and guidance on planning and data collection methods.
Hard-copy versions are available upon request.
• DM&E-in-a-Box72: comprehensive set of tools to assist with all things DM&E developed by and for practitioners
as a proven resource for carrying out DM&E activities in the field.
• DM&E Community of Practice on Clearspace73: Web-based platform for sharing experiences and example
tools with M&E-interested staff from around the Mercy Corps world.
• DM&E webinars: Live, interactive sessions in a virtual classroom for shared learning.
• DM&E TSU and Help-desk: Email dme@mercycorps.org for specific technical support.
6.2. M&E in Program Design

Planning for effective M&E begins in the Program Identification and Design phase by incorporating SMART objectives
and well thought-out indicators into the program logframe. This is also the time to utilize the Mission Metrics Training
and Indicator Guide to ensure alignment of indicators with Mercy Corps’ Mission Metrics and inclusion of Mission
Metrics reporting in the schedule. Please see Section 2, Chapter 1 in the A Guide to the PMD Pro and Chapter 3
of this manual for more on designing projects with measurable results.
Budgeting and Structuring for M&E
Strong monitoring systems and evaluations require appropriate resource allocations. It is important to have clear M&E
roles and responsibilities for staff and partners. Having one or more staff exclusively focused on M&E, especially in
larger programs, is recommended. Even smaller programs can have staff with explicit M&E responsibilities built into
their Position Descriptions, serving as M&E focal points in addition to their other duties. This should be taken into
account when planning Program Human Resources and Budgets.
Many Mercy Corps countries choose to staff a country portfolio-level DM&E Unit consisting of M&E specialists to
provide technical assistance across projects and work with program-level M&E staff or focal points74. This has proven
effective in developing greater coordination and harmonization of approaches, and can be funded by allocating
percentages from each program. A clear role for IT staff in M&E is also recommended to support data management
solutions.
Please see Chapter 3 and Chapter 4 on Budget Draft and Preparation for further guidance.
6.3. M&E at Program Set Up and Planning

Integrating M&E into start-up workshops allows us to better define and internalize program objectives, and position
our M&E systems to measure progress towards these objectives. This collective planning should occur as part
of the program design (Chapter 3) and the creation of the Work Breakdown Structure (Chapter 4) and should be
presented to the full Program Team at the kickoff workshop covered in Chapter 5. The text box at right summarizes
major M&E items to address; please see the DM&E at Project Kickoff tip sheet for more detail.75
69 DM&E Guidebook: https://mcdl.mercycorps.org/gsdl/docs/DM-E%20FINAL%20Guidebook%203final.pdf

70 DM&E Online Orientation Training on MC Online Learning Center: http://elearn.mercycorps.org/
71 DM&E Guidebook Supplement: https://mcdl.mercycorps.org/gsdl/docs/DMEGuidebookSupplementPart1.pdf
72 DM&E-in-a-Box toolkit: https://mcdl.mercycorps.org/gsdl/cgi-bin/library?a=p&p=dme
73 DM&E community of practice space on Clearspace: https://clearspace.mercycorps.org/community/cops/dme
74 DM&E Tip Sheet #10: Structuring the DM&E Unit: https://mcdl.mercycorps.org/gsdl/docs/DME%20Tip%2010%20Structuring%20DME
%20Unit.pdf
75 DM&E Tip Sheet #7: DM&E at Project Kickoff: https://mcdl.mercycorps.org/gsdl/docs/DME%20Tip%20Sheet%207%20Project%20Kick
off.pdf

Chapter 6
Indicator Plan
M&E Workshop at Start-up: The Indicator Plan provides the basic details of a functional M&E
• Update and internalize team system, and is therefore a critical tool in the M&E planning process.
understanding of logframe The indicator plan is a Minimum Standard for Program
• Review or develop indicator plan Management at Mercy Corps. It is referred to as the M&E Plan in
with roles and responsibilities A Guide to the PMD Pro, with slightly different format and terminology
• Insert M&E activities in workplan to the Mercy Corps format but is essentially the same information. For
example, in PMD Pro format, “Outcomes” = “Objectives” and “Info
• Plan for baseline study Needed” is similar to “Definition and Utility of Indicator”. USAID often
• Develop data collection and refers to Performance Monitoring Plans, or PMPs, which are also very
management tools and processes similar in substance to Indicator Plans. When completing the Indicator
Plan, Mission Metrics alignment and scheduling should be entered into
the Mission Metrics system.
Mercy Corps Indicator Plan Template and Sample:

Objective: 75% of mothers aware of at least two pregnancy-related danger signs
Indicator Definition of Baseline Data and Data Frequency Person
Indicator and Targets Collection of Data Responsible
Management Sources & Collection
Utility Methods
1. % of mothers Mothers can Targets: 1. Baseline 1. Month 1. Surveys

aware of at least list two of the - 50% by month 12 Survey / Final 2,12, 24 Designed by
two pregnancy- four danger - 75% by project end Survey of Maternal Health
related danger signs defined by mothers Officer
signs PEPC Program Baseline:
2. Carried Out
Guidelines. Less than 22% By Maternal
(according to Health
assessment data, Assistants
Recall of danger to be confirmed by
signs is key to baseline survey)
awareness and
prevention
Tips for developing indicator plans (please see DM&E at Program Kickoff tip sheet within the DM&E Toolkit for more)
include:
• In the Definition of the Indicator column, make clear the unit of analysis we are interested in (i.e., individual,
household, association, etc.) and any key sub-groups.
• Data collection sources refer to the primary data source – for example, farmer association members, or pregnant
mothers. Methods can include sampling strategy as well as methods of inquiry (e.g., survey, focus group, case
study, etc.).
• The Frequency column helps define monitoring versus evaluation. Be wary of high frequencies for activities that
take effort to collect, like surveys, and try to standardize so that multiple indicators are rolled into the same data
collection activities and reports.
• Include detailed Roles and Responsibilities and/or write out in narrative so it is clear who is responsible when
data is collected, inputted, analyzed, reported on and disseminated.
• Proactively include partners and beneficiaries, and adjust contracts or MOUs as needed.
• Consider budgetary and time implications of tracking each indicator.
• Note it is a live document that should be adjusted and updated throughout the life of the program.

Chapter 6
All Monitoring and Evaluation tools should disaggregate information by both gender and age. This will allow
program teams a better understanding of who their activities are reaching and how the impact of those activities
may vary based on these factors. Collecting this information during routine monitoring and key M&E events
can allow program teams to adjust activities in order to increase access to resources and/or participation if
necessary.
Baseline Study
A solid baseline study provides the basis by which results can be measured at the end of the program. Baselines are
especially important for outcome indicators – i.e., those which measure objectives and entail changes in knowledge,
attitudes, behaviors and conditions. The indicator plan should include clarity on what will be measured and the
methods required.
Baseline data should be collected on indicators before the activities relevant to those indicators have begun,
and thus baselines are usually conducted in the early part of the Program Implementation phase. Sometimes a
phased approach is appropriate, with different waves of baseline data collection for specific target groups prior to
the start of their activities. For further guidance on planning and implementing the baseline study, see DM&E Tip
Sheet #5: Baselines76. Please note that the methodology and results of the baseline study should be
documented in a Baseline Study Report, which is a Minimum Standard for Program Management at
Mercy Corps.
6.4. M&E at Program Implementation

Introduction to Program Monitoring
Mercy Corps defines program monitoring as a cycle of regularly collecting, reviewing, reporting and acting
on information about Program Implementation. This is congruent with A Guide to the PMD Pro , which covers
basic monitoring concepts. The Mercy Corps DM&E Guidebook and training also provide a good introduction
to monitoring. See DM&E Tip Sheet #12: Developing a Monitoring System for more detail on the steps in text
box77. Note that carrying out and reporting on routine Program Monitoring is a Minimum Standard for
Program Management at Mercy Corps.
Data Collection for Monitoring
Data collection for monitoring generally focuses Considerations for Data Management Solutions
on key activity and output indicators needed • What are our key data needs and uses?
to chart progress, fulfill reporting requirements • What are the major components or desired features
and address other management information of the system? Consider data integration and
needs. Be wary of trying to collect too much compatibility, quantity and organization of data, data
information, as this can overburden staff and transfer, adaptability, analysis and reporting tools, etc.
systems. Also be sure to coordinate with
• What are our main constraints? Includes budget, time,
logistics and administration to harmonize and
technology, staff capacity, etc.
limit duplication.
• Analyzing software options: MS Excel vs. MS Access;
Data collection tools, or monitoring tools, needed other data management software
for the monitoring system can be mapped out • Setting up the process: Identifying data flows; team
by looking at the data sources and frequencies approach to system design; training staff; defining roles
columns in the program indicator plan. Mercy and responsibilities.
76 DM&E Tip Sheet #5: Baselines: https://mcdl.mercycorps.org/gsdl/docs/DME%20Tip%20Sheet%205%20Baselines.pdf
77 DM&E Tip Sheet #12: Developing a Monitoring System: https://mcdl.mercycorps.org/gsdl/docs/DME%20Tip%20Sheet%2012%20Devel
oping%20a%20Monitoring%20System.pdf

Chapter 6
Corps has developed templates for tracking common activities such as trainings and small projects in the field,
which can be adapted to fit a wide range of activities and project contexts78-79. Examples of sector-based monitoring
tools are in DM&E-in-a-Box and on Clearspace.
78 DM&E Data Collection Template for Trainings/Events/Field Activities: https://mcdl.mercycorps.org/gsdl/docs/

DMEDataCollectionTemplateTrainingsEvents.doc
79 DM&E Data Collection Template for Small Projects: https://mcdl.mercycorps.org/gsdl/docs/DMEDataCollectionTemplateSmallProjects.doc

Chapter 6
Data Management Systems for Monitoring

Program data management and filing systems aim to maintain Steps to Develop a Monitoring System
an accurate, timely information base concerning the program’s 1. Clarify the management structure
activities and outputs and their associated documentation80. 2. Review & refine the project logframe
Mercy Corps’ systems and technologies for managing data range 3. Identify key management questions
from the basic, such as simple Excel tools, to the sophisticated,
including use of online databases and Geographic Information 4. Develop the indicator plan – what, how,
System (GIS) mapping. when, who?
5. Assess the means, costs and risks of the
It is important to design systems that are secure, accessible, monitoring system
and reflect the level of staff capacity and overall technology 6. Identify the required data collection tools
environment. Clarify the process or data flow for the system
before jumping ahead to the technology or software solution. 7. Develop data collection tools & data
management systems
Mercy Corps has several resources for assisting field programs 8. Integrate M&E activities into workplan
with management of monitoring data. This includes a tip sheet 9. Map out the M&E System
on M&E data management81, example Excel tools82, an M&E
database template in Microsoft Access that can be adapted to
various program contexts83, and examples and experiences of programs using various technologies on Clearspace.
This is a very fluid area with tools and technologies developing rapidly, so it is good to check-in with the DM&E
and Information Technology (IT) teams for updates, questions or assistance in developing M&E database systems.
Development and use of at least a basic M&E data management system is a Minimum Standard for
Program Management at Mercy Corps.
Analysis and Reporting of Monitoring Data
Conducting regular, participatory data analysis sessions with staff and partners to analyze monitoring data, assess
progress as related to targets, and make any necessary adjustments to implementation strategies is the key to an
effective monitoring system. Building a placeholder for these meetings in the Program Work Plan (PWP, see Chapter
4) and on the agenda of routine program coordination meetings is important. For tips on organizing and presenting
data for effective analysis, please see DM&E Tip Sheet #11: Data Analysis84. For tips on reporting of monitoring
information, please see Chapter 5 and the guide referenced there.
Program Evaluation
Mercy Corps defines evaluation as an in-depth, retrospective analysis of an aspect or aspects of a program that
occurs at a single point in time. This is in line with the framing of evaluation in A Guide to the PMD Pro. More
background introduction to evaluation is in the DM&E Guidebook.
Mid-term and final evaluations are the most common types.
• Mid-term evaluations are used to 1) measure the effectiveness of the program and 2) determine changes to
improve effectiveness for the remainder of the program. They’re generally only relevant for programs of at
least 2 years duration.
• Final evaluations in the NGO world generally take place in the final months of a program. These evaluations
are generally designed to 1) measure the effects and impact of a program and 2) draw conclusions about
lessons- learned for future programs.
Other evaluative efforts include field studies and action research, designed to evaluate particular program elements
in-depth, as well as impact evaluation. Impact evaluations are generally more relevant to untested approaches, pilots,
and particularly innovative or high-profile initiatives. These efforts are most effective when planned and budgeted at
program design.
80 Project Management Body of Knowledge (PMBOK)
81 DM&E Tip Sheet #8: Data Management: https://mcdl.mercycorps.org/gsdl/docs/DME%20Tip%20Sheet%208%20Data%20Mgmt%20
EN.pdf
82 E xample Excel Data Management Tool: https://mcdl.mercycorps.org/gsdl/cgi-bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=D
ME+Example+Tool+Excel+Data+Solution
83 M &E Database Template in Access: https://mcdl.mercycorps.org/gsdl/cgi-bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=DME
+Monitoring+Database+Template
84 DM&E Tip Sheet #11: Data Analysis: https://mcdl.mercycorps.org/gsdl/docs/DME%20Tip%20Sheet%2011%20Data%20Analysis.pdf

Chapter 6
Evaluations can be internal or external, depending on donor requirements, available funding, internal capacity levels,
objectives of the evaluation and other circumstances. Within Mercy Corps, we generally refer to an external evaluation
as led by an expert external to the agency, usually a private consultant. Staff and partners, however, often assist
the external consultant in data collection and analysis, both for logistical reasons as well as to maximize learning85.
Donors often require final evaluations to be external, while mid-term evaluations are often led by the program team
due to budget reasons and the focus on learning for the next phase.
Within Mercy Corps, evaluations can be conducted whenever portfolio management sees fit. Final evaluations are often
donor required, while mid-term evaluations are often program initiated with the focus on learning for the next phase. Mid-
term evaluations are recommended for programs lasting two years or more. The Minimum Standard for Program
Management at Mercy Corps stipulates that final program evaluations must be carried out and a report
must be available. These evaluations can be very simple for smaller or less complex programs (for example, a documented
end-line study report only), or can be more detailed for larger or more complex programs (for example, an external impact
and process evaluation). The type of evaluation conducted is at the discretion of the PMO.
Evaluation Planning and Scope of Work
Effective evaluation planning begins in the Program Mercy Corps Evaluation Checklist
Set Up and Planning phase (Chapter 4), with � Focused on utility; designed to measure indicators
appropriate budgeting and staffing for M&E and and answer management needs.
allocation of time in the PWP. More detailed � Start with clear Scope of Work.
evaluation planning should begin several months in
advance of actual data collection to allow time for � Primarily a learning tool rather than an audit.
consultant contracting, organization of evaluation � Employ mix of quantitative and qualitative methods
team, logistics planning, etc. and use robust sampling techniques.
� Adequately resourced and planned in advance.
The Scope of Work (SoW) is the central reference
document containing these planning details, and is � Team participation in implementation and review of
the first step in organizing an evaluation. See the results.
Baseline/ Evaluation Scope of Work Template and � Draft completed and discussed with staff while
Sample for a detailed guide to producing a solid evaluation team still in country.
SoW86. Note that Terms of Reference (or ToR) is � Short but informative - usually no more than 20
often used interchangeably with SoW, but technically pages plus attachments.
a ToR refers to a specific consultant’s contract, � Findings shared, presented and discussed across
whereas the SoW can include broader planning for programs for maximum learning.
the full scope of the evaluation, including externally
and internally-led elements.
For external evaluations, managers should negotiate Evaluation Scope of Work Contents
with consultants for agreed upon methods and
timetables, and provide feedback on draft reports. 1. The Project or Program to be Evaluated
Mercy Corps has a roster of external evaluation 2. Purpose of the Baseline or Evaluation
consultants, many with Mercy Corps experience87. 3. Background
The DM&E team can also help organize Temporary 4. Existing Project/Program Information Sources
Duty (TDY) assignments for experts within the DM&E 5. Key Baseline or Evaluation Questions
Community of Practice to help with field work, and
is available to help review draft SoWs, sampling 6. Data Collection Methods, including Sampling
strategies, data collection tools, reports and other Techniques and Data Management/Analysis
types of technical assistance. 7. Team Composition and Participation
8. Procedures: Schedule and Logistics
9. Reporting and Dissemination Requirements
10. Budget
85 USAID Evaluation Policy has different definition of external evaluation: http://www.usaid.gov/evaluation/

86 Baseline/Evaluation Scope of Work Template and Sample: https://mcdl.mercycorps.org/gsdl/docs/Baseline%20Evaluation%20SOW%20
Template%20Sample.doc
87 Mercy Corps M&E Consultant Roster: https://mcdl.mercycorps.org/gsdl/cgi-bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=co
nsultant+roster

Chapter 7
Data Collection Methods for Evaluation

Mercy Corps promotes a mix of quantitative (yielding numeric Common Data Collection Methods:
results) and qualitative (more open-ended, often text-based • Surveys
results) methods to capture intended and unintended • Focus groups
outcomes. • Review of monitoring data
To inform the approach it is necessary to first review the program • Observations
indicators and key questions in the SoW, and employ methods • Case studies
that best capture this information. For measuring changes in • Document/secondary data review
indicators from baseline or mid-term, try to replicate the data
collection tools and sampling strategy as closely as possible. • Structured & semi-structured Interviews
More detailed guidance on data collection techniques is • Participatory Impact Assessment
in the DM&E Guidebook Supplement88. DM&E Tip Sheet • Community and social mapping
#3: Sampling provides more detailed guidance and links for • Most Significant Change
sampling89. • Field visits and tours/transect walk
Evaluation Reporting, Dissemination and
Learning
Evaluation reports should be clear and concise, with an executive summary that can serve as a stand-alone document.
For external evaluations, the program team should provide feedback on the report draft before it is finalized by
the consultant. A recommended evaluation report structure is included in the Baseline/Evaluation SoW Template
referenced previously.
Making effective use of evaluations, for organizational learning and evolving program approaches, is an often
overlooked aspect of evaluation. Workshops should be held with staff and partners to review evaluations and analyze
how the findings and recommendations relate to current and future programs and strategies within the country
program. This can include staff from other programs in order to maximize cross-learning and collective institutional
knowledge-building. After submitting to donor, final evaluation reports are sent to the relevant Program Officer at
HQ and placed on the Digital Library. They should also be distributed to local and international stakeholders.
See Chapter 7 of this manual for more on lesson-learning at project close-out. The text box at right includes other
actions for building agency-wide learning from evaluation. 90 91
Maximizing Organizational Learning from

Evaluations:
• Organize analysis and lessons learned
workshop and consider relevant action items
for future implementation
• Include outcome data in Mission Metrics
reporting
• Submit to HQ Program Officer and load on
Digital Library
• Contact DM&E team for results in Globe90,
Hub91 and GAIT
• Consider presenting on global webinar
sessions
88 DM&E Guidebook Supplement: https://mcdl.mercycorps.org/gsdl/docs/DMEGuidebookSupplementPart1.pdf

89 DM&E Tip Sheet #3: Sampling: https://mcdl.mercycorps.org/gsdl/cgi-bin/library?a=q&r=1&hs=1&c=progdev&h=dtt&t= 0&q=dme+tip
+3+sampling
90 Mercy Corps’ internal global newsletter
91 Mercy Corps’ intranet site

Chapter 7
Chapter 7: End-of-Program Transition

End of Program Transition
S S S S S
Update End Communicate Review Transition
Document
of Program End of Program Contract / Deliverables
Lessons
Transition Plan Transition Plan Sub Grantee to External
Learned
Status Stakeholders
T T T T
Local Partnership Guide to
Functional Stakeholder Community
Guide: Section
Analysis & Staff Register Mobilization
3.6. Sustaining
Transition Plan Programming:
Outcomes
and Impact Section 4.7
Handover
T T T T
BVA with match Program Work Field Finance Field Asset
or co-financing Plan – Manual: Form Management
status Communications 11.5B Subgrant Manual and
Plan Closeout Disposal of
Checklist Assets Form
T T T
Review of Actual FAM, Section Subgrant Final
Achieved 2.2.13, Close-out Visit
Against Baseline Termination Scope of Work
Schedule Process and
Documentation
S T
Final Subgrant
Final 90 Day Close-out Letter
Meeting
T
Grant 90 Day
Meeting
Checklist –
Compliance &
Administrative
Donor
mercycorps.org
Updated
Requirements
Lessons
< Table Complete 57
of Contents
End-of-Program Learned
Transition Plan and Final Documentation Program File
Report
Chapter 7
Minimum Standards for the End-of-Program Transition Phase:

�� Written End-of-Program Transition Plan exists (see 7.2)
� “Final 90 day” meeting has taken place, and minutes exist (see 7.2)
� Contract/ sub-grantee status reviewed and finalization plans specified (see 7.2)
� Deliverables to be transitioned to external stakeholders have been handed over, and handover documentation
exists (see 7.2)
� Lessons learned have been documented, and have been sent to the Program Officer(s) and TSU (see 7.2)
� End-of-Program Transition has been clearly communicated to the Program Team, beneficiaries, host
government counterparts, and partners (see 7.2)
� Program File is complete (see 7.2)
� Final report is completed and donor close-out requirement are met (see 7.3)
About This Chapter

The End-of-Program Transition phase is the final phase of a program. Although some aspects of this phase are
considered in the Set Up and Planning phase, and are further elaborated during the Program Implementation
phase, the End-of-Program Transition is essentially a linear phase that occurs after or towards the end of, Program
Implementation. It is the phase in which the Program Team exits the program, transitions program deliverables to
external stakeholders, or transitions program processes and learning into the next relevant Mercy Corps program.
This chapter describes the key program management steps during the End of Program Transition phase. These
are described below, divided into the following categories: 7.1) Types of Program Transitions; 7.2) Updating and
Communicating End-of-Program Transition Plan; and, 7.3) Donor Requirements.
7.1. Types of Program Transitions

Per PMD Pro, there are four types of end of program transitions:
• Termination – Specific source of program funding ends, and the program will not continue, either via direct
follow-on funding from the same source, other external funding sources or through program generated funding.
Some program activities may continue after termination, but the activities will be managed and supported by the
beneficiaries or other external stakeholders, not by Mercy Corps.
• Extension – Program period is extended, and source of funding continues. However, no additional funding is
provided. Generally called a “No Cost Extension” or NCE.
• Expansion - Program period is extended, and additional funds are provided by the donor or other donors.
Includes a continuation of some, or most of the program activities, and may add additional activities or geographic
areas. Generally called a “Cost Expansion” or “Cost Extension”.
• Redesign – Revaluation or internal realignment. Continuation via a new phase with modified interventions or
activities, or via different funding sources.
Extensions, Expansion and Redesign are functionally the equivalent of starting a new program, and the program
management processes and phases should be followed from the beginning, as applicable.
7.2. Updating and Communicating the End-of-Program Transition Plan

The first step in executing the end of program transition is to review and update the End of Program Transition plan
that was created in the Set Up and Planning phase and iterated or refined in the Program Implementation phase.
There is no particular format for this plan, but it should describe both the administrative close-out processes and
the programmatic transitional processes required. A written End-of-Program Transition Plan is a Minimum
Standard for Program Management at Mercy Corps. This review process should take place no later than 90
days prior to the end date of the program.

Chapter 7
A transition planning meeting or “final 90 days meeting,” is required as a Minimum Standard for
Program Management at Mercy Corps. Please see the Grant 90 Day Meeting Checklist92 as one source
of information for the administrative and grant compliance related contents of this meeting. The minutes from this
meeting must be documented and placed in the Program File.
This meeting considers two things:
Administrative Close-Out: All tasks must be completed, expenses recorded, assets disposed of, reporting
requirements fulfilled, documents organized, and contracts and sub-grants closed out, and any Mercy Corps
matching or co-financing requirements verified. Plans should be made for completion of final reporting
requirements. It is important to consider staff care and be sensitive to and supportive of follow-on employment
planning of staff as part of the transition process. Usually administrative close-out is happening as Program
Team is leaving and moving to other programs. Thus it’s critical to plan ahead for this date leaving enough time
to ensure proper closure of the program. Staff will likely be looking for work prior to the end of the program, often
leaving before fully completing their duties and consequently losing important institutional knowledge. Initiating
open discussions with staff to identify their intentions and build the 90 day plan around their timeline can help to
avoid surprise losses of staff. At times, it may be necessary to provide incentives to key staff to stay through the
end of the program.
Programmatic Transition: The programmatic deliverables must be ‘transitioned’ to external stakeholders.
Depending on the program, these might be partners, local government, or beneficiary groups. Hand-over
documentation must be prepared; program transitions and accomplishments must be communicated to
stakeholders; any training or processes required for sustainability must be finalized; program M&E processes
must be finalized; and, lessons learned must be documented and disseminated. While all of these are important,
the most important aspect of programmatic transition is to have and communicate a clear and realistic exit
strategy, so that the incremental benefits achieved by the program can be continued by external stakeholders
after the end of program transition. To be effective, these processes should be initiated during the course of
implementation.
Specific steps in this process are discussed below:
Review Status of the Program Scope
Reviewing the status of the program means analyzing progress made towards achieving the program objectives and
updating program management documents. Update documents in the PWP and other program documentation to
detail program accomplishments to date against key objectives, activities and indicator targets. If program benefits
and deliverables are not going to be achieved, provide a detailed explanation as to why not. Physically verify outputs
and quality, as described in Chapter 5.
Based on achievements to date, and remaining planned activities, determine if program objectives will be achieved.
If program objectives likely will not be achieved, determine if a request for change of scope should be sent to the
donor, or if a no-cost extension (NCE) should be requested (NCE assumes adequate funds remain for both program
and program support requirements for the duration of the extension). The decision to request a NCE or to request a
change of scope is a decision gate requiring the approval of the RPD.
Financial and Operational
The Finance Manager should provide a current Budget vs Actual (BVA) financial report, as described in cost control
procedures in Chapter 5. Starting with the BVA and working with the Finance Manager and PMO, prepare a Budget
Forecast for remainder of grant period. Using this forecast, determine if the program is projected to be within donor
budget flexibility limits. If not, determine next steps (alignment request to donor, internal budget changes, etc).
Ensure program expenses are up-to-date; including follow-up on outstanding advances and commitments.
The Finance Manager should provide a current match or co-financing report, if applicable. Determine if match or
co-financing requirements will be achieved. If it appears the match commitments are not going to be reached, HQ
Programs and Finance must be notified.
92 Grant 90 Days Meeting Checklist: https://mcdl.mercycorps.org/gsdl/cgi-bin/library?a=q&r=1&hs=1&t= 0&c=all&h=dtt&q= Grant+90+
Days

Chapter 7
If it is determined at the 90 day meeting or before that funds are expected to be unspent at the end of the grant period,
they cannot be expended in a manner that is not in direct support of the achievement of the program activities. Donor
regulations require that expenses charged to a grant provide a reasonable benefit to the grant. If equipment is to be
purchased in the pre-close out period, a written justification detailing why the equipment is required for the program
and the benefit the program will receive from the equipment is prepared and signed by Portfolio Management. If
supplies and materials are purchased, they must be utilized before the end of the grant. Donors and auditors give
extra scrutiny to the pre-closeout period to ensure that inappropriate expenditures are not charged to the grant.
The warehouse inventory records should be reviewed and a list of items purchased with grant funds is prepared.
Inventory needs to be utilized before the end of the grant period, as most donors require reimbursement for the cost
of unused inventory at the end of the grant period.
Program Team
Transition strategies for Program Team members should be determined, together with the PMO and Human
Resources (HR). The PMO must determine which program personnel will be terminated and which will be retained
and transitioned to other projects, programs, or roles. HR should review local labor law regarding period of notice
requirements and begin preparing end of service notifications as required for staff that are not being retained. Staff
often will begin to look for other employment as the end of program transition approaches, potentially affecting the
program’s completion. In these instances, it is advisable for the PMO to work with HR to determine a strategy for
retaining staff until the end of program (shift to other programs, eligibility for severance, bonuses, etc). For staff that
will not be retained after the end of the program, follow the termination process in Field Administration Manual 2.2.13
and the requirements of local labor law.
When faced with program closure and staff downsizing, a functional analysis can be a useful exercise to ensure all
important tasks for ongoing operations are assigned to remaining staff and separation of duties is maintained.
The final months of a program can be a very stressful time for the program team. In addition to pressures to
effectively meet program objectives and finish the program on target, uncertainties around employment continuity
may magnify stress. Fear of not finding follow on work and pressure to spend time seeking their next opportunity
may be affecting the concentration and focus of team members. Program Managers should be aware of these
concerns and discuss end of program staff transitions with staff. Smoothing the transition for the team should
be a topic within the 90 day meeting and Program Managers should consider providing training or support in
CV development and interviewing skills as well as allowing for staff time off for job seeking and interviews during
the close out period. The Program Manager may also serve as an effective advocate for high performing team
members to help them find follow on work internally with another program or department.
Formal Partnerships
In the final 90 days, review partner accomplishments to date, ensuring that they have created and transitioned the
expected program deliverables, that the quality of deliverables meets standards, and that all necessary reports
and supporting documentation have been provided. Clearly communicate the end of program transition strategy
to partners, and ensure that they are working on both administrative close-out and programmatic transition. Most
importantly, ensure that they understand the End-of-Program Transition strategy. Ensure that roles and responsibilities
for end of program transition are clear, and that partners are communicating the same thing to external stakeholders
as Mercy Corps team members – sometimes a local partner communicating an End-of-Program Transition strategy
differently from Mercy Corps team members can be a source of confusion. Ensure partners have contracted, or are
in the process of contracting or conducting, any audits and/or M&E events as per the sub-grant agreement or as
required by the donor. Schedule financial close-out work with the sub-grantees as per the requirements outlined in
FFM 1193 In the final 90 days, contract and sub-grantee status must be reviewed and finalization plans
specified as a Minimum Standard per Program Management at Mercy Corps. Local Partnerships Guide,
Section 3.6. Sustaining Outcomes and Impact, is a useful resource for transition or exit planning with partners.
93 Section 11 of the Field Finance Manual for sub-grant management was under development at the release of this manual. These resources
are expected to be released in 2012.

Chapter 7
Transition of Deliverables
During the Program Implementation phase, descriptions of deliverables are developed, quality assurance checks are
conducted, and outputs are physically verified (see Chapter 5). During the end of program transition phase, ensure
that handover documentation of these deliverables to external stakeholders (beneficiaries, host country government,
partner, etc.) is prepared, that deliverables are transitioned to these stakeholders, and that planned operations,
maintenance, and sustainability measures are implemented. In some cases, additional training or orientation
on operations, maintenance, or sustainability measures may be required to ensure a higher probability of post-
program use of deliverables and post-program realization of benefits94. It is a Minimum Standard for Program
Management at Mercy Corps that deliverables be transitioned to external stakeholders and that
handover documentation exists within the Program File.
M&E and Lessons Learned Documentation
As per Monitoring and Evaluation phase requirements (see Chapter 6), a final program evaluation should be
conducted as a minimum standard. Based on the evaluation and other M&E events, program accomplishments and
lessons learned should be documented and disseminated. In addition to formal evaluative activities, it is often helpful
to compile lessons learned through a participatory workshop of the program team and other stakeholders to ensure
consideration of a range of experiences with the program. Internally, it is a Minimum Standard for Program
Management at Mercy Corps that these lessons learned be documented and sent both to the Senior
Program Officer of the region in question, as well as to relevant Technical Support Unit members.
Communicating End-of-Program Transition Plan to Stakeholders
It is critical that the End-of-Program Transition Plan be communicated to stakeholders early in the program and actively
re-communicated during the final 90 days. Failure to do this will almost always result in future misrepresentation of
the program’s strategies and accomplishments. Clear communication of the End-of-Program Transition
Plan to the Program Team, beneficiaries, host government counterparts and partners is a Minimum
Standard of Program Management at Mercy Corps.
Beneficiaries: Communicate deliverables, the transition of deliverables, M&E results, and other results to
beneficiaries as a key aspect of accountability to beneficiaries. Request beneficiary feedback on programmatic
processes and impact, and incorporate this feedback into lessons learned documentation. Clearly manage
beneficiary expectations regarding the termination or extension of the program. Plan to celebrate program
accomplishments, which may require the involvement of community leaders or the media.
Host Country Government: Inform local governing authorities of the end of the program; describe the program
transition strategy, and the roles and responsibilities of stakeholders within this strategy. Ask host country
government counterparts for feedback, and incorporate this feedback into lessons learned documentation.
Program File
Ensure that all relevant program documentation is complete, and filed in the Program File as per the guidance in
Chapter 4. Ensure that there is a mechanism for retaining this documentation for the required time period (generally
3-7 years) after the completion of the program. Confirm with headquarters that all required documentation exists
at the headquarters level as well. A complete Program File is a Minimum Standard for Program Management at
Mercy Corps.
94 Mercy Corps’ Guide to Community Mobilization Programming, Section 4.7, Handover, provides useful guidance for concluding work with
communities.

Annex 1
Stakeholder Register Template
Annex 1: Stakeholder Register Template

Use Stakeholder Register to determine the best interactions for various stakeholders
1. For each significant stakeholder identify basic characteristics about them.
2. Identify what their interest is in the project and how they will be affected by it (good & bad).
3. Identify the stakeholder’s capacity and motivation to help or hurt the project.
4. Identify plans for how to address stakeholder’s interests and motivations (public meetings, private interviews,
communication, discussion, involvement on a committee, capacity building, etc.)
5. Modify this template by deleting irrelevant columns and adding others that might be useful for your project
6. As needed, consider additional registers for each program phase or project within your program scope.
Program Stakeholder Register (template)

Project Name: Date last Updated:
Project Phase:
Name of Designation Contact Role in Requirements Communications Influence
Stakeholder Information Program & Expecta- Strategy (What on Program
tions communication? Outcome
How? How of-
ten? When?)
Stakeholders are persons or organizations whether in the public, private or civil sector, whose interests may be
positively or negatively affected by Mercy Corps’ decisions, actions and ensuing results. Stakeholders can be both
internal and external to Mercy Corps. Examples of stakeholders include: Mercy Corps team members, community
groups, households, donors, the private sector, host country government, media, partners, and colleague agencies.
In a program context, stakeholders are persons or organizations that are actively involved in the program and whose
interests may be positively or negatively affected by the performance or completion of the program. Stakeholders may
have very different interests, capacity and influence based on gender and power relationships in the community. Each
program stage and sub-project may include unique stakeholders and it is the responsibility of the Program Manager
and PMO to identify the stakeholders, communicate their anticipated level of participation and/or responsibility and
manage expectations.

Annex 2
Is / Is Not Matrix Example
Annex 2: Is / Is Not Matrix Example

When specifying the program scope, an “Is/ Is Not Matrix” may help various stakeholders understand what the
program is and is not designed to do. An example of an Is / Is Not Matrix follows:
Is / Is Not Matrix Example for Multiple-Clinic Scope

IS/Includes IS NOT
Six new buildings (list locations) Does not include building in “named” location
Four buildings rehabilitated (list locations) Does not include HIV medicines (use other grant)
Includes medicines for pre-natal health care Does not include care for infants over five years of age
including family members
Includes equipment for pre-natal health care
Includes training of clinic staff

Annex 3
Tip Sheet: Creating a Work Breakdown Structure (WBS)
Annex 3: Tip Sheet: Creating a Work Breakdown Structure (WBS)

The WBS is a hierarchical tree used to organize the activities of a program into related tasks. A program is divided
into projects or components, and these are then divided into sub-projects or sub-components, and then into tasks or
work packages, which is the lowest level of work. The work package feeds into various levels of summary tasks and
activities that eventually support the project objectives.
There can be many task levels depending on the complexity of the program. Some programs may need as few as
three layers in the WBS. Others may require ten or more layers, or require a separate WBS for each sub-project.
The steps to create a WBS include:
• Step 1: Start at the Top and Move Down
Tip: Tasks are best written in the form
A good starting point is the key outputs and major activities “Action Word” + Subject. In this way
identified in the program’s Logical Framework (see Chapters 3 they state the “action” that must be
and 6). The WBS should directly tie into completion of the key completed on “something”. It provides a
outputs. This is an opportune time to review the Logical Framework, short, easy to read, identifiable work
since in many cases the team involved in creating the WBS may package of something that is “delivered”.
be different from those who created the Logical Framework. At Example: ‘Conduct assessment of health
first, to create the WBS tree don’t worry about organization, just posts.’
start brainstorming tasks. Starting with your program goal, ask,
“What must be completed to deliver the program successfully?”
Brainstorm with the group and list all of the named tasks; then repeat this process with the objectives, outputs, and
major activity areas, until the tasks are broken down into work packages and cannot be broken down any further.
Don’t forget to include tasks for delivery of items required to enable
M&E or quality assurance. Tasks could include initial delivery of Example: Hierarchical Structure of Tasks
descriptions of a deliverable and then eventually final delivery of a for an indicative Nutrition, Hygiene
deliverable, such as: and Sanitation Awareness Campaign
Component of a Health Program
• Training agendas, materials, and facilitators’ notes for
trainings 1. Assess current community nutrition,
hygiene and sanitation practices
• Design drawings and Bill of Quantities for infrastructure 1.1. Design survey
• Scope of Work or Terms of Reference for technical 1.2. Field test survey
consultancies 1.3. Select enumerators
1.4. Train enumerators
• Approach and process documentation (for example, a 1.5. Conduct survey
community mobilization process, or nutrition rehabilitation 1.6. Analyze data
process, or a farmers’ capacity building process)
2. Assess gaps between current practices
• Step 2: Organizing the WBS and recommended Essential Nutrition
After brainstorming summary activities, tasks, and work packages, Actions and Essential Hygiene and
organize them into a logical structure for the program. At this point Sanitation Actions
the WBS starts to take on the hierarchical tree shape: the few 2.1. Contract technical specialists
objectives or outcomes at the top and the multiple deliverables or 2.2. Draft essential actions
work packages spread as roots at the bottom. 2.3. Compare community
assessment results to
• Step 3: Assigning Owners recommended actions, identify
At this time, it’s helpful to identify the owner of each task. This is the gaps
person (or position) who is responsible for ensuring the delivery of 2.4. Based on gaps, create key
a specific work package to the program. They may need a team messages
to help them complete the lower level tasks or a specific work 2.5. Contract IEC materials artist
package, but ultimately they are responsible for delivery of the 2.6. Design IEC material based on
work package. key messages
2.7. Contract Printer
2.8. Print IEC materials

Annex 3
Tip Sheet: Creating a Work Breakdown Structure (WBS)
The owner may be the Program Manager, a member of the core Program Team, an external contractor or partner,
or a resource not yet identified. For example, to develop training materials for health workers in a prenatal health
project you might need an Obstetrician to complete several tasks. You would identify those tasks as owned by
“Obstetrician”. And you would need an additional task “Contract One Obstetrician” owned by “Maternal Health
Officer”.
Tip: Facilitation of WBS Creation

An easy way to facilitate a team through creation of a WBS is to have individual team members
brainstorm tasks onto medium-sized Post-Its.
1. Write the project objectives and key outcomes so that everyone on the team can see them.
2. Ask team members to write down their functional tasks in support of the project objectives and key
outcomes. Add suggested owners. One task per Post-It.
3. Ask team members to think of what tasks they need to have performed by others before they can do their
own tasks. Have them write the tasks down with the owners identified. These are the resources they
expect to go to for these deliverables. One task or deliverable per Post-It.
4. Once the brainstorming slows down collect the tasks and start grouping them according to the
organizational structure agreed to by the team. Move tasks around or if they fall under multiple groupings
mark that in some way.
5. Go through the “final check” activities. Many times tasks will be overlapping or duplicates from different
team members. Be sure to get agreement of how to separate tasks or which tasks to use with identified
task owners.
6. Now that you have Post-Its in a tree, you’ll want to document this structure. Typically you’ll be transferring
this into software such as MS Project. However first Code your structure through the following:
a. At the first level of the tree number your categories by hundreds, 100, 200, 300, etc.
b. At the next level, usually summary activities, number using tens, 110, 120, 130, etc.
c. At the next level, usually tasks and work packages, number using ones, 111, 112, 113, etc.
d. Adjust as needed.
• Step 4: Final Check

Once you have the full WBS drafted, review the following to determine if the WBS is complete:
1. Start at the top of the WBS and work your way down. Are there any activities or tasks that are not connected?
Did the team miss a connection or is the task out of scope? Does every task support an objective, output,
activity area, or support need?
2. Start at the bottom of the WBS and go up. Do all work packages, tasks, summary activities support an objective,
output, activity area, or support need? If not, why is it there?
3. Are all work packages worded in the form “Action Word” + Subject? Is it clear what it means for the work package
to be “complete”? Do you need completion criteria to the work package? Or do you need additional tasks (or
check-points) such as “Checklist Approved,” “Contractor Work Approved,” “Complete project reviews.”
4. Does every work package have an identified an owner or required resource? Do summary activities have
owners?

Annex 4
Tip Sheet: Creating a Schedule
Annex 4: Tip Sheet: Creating a Schedule

• Task Relationships
The task relationships between work packages are known as Dependencies. If one task must happen before
another, it’s said to be dependent, or “linked.” This is called a Predecessor-Successor relationship. In scheduling
the focus is typically on the predecessor; that is, the task that must be done before something else can happen.
To create a schedule it’s important to know what the relationship is between
two tasks. If it is Serial, this means that one task must finish before another
Finish/Start
can start (finish/start). If two or more tasks can be performed at the same
Relationship
time, they are said to be Parallel: the tasks either start at the same time
(start/start) or finish at the same time (finish/finish).
• Milestones
Milestones are used to track major points of progress in a program while giving Start/Start
the Program Team smaller successes (“incremental benefits”) on which to Relationship
focus rather than the entire program’s goal. Milestones are significant events,
which mark completion of an activity or event and can be used to group major
components of a program. The top levels of the WBS are a good source for
milestones.
Examples of typical construction project milestones are: Design Complete,
Finish/Finish
Schematics Complete, Schematics Approved, or Construction Initiated.
Relationship
Notice milestones follow a different form from Tasks. Milestones are usually
in the form of “Subject” + “Statement of Completion or Initiation”. Example
statements of the ending or starting point are: complete, delivered, signed,
approved, or kick-off, start, initiate. Milestones are a single point in time. It’s
important to note that, unlike tasks, milestones have no time or resources
associated with them.
• Critical Path
The Critical Path is the route through the program tasks which takes the shortest amount of time to complete. If a
single task on the critical path is delayed, it means all the tasks behind it are delayed. There is no slack time, float,
no extra days: what this means is that, unlike other tasks, delays in tasks on the critical path can delay the delivery of
the entire program.
The critical path focuses the Program Team on priorities. If the choice is between doing a task on the critical path
versus one that isn’t, then the critical path task should be prioritized so that the program can stay on schedule. Again,
it is essential to track the critical path closely during implementation to avoid overall delays to the entire program.
• Step 1: Getting Started
Begin with the WBS. The WBS contains the task list that needs to be scheduled. Instead of the WBS tree structure
that flows top-to-bottom, you will now turn it on its side, creating a timeline format moving from left to right.
Whether you start from the end and work towards the beginning of the program, or the other way around, is a
matter of preference. But the simplest place to begin is with a box (Post-it) labeled “Program Start” and end with
a box labeled “Program End”. Now it’s a question of where all the other tasks fit in between. Identify major program
milestones and spread them out in rough order between Program Start and End. Taking tasks from the WBS, place
the summary activities in between the milestones where they make sense chronologically. Continue, again in rough
order with the subtasks, down to the work package level. You may now enter the WBS into scheduling software,
such as MS Project.

Annex 4
• Step 2: Establish Dependency Relationships Between Tasks

Above was a simple exercise to get tasks in roughly the right order on a timeline. This is followed by the more exacting
work of determining the dependency relationships. To do this, ask the following questions about each task:
- What other tasks must be completed before this one can be started?
- What task follows this one or can’t be started until this task is complete?
- What tasks can take place in parallel with this one; the tasks can be worked on at the same time as this?
• Step 3: Review the Schedule Dependencies
Once you think you have the task dependency relationship identified, it’s a good idea to review the logic of your
dependencies one last time. Starting either at the program end and moving backwards, or at the program start and
moving forwards, take a look at each task and draw connections to ask the following questions:
- Is this task a predecessor or successor to each of its connected tasks?
- Are there some predecessors that aren’t really required? Can the tasks be done at the same time or not; in
parallel rather than in serial?
- Do all the tasks connect and flow to support the project end (and the objectives represented by the
completion)?
- Are all of the tasks necessary? Are there duplicates or overlaps?
- Are all the necessary tasks shown? Do you need to add a task to make logical sense?
- Can tasks be split into smaller pieces so that it changes the dependency, allowing some work to be done in
parallel and some in serial?
• Step 4: Estimate Work Package Duration
You have now created what’s known as a Network Diagram, a diagram of the relationship between all the tasks. But
to create a schedule, time needs to be associated with each of the work packages. This comes through estimating
how long it takes to complete or deliver on a work package (in hours, days, or weeks). This is called the duration of
the task.
Task duration is a best guess, based on the resources you expect to have, the number of work hours in a day, and the
number of work days in a program month (after incorporating holidays and other non-work days). Add notes to your
tasks to indicate any assumptions your team makes as it creates the durations. Later you may want to run scenarios
modifying those assumptions.
When estimating durations, use the information you have from your team, people who will actually do the work,
experts, or refer to previous program experiences. Estimate duration at the work package level only. These durations
will be summed to create calculated durations at the summary activity level and up to the final project schedule. Once
the durations are estimated, add them to the work packages in the software.
Similar to creating the WBS, it’s common to ask at what level of detail the duration should be tracked at (hours,
days, weeks or months). Just as in the WBS, there is no “right” answer, but it is preferable if the owner of each work
package plays a leading role in estimating the duration required for that work package. The “right” level of detail is
associated with the potential risk of the task and how long it will take to complete the task. The higher the risk or the
longer the duration of a single task, the more likely the task should be broken down into smaller duration tasks. In this
way a high risk or long duration task can be tracked for progress in several small steps. The smaller steps have the
advantage of alerting the Program Team to problems earlier than if one large task is used. For example in the figure
below, the team could represent the tender process as a 39 day process, or by showing the detail below, they can
track who is responsible for which tender components and if the tender process starts to slip they can determine
the impact.
Sample Network Diagrams can be found within A Guide to PMD Pro.

Annex 4
Sample WBS / Schedule for a Tender Process
• Step 5: Calculating Schedule

For anything but the smallest programs, project management software such as Microsoft Project is a life saver.
The project management software automatically:
• reates the schedule. MS Project automatically creates the schedule (with the team’s task, relationship and
C
duration inputs), calculating start and stop dates, and critical path.
• Simplifies reporting. As the program begins, with progress data from the team (“actual start dates” for work
package, “actual end dates” for work packages, etc.), the software automatically calculates the program and
milestone percentages complete.
• ecalculates dates. As task owners report progress, the software calculates the effect of late or early
R
completed tasks, changing due dates and critical path. With a quick look, the Program Manager or PMO can
determine the status and priorities of the program.

Annex 5
Tip Sheet: Risk Management
Annex 5: Tip Sheet: Risk Management

The risk management planning process generally follows four steps:
• Step 1: Identify Risks through Team Brainstorming
Program risks can be internal and external. Internal include lack of resources or budget to accomplish the defined
project, or lack of expertise. External can be stakeholder based, geography, weather, language, etc. Risks can be
identified by making use of people who have done similar programs elsewhere, have worked in-country previously
and understand the specific challenges, and through lessons learned from other programs. Assumptions which may
have been outlined in the Identification and Design Phase become risks during subsequent program phases.
• Step 2: Prioritize Risks
Have the team estimate if the probability of the risk occurring is low, medium or high. And then have the team
determine the severity of impact if the risk were to occur; is it low, medium or high. In this way the risks can be
prioritized and the team can choose to further research and plan for those risks that are only “high” or “medium”
in some respect. It may not be worth the team’s time to review “low” severity or probability risks. However by not
addressing low risks, the team is in essence accepting that risk. If the risk occurs, the team has decided they can
deal with the impact at that time. It’s important not to remove the low risks from the matrix. Risk Management is
an iterative process and it is important to review even low risks as the program proceeds to be sure they haven’t
changed or become an indicator of a new higher risk item.
• Step 3: Reduce Risks
Once high and medium risks have been determined, the team can develop plans to reduce or even eliminate the risk.
The idea is to determine how to reduce the probability and severity of a risk from high or medium to low or zero. For
example, if through the vehicle procedures there is a check for an inflated spare tire on a vehicle, the unexpected
event of having a flat tire (perhaps in some regions a high probability, and a high severity) can be reduced to low
severity by having the spare.
There are different ways to respond to risks:
1. Accept Risk – an example is the team accepting low severity/low probability risks. If the risk occurs the team
has accepted the consequences and will react when necessary.
2. Avoid Risk – the team can avoid a risk by not doing that part of the program, or by doing it in a different manner
that avoids the risk. An example is that it may be cheaper and faster to have materials delivered directly to various
building sites, however if security of materials is a risk the team may choose to take extra steps and warehouse
the material first in a secure location.
3. Transfer the risk – a risk may be that Mercy Corps does not have the expertise or core competencies to implement
a particular portion of a program. In this case to transfer the risk of not completing that portion successfully,
Mercy Corps may decide to contract it out. This transfers part of risk to the contracted partner. However it
introduces new risks, which Mercy Corps must track through monitoring of the partner and associated risks.
4. Mitigate the risk and have contingency plans – Mitigating risks simply means a way to reduce the risk. If the team
isn’t able to completely avoid or transfer the risk, they may be able to decrease the probability of it occurring or
the impact should it occur. If it is deemed highly probable then the team should look at contingency planning.
What would the team need to do if the risk occurred? How much addition budget would be required? Would
addition people, equipment, or time be needed?
• Step 4: Develop Contingency Plans
Many risks cannot be mitigated. But they can be planned for and contingencies or “reserves” put in place. This is
the setting aside of additional funding in case a specific risk occurs. A classic example is a 10% contingency fund
for a building project. The percentage will be different depending on the estimated probability of error in the budget.
If inflation is great, or if the program has not been clearly defined, these are points of risks that the team will need to
determine a corresponding contingency fund against during the Set Up and Planning Phase.
The Risk Analysis Matrix is a project tool that the Program Manager facilitates and tracks. It is a listing of prioritized
risks that then identifies owners (the risk monitors), trigger events ( (indicates a risk is occurring), the potential
impact, and the mitigation plan which may include contingency plans (money, resources on call, etc).

Annex 6:
Example Process: Creating an Activity Budget
Annex 6: Example Process: Creating an Activity Budget

The following is an example of the steps to create an Activity Budget: A program activity is to hold a WASH training
of trainers. The program document says that there will be trainings in three counties, and four trainings will be held
per county.
Step 1: Identify Activity Parameters
a. Develop SOW for the training and identify total duration of the training activities.
b. Identify whether the trainer will be an internal staff member or consultant.
c. Identify the requirements for the training location.
d. Identify beneficiaries. How will they get to the training? Where will they stay if they are going to be overnight?
e. Identify materials requirements for the training.
f. Identify if snacks and meals will be provided.
Step 2: Identify Cost Categories
a. If consultant, what costs will be covered by the activity budget? (i.e. Will you need to pay daily rate? Keep in mind
this may include preparation time along with time to give the actual training. Do you need to pay for consultant
travel, per diem and lodging?)
b. If the training is held in a hotel the program will need to pay for the conference room rental. The budget may also
need to pay for tea breaks and lunch.
c. What costs will be required to get the beneficiaries to the training venue? Will the beneficiaries need lodging?
Per diems?
d. Any costs related to creating and/or supplying the training materials? What costs are necessary to print and bind
the training materials?
Step 3: Estimate Quantities
a. How many trainers/consultants and how many days/hours of service are required?
b. How many beneficiaries?
c. How many beneficiaries are local, and will not need transportation, lodging and per diems. How many beneficiaries
are not local?
d. How many meals and snacks will be provided?
e. How many days will lodging or room rental be required?
Step 4: Estimate costs
a. What is the average daily rate for a consultant in this area (check rates paid previously for similar activities)?
b. What are conference venue rates? What are the lodging rates?
c. How much should beneficiary travel cost? Per diems?
d. What are material printing costs?
Step 5: Roll Up Costs into a Detailed Activity Budget
a. Use spreadsheet or an existing budget template to show units, unit costs and totals.
b. Compare to available budget and adjust plans as necessary.
c. Ensure approval as required by your program and the FFM.
d. Ensure activity budget is included in program budget forecasting.

Annex 7Sample Kick-Off Meeting Agenda
Annex 7: Sample Kick-Off Meeting Agenda

Program Name
Portfolio
Participants:
• Portfolio management representative (Country Director, or HQ management)
• PMO representative (Director of Programs, or HQ Head of Department)
• Program Manager
• Program Team
• Senior Operations team members (Finance & Compliance, Logistics/ Procurement, HR/ Administration)
• Key external stakeholders (Partner team leaders, etc.).
Handouts: Proposal and Logical Framework; PWP (at a minimum, Program Schedule and relevant parts of Program
Budget); Program Charter (if it exists); M&E Plan
Agenda:
Sample WBS / Schedule for a Tender Process
Session 1: [insert time slot]
Goal, Objectives and Basic Parameters (time, cost, scope) of the Program, and its relationship to the overall
Portfolio

Review of Lessons Learned from Previous Similar Mercy Corps programming, if any

Review of Cross-Cutting Themes and their Integration into the Program

Presentation of approved Program Work Plan [reviewing, at a minimum, relevant parts of the schedule, budget, and
stakeholder register (recommended for complex programs)]

Discussion of Tasks on the Critical Path

Presentation of Program Charter [if applicable – not all programs will have a Charter]

Discussion of Program Support Needs (finance, logistics, administration) and Schedules

Presentation of Program Reporting (financial, narrative), Compliance (financial, operational, programmatic), and
Communication (internal, external) Requirements

Presentation of Program Monitoring & Evaluation Requirements

Annex 8
Sample Baseline Schedule Tracking Sheet
Annex 8: Sample Baseline Schedule Tracking Sheet

Program Name
Portfolio
Note: List all tasks or only those tasks that have been identified as on the Critical Path during the Set Up & Planning
Phase
Task
Task Respon-
Respon- Depen-
Depen- Planned
Planned Planned
Planned Actual
Actual Interim
Interim Actual
Actual Corrective
Cor-
sible (R);
sible (R); dent On
dent On Start
Start Finish
Finish Start
Start Review
Review Finish
Finish Actions
rective
Account-
Account- [from
[from [from
[from [from
[from [from
[from [from
[from Required
Actions
able (A)
able (A) PWP]
PWP] PWP]
PWP] PWP]
PWP] PWP]
PWP] PWP]
PWP] Required
1 Design Project – 10 March 09 April 2011 15 March 31 March 11 April 2011

Irrigation Engineer (R); 2011 2011 2011
Canal (sample PM (A)
only)
2 Carry Out Same Task 1 10 April 2011 27 April 2011 12 April 2011 20 April 2011 27 April 2011 Accelerate
Irrigation by two days
Canal due to late
Feasibility completion of
Study design
3 Contract Procurement Task 1 & 2 1 May 2011 15 May 2011 1 May 2011 7 May 2011 20 May 2011
Irrigation Officer, PM
Canal Skilled (R); PM and
Labor DoP (A)
4 Mobilize Project Task 1 10 April 2011 15 May 2011 12 April 2011 1 May 2011 15 May 2011 Accelerate
Supplementa- Officers (R); by two days
ry Community PM (A) due to late
Labor completion of
design
5 Construct Contractors, Tasks 1, 2, 3, 16 May 2011 15 September 21 May 2011 15 July 2011 15 September Accelerate
Irrigation Community and 4 2011 2011 by five days
Canal Project Engi- due to late
neer/ Officers completion of
(R); PM (A) contracting

Annex 9
Program Team Training Needs Assessment Format
Annex 9: Program Team Training Needs Assessment Format

Program Name
Portfolio
Position Skills Required Existing Skills Skills Needed Means of Skill

[from interview & Acquisition Rec-
observation] ommended (Time-
frame)
Program Engineer – Design of – Good – More exposure to – Self-directed

(sample only) moderately infrastructure irrigation system reading of
complex irrigation design design concepts irrigation and
projects experience, hydrology texts
but limited – More exposure (3 months)
– Feasibility studies experience with to hydrological
of potential irrigation concepts – Meeting with
irrigation projects Department
– Good feasibility – More exposure of Hydrology
– On-site study experience, to best practices counterparts
supervision of but limited in construction (2 months)
construction hydrology supervision
experience – Training on
construction
– Low on-site supervision
construction (6 months)
supervision
experience
Program Officer – Mobilize – Moderate – More mobilization – Gender-sensitive,
community user mobilization skills conflict-sensitive
group experience community
– Better mobilization
– Train community – Good training understanding training
user group experience, of O&M for (2 months)
on internal but no O&M community-
management experience managed – Training on O&M
and irrigation infrastructure for community-
operations & – Good monitoring managed
maintenance experience infrastructure
(6 months)
– Monitor activities
of community
user group

Annex 10
Annex 10: Program File Contents Checklist
Identification & Design
1. Assessments (see Minimum Standards checklist)

a. Written assessment or problem analysis (can be included in proposal document or can be a separate
assessment document)
2. External stakeholders list
a. List of external stakeholders (with contact information) participating in initial consultations
b. Community selection written rationale
c. Partner identification written rationale
3. Proposal or Preliminary Scope Statement
a. Final submission approved by donor
b. Logical Framework
c. Summary Budget
4. Documentation of the review of lessons learned and best practices
Set Up And Planning
1. Agreements
a. Final signed program agreement with donor
b. Agreements of Understanding – communities/partners/government (Memorandum of
Understanding (MOU), letters of support, etc.)
c. Modifications and amendments to program agreement
d. Official communications with donors, including requests (NCE, key personnel, waivers, etc.) and
approvals
2. Work Plan (see Minimum Standards checklist)
a. Key program parameters, coming from preliminary program documents
b. Work Breakdown Structure (WBS)
c. Program Schedule
d. Coded program budget
e. End of Program transition plan
CONTINUED

Annex 10
Implementation
1. Meeting Minutes
a. Kick-Off Meeting minutes
b. Program Team Coordination Meeting Minutes (quarterly)
c. External stakeholder meeting minutes
2. Reporting
a. Program reports submitted to donor (interim, annual and final)
b. Internal Program Progress reports
i. Means of verification such as beneficiary lists, attendance sheets, survey data, etc.
c. Updates to Program Work Plan
d. Issues Log (recommended)
e. Risk Register (recommended)
3. Sub-grants (see sub-grant manual and Grant File for more info)
a. Approved proposal and coded budget
b. Sub-grant agreement
c. Memorandum of Understanding
d. Program reports (interim, annual and final)
4. Deliverables
a. Descriptions of Deliverables (Documentation of planning)
b. Verification of execution / proof of assistance received
c. Reports of quality assurance checks
5. Human Resources
a. Organizational chart (Personnel and Job Files are retained with HR)
b. Consultants
i. Consultant agreement
ii. Scope of Work
iii. Final deliverables / output
c. Training Needs Assessment
1. Indicator Plan / Performance Monitoring Plan (PMP)

a. Deviations formally documented and plan updated
2. M&E Event Reports (baseline, endline, and routine monitoring)
3. Evaluation Report (mid-term and final)
4. M&E Data Management System Reports
5. M&E Data Sources disaggregated by sex and age
a. Surveys
b. Beneficiary lists – activity, location, names, etc
c. Attendance sheets – trainings, meetings, etc
d. Pre- and post- tests from trainings
e. Routine monitoring reports (projects & sub-grants)
CONTINUED

Annex 10
1. End-of-Program Transition Plan (written & approved)

a. Proof of communication to internal team members as well as external stakeholders
b. Sub-grant end of program closure documentation and formal acceptance of work performed
2. “Final 90 Day” Meeting Minutes
3. Handover report to external stakeholders
a. Handover of deliverables documented (includes infrastructure)
4. Lessons learned written document

Acknowledgements
First published in 2012. This manual was developed for Mercy Corps with significant contributions from many
people. I would like to acknowledge the great work of Learning in NGOs (LINGOs), under the leadership of Eric
Berg, who first developed a Guide to Project Management for Development Professionals (PMD Pro) upon which
this manual is based.
I would like to extend my gratitude to the Program Management Advisory Group, Mignon Mazique, Craig Redmond, Bill
Farrell, Myriam Khoury, Jim White and Fernando Soares, for their direction and support throughout the development
of this manual.
Thanks goes to Josh DeWald and Najia Hyder who carefully guided the development of this manual’s content with
the support of members of the Program Management Working Group, who lent their time and expertise to crafting
sections of this manual. Working Group members included Stephen Claborne, Andrew Dwonch, Doug Baken,
Gretchen Ansorge, Alder Kovaric, Joe Dickman, Gretchen Shanks, Laszlo Viranyi, Greg Shortreed, Michael Bowers,
Janell Lee, Jim Berry, Mort Anoushiravani, Kathy Grantz and Tricia Matthews.
Numerous content reviewers provided their insight into making the manual a useful resource for Program Management
at Mercy Corps. Thank you to Kevin Grubb, Su’ad Jarbawi, Victoria Stanski, Barbara Willett, Jodie Behfar, Aimee
Pedretti, Jihane Nami, Catherine McMahon, Carol Skowron, Emily Sinn, Shannon Alexander, Sahar Alnouri, Jenanne
Luse, Cali Livingstone, Grace Becton, Anna Young and Laura Miller.
Countless other team members from throughout the Mercy Corps world contributed to the content of this manual
both directly and indirectly.
Finally, I would like to offer a special thank you to Mercy Corps’ CEO, Neal Keny-Guyer, for his leadership in building
an agency that strives for excellence in all that we do.
Brandy Westerman
Program Management Director

Proposal Writing

Uploaded by

Copyright:

Available Formats

Proposal Writing

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Proposal Writing

Uploaded by

Copyright:

Available Formats

Program Management Manual

mercycorps.org < Table of Contents 

Acronyms and Abbreviations

BVA. . . . . . . . . . . . . . . . . . Budget vs. Actuals

 < Table of Contents mercycorps.org

Chapter 1: Introduction and Contextual Information

Why Do We Need the Program Management Manual?

resources and instruction for meeting the Minimum Standards as well as

additional recommendations for successful program management.

This manual is a supplementary document to A Guide to the Project Management

mercycorps.org < Table of Contents 

What is PMD Pro and How Does it Relate to This Manual?

1.2. Certification Requirements for Mercy Corps Program Management

Team member Certification Requirements Timing

 < Table of Contents mercycorps.org

1.3. What is Program Management?

What is Program Management?

Global Standard Terminology Mercy Corps Context

mercycorps.org < Table of Contents 

Field Example Notes

1.4. The Program Manager’s Role and Generally-Accepted Knowledge/

 < Table of Contents mercycorps.org

Chapter 2: The Program Lifecycle and Minimum Standards

Monitoring & Evaluation

Program Program Planning End of

2.1. Definition of Each Phase within Mercy Corps:

A Guide to PMD Pro.

mercycorps.org < Table of Contents 

2.2. Key Aspects of the Program Management Lifecycle at Mercy Corps

! 2.3. Minimum Standards Checklist

Minimum Standards Checklist

 < Table of Contents mercycorps.org

Set Up and Planning (Chapter 4)

Monitoring & Evaluation (Chapter 6)

End-of-Program Transition (Chapter 7)

mercycorps.org < Table of Contents 

2.4 Mercy Corps Internal Resources

10 < Table of Contents mercycorps.org

Chapter 3: The Program Identification and Design Phase

Identify Analyze Develop Develop

Planning Kit: Assessment Problem Tree Framework Development

mercycorps.org < Table of Contents 11

Minimum Standards for the Program Identification and Design Phase:

About This Chapter

3.1 Introduction to New Program Development at Mercy Corps

12 < Table of Contents mercycorps.org

3.2 Identification of Program Ideas

14 Overview of Strategic Planning Tools and Techniques: https://mcdl.mercycorps.org/gsdl/cgi-

mercycorps.org < Table of Contents 13

3.3 Funding Opportunity Analysis 18 19

Responding to a Request for Applications (RFA)/Call for Proposals

14 < Table of Contents mercycorps.org

mercycorps.org < Table of Contents 15

3.5 Program Analysis

23 Section 2: Chapter 1, page 16

16 < Table of Contents mercycorps.org

3.6 Program Logic

mercycorps.org < Table of Contents 17

mercycorps.org < Table of Contents

< Table of Contents mercycorps.org

mercycorps.org < Table of Contents

1.2. Certification Requirements for Mercy Corps Program Management

< Table of Contents mercycorps.org

mercycorps.org < Table of Contents

1.4. The Program Manager’s Role and Generally-Accepted Knowledge/

< Table of Contents mercycorps.org

Chapter 2: The Program Lifecycle and Minimum Standards

mercycorps.org < Table of Contents

2.2. Key Aspects of the Program Management Lifecycle at Mercy Corps

< Table of Contents mercycorps.org

mercycorps.org < Table of Contents

14 Overview of Strategic Planning Tools and Techniques: https://mcdl.mercycorps.org/gsdl/cgi-

37 Proposal Work Plan Template: https://mcdl.mercycorps.org/gsdl/cgi-

42 E xclusive Letter of Commitment for Key Staff: https://mcdl.mercycorps.org/gsdl/cgi-

51 Tips for Proposal Reviewers: https://mcdl.mercycorps.org/gsdl/cgi-

1. Assessments (see Minimum Standards checklist)

Consider likely distribution procedures, and time requirements

Initially, base operations staffing levels on the “ideal case”

Determine the need for a security assessment