PIMS Chapter 3

Chapter 5 System Development | 55

Chapter 3 Modules “Not everything that can be counted counts, and not everything that counts can be counted.” Albert Einstein.

Modules of an Information System Any information system must be built with enough flexibility to accommodate the specific needs of the project, but at the same time must comply with basic standards that make analysis of the project progress available at all levels of management. Depending of the nature and information complexity of each project, the system will contain a basic core or central module that structures the project’s basic set of information. Each project can then add more complex processes and modules as the specific needs of the project may require it.

A PIMS is designed using a modular approach; each module provides a specific functionality and meets a specific goal. The modular approach allows for a structured method to develop and grow the information system based on needs. It also takes into consideration the integration of the different modules with each other to improve the management of information and eliminate redundancies.

An Integrated Approach Most project-information systems are built independent of each other, each designed to specific needs, and each project has a different definition of how to structure information. For example, a project health-information system

56 | Project Information Management Systems for Development Organizations

will focus on collecting health information such as the number of patient visits, the number of vaccines, and the number of health practitioners trained; an agriculture-project system will concentrate on collecting data on crop yields, market prices, types of pesticides used, etc. All the systems are serving the specific needs of projects, but it becomes impossible for an organization to consolidate information, as each project defines its own process and components of project information.

Project information systems are also designed to meet the specific needs of a donor entity and do very little to manage information beyond the scope of those needs. These systems have their own methods, tools and processes for collecting and structuring data that, for most cases, will not be used beyond the life of the project. As a result, development organizations end up with information on the systems that is isolated and difficult to integrate or consolidate. Additionally, the excessive focus on collecting data gives projects little time to analyze and use the information internally, and even less time to share it and compare it with other similar projects.

Most of the data that projects collect is seldom reported or has little use in the evaluation of the project. This excessive focus on data collection has led many projects to have data, but little information to guide the organization on how the project contributes to the organization’s strategy and objectives.

Development organizations need a holistic view of project information systems, one that looks at information as an organizational resource and not as a project output. This book will present the concept of structuring project information into six modules, which will facilitate the consolidation and management of information across all projects.

The Core Modules of PIMS The core modules are a way of categorizing basic information into logical groups, each with its own set of processes for information management.

Each module defines the minimum information elements that a PIMS should have. There are six basic modules for a good PIMS:  Scope: the agreed work of the project  Schedule: the timing of all the project work  Budget: the project funding

Chapter 4 Information Life Cycle | 57

 Team: the project members  Beneficiaries: the project participants  Results: the project indicators to measure goals

The Project Scope The project scope includes basic project information, and information on all objectives and activities. As the central module of PIMS, it defines the relationships among the other modules. This module includes information across two areas:  General Project Information  The Project Scope

General Project Information Information on the project includes the main objective of the project, the project code, and the donor. It also includes the name of the project manager, the estimated start and end dates of the project, the project type, and total amount of funds available to the project. This information is set up at the beginning of the project and requires little or no changes; it provides high-level information about the project to all stakeholders.

Information Type

Description

Country

Name of the country where the project will be implemented.

Project Number

A unique number assigned to identify the project.

Project Acronym

A simple word to easily identify the project.

Project Name

The complete name of the project.

Project Type

The type of project, emergency, development, etc.

Project Start Date

The actual start date of the project, per donor contract.

Project Completion Date The planned end date of the project, per donor contract.

58 | Project Information Management Systems for Development Organizations Project Final Evaluation Date

Estimated date of project evaluation (month/year).

Project Manager

Name of manager responsible for the project, phone and email.

Project Main Objective The ultimate goal or the impact the project is seeking to achieve.

Project Beneficiaries

A description of the main beneficiaries of the project.

Number of Direct Ben- Detail the total number of beneficiaries. eficiaries Project Location

The locations where the project will be implemented.

Project Stakeholders

All the key project stakeholders.

Project Budget

The total project budget (USD, Euro, etc.).

The Project Scope Information The project scope is a description of all the work of the project. One way to present this information is with the use of a Work Breakdown Structure (WBS). The WBS is a deliverable-oriented hierarchical decomposition of the work, listing all the work of the project to accomplish the project objectives. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. In a PIMS it is used to organize all the activities of the project in a logical grouping structure that links the project goal with the project outcomes, and each outcome with a project outputs and its related activities.

The example below shows a diagram of a WBS, the top level is the project goal. On the second level are the project outcomes. The third level groups the project outcomes that contain all the project activities at the fourth level.

Chapter 4 Information Life Cycle | 59

Figure 2 Work Breakdown Structure

The WBS builds the relationship among all the elements of the project. The structure is built following a direct relationship between the expected final goals down to all the planned activities of the project. The information should include detailed descriptions of each level and the indicators of achievement selected by the project to measure progress.

Project Goal Information Type

Description

Goal Statement

A description of the project goal. (By June of 2010, 5,000 project beneficiaries will reduce diarrhea infections by 90 percent.)

Risks

All the critical risk the project will face trying to meet the goal.

Dependencies

Any dependencies of this goal on other projects or actions taken by the organization or other entities with the same group of beneficiaries.

60 | Project Information Management Systems for Development Organizations

Project Outcomes Information Type

Description

Outcome Statement

A description of the project outcome.

Assumptions

The factors necessary to contribute to the achievement of the outcome.

Risks

The risks that will jeopardize the achievement of the outcome.

Factors outside the control of the project.

Constraints

The constraints to achieving the project outcomes.

Dependencies

Any dependencies of this outcome on other projects or actions taken by the organization or other entities with the same group of beneficiaries.

Project Outputs Information Type

Description / Example

Output statement

A description of the project output.

Assumptions

The factors necessary to contribute to the achievement of the output.

Risks

The risk associated with achieving the project outputs.

Constraints

The project constraints to achieving the project outputs.

Dependencies

Any dependencies of this output on other projects or actions taken by the organization or other entities with the same group of beneficiaries.

Chapter 4 Information Life Cycle | 61

Project Activities Information Type

Description / Example

Activity

A description of the project activity.

Assumptions

The factors necessary to contribute to the achievement of the activity.

Risks

The risk associated with achieving the project activity.

Constraints

The project constraints to achieving the project activity.

Dependencies

Any dependencies of this activity on other projects or actions taken by the organization or other entities with the same group of beneficiaries.

Responsibility

Name of the person responsible for delivering the activity.

Support Resources The names of the people that will provide support to achieve the activity; these may include consultants, vendors or partners.

Material Resources A list of the required materials needed by the activity.

Equipment Resources

A list of the required equipment or tools needed by the activity.

The Project Schedule Schedule Development Information to create the schedule comes from the WBS, which has all the activities identified for the project. The quality and completeness of the WBS will determine the quality of the schedule, and this is a good time for the project team to review whether all the project activities are accounted for. Building the schedule is actually the easy part; once a project is published and issues and changes start to creep, the schedule becomes difficult to manage. The goal of developing the schedule is for the project team to have a complete understanding of all the work that they must accomplish

62 | Project Information Management Systems for Development Organizations

and develop an understanding of the constraints, dependencies, and the sequence of the activities.

The duration of an activity includes the actual amount of time needed to complete an activity or work effort. The estimation should take into account the number of people available to the project. For example, if an activity takes one week for one person, the estimate may become two weeks if the person works only half-time. This information is important at the moment of determining the total time needed for the project based on the resources available. It is important that the people actually responsible for doing the work have a say in the selection of the estimates. The typical units for measuring the duration of an activity are days or weeks.

Schedule Information All activities in the WBS have an estimate of the time it will take to complete them. This estimate becomes part of the project schedule, which is the total time to complete the project. Each activity identified in the WBS will have an estimated start and end date. Each activity will also have a dependency relationship with other activities; the purpose is to create a chronological order among the activities.

Using the information from the WBS, the project team will start defining the estimates of duration of each activity and its chronological dependencies; the table below shows an example: WBS

Activity Name

Days

Start Date

End Date

Dependency with Activity No

1.1.1

Activity 1.1.1

20

Tue 01-06-10 Mon 21-06-10

1.1.2

Activity 1.1.1

30

Tue 22-06-10 Mon 02-08-10 1.1.1

1.2.1

Activity 1.2.1

30

Tue 03-08-10 Mon 13-09-10 1.1.2

1.2.2

Activity 1.2.2

20

Tue 14-09-10 Mon 11-10-10 1.2.1

1.2.3

Activity 1.2.3

10

Tue 12-10-10 Mon 25-10-10 1.2.2

1.3.1

Activity 1.3.1

30

Tue 14-09-10 Mon 25-10-10 1.2.2

1.3.2

Activity 1.3.2

20

Tue 26-10-10 Mon 22-11-10 1.3.1

Chapter 4 Information Life Cycle | 63 2.1.1

Activity 2.1.1

10

Tue 23-11-10 Mon 06-12-10 1.3.2 and 1.2.3

Schedule Graphics A network diagram is a graphical representation of the sequence of project activities and the dependencies among them. The network diagram is read from left to right, or top to bottom. The network diagram uses a diagram technique in which boxes represent activities (used by project-scheduling software).

The complex and dynamic nature of development projects make this tool especially valuable because it forces the project team to address potential interactions of project activities that can be easily missed otherwise. Another benefit of a network diagram is the identification of the project critical path, the longest path in the network diagram. In this diagram, the project’s critical path is the path with the longest duration. The example below shows the critical path as the series of activities 1.1.1, 1.1.2, 1.2.1, 1.3.1, 1.3.2, and 2.1.1, a total of 135 days. Any delays in those activities will result in a delay of the project. Activities 1.2.2 and 1.2.3 have a lag of 20 days compared with activities 1.3.1 and 1.3.2. That means that those activities can be delayed to up to 20 days without delaying the project.

Figure 3 Network Diagram

Another popular method to display and monitor a project schedule is the Gantt chart. It is a popular method used in most project-scheduling software.

The chart was developed by Henry Gantt in 1911 and since then has been incorporated, with some improvements, to the field of project management.

64 | Project Information Management Systems for Development Organizations

Figure 4 Gantt chart

As a graphical representation of activities as segments on a time scale, the Gantt chart helps plan and monitor project progress. The left side of the Gantt chart is a column with a list of all activities or tasks. The horizontal axis is a time scale, expressed either in absolute or relative time. In a Gantt chart, each activity takes up one row. Dates run along the top in increments of days, weeks or months. Rows of bars in the Gantt chart show the start and end dates of each activity in the project. Activities may run sequentially, in parallel or they may overlap.

Schedule Analysis and Monitoring Monitoring the project schedule is mainly focused on determining the current status of the project. The project manager will determine what factors have resulted in changes to the planned schedule; these factors may be internal or external. The project manager will determine the impact on the schedule and identify the necessary actions to bring the schedule back to its original status. For example, an activity was estimated to take 30 days to complete, but an external factor caused a delay of two days. If the activity is on the critical path, the entire project will be delayed by two days. The project manager will need to evaluate how critical the delay is and find alternatives, such as adding resources in the critical path in order to reduce the time needed and bring the project completion to the planned date.

Chapter 4 Information Life Cycle | 65

The Project Budget Budget information is among the most critical information a PIMS should have. The careful planning of project costs and expenditures can be a significant factor in the success of a project. The project manager is responsible for the project budget, especially in using resources wisely to meet the desired objectives. Project expense reports are an important source of information for a project manager. They provide a detailed view of where the project is in terms of its cost and that can help determine whether or not the project can complete all its planned activities. Quick access to accurate budget information is a critical requirement of a PIMS.

Budget Development The PIMS should have the means to help in the development of the project budget. There are two approaches to develop a budget: top-down and bottom-up. Top-down occurs when the project has been assigned a lump-sum figure and the project managers needs to figure out the number of activities that can be achieved with the assigned budget. The bottom-up approach is to determine how much money a project will need based on the required activities. In any case, all activities should have an estimate of the cost required to complete them. The project can use the initial estimate to develop the final project budget using financial codes from the chart of accounts.

The purpose of having the project budget broken down by activity is to help in the analysis of project progress and determine if the project is meeting its goals on time and within budget. A common problem for project managers is to find out at nearly the conclusion of the project that they either have no money to complete the planned activities, or that there will be an excess of funds that the project will not be able to spend and may need to be returned to the donor.

Budget Information With budget information broken down by activity, the project manager can easily verify how the physical progress of the project, from the project

66 | Project Information Management Systems for Development Organizations

schedule, matches the project budget plans and actual expenditures. The table below is an example of a budget that details the costs for each activity in terms of labor, material and other costs.

Activity No.

Labor Cost

Material Cost

Other Costs

Total Cost

Activity 1.1.1

2,500

1,000

2,000

5,500

Activity 1.1.2

3,500

2,500

3,000

9,000

Activity 1.2.1

4,500

2,000

2,000

8,500

Activity 1.2.2

2,000

4,000

3,000

9,000

Activity 1.2.3

6,000

5,500

2,000

13,500

Activity 1.3.1

2,500

3,500

4,000

10,000

Activity 1.3.2

2,000

1,500

2,000

5,500

Activity 2.1.1

3,000

2,500

1,000

6,500

Total Costs

26,000

22,500

19,000

67,500

With this type of information, the project manager can organize the budget following the initial project Logframe, tracking and measuring the cost of the project by the outputs it has produced. The budget information is quite useful at the time of project evaluation to determine the actual cost of the project, or the cost that the project incurred, in order to meet a desired outcome.

Budget Analysis A simple method to analyze the progress of a project against the planned and actual budget is to chart the information. The chart below shows a line for the planned budget and another for the actual expenses, and the difference shows whether the project is under- or over-budget. Under-spending, is when the project spends less funds than what was originally planned; this can be caused by a slow start of the project. Overspending, is when the pro-

Chapter 4 Information Life Cycle | 67

ject is using funds faster than originally planned. The results of overspending can be significant for an organization, since it may need to use unrestricted funds to cover the costs reimbursed to the donor.

Every project has a natural cycle that defines the rate of fund use during a year; the project manager must try to align the project's budget expenditure plan to its natural cycle and avoid the cost associated with under-spending or overspending.

Figure 5 Project Budget Chart

Budget Monitoring At the end of a cycle, a month or a quarter, the project manager needs to evaluate the project budget to determine if the project is on-track and whether its financial resources are being used accordingly. The most common method is to use the budget reports that show the planned budget versus the actual expenses made by the project. This report shows the budget permonth, the remaining balance for each account, and the burn rate of how fast the project is using the budget. The project manager uses the report to monitor how the project is using the budget, if there are any deviations from the plan, and how the remaining balance fares in order to complete the project as planned. One limitation with this report is that sometimes the report does not

68 | Project Information Management Systems for Development Organizations

show the purchase orders that are in transit or in the payment process. The following is an example of a budget report on month six that shows the planned, actual and balance for each account for a twelve-month project.

Account No.

Planned

Actual

Balance

Burn Rate

5401

20,000

10,000

10,000

50%

5402

35,000

15,000

20,000

43%

5403

45,000

25,000

20,000

56%

5404

20,000

25,000

-5,000

125%

5405

60,000

30,000

30,000

50%

5406

20,000

10,000

10,000

50%

5407

20,000

25,000

-5,000

125%

5408

30,000

10,000

20,000

33%

Total

250,000

150,000

100,000

60%

The above example shows the project manager that some accounts have used the planned budget faster than other accounts. It also shows two accounts that have exceeded the budget amounts and one account that has had very little activity. In general, the project has spent 60 percent of its budget in 50 percent of its time. One of the limitations of the burn rate report is that it shows the budget by account and not by activity. One way to present this information is in the example below: Activity

Planned

Actual

Balance

Burn Rate

Activity 1.1.1

15,000

15,000

0

100%

Activity 1.1.2

25,000

25,000

0

100%

Activity 1.2.1

55,000

55,000

0

100%

Activity 1.2.2

15,000

25,000

-10,000

167%

Chapter 4 Information Life Cycle | 69

Activity 1.2.3

35,000

30,000

5,000

86%

Activity 1.3.1

15,000

0

15,000

0%

Activity 1.3.2

40,000

0

40,000

0%

Activity 2.1.1

50,000

0

50,000

0%

250,000

150,000

100,000

60%

Total

The above table shows information that a project manager can actually use.

From the report, the project manager can see that activity 1.2.2 cost more than planned and that the remaining budget will only allow the completion of activities 1.3.1, 1.3.2 and 2.1.1. This leaving activity 1.3.1 incomplete or the project manager must find ways to reduce the cost, or request additional funds from the donor. The dynamics and different environments make the use of funds differ from month to month. The use of accounts to monitor a project is limited; a project manager needs to see if the remaining budget allows the completion of the remaining activities.

The Project Team This is the information on all the people dedicated to manage and execute the project activities. This information is complementary to the information captured by HR systems, and seeks to inform on the skills, responsibilities and roles of the people involved in the project.

By properly managing project staff information, the project manager can better understand the relationships and collaboration required to accomplish the project goals. This information can help clarify the roles of all members in the project, can help in the resolution of conflicts, and can especially help in identifying redundancies and omissions.

The PIMS organizes the information for all the people involved in the project to identify the different responsibilities, roles and levels of supervision.

Every task in the project should have a person assigned to it. Clear roles and

70 | Project Information Management Systems for Development Organizations

responsibilities reduce the chances for misunderstandings among the team members.

Project Staff Information Matrix The following table is an example of the type of information the PIMS needs to have: Information Type

Description / Example

Project Manager

Name Phone number Home Address (for emergency needs) E-mail Responsibilities in the project

Project Staff

Name Phone number Home Address (for emergency needs) E-mail Roles and responsibilities in the project

Every person with some level of responsibility in the project should have their information in the system.

Project Organizational Chart The organization chart helps in the management and supervision of staff assigned to the project. The chart may also include staff from other partner organizations that are working for the project. The use of this chart helps the visualization of the project structure and the various reporting relationships.

Chapter 4 Information Life Cycle | 71

Figure 6 Project Org Chart

A project organization chart is a good reference tool to identify everyone involved in the project. The information determines the functions, roles and supervisory relationships across the project. The chart also shows the structure the project has chosen to organize the project work; in some cases subdivisions in the chart are included to manage different sub-projects, each one with a sub-project manager in charge of the work.

Project Roles and Responsibilities Matrix The responsibility Assignment Matrix (RAM) is a tool to help the coordination and collaboration of the project team. The matrix comes in the form of a table that details all the roles and responsibilities of all the people involved in the project, and may include key stakeholders and other people who will directly participation in the project.

Project Role

Name

Main Responsibilities

Major Deliverables

Support Required

Project Manager

Name

Manage resources, plans and communications

Status reports

Program manager

Project Coordinator

Name

Coordinates use of resources

Schedule, scope and budget updates

Project manager Finance manager

72 | Project Information Management Systems for Development Organizations M&E Coordinator

Name

Information analysis. M&E. Staff training

Plans and evaluations

Project and program manager

This table is useful at the start of the project to monitor the allocation of resources to the project, and ensure all positions and roles are filled.

Project Resource Assignments It is important that all project activities are assigned to the project team and responsibilities identified. The activities come from the list of activities planned in the WBS. There should not be “orphan” activities; that is, activities that do not have an owner or a member of the project team assigned to them. The following table helps identify who is responsible for the project activities: WBS

Activity Name

Days

Start Date

End Date

Resources

1.1.1

Activity 1.1.1

20

Tue 01-06-10 Mon 21-06-10

Field Coordinator

1.1.2

Activity 1.1.1

30

Tue 22-06-10 Mon 02-08-10

Technical Assistant

1.2.1

Activity 1.2.1

30

Tue 03-08-10 Mon 13-09-10

Technical Assistant

1.2.2

Activity 1.2.2

20

Tue 14-09-10 Mon 11-10-10

Field Coordinator

1.2.3

Activity 1.2.3

10

Tue 12-10-10 Mon 25-10-10

Technical Manager

1.3.1

Activity 1.3.1

30

Tue 14-09-10 Mon 25-10-10

Project Manager

1.3.2

Activity 1.3.2

20

Tue 26-10-10 Mon 22-11-10

Technical Manager

2.1.1

Activity 2.1.1

10

Tue 23-11-10 Mon 06-12-10

Technical Manager

Chapter 4 Information Life Cycle | 73

Activity Assignment Sheet The activity assignment sheet lists all the activities a member of the project team is responsible for. It lists the start- and end-date of each activity, and the expected results. Depending on the project, the document can also include the instructions to carry the activity, locations, beneficiaries, budget, and other inputs needed to complete the activity. The document can be used to assign work to the team. Project assignments can be planned by the project manager on a quarterly basis. The assignment document is used to feed information to the project progress reports.

Upon completion of the activity, a project member will report to management any delays or issues the activity faced; these may include reasons why the activity was not completed and an estimated date of its future completion.

Resource Allocation Chart Another important tool to monitor the team is the Resource Allocation Chart, which shows the total hours of work each team member responsible for on an activity, and how each team member is allocated to the project.

This tool helps identify over-allocations, and identifies opportunities to redistribute and balance the project work. The chart below shows the hours per week of all the staff assigned to a project and the total work hours. From this information, the project manager can identify the resources that are working more than 40 hours per week, and where some resources are not being fully used.

Resource Name

Week Week Week Week Week Week Week Week 1 2 3 4 5 6 7 8

Resource 1

30

15

20

10

15

Resource 2

40

10

40

20

10

Resource 3

50

60

10

20

Resource 4

20

40

10

50

Resource 5

15

20

15

20

15

20 20

Total Hrs 110 140

40

40

220

15

15

165 70

74 | Project Information Management Systems for Development Organizations

Resource 6

25

15

20

Resource 7

35

10

15

Resource 8

15

Resource 9

10

Resource 10

20

Total

260

40

10

60

40

10

40

15

70

40 10

160

10

25

20

20

40

180

170

200

145 60

160

125

225

115

60

1295

Figure 7 Resource Allocation

The project manager uses the schedule progress reports to evaluate variances in the schedule and determine if the project is still on track or not. The information helps the project manager determine if the schedule requires any corrective action.

Project Beneficiaries This is information about the project’s beneficiaries. The information is basic and seeks to provide a general understanding of the demographics, social health, educational and economic information of the beneficiaries. The information also tries to capture the baseline project indicators defined in the baseline study. Additionally, the information will include the issues, chal-

Chapter 4 Information Life Cycle | 75

lenges, risks, and assumptions the project makes of the beneficiaries, as well as information on quality attributes the beneficiaries will use to label the project a success, including the criteria by which the beneficiaries will define the project as successful or not.

Beneficiaries include families, communities, and other groups that will benefit directly by the project interventions.

Beneficiary Information Information Type

Description / Example

Beneficiaries

Describe in general terms the beneficiaries of the project

Total number of benefi- Men, women, children ciaries by: Background

Cultural characteristics of the beneficiary group (languages, religion, social customs, etc.)

Location

Geographic locations of beneficiaries (states, departments, regions, etc.)

Statistics

Basic statistics that describe the major issues facing the beneficiaries: Health indicators Education indicators Access to public services (water) Economic indicators Other indicators Languages, religion, etc.

Community Leaders

The names of the leaders in each community of beneficiaries, their role in the project, and general contact information (name, address)

Project Success Criteria

Describe how the beneficiaries define the project a success.

76 | Project Information Management Systems for Development Organizations

Beneficiary Tracking A method to track project progress is to track the activities the project beneficiaries have participated in. This information feeds into the output indicators to track the initial results the project is achieving. The list includes all the beneficiary activities and their start- and end-dates.

Activity

Beneficiary groups

Start Date

End Date

Activity 1.1.1 – Training on water sanitation

50 men and women.

October 15, 2010

October 20, 2010

Activity 1.1.2 – Training on water sanitation

100 children of school age.

November 15, 2010

November 20, 2010

Activity 1.2.1 – Workshop with local health workers

20 health workers

December 10, 2010

December 11, 2010

Activity 1.2.2 – Workshop with local teachers

30 teachers at local schools

December 12, 2010

December 13, 2010

Beneficiary Analysis Analysis of beneficiaries is information that describes all the factors that can have an influence on the project. These include factors that may prevent the beneficiaries from supporting the project and those that help the project to develop strategies to reduce obstacles.

Information Type

Description / Example

Beneficiary Analysis

The major issues affecting the beneficiaries that the project WILL address.

The major issues affecting the beneficiaries that the project will NOT address.

Challenges the beneficiaries will face during the project.

Chapter 4 Information Life Cycle | 77 Factors that may prevent the beneficiaries from supporting the project.

Strategies to reduce the obstacles for support to the project.

Information from the analysis can help identify potential issues or risks with a group of beneficiaries. This information will help the project manager determine the courses of action.

Project Results A final, but significant element of the PIMS is to define the critical result indicators to track progress. The project Logframe lists the indicators the project manager will use to monitor progress against the expected goals. During the development of the Logframe, indicators at the goal, outcome and output level were developed. Each indicator also receives a value from the baseline that defines the level of the indicator at the start of the project. On a regular basis, the project obtains new data to track against the expected goals and make appropriate decisions.

Project Indicators One significant value of the Logframe, within the context of an information system, is the ability to show where the project achieved its initial goals and where it is lagging behind; this helps managers reallocate resources and efforts to those areas that need more inputs. As an example, the chart below shows the progress of a project as defined by the project indicators.

Project Logframe

Verifiable Indicators

Means of Verification

Assumptions

Project Final Goal

The quantitative measures or qualitative judgments to know whether these broad objectives have been achieved

Sources of information to allow the goal to be measured

External factors necessary to sustain the objectives in the long run

78 | Project Information Management Systems for Development Organizations Intermediate Objectives

The quantitative measures or qualitative judgments, by which achievement of the purpose can be judged

Sources of information to allow the goal to be measured

External factors necessary to contribute to achievement of the goal

Outputs

The quality of outputs and the time when they will be produced

The sources of information to verify the achievement of the outputs

The factors not in control of the project which restrict the outputs achieving the outcomes

The following chart shows the progress on each project-outcome indicator. It shows the baseline value, the progress to-date, and the expected goal of the indicator. From this view, one can see that the indicators #2, #5 and #6 have met the goals before the end of the project, while indicators #1, #3 and #4 are still below-target. This could be a typical case for a project during its midterm evaluation. From this information, a project manager can deduce that more effort is required to achieve the intermediate objective #4.

Figure 8 Project Indicators

This type of information representation can significantly reduce the time required for data analysis and help the project focus on the areas that need more attention. With a quick analysis, the project can decide to reorganize

Chapter 4 Information Life Cycle | 79

its priorities, and place more effort on catching up on the activities required to achieve the desired goals.

Visualization of project information is a powerful capability of any PIMS, as it allows for a quick analysis and the identification of areas where the project has problems, or areas where there are opportunities to increase the performance of the project.

A good PIMS will always have a method to present the data in a meaningful format that reduces the complexity and time to analyze raw data. In the next chart, the project can decide to move the effort or reallocate resources dedicated to the indicator #5 to the work under the indicator #4.

Figure 9 Logframe and Project Resource Reallocation Once the project has reallocated resources to improve the Project Outcomes #2, the project can then monitor and evaluate the impact of these actions.

The picture below shows how the decisions made by the project were able to improve the project by reallocating the resources from one component to another.

80 | Project Information Management Systems for Development Organizations

Figure 10 Project Indicators Improvement

The main focus of a PIMS is to track project inputs, activities and outputs.

This is the day-to-day information and data management that a PIMS does at the project level. The process at this level has two targets: short-term information that can be made available on a monthly basis, and short-term information obtained via quick surveys and field observations. Above this level is the Outcome and Objective information obtained through formal evaluations that can even go beyond the life of the project.

Figure 11 Relationships between Process and Outcomes