Chapter 9.
Project Feasibility and Design

9.1 Introduction

Project feasibility and design are based on the knowledge and information obtained from the previous stages of the project cycle (the preliminary screenings described in section 6.5 and the more in-depth project analyses described in Chapter 8), continued stakeholder consultations and data gathering. Project feasibility and design are products of the information gathering and knowledge building continuum started with the preliminary screening. From different perspectives, both synthesize all the relevant information from the above sources, especially the in-depth project analyses. However, they both also contribute to greater knowledge and understanding about the proposed project and provide the necessary documentation to proceed with the project approval and the contracting processes (Request for Proposals [RFP], contract or contribution agreement) (see Chapter 11 and the Contracting Guide for Managers in CIDA).

Information gathering for the appraisal and feasibility exercises is usually part of the same review process, but responds to different requirements. Project appraisal answers the questions, "Why should we invest in this project and what specifically should the project try to accomplish?" Project feasibility answers the question, "Can we do this project?" Project design answers the question, "How should we structure the project to best achieve the expected results?" The over-lapping of these processes are particularly important to note when external resources and missions overseas are involved.

As with other project cycle activities, project feasibility and design should follow a consultative process whenever possible and region/country partners must agree to the design of the project.

During feasibility and design activities, the PM will rely heavily on the appropriate scientific and technical specialists on the project team as all projects have a "technical" element whether they address newer and "softer" subjects (like capacity development) or in more traditional sectors where there are physical outputs.

As in other project cycle activities, the time and effort devoted to project feasibility and design should be a function of the size, complexity and potential risk of the project.

9.2 Project Feasibility

9.2.1 Background and Purpose

In additional to the specific appraisal analyses described in Chapter 8, it is often necessary to determine and report on the feasibility of a proposed project usually using information from the project analyses which should be complemented by other information, as appropriate.

The feasibility work is not necessarily a separate activity from the project analyses. Rather, it produces a different type of report which has two objectives:

When a project is considered feasible, it leads to project design which is dealt with in greater detail in section 9.5 below.
Helpful Hint:
Ideally, the staff or consultants responsible for assessing project feasibility are (or have been) already involved in the project analyses required on the proposed project.
9.2.2 Feasibility Process

The feasibility study can be seen as a three step process.

Step One - Viability: The first step reviews the viability of the proposed project by determining whether or not the project is:

The viability assessment uses the knowledge gained during the appraisal process and is normally done by the same staff or consultants who conducted the various project analyses described in Chapter 8. In addition to the specific subjects covered by the analyses, the issues of technical soundness and project manageability (including the availability of any untied funding required, other financial management considerations, and Canadian capacity) are reviewed.

The results of the viability assessment should be summarized and documented. If the result is positive, the project team moves to the second step. If the viability assessment is negative, this should be communicated to the Program Director (PD) and project planning activity should cease with the agreement of the PD. Other project ideas should then be screened for possible selection as per Chapter 6.

Step Two - Delivery Options: If the project is considered viable, the feasibility study then identifies various delivery options for achieving the desired project result at the purpose level (Outcomes) and provides a preliminary analysis of each option. The issues for review will vary by project, but typically they would include issues of appropriate technology, appropriate technical methodologies and approaches, prospects for technology transfer and sustainability, maintenance issues, recurring costs, the recipient country and Canadian capacity to undertake each delivery option, donor cooperation, and the overall capacity development potential of each option. Cross-cutting themes such as gender equality and the environment may also influence the review of delivery options. The positive and negative aspects of each option should be described along with a preliminary costing for each option.

Step Three - Decision: The options are then assessed one against the other and the preferred option is chosen by the Project Manager (PM) in consultation with the project team (and PD, if appropriate). Consultations should also be held with the recipient country on the choice of the preferred option as soon as possible.

Once the preferred option has been chosen, the documentation produced during feasibility is compiled and put in the official project file for future reference. CIDA staff or consultants then proceed with project design as outlined below.

Note:
CIDA's participation in either conducting or reviewing feasibility studies is normally assigned to the scientific and technical specialist(s) on the project team working in collaboration with the PM.
9.3 Project Planning and Design Considerations

Project design follows from the project analyses and the feasibility assessment of the project. It is implicit that the recipient country/partners are involved, as appropriate, throughout the process and agree to the design (see section 9.6 below). Project design work includes the preparation of the project design documentation to be shared with the recipient country/partners (see section 9.4 and section 9.5), as well as the CIDA Project Management Strategy (see section 9.7 and section 9.8) and the Contracting Plan (see section 9.9) which are in-house documents.

The project design will be used in the preparation of the Project Approval Document (PAD) (see Chapter 10) and the Request for Proposals (RFP) from potential Executing Agencies (EA). (The RFP includes the project description and the Executing Agency's terms of reference.) The project design needs to describe "what" CIDA wants done within given parameters (at a suitable level of detail) and not "how" to implement the project in great detail. Project design does not include preparation of a detailed management or operational plan by CIDA. The project Executing Agency will prepare a detailed Project Implementation Plan (PIP) and associated plans as one of the first tasks under its contractual obligations and responsibilities.

The following points may be useful in managing the project design process:

9.4 Project Design Tools

To plan and manage a project, CIDA relies on several common project management tools, all within the framework of the Results-Based Management in CIDA - Policy Statement . These project design tools include: the Logical Framework Analysis (LFA) (see Chapter 5); the Work Breakdown Structure (WBS) ; project budgets and schedules; project progress and results reporting, as well as the contract or contribution agreement governing the implementation of the project.

Note:
Further information on the following tools is available from your Branch Strategic Management Division.
a) The Work Breakdown Structure should be developed along the following lines:
Note:
For planning purposes, CIDA may record the activities and resources required to produce each desired Output. However, during implementation, CIDA's management interest remains at the Output or Outcome level, depending on the nature of the project, but not at the activities level, which is the responsibility of the EA.
Like other project documents, the WBS evolves over the life of the project. The general WBS prepared as part of the project design is used by CIDA in the Request for Proposals. This is further developed by the consultants or organizations submitting proposals and refined by CIDA and the successful firm or organization during the contracting process. Once the EA is fielded, it will prepare a detailed WBS as part of their Project Implementation Plan (PIP) (see section 12.3) which breaks each Output into smaller work packages which the EA must organize, schedule, monitor and control.

The WBS should also indicate any interrelationships between individual Outputs and the party responsible for achieving each Output.

Note:
LOB 5 Projects (see section 4.4.5): During Project Design and Approval, the CIDA WBS on an Iterative Project (LOB 5) would have detailed information for the first year and preliminary information for future years.
b) The Project Budget provides a tool for estimating the cost of each of the proposed Outputs and, therefore, the anticipated Outcomes. The CIDA project budget will initially be used in the CIDA Project Management Strategy (see section 9.7) and the PAD (see Chapter 10), and may include funds for monitoring, contingency, risk and other items which may not be included in other project documents such as the MOU, RFP or EA contract or contribution agreement. The CIDA budget will provide a matrix of Output costs by fiscal year for cash-flow purposes, including projected rates for, and cost of, inflation.
Notes:
§ For planning purposes, CIDA may estimate the cost of activities and resources required to produce each desired Output. However, RFPs and EA contracts for project implementation, would focus on Output costs, not activity costs. While CIDA may monitor activity costs during project implementation, CIDA's management interest remains at the Output or Outcome level, depending on the nature of the project. Activities are the responsibility of the EA.
§LOB 5 Projects: The budget on an Iterative Project (LOB 5) at the time of Project Approval would have detailed cost estimates for the first year and general cost estimates for future years (see section 4.4.5).
c) The Project Schedule can be shown as a bar or Gantt chart which would indicate the planned start and end dates for each Output (CIDA's management interest) and other major project milestones, but not each activity (which the EA will do in the Project Implementation Plan [PIP], see section 12.3).

d) Project Progress Reporting is the key tool for the CIDA PM to assess project progress towards the anticipated results (compared to the utilization of project resources) and is dealt with in section 9.8.4 below.

9.5 Proposed Project Design Documentation

The proposed project design is the final product of the planning process. It is the culmination of all of the information gathering and knowledge building activities directed at the specific project (mainly appraisal/analyses and feasibility) and leads to the CIDA Project Management Strategy (see section 9.7), the PAD (see Chapter 10), the MOU (see section 11.3), and selection of an Executing Agency.

Project design documentation should be concise and include:

Project design (and the CIDA Project Management Strategy described in section 9.7 below) should be detailed enough to allow for the immediate preparation of the PAD and the terms of reference for the RFP. Project design documentation should be structured and written so as to allow for the transferring of information and text from the design stage to the PAD and RFP documentation with a minimum amount of editing. These documents, in turn, lead to the project MOU and implementation contract.
Note:
The nature and scope of project design documentation will be affected by:
§ the size and complexity of the project; and
§ the Line of Business (see section 4.4 and the document entitled Lines of Business):
»LOB 1, design documentation will be quite detailed;
»LOB 2 and LOB 3, project design may be less detailed;
»LOB 4, design documentation will deal mainly with the mechanisms of the overall development fund;
»LOB 5, project design will focus mainly on the first year and provide the mechanisms for determining/approving future year design parameters;
»LOB 6 and LOB 7, handled on a case by case basis; and
»LOB 8, the Project Proponent is responsible for project design, but the bilateral desk must produce a CIDA Project Management Strategy including a Project Performance Measurement Framework.
9.6 Recipient Country Agreement with Project Design

Assuming that a recipient government partner has been involved in the design process, it is wise to obtain working level agreement to the basic design parameters before the project is submitted for approval. This is best achieved in writing. Options include an Exchange of Letters (attaching a proposed project design document) or by obtaining a signature on the proposed project design document itself.

The main points requiring agreement are:

There should also be clear agreement on the general responsibilities of the parties and what resources each party will provide and when.

The agreement on project design would mention that, if the project is approved, an MOU would be signed between the parties and a plan (prepared by the EA or Implementing Organization) would be drafted which would provide further project details for the approval of the parties.

Project design is the basis for preparing and adopting a suitable CIDA Project Management Strategy as discussed below.

9.7 CIDA Project Management Strategy

9.7.1 Introduction

Detailed Project Management Plans are no longer prepared by/for CIDA prior to project approval. Instead, a more strategic document, the CIDA Project Management Strategy (as described below), is required for all projects, including responsive projects. When a project becomes operational, a Project Implementation Plan (prepared by the EA or Implementing Organization) will be required in accordance with section 12.3.

The CIDA Project Management Strategy uses the project design documentation (section 9.5 above) and decisions taken in relation to other management matters as found in section 9.8 and section 9.9 and brings them together into a single, summary, project management document. The level of detail of the CIDA Project Management Strategy should reflect the size, complexity and potential risk of the project, but it should not be a detailed Management Plan. The Project Management Strategy is a strategic document and should not get into operational details, which are the responsibility of the EA.

The CIDA Project Management Strategy is prepared by the PM with the assistance of other project team members, particularly the scientific and technical specialist(s), and is approved by the PD.

The CIDA Project Management Strategy serves the following main purposes:

Notes:
§The document should be short, clear and focused on managing change so as to serve as a useful management tool for the PM and other project team members.
§If the CIDA Project Management Strategy is to be shared with the recipient country and/or included in the project MOU, the PM should review the Strategy to assure that any strictly internal information (such as any sensitive elements of the Contracting Plan (section 9.9)) are deleted or summarized in the version to be shared.
The CIDA Project Management Strategy is not a part of the PAD (see Chapter 10). As CIDA's intended approach to project management, it is a key supporting document that will lead directly to the RFP, MOU and implementation contract (see Chapter 11). Its existence is confirmed to the approval authority in Item c) of Annex A of the PAD.

As suggested above the CIDA Project Management Strategy should be structured and written so as to allow for the transferring of information and text from the Strategy to the PAD and RFP documentation with a minimum amount of editing.