Sistema de Manejo de Proyectos by Marco Antonio

MINISTERIO DE AGRICULTURA Oficina Sectorial de Planificación Agraria – OSPA Proyecto Planificación Agrícola y Desarrollo Institucional PADI

METODOLOGÍA DEL SISTEMA DE MANEJO DE PROYECTOS ACTIVIDAD 03 PADI – OSPA “Apoyo a la Capacidad de Monitoreo y Evaluación de Proyectos”

Lima – Perú

1986

CONTENIDO

“SISTEMA DE MANEJO DE PROYECTOS” (SMP) (Un método integrado de sistemas para la administración del ciclo de un Proyecto)

“EL MARCO LOGICO” (Una guía de Gerentes para Diseñar y Evaluar Proyectos en forma científica).

“EL PLAN DE EVALUACIÓN DE UN PROYECTO”.

INTRODUCCIÓN

El presente documento “Sistema de Manejo de Proyectos” (SMP), constituye el Anexo N° 1 de la Directiva Sectorial: “Normas para el Seguimiento y Evaluación de Proyectos de Inversión del Sector Público Agrario” y tiene como objetivo establecer instrumentos y mecanismos de comunicación para tramitar

los

información selectiva y

estandarizada sobre la ejecución de los proyectos de inversión del Sector Público a los diferentes niveles de autoridad. De esta manera el SMP contribuirá a mejorar decisiones en el Sector Público Agrario de manera que los proyectos de inversión se ejecuten adecuadamente para cumplir sus objetivos. El presente documento ha sido elaborado por el Asesor Externo, Doctor Rafael Diez Angulo, en el marco del Proyecto Apoyo a la Planificación – Institucional PADI-OSPA – Actividad 03.

SISTEMA

MANEJO

PROYECTOS

(SMP)

UN MÉTODO INTEGRADO DE SISTEMAS PARA LA ADMINISTRACION DEL CICLO DE UN PROYECTO

TABLA DE CONTENIDO PARTE I: INTRODUCCION AL SISTEMA DE MANEJO DE PROYECTOS (SMP) DE PRACTICAL CONCEPTS INCORPORATED .................................... 7 A.

INTRODUCCION ................................................................................................... 7

EL CICLO DE UN PROYECTO ........................................................................... 8

LOS INSTRUMENTOS DEL SMP APOYAN A TODAS LAS FASES DEL CICLO DE UN PROYECTO ...................................................................... 10

PARTE II: ADMINISTRACION DE PROYECTOS Y CONCEPTOS DEL SMP: CONSIDERACIONES GENERALES ......................................................12 A.

CONCEPTOS GENERALES DEL SISTEMA .................................................. 18

MARCO LOGICO ................................................................................................. 20 1.

La Lógica Vertical del Marco Lógico ............................................................ 21

Verificación Objetiva: La Lógica Horizontal ............................................... 22

REDES Y PROGRAMACION............................................................................ 23 1.

Ruta Crítica ............................................................................................................ 23

Holgura Libre ........................................................................................................ 23

ADMINISTRACION DE RECURSOS ............................................................. 24

INFORMES DE LOGROS Y ALERTIVOS ...................................................... 26

EVALUACION ....................................................................................................... 27

PARTE III: ADMINISTRACION DE PROYECTOS: BREVE REVISION DE DEFINICIONES .....................................................................................28 A.

QUE ES UN PROYECTO Y QUE ES LA ADMINISTRACION DE PROYECTOS.......................................................................................................... 28

PROYECTOS EN ORGANIZACIONES FUNCIONALES .......................... 29

SITUACIONES EN LA ADMINISTRACION DE PROYECTOS: ............. 30

GERENTES DE PROYECTO .............................................................................. 31 1.

Funciones ............................................................................................................... 31

Liderazgo................................................................................................................ 31

POR QUE FRACASAN LOS PROYECTOS ................................................... 32 1.

Planificación Inadecuada .................................................................................. 32

Control Inadecuado durante la Implementación..................................... 32

Seguimiento Inadecuado de parte de los Administradores de Alto Nivel: ........................................................................................................................ 32

Ausencia en el equipo del Proyecto de Personas que se beneficiarían de los Resultados del Proyecto. ..................................................................... 33

Falta de uso de la Información de Evaluación de Proyectos Similares conduce a la Repetición de Errores. ............................................................. 33

Mala Conformación del Equipo de un Proyecto. ..................................... 33

Ausencia de un Conjunto Formalizado de Procedimientos para la comunicación y Documentación. .................................................................. 33

Incompetencia del Gerente del Proyecto. .................................................. 33

PARTE IV: INFORMES Y SEGUIMIENTO – REVISION DETALLADA ..............34 A.

TODOS LOS INFORMES TIENEN UN COSTO ............................................. 35

ESTRUCTURA BASICA DE UNA ORGANIZACIÓN .................................... 36

LAS REDES DE ADMINISTRACION SUPERIOR RESUMEN LA INFORMACION MAS DETALLADA DE LOS NIVELES INFERIORES ...... 39

EJEMPLO DEL FORMATO DE UN INFORME ALERTIVO ......................... 41

INFORMES DE LOGRO ....................................................................................... 44

EJEMPLO DEL FORMATO DEL INFORME DE LOGRO ............................. 44

TABLEROS INFORMATIVOS PARA HACER SEGUIMIENTO DE LA SITUACION DE UN PROYECTO....................................................................... 47

PARTE I

INTRODUCCION AL SISTEMA DE MANEJO DE PROYECTOS (SMP) DE PRACTICAL CONCEPTS INCORPORATED

A. INTRODUCCION Todos aquellos responsables de proyectos que tienen objetivos sociales y económicos

han

ido

necesitando

por

mucho

tiempo

sistema

–

procedimientos integrados para organizar la información y las personas – que proporcione el mismo tipo de control administrativo que tienen a disposición los gerentes de proyectos industriales y de construcción. La considerable “brecha de implementación”, o sea las numerosas dificultades que existen al pasar de la conceptualización de un proyecto a su ejecución, y los proyectos que sobrepasan substancialmente sus límites de costo o tiempo demuestran claramente la necesidad de tal sistema. Al trabajar con cientos de proyectos y equipos de proyectos, PCI (Practical Concepts Incorporated) ha empleado y observado muchos diferentes métodos para administrar el proceso de desarrollo. Los instrumentos y métodos que han demostrado ser más efectivos han sido refinados en un solo sistema que nosotros llamamos el Sistema de Manejo de Proyectos (SMP). El Método SMP y sus conceptos son fáciles de comprender. Son conceptualmente válidos y atractivos. Más aún, han demostrado su valor en la práctica. El sistema de Manejo de Proyectos (SMP) ofrece disciplina y control sobre cualquier fase de un proyecto, desde su concepción original hasta su terminación exitosa. El SMP, como sistema total integrado y con sus elementos individuales, ha demostrado ser relevante y útil en el ambiente de los países menos desarrollados. El PCI ha probado o ha implementado el SMP en numerosos países, incluyendo el Canadá, los Estados Unidos, Guatemala, Mali, Paquistán, el Sultanato de Omán y Tailandia. El SMP se ha empleado en programas tan diversos como la educación por satélite, desarrollo rural integrado, agricultura y ganadería, administración de recursos hidrográficos y desarrollo industrial. Los conceptos han sido utilizados con mucha efectividad por ejecutivos del sector privado y público a nivel nacional, regional y local.

Podríamos considerar que el SMP consiste de dos elementos básicos: 1. Los instrumentos, técnicas y procesos básicos para elaborar planes, cronogramas, Informes, etc. 2. Los procesos a través de los cuales dichos elementos individuales son integrados en solo sistema, y mediante los cuales el equipo de un proyecto es organizado y mantenido. El primero de los puntos arriba mencionados, o sea los elementos que conforman el SMP, pueden ser prontamente descritos. El segundo punto, o sea los métodos para integrarlos en un sistema, es menos fácil de describir en lo abstracto y debe ser adaptado a las organizaciones y circunstancias individuales reales. El resultado neto debe ser una síntesis del proyecto como concepto y como conjunto de planes, y el equipo administrativo como individuos y organizaciones individuales. El SMP tal como fue elaborado y refinado por PCI consiste de un conjunto de herramientas y técnicas de administración científica que ayudan a todo el equipo de un

proyecto de la

siguiente manera: 

Formulando objetivos medibles para el proyecto finales y parciales.



Separando los objetivos del proyecto en una secuencia lógica de las actividades requeridas para lograr esos objetivos.



Organizando todas las personas e instituciones involucradas en el éxito del proyecto y concretando sus responsabilidades.



Midiendo el progreso obtenido versus planificado en forma continúa.



Simplificando la vigilancia e informes de situación del proyecto a otras personas.



Incorporando “las lecciones aprendidas” en la evaluación de este y otros proyectos.



Elaborando otros instrumentos especializados de administración y planes de acuerdo a lo requerido por un proyecto.

B. EL CICLO DE UN PROYECTO Puede considerarse que todos los proyectos siguen un ciclo de tres fases (diseño, ejecución y evaluación) tal como se muestra en el Gráfico 1-1.

Gráfico 1-1

EL CICLO DE UN PROYECTO

1. DISEÑO

OBJETIVOS 3. EVALUACIÓN

LOGRADOS

2. EJECUCIÓN

EN EL PROYECTO

Los proyectos comienzan en la fase de diseño. En esta fase, se establecen los objetivos del proyecto, se llevan a cabo estudios de factibilidad, se estiman los requerimientos de presupuesto y recursos, se definen y coordinan las responsabilidades del proyecto, se elaboran planes detallados de trabajo, se obtiene aprobación, etc. La fase de diseño puede durar días o años. La fase dos del ciclo del proyecto es la ejecución. La ejecución es la administración de los insumos del proyecto (actividades y recursos) requeridos para lograr los productos del proyecto (resultados específicos). La fase Tres del ciclo es la evaluación. La Evaluación es el proceso de examinar el avance que se hace hacia el logro de los objetivos. Tiene la función de ayudar a los administradores a mejorar el proyecto. La evaluación podría resultar en el rediseño, seguido de una ejecución mejorada hasta que se logren los objetivos del proyecto.

C. LOS INSTRUMENTOS DEL SMP APOYAN A TODAS LAS FASES DEL CICLO DE UN PROYECTO El sistema SMP elaborado por PCI proporciona cuatro instrumentos básicos de administración para apoyar a todas las fases del ciclo de un Proyecto. Es importante enfatizar que estos instrumentos han sido elaborados y refinados en base a experiencias reales de equipos de administración de proyectos en cientos de casos. Por tanto, no son solamente métodos conceptuales, sino también, técnicas válidas que funcionan y tienen valor. Los cuatro instrumentos de administración son los siguientes: 

Marco Lógico.- Es un método para especificar los objetivos de un proyecto. El Marco Lógico, aclara los resultados específicos, así como los resultados esperados de un proyecto. Identifica importantes supuestos y demuestra cómo medir el logro de los objetivos de un proyecto.



Redes de desempeño.- Son redes que muestran cómo un proyecto será implementado en el tiempo. Las redes de desempeño identifican la secuencia y relación de las actividades del proyecto y miden el comportamiento de todo un proyecto.



Sistema de Informes.- Es un medio simple, efectivo, y que ahorra tiempo para comunicar el status de eventos claves del proyecto, conforme estos ocurren o conforme surgen problemas.



Sistema de Evaluación.- Son métodos para evaluar periódicamente los logros del proyecto hasta la fecha para refinar la estrategia y para mejorar el proyecto.

El Gráfico 1 – 2 muestra cómo los cuatro instrumentos de administración SMP se relaciones con el ciclo del proyecto. Estos instrumentos se discuten en las secciones que siguen más adelante. Otros instrumentos relacionados y elementos del sistema – es decir, el uso del Marco Lógico para contratación – fueron desarrollados pero no se presentan en este informe básico.

Gráfico 1 – 2 EL SMP PROPORCIONA HERRAMIENTAS DE ADMINISTRACIÓN PARA APOYAR TODAS LAS FASES DEL CICLO DE UN PROYECTO MARCO LÓGICO

REDES DE DESEMPEÑO

Establece el diseño

Las redes muestran los

de un proyecto orientado

planes de desempeño

al desempeño y establece

en el tiempo

las bases para la evaluación

1. DISEÑO

3. EVALUACIÓN

OBJETIVOS LOGRADOS

2. EJECUCIÓN

EN EL PROYECTO

SISTEMA DE EVALUACIÓN

SISTEMA DE INFORMES

LÓGICO ALERTIVO

La evaluación mide el desempeño

Indicadores de progreso

frente a los planes y analiza

y formatos para transmitir

las relaciones causales

información sobre el proyecto.

PARTE II

ADMINISTRACION DE PROYECTOS Y CONCEPTOS DEL SMP: CONSIDERACIONES GENERALES

La introducción del concepto de proyectos para actividades de desarrollo implica grandes cambios en muchas áreas de la administración. Los registros, informes, controles, planificación, etc. Que son característicos de la administración de operaciones o de

la administración son usados

en forma diferente bajo la administración de

proyectos. Es necesario contrastar lo más claramente posible las diferencias; de modo de que se comprendan las implicaciones de los conceptos del proyecto. La mayoría de los sistemas de administración usados por gobiernos y por empresas hoy en día pueden ser identificados como administración de programas. Se pone énfasis en los procedimientos para ejecutar operaciones regulares y repetidas de la institución. Cualesquiera sea el área de actividades, se organiza el trabajo y se informa sobre éste de la misma forma que se lo hace con referencia al uso de materiales u otros recursos. La atención de la administración se concentra en las tasas diarias, semanales, etc. En que las actividades, materiales y fondos se mueven a través de la institución. Ya sea que la institución esté orientada hacia el logro de utilidades, o sea un servicio público de una institución militar, se emplean los métodos normales de administración: teneduría de libros, inventario, informes laborales, balances de débitos y créditos etc. Se han elaborado varias estrategias para mantener o aumentar la eficiencia: contabilidad de costos, inventarios perpetuos, razones de efectivo-crédito, control de calidad, y otros que han mejorado los diferentes aspectos de la administración. Desde la década del 30 han surgido un conjunto de especialidades profesionales relacionadas, las cuales han analizado las características organizativas de la empresa privada, oficinas gubernamentales, y similares. Se han identificado ciertos estilos de administración considerados más apropiados que otros para los objetivos principales de las instituciones. Las preguntas que han surgido en este tipo de análisis a menudo han conducido

profundos

cambios

perspectiva

los

organizadores

administradores. Por ejemplo, las bibliotecas eran tradicionalmente organizadas alrededor del concepto central de que la biblioteca era un almacén o repositorio de

libros. Los métodos de catalogación, almacenamiento, y protección de los libros reflejaban este concepto. El énfasis en el uso de los libros como fuente de información condujo a las estanterías abiertas, referencia cruzada detallada por materia, y otras innovaciones que eran enormemente resistidas por bibliotecarios de varias generaciones anteriores. El análisis organizacional demostró que algunas actividades pueden llevarse a cabo más efectivamente cuando la unidad de trabajo es separada de la administración rutinaria, y organizada como proyecto. Las preocupaciones normales y presumiblemente efectivas de la administración están subordinadas a una perspectiva administrativa diferente y que es pertinente solamente para un proyecto. La organización de un proyecto se aplica generalmente a actividades no repetitivas

tales como investigación, desarrollo

construcciones de monta y similares. La organización interna de un proyecto es diferente de la administración normal y puede variar en función de los objetivos. Es mas importante todavía el hecho de que la administración de un proyecto sea conducida de manera diferente de la administración normal. Los registros, informes, estrategias de control, instrumentos, procesos, etc., de un proyecto no se derivan de procedimientos de operación estándar, sino más bien son seleccionados o diseñados en relación a las necesidades de un proyecto y su objetivo específico limitado. Los proyectos tienen dos características que los diferencian de la administración de rutina: 1) Los proyectos son diseñados para proveer medidas de resultados que son independientes de su sistema administrativo interno de informes y control; 2) Los proyectos permiten que sus operaciones crucen líneas de jurisdicción y sean gobernados

de acuerdo a reglas y regulaciones específicamente

diseñados para optimizar su propio propósito. Los contrastes entre estilos de programas y proyectos de las organizaciones y la administración, se ilustran en el Cuadro II – 1.

Cuadro II - 1

CARACTERÍSTICAS DE OPERACIONES Y PROYECTOS

CARACTERÍSTICAS Orientación o Estilo

OPERACIONES

PROYECTOS

Tasas de producción fijas o

Investigación, desarrollo,

variables

experimentación, actividades únicas, construcciones de nuevas aplicaciones de tecnología

Diseño

Informes

Optimización de la

Pasos, acciones y tiempos

eficiencia mediante

lógicamente

acciones repetitivas

dependientes y

simplificadas (cronograma

organizados para un

de barras)

propósito limitado (redes)

Informes periódicos,

Regulares: Logro o

tiempo,, materiales, mano

realización de actividades,

de obra, fondos

prevenciones, cambios en

empleados, inventarios,

condiciones,

producción

recapitulaciones y revisiones

Presupuestación

Por unidad y sub-unidad

Por pasos, metas y

organizacional

actividades específicas lógicas

Contabilidad

Flujos de dinero en

Centros para costos: uso

efectivo, inversiones de

regular de recursos

capital, proporción de créditos, determinación de costos Criterios de Éxito

Pérdidas o ganancias,

Logro de un fin global en

ventas, unidades de trabajo

base a medidas

cumplidas

independientes.

Es importante hacer explícitas las diferencias entre la administración de programas y la administración de proyectos, a fin de establecer el marco para un efectivo uso de la administración de un proyecto. Esto es particularmente cierto, cuando la administración de un proyecto tiene un estilo desacostumbrado. Muy a menudo, los componentes del sistema de administración de programas son mantenidos e impuestos en el sistema de proyectos distorsionando la lógica alrededor de lo cual se desarrolla un proyecto. Vale la pena examinar los procesos cruciales de administración, tal como se los emplea en los proyectos.

El cuadro II – 2 muestra que el diseño de un proyecto, con su lógica y estructura interna, es consistente con el propósito del proyecto, pero no sigue el patrón establecido por los procesos de administración de programas en los procesos administrativos. Debe recalcarse que esto no disminuye el rol de la autoridad encargada de su aprobación. Por el contrario, la aprobación del proyecto, estableció un sistema especializado de procesos administrativos específicamente para los propósitos del proyecto. Pueden desarrollarse ciertos patrones para proyectos en los que se encuentran recursos, actividades y objetivos similares. Corresponde a la autoridad encargada de la aprobación, establecer cualquier combinación de procedimientos y regulaciones especializadas y previamente estandarizadas para gobernar la administración del proyecto que sea apropiada en cada proyecto. Existe la tendencia, cuando se instituye la administración de un proyecto, de ignorar los supuestos no expresados, inherentes ya sea en el sistema de administración de programas o de administración de proyectos. Estos supuestos se refieren al desempeño del trabajo, métodos de contratación, normas y acciones específicas, prerrogativas de jurisdicción y muchas otras más. Como ejemplo: existía un proyecto agrícola que tenía como objetivo, el incrementar la productividad y el ingreso de los agricultores.

Cuadro II - 2 PROCESOS ADMINISTRATIVOS APLICADOS A OPERACIONES Y PROYECTOS

PROCESOS Aprobación

Control y Revisión

OPERACIONES

PROYECTOS

Concedido anualmente

Concedido una sola vez en

para el funcionamiento

base al diseño total de

continuado con posibles

pasos lógicos conectados

modificaciones. Diferentes

hacia el logro del

grupos de aprobación, para

propósito, una sola

diferentes aspectos

institución de aprobación

Examen periódico y

Predeterminados por el

evaluación del desempeño

diseño del proyecto como el indicador de eventos mayores

Fondos

Informes

Flujo regular establecido en

Programados en el diseño

base al nivel de

del proyecto al momento

operaciones.

de su aprobación.

Periódicos calculados en

Programados en el diseño

tiempo para reflejar el uso

del proyecto, muestran el

regular de los recursos y el

logro de metas o alertan

desempeño

toda vez que se amenaza al desempeño

Evaluación

Por lo general sigue el

Evaluación para factibilidad

resumen anual para la

previa a la aprobación y

renovación de la

programada en el diseño

aprobación

para eventos críticos a fin de asegurar que se haga frente a problemas

Administración de recursos

Procedimientos generales

Asignación de recursos de

contables e informes.

acuerdo a la realización de actividades en base a pasos de desempeño diseñados previamente

Dos elementos en el problema parecían ser cruciales: la administración del agua y la estructura de comercialización. El examen de la situación demostró que el área donde estaba el agua para irrigación, no coincidía con el área para el modelo de comercialización. Claramente estaba involucrándose a áreas diferentes en las jurisdicciones de los dos ministerios. Más aún, se descubrió que el uso del agua por parte de los agricultores no dependía de su conocimiento o motivación por prácticas mejoradas, sino que era regulado por la oficina de aguas cuyos hábitos de distribución estaban controlados por un manual detallado de regulaciones acerca del uso del agua, el mismo que había sido preparado en base al más profundo conocimiento científico hacía 80 años. Ninguna persona estaba activamente obstaculizando el progreso, pero los proyectos no consideraban el hecho de que el uso del agua dependía de un complicado sistema administrativo ya en funcionamiento y que tiene diferentes preocupaciones y supuestos no expresados. Este ejemplo ilustra el tipo de problema que puede ocurrir cuando se intenta introducir cambios para el desarrollo y mejoramiento. La realidad no se acomoda a prácticas administrativas o jurisdicciones burocráticas. Además están incorporadas en la administración operativa, las definiciones aceptadas de autoridad y responsabilidad que limitan la conducta de un proyecto. Romper estas limitaciones deliberadamente, mediante la organización de un proyecto alrededor de un propósito limitado, significa que la referencia última es la realidad dentro de la que funciona el proyecto y que, dejando de lado reglas y regulaciones normales, requiere de un análisis de las implicaciones que ello tendría en el propósito del proyecto. Para reunir los puntos que han sido examinados bajo el concepto de estilo de administración, la administración de proyectos se concentra en actividades, recursos y prácticas de administración lógicamente necesarias y suficientes que son requeridos para lograr un propósito particular limitado. La administración operativa se concentra en procedimientos, actividades y recursos operacionales estándar que son necesarios para el continuo funcionamiento de servicios, producción, información de rutina y similares. Cada uno es apropiado para ciertas situaciones, problemas y propósitos, pero no son intercambiables. El sistema de manejo de proyectos SMP tal como fue definido durante el trabajo de elaboración de este sistema, por PCI, se resume conceptos: A. Conceptos generales del sistema B. Marco Lógico C. Redes y Programación D. Administración E.

Informes de logros e informes alertivos

acá en términos de los siguientes

A. CONCEPTOS GENERALES DEL SISTEMA El SMP, en el sentido de la gente y el equipo, no es tanto un sistema sino más bien la aplicación de ciertos conceptos claves entre dos niveles de administración.

sistema se concentra en la relación entre el gerente del proyecto y sus superiores. Sin embargo, las reglas sobre informes entre superior y subordinado, son en esencia las mismas, independientemente del nivel de administración. El sistema supone que para cada gerente que participa en el sistema puede haber lo siguiente: 

Un marco lógico que expresa su esfera de control, propósito y fin;



Una red para el proyecto que muestra las fases del tiempo y la interdependencia lógica de todas las actividades requeridas para producir los productos especificados.

En base a la existencia de esta información para la planificación cada nivel subordinado de la administración, por tanto, identifica para sus superiores los siguientes: 

Un conjunto de eventos “claves” seleccionados que proporciona las bases para el informe de logros (es decir, el momento en que un evento clavé está programado para ser completado, debe generarse un informe que indique la naturaleza y nivel del logro);



Aquellos eventos subordinados sobre los que se basan los informes alertivos (es decir, habrá un informe, solamente si no se cumple con las metas de fecha, calidad o cantidad).

Incluidos entre los eventos claves así identificados estarán los “informes especiales”, que generalmente son informes de evaluación. Tales informes especiales serían normalmente elaborados para anticiparse y para respaldar los putos de decisión del proyecto. Un punto de decisión es, por su puesto, cualquier punto donde la lógica del proyecto en términos de insumos, productos o propósitos, debería ser considerada en términos de restructuración del proyecto ó la asignación de recursos de un proyecto a otros objetivos. En base al paquete de planificación y al método recomendado de información que se presentaron, el gerente del nivel superior establece su propia red de proyectos que consiste de los eventos claves identificados por el gerente de un proyecto y/o eventos claves que él pueda considerar de particular interés para él, más los reportes adicionales, usualmente conectados a decisiones, que pueda requerir. El sistema excluye los informes periódicos per se; aunque es posible para los niveles

superiores de administración requerir evaluaciones periódicas (digamos cada doce meses) para asegurarles que el proyecto está en curso y promete lograr los objetivos a nivel de fin. En reconocimiento del hecho de que la información también consume recursos, particularmente los escasos recursos de los buenos administradores y analistas, existe para el gerente de nivel superior la responsabilidad de especificar claramente la información que necesita y por qué la necesita. El gerente de nivel subordinado, también indica la información que requerirá con relación al avance de otros proyectos y actividades de los cuales el éxito del proyecto depende. Estos son usualmente los supuestos mencionados en el Marco Lógico, cuya evaluación podría requerir la asignación adicional de recursos de captación de información. El Gerente de Nivel Superior, por tanto, retiene el paquete de planificación tal como fue elaborado por su subordinado, con el entendimiento claro de que el subordinado vigilará las actividades del proyecto al nivel indicado en el paquete. El superior en realidad vigila el proyecto basándose sólo en eventos claves que él ha seleccionado. Es normal y frecuentemente deseable que, especialmente en los niveles medios de administración, el superior y el subordinado usen la misma red con la excepción de que los eventos claves seleccionados por el superior están representados por símbolos diferentes para facilitar su identificación. El SMP requiere la utilización de la planificación antes mencionada y los requerimientos de informes sólo a nivel de proyecto. Sin embargo, estos conceptos pueden ser indefinidamente extensibles tanto hacia abajo como hacia arriba. Basándose en este diálogo entre dos niveles de administración, se ha establecido un programa de información que incluya tres tipos de informes generados por el sistema: 

Informes de Logros



Informes Alertivos



Informes Especiales

Un informe de logro indica la calidad, cantidad y fecha de logro de un evento clave pre-especificado. Un informe alertivo muestra una de las siguientes condiciones: 

Un evento clave (un evento en la red del superior del proyecto) está en peligro de no realizarse, lo cual constituye

un informe de “bandera

amarilla”. Esto normalmente significa que un evento inmediatamente subordinado a un evento clave no se ha realizado*.



Un evento clave no se ha realizado, y ello constituye un informe de “bandera roja”.

Los informes especiales deberían normalmente incluir una evaluación del avance en cada uno de los cuatro niveles del proyecto (insumo, producto, propósito y fin), una determinación de la congruencia de esa relación y una extrapolación en cuanto al nivel y probabilidad de éxito (evaluación). En parte IV de este documento se presentan formatos representativos de los informes de logros y alertivos. Se recomienda, aunque no es un requerimiento del sistema que: 1. El problema que ocasiona un informe alertivo reciba de parte de la administración, el mismo nivel y grado de atención que el proyecto mismo recibe. Esto es apropiado, pues, el éxito del proyecto depende de la resolución de ese problema. 2. Después que se ha generado un informe de “bandera roja”, la administración revisará y re analizará el proyecto como si tratara de un nuevo proyecto. Una vez que se ha analizado el problema y se ha aceptado una solución, entonces la red será modificada respectivamente y el evento reprogramado (que originalmente no se realizó) retorna el flujo normal de informes. Si es realizado a tiempo, se reporta en base al logro. B. MARCO LOGICO* El método del Marco Lógico supone que los proyectos de desarrollo son instrumentos de cambios, es decir que fueron seleccionados de entre instrumentos alternativos, como el método potencialmente más efectivo en cuanto a costo para lograr un resultado beneficioso deseado. Nuestro método acepta la incertidumbre inherente en todos los proyectos de desarrollo identificado explícitamente la naturaleza e la incertidumbre, la hipótesis de desarrollo. En base a la aplicación demostrada en cientos de proyectos de desarrollo social y económico, creemos que los conceptos son táctica y estratégicamente sólidos. Es conveniente considerar el Marco Lógico en términos de dos tipos de procesos mentales:

Ver panfleto del PCI titulado “El Marco Lógico: Una Guía de Gerentes para diseñar y Evaluar Proyectos en Forma

Científica”, para una discusión más completa del Marco Lógico.



Una lógica vertical que aclara el por qué un proyecto se lleva a cabo (diseño del proyecto)



Una lógica horizontal que aclara qué es lo que se va a producir y la evidencia que señalará el éxito (evaluación).

1. La Lógica Vertical del Marco Lógico El fin, propósito, productos e insumos caracterizan a un proyecto y están encadenados por un conjunto de hipótesis. Un buen diseño de proyectos requiere que a cada nivel en la lógica vertical, las condiciones estipuladas, sean aquellas necesarias y suficientes para lograr el o los objetivos en el siguiente nivel superior. Reconociendo que tanto el conjunto de condiciones necesarias y suficientes deben ser indicados a cada nivel y que muchas cosas importantes para el éxito del proyecto, pueden estar fuera del control o influencia del proyecto, el Marco Lógico requiere que el gerente del Proyecto identifique los supuestos claves que debe hacer para postular el éxito de su proyecto. Es decir, debe identificar explícitamente los factores que van más allá de su influencia y que afectan el éxito de su proyecto. Por tanto, los supuestos acerca del proyecto son a menudo objeto de diálogo entre el gerente del proyecto y los siguientes niveles de administración. Habiendo caracterizado al proyecto como un conjunto de hipótesis en cadena, es importante notar que existe una diferencia significativa entre el nexo insumo – producto y los otros nexos de nivel superior. Podemos esperar que el gerente de proyectos use adecuadamente los insumos para lograr productos; él es el responsable de los resultados. Sin embargo, es a su juicio, una hipótesis compartida con niveles de administración superior, que los productos, en efecto, conducen al propósito. Basándose en este punto de vista, el gerente acepta la responsabilidad personal de lograr productos; él es el administrador del proyecto en el sentido moderno del término. Sin embargo, al postular que esos productos serán suficientes para lograr el propósito, se convierte en un cientista del desarrollo. Se lo considera responsable de la calidad de su análisis y juicio, no así por los resultados a nivel de propósito.

Al separar el rol convencional de administrador del de cientista del desarrollo, siendo el proyecto un experimento de desarrollo, establecemos el marco para una cándida y objetiva evaluación. Así, el Marco Lógico solo clarifica el por qué se llevan a cabo los proyectos, sino también fomenta la selección objetiva y analítica de la evidencia que será requerida en evaluaciones posteriores. 2. Verificación Objetiva: La Lógica Horizontal Habiendo aclarado el diseño básico de un proyecto en término de insumos, productos, propósito y fin de porqué se está llevando a cabo la tarea – el Marco Lógico exige que el equipo del proyecto identifique la evidencia requerida para demostrar el logro. Usamos el término “Lógica horizontal” porque la experiencia demuestra que el definir la evidencia requerida para demostrar un evento

determinado,

aclara

naturaleza

del

evento

cuestión.

Específicamente hablando la lógica horizontal exige que en cada nivel conceptual del Marco Lógico, el equipo de proyecto debe hacer explícitos: 

Los indicadores objetivamente verificables que demostrarán que el resultado deseado ha sido obtenido.



Los medios de verificación – mecanismos específicos a través de los cuales se verificará objetivamente el logro.

Es importante notar que la verificación objetiva no significa necesariamente cuantificación. Más aún, la fase de dos pasos de aclaración de la evidencia – identificación del indicador primario y luego los medios de verificación – es específicamente introducida para dar aliciente a los equipos de trabajo de los proyectos para medir lo que es importante en lugar de medir aquello que es fácilmente medible. Reconociendo las limitaciones de indicadores individuales para medir cambios complejos, el Marco Lógico fomenta el uso de indicadores múltiples para verificar el éxito a nivel de propósito. Para aclarar el propósito del proyecto para la planificación y evaluación, los diseños de propósito del proyecto pueden ser presentados en forma de resumen usando la matriz del Marco Lógico. El marco presenta los conceptos interconectados que aclaran el porqué un proyecto está siendo llevado a cabo y expresa específicamente lo que se hará para lograr el resultado deseado.

C. REDES Y PROGRAMACION La red es la presentación gráfica de la secuencia o interdependencia de las actividades y eventos en un proyecto de desarrollo. Como herramienta de planificación, el diseño de redes incrementará la confianza en el diseño de un proyecto. El Marco Lógico señala cuales son los recursos y actividades necesarias para que se obtengan los productos deseados. Las redes ilustran cómo pueden ser usados los recursos y actividades para obtener estos productos. Este ejercicio aclarará algunas de las limitaciones en las actividades de un proyecto y que no eran evidentes con anterioridad. Las redes proporcionan un puente entre el diseño y la implementación. Una vez iniciada la implementación, las redes proveen la base para vigilar el avance de un proyecto. El diseño de redes facilita la preparación de informes de avance a la administración de más alto nivel, haciendo explícitos la fecha y la naturaleza de los informes las redes permiten una administración más adecuada de los recursos proporcionando un formato que indique a la administración donde se necesitan recursos, cuándo se los necesita y cuánto se necesita. Finamente, las redes proporcionan una base para evaluar el logro, se establecen claramente metas de cantidad y calidad en varios puntos críticos de tiempo. 1. Ruta Crítica Es el tiempo transcurrido para cada actividad en una red, es decir, se muestra el tiempo requerido para completar cada actividad. La trayectoria más larga de tiempo de actividad, desde el principio hasta la terminación de un proyecto se denomina Ruta Crítica. Este es el mínimo periodo de tiempo requerido para completar un proyecto. Un incremento en el periodo de tiempo necesario para completar cualquier actividad en la ruta crítica, resultará por lo menos en un incremento igual en el tiempo requerido para completar el proyecto. Las actividades y eventos que descansan en la Ruta Crítica son por lo tanto, generalmente vigiladas más estrechamente que otras actividades y eventos. 2. Holgura Libre

Se llama holgura libre al período por el cual pueden demorarse las actividades, sin que ello afecte la duración total de un proyecto. Cuando se conoce la holgura libre los administradores del proyecto pueden demorar la iniciación de una actividad por un período de tiempo, hasta cubrir toda la holgura libre de la actividad, a fin de economizar en la asignación de recursos. A través del diseño de redes, los administradores de un proyecto, pueden recibir varios informes que van más allá de los antes mencionados informes parciales de logro y alertivos. Algunos de los informes más usuales que se requerirán para el análisis y programación de proyectos son: 1. Lista de todas las actividades, en secuencia numerada de actividades, para ser usada como referencia para obtener información relativa a cualquier actividad; 2. Lista de todos los eventos, en secuencia numerada de eventos, para ser usada como referencia para obtener información relativa a cualquier evento; 3. Lista de todas las actividades en secuencia cronológica por fecha de iniciación o fecha de terminación; 4. Lista de todas las actividades en orden decreciente de holgura libre. Esto proporcionará a los administradores una imagen inmediata de la ubicación de la flexibilidad en la programación y asignación de recursos; 5. Lista de todas las actividades de la ruta crítica y/o todos los eventos en la ruta crítica. Este tipo de informes facilitará la administración de un proyecto al evaluar alternativas en la reprogramación y re-asignación de recursos. Los informes pueden generarse en forma selectiva después de cualquier modificación a la red y mostrarán inmediatamente el impacto de la modificación sobre el costo programado. D. ADMINISTRACION DE RECURSOS Cuando se discute la administración de recursos, es importante considerar dos aspectos conceptuales básicos: El primero que ya ha sido puntualizado en numerosas ocasiones por algunos participantes del diseño de sistema de administración. Su posición es que, la falta de

suficientes recursos disponibles para realizar la tarea representa

una limitación

fundamental en la utilización del sistema. La conclusión que parece sacar de ello es que cualquier sistema que no incrementa el nivel de recursos disponibles, no es útil. La opinión de PCI, que está incorporada en el concepto de sistema presentado aquí, es que el arte de administrar es exactamente el arte de maximizar el valor agregado haciendo uso de los recursos disponibles. La disponibilidad de recursos es siempre una limitación. No existe nunca una infinidad de recursos. No obstante, el examen de la llamada brecha de implementación sugiere que la disponibilidad de recursos no es realmente el problema más crítico con el que se enfrentan los planificadores y programadores. En la mayoría de los casos, hay más dinero disponible para proyectos, que proyectos de alta calidad que merezcan ser financiados. Si usted no cree esto, haga una lista de cinco realmente buenos proyectos que no hayan sido financiados. Si usted no tiene

proyectos que realmente podrían tener una alta tasa de retorno

y ser

administrados con éxito, entonces no se puede suponer que los fondos son la limitación clave. Más bien, las buenas ideas expresadas como proyectos factibles, son la limitación clave. Aún en el caso de proyectos para los cuales hay recursos sustanciales disponibles, el propósito de cualquier análisis es hacer notar

las

oportunidades para optimizar la tasa de retorno de nuestra inversión de recursos y proporcionar una visión continúa tal que, aquellos recursos puedan ser reasignados, en base al creciente valor actualizado de inversiones alternativas. El segundo aspecto conceptual que se relaciona con los recursos, es que el seguimiento del desempeño conduce al seguimiento de los costos, como en el caso de un proyecto que tiene problemas para lograr sus metas de desempeño y funcionar dentro de sus limitaciones financieras. Por tanto, una orientación hacia el desempeño es la manera más efectiva, en cuanto a costo, de considerar la información, permitiéndonos comprender y predecir la probabilidad de éxito del proyecto. El SMP es un sistema de administración orientado hacia los resultados, en el cual la atención de los administradores se dirige hacia el desempeño, siendo la disponibilidad de recursos una limitación. Este es una alternativa clara, que guarda consistencia con nuestra previa discusión de que en realidad estamos hablando de un cambio en el estilo administrativo, del sistema de seguimiento orientado hacia gastos y contabilidad. Es posible, aunque costoso, saber todo lo que hay que saber

acerca de patrones de gasto y aún acerca de proyecciones de gastos, y saber muy poco o nada acerca del éxito o fracaso de nuestros proyectos en términos de sus productos, propósitos y metas. Es importante evitar la precisión asociada con el análisis de costos, seguimientos e informes de bajo nivel. La orientación del SMP es hacia el seguimiento de metas de desempeño y el prestar atención continúa a la definición y re-definición de objetivos de proyectos y programas que guardan consistencia con el área de control de la administración. E. INFORMES DE LOGROS Y ALERTIVOS La función de un buen sistema de información gerencial (SIG) es proporcionar la información adecuada a quienes la necesitan en el momento oportuno. La información adecuada es la que identifica un problema, de manera tal que el nivel de administración respectivo pueda solucionarlo. Esto significa que la administración a nivel de políticas debe tener cuidado de no sobrecargarse con datos en lugar de información. No es adecuado remitir información referente al avance o falta de avance del proyecto desde el nivel más bajo de operaciones al más alto nivel de administración. Virtualmente, cada proyecto está atrasado en su cronograma de alguna manera. Por tanto, un sistema totalmente desagregado, en el cual se lleva toda la información a la administración de alto nivel, indicaría simplemente que todos los proyectos están atrasados. No es necesario que un sistema de información proporcione este tipo de información. Uno podría ahorrarse tiempo y problemas, y simplemente preparar informes mensuales muy resumidos para que el registro diga exactamente que los proyectos están atrasados. El trabajo que se debe hacer, por tanto, es informar sobre aquellos problemas que son lo suficiente importantes como para ser mencionados al nivel administrativo que recibe el informe, de manera tal que pueda esperar una resolución. El método de los informes de logro y alertivos incorporado en el SMP logra esos objetivos. Está relacionado con, y basado en, la delegación ordenada de responsabilidades establecida por el Método del Marco Lógico. El requerir el mantenimiento de redes y programas de menor nivel, proporciona la capacidad para hacer un auditaje inmediato del desempeño de la administración en todos los niveles de la organización.

F. EVALUACION En cierto sentido, la evaluación es simplemente parte del sistema de informes –los informes evaluativos corresponden a la categoría de Informes Especiales y deberían ser programados para ser terminados antes de que se tomen decisiones importantes sobre el proyecto. La evaluación, en el sentido del SMP, trata del desempeño del proyecto en relación al logro de sus objetivos establecidos. Seguimiento se refiere al hecho de ver si el proyecto está o no logrando los productos planificados dentro de un período de tiempo y con las limitaciones de costo pre-establecidos. La evaluación busca determinar si los objetivos a nivel del propósito y fin se están cumpliendo, en qué medida, si se los podría cumplir más rápidamente con una combinación diferente de productos, etc., y determinar, en el caso de que un proyecto no esté logrando estos objetivos de mayor nivel, por qué no lo está haciendo. La evaluación también busca establecer la causalidad ¿Son los efectos observados a nivel propósito y del fin, causados por las actividades/productos del proyecto? En resumen, el seguimiento supone que el diseño es adecuado tal como está y simplemente busca asegurarse de que las actividades y productos funcionen de acuerdo al plan, y alertar a la alta dirección sobre los problemas, de modo que el proyecto pueda ser recolocado en el curso planificado. La evaluación busca asegurar que se logren los objetivos y conocer por qué están siendo logrados, de modo que el proyecto pueda ser considerado haber sido bien diseñado, rediseñarlo si

información sugiere que está errado, ó inclusive terminarlo si ya no se lo requiere (por ejemplo, los objetivos originales ya se han cumplido, o ya no se los considera un problema). Para una discusión detallada del método de evaluación que es componente integral del sistema SMP, además de ser un método válido de evaluación para programas o proyectos que usan otros sistemas de administración, o, que no tienen ningún sistema en particular, ver el panfleto de PCI titulado Project/Program Evaluatión: A Practical Systematic Approach.

PARTE III ADMINISTRACION DE PROYECTOS: BREVE REVISION DE DEFINICIONES

A. QUE ES UN PROYECTO Y QUE ES LA ADMINISTRACION DE PROYECTOS Las ideas que están sector

detrás de estos términos no son nuevas. Las empresas del

privado han empleado estos conceptos por décadas. Los programas

aeroespaciales y de defensa para el desarrollo de sistemas complejos han refinado la administración a un nivel altamente sofisticado. Lo novedoso acerca de la administración de proyectos es su aplicación en organizaciones operativas y gubernamentales pre-existentes. Esta tendencia se debe, en parte, al gran número de demandas ad-hoc ó únicas que se hacen actualmente a los gobiernos. Se acomoda bien a la solución de problemas socio-económicos de corto plazo ó a la conducción de estudios de investigación y piloto. En efecto la administración de proyectos es una manera útil de manejar cualquier actividad a la que se intenta dar una alta prioridad. Para comprender mejor lo que significa la administración de proyectos, veamos algunas definiciones de “proyecto” y “administración de proyectos”. Un proyecto es un conjunto de actividades interrelacionadas para las cuales el tema de organización (que crea la interrelación) es el logro de un objetivo específico, dentro de un periodo específico de tiempo. Un proyecto, por tanto, es muy similar a un sistema. La diferencia está en que un proyecto termina cuando su objetivo es alcanzado y un sistema podría continuar indefinidamente para producir los resultados que busca. Los proyectos normalmente, pero no necesariamente involucran disciplinas y habilidades múltiples. Asimismo normalmente, pero no necesariamente consumen niveles significativos de recursos. La administración de proyectos es, por tanto, simplemente la organización de personas y de utilización de recursos tal como se requieran para lograr el objetivo de un proyecto. La estructura apropiada resulta de una función única del proyecto: lograr el objetivo del proyecto.

B. PROYECTOS EN ORGANIZACIONES FUNCIONALES Modelo Burocrático Tradicional:

Cada unidad tiene responsabilidades bien definidas. En una organización racionalmente estructurada, cada unidad debería corresponder a un producto, servicio ó elemento de un proceso. Este modelo está bien acomodado a las actividades continúas y bien definidas de los departamentos en instituciones gubernamentales. Cuando se presenta una demanda poco usual a corto plazo, y que no encaja en ninguno de los

elementos

organizacionales

existentes,

modelo

ilustra

cómo

departamento puede crear un equipo de trabajo para resolver el problema:

La organización utilizará aquel personal, con la capacidad necesaria, que trabaja en la organización existente. Se los asignará a un equipo de trabajo dentro del proyecto por el tiempo que dure la actividad. Esto elimina la necesidad de una comunicación vertical dentro de la organización y una participación excesiva del personal superior.

La aplicación de la administración de proyectos a todas las actividades de una organización se llama “administración de tipo matriz”. La organización permanente o funcional existe solo para proveer recursos a la organización temporal del proyecto. PROYECTO 1 PROYECTO 2 PROYECTO 3 PROYECTO 4

PROYECTO 5 PROYECTO 6

C. SITUACIONES EN LA ADMINISTRACION DE PROYECTOS: Dos puntos de vista: A.

1. Existe un fin bien definido. 2. El fin de significación para la organización. 3. El contenido esta fuera de lo común. 4. Los planes están sujetos a cambios y requieren un alto grado de flexibilidad organizacional. 5. El logro del fin requiere la integración de dos o más elementos organizacionales.

1. Alcance: Si una actividad es más grande que cualquier otra que se haya realizado antes, y es temporal en naturaleza, se debe establecer un equipo de proyecto para concentrarse en el problema. Esto permite a la organización existente concentrarse en asuntos normales. 2. Falta de familiaridad o exclusividad: La falta de experiencia en una actividad podría conducir a la creación de un equipo de proyecto compuesto de expertos contratados temporalmente para llevar a cabo las actividades necesarias. 3. Complejidad: Cuando una actividad va a requerir numerosos elementos organizativos es aconsejable crear un equipo de trabajo temporal para el proyecto. Esto permite lograr una fácil comunicación lateral entre las unidades y acelerar la solución de un problema temporal.

4. Riesgo: Si el fracaso de una actividad tuviera serias consecuencias para una organización, es aconsejable crear un equipo de trabajo para el proyecto. Un equipo tiende a estar orientado al logro de resultados ya que sus miembros participantes se concentran en un asunto en particular. D. GERENTES DE PROYECTO Los gerentes de proyecto deben tener una buena combinación de habilidades técnicas, humanas y conceptuales. La mayor parte de los gerentes de proyectos son generalistas más bien que especialistas quienes han demostrado habilidad en planificación, organización y manejo de personal. 1. Funciones a.

Participar en la determinación de objetivos;

Elaborar un plan general de trabajo;

Seleccionar participantes y delegar responsabilidades;

Revisar los planes detallados de los participantes;

Establecer un sistema de vigilancia e informes;

Comunicar los planes detallados a los gerentes senior y determinar sus requerimientos de información;

Implementar, vigilar y controlar;

Motivar a los participantes.

2. Liderazgo El gerente del proyecto no tiene autoridad formal sobre el equipo de trabajo de su proyecto. Su habilidad de dirigir dependerá de la autoridad que derive de su competencia y habilidad para motivar a los participantes. La motivación no debería ser un problema para los equipos de trabajo, ya que la estructura misma del equipo ofrece responsabilidad y reconocimiento a los miembros del equipo. Los equipos también tienen la tendencia a fomentar un sentimiento de interdependencia entre los miembros y esta cohesión de grupo puede ayudar a la motivación. Los gerentes de proyecto deben tener fuertes habilidades de comunicación y conceptuales. Deben ser capaces de interpretar el efecto de los cambios en los planes sobre el fin del Proyecto durante la implementación.

E. POR QUE FRACASAN LOS PROYECTOS

¿Qué es el fracaso de un proyecto? Objetivo no Logrado: La imposibilidad de satisfacer los estándares de costo, cantidad, tiempo y calidad. Para prever el fracaso, un gerente de proyecto tendrá que hacer ajustes ó concesiones entre cada uno de estos elementos, siempre concentrándose en el fin pre-establecido. Las evaluaciones de proyectos a menudo mencionan las siguientes razones cuando tratan de explicar el fracaso de un proyecto:

Planificación Inadecuada a.

Las estimaciones de tiempo para actividades no fueron establecidas por los individuos responsables de llevar a cabo las operaciones.

Las estimaciones de costo no toman en cuenta las tendencias inflacionarias y del mercado.

Todas las actividades necesarias o las limitaciones no fueron anticipadas durante la fase de planificación.

Fueron ignorados factores externos (limitaciones y supuestos) que eran probables y críticos y que deberían haber impedido llevar a cabo la iniciativa.

La relación causal entre insumos, productos, productos y propósitos no fue lógica; no se realizo ningún estudio de factibilidad.

Control Inadecuado durante la Implementación a.

Seguimiento irregular y toma de decisiones lenta.

Falta de flexibilidad en el plan del proyecto.

Comunicación inadecuada de los problemas a los participantes.

Seguimiento Inadecuado de parte de los Administradores de Alto Nivel: a.

Falta de habilidad para comprender los planes iniciales.

La falta de habilidad para identificar fechas claves, conduce a un seguimiento irregular y a cambio en los planes.

Ausencia en el equipo del Proyecto de Personas que se beneficiarían de los Resultados del Proyecto.

Falta de uso de la Información de Evaluación de Proyectos Similares conduce a la Repetición de Errores.

Mala Conformación del Equipo de un Proyecto. a.

La capacidad de los participantes está por debajo de los estándares requeridos.

Falta de capacidad de los participantes para trabajar juntos.

Los miembros del equipo cambian durante el proyecto.

Ausencia de un Conjunto Formalizado de Procedimientos para la comunicación y Documentación.

Incompetencia del Gerente del Proyecto. a.

Falta de entrenamiento en administración

Falta de habilidad para controlar y motivar a los empleados sin tener autoridad formal.

PARTE IV INFORMES Y SEGUIMIENTO – REVISION DETALLADA

El objetivo principal de cualquier sistema de seguimiento e informes es simple: proporciona a las personas adecuadas, la información adecuada, en el momento adecuado. ¿Quiénes son las personas adecuadas? Las personas adecuadas son los miembros del equipo de trabajo, responsables del éxito del proyecto. Incluye, por lo menos, al gerente del proyecto

y su superior, pero podría también incluir a jefes de departamento,

contratistas, el Ministro, etc. Deberían incluirse entre las personas adecuadas casi siempre a los subordinados del gerente, quienes deben estar continuamente conscientes del progreso y efectos de las actividades que dirigen. La definición de personas adecuadas depende del proyecto en particular y su configuración administrativa. Qué es la información adecuada? La información adecuada es aquella requerida por cada nivel administrativo para cumplir con sus responsabilidades. La información adecuada se encuentra al nivel de detalle apropiado para cada gerente. Obviamente, el Ministerio de Agricultura necesita menos detalles en un proyecto de semillas de alto rendimiento, que el gerente del proyecto. ¿Cuándo es el momento adecuado? El momento adecuado es el momento en que se identifican los problemas potenciales y se consideran las alternativas disponibles para introducir correctivos. Esto significa identificar problemas potenciales e informar a ellos a tiempo. En cuanto a la información que no es esencial para la toma de decisiones, el “momento adecuado” podría ser nunca. El método de informes SMP está diseñado para satisfacer estos objetivos primarios. Incluye la selección e identificación de la información que debe ser transmitida por esos gerentes a otros niveles de administración. El procedimiento implica el diálogo entre superior y subordinado en cuanto a lo que son eventos importantes. Este diálogo ocurre generalmente dentro de la red elaborada por el gerente del proyecto al nivel de detalle que

requiere para controlar adecuadamente el proyecto. El gerente del nivel subordinado podría sugerir a su superior eventos para informes y el superior seleccionar el conjunto de eventos que constituirán su nivel de seguimiento. El superior es libre de especificar eventos adicionales para informes. En cuanto al formato, los eventos seguidos por el superior podrían ser indicados por un símbolo especial en la red del gerente del proyecto. Esto hace que el gerente está más alerta en cuanto a lo que le interesa a su superior y elimina la necesidad de diseñar redes separadas. Este tipo de diálogo de programación debe ocurrir en todos los niveles de organización de un proyecto. Se debe llegar a un acuerdo entre dos niveles de administración acerca de los eventos importantes que deben ser seguidos. Esto determina la base para la elaboración de informes. La elaboración de informes se basa en los eventos elegidos por el gerente de cada nivel. Ya que estos eventos han sido seleccionados por el gerente mismo, en base a sus responsabilidades e intereses, la preparación de informes se hace a la medida de sus necesidades reales. El SMP usa dos tipos de informes, informes de logros, conforme se llevan a cabo los eventos, e informes alertivos, es decir, cuando los eventos no se han realizado o están en peligro de no realizarse.

A. TODOS LOS INFORMES TIENEN UN COSTO La elaboración de informes tiene un costo. Existen costos directos en tiempo, dinero o ambos para el que los prepara. Estos incluyen el decidir que es lo que se va a informar, el recolectar y analizar los datos necesarios, preparar, los informes, enviarlos, etc. También hay costos para quien lo recibe. Estos incluyen el leer el informe, el cuestionar a quien los envía sobre información adicional, archivarlos, etc. Estos costos afectan la eficiencia de la administración. Cada gerente tiene una cantidad limitada de tiempo, cuanto más tiempo se emplea enviando o recibiendo informes, hay menos tiempo disponible para hacer otras cosas. El exceso de información es un peligro potencial. Cuando un gerente recibe más información de la que puede manejar, se hace difícil separa aquella información que requiere su acción administrativa del resto. El resultado es una disminución de la capacidad administrativa para responder y tomar decisiones afectivas.

Se cuenta la historia de un gerente de campo que se quejaba porque todos sus proyectos estaban atrasados y él no tenía tiempo para trabajar en ellos porque se pasaba todo el tiempo preparando informes a su superior. ¿Sobre qué informaba? Falta de avance de la implementación. Lo irónico es que el tiempo que empleaba en informar sobre los problemas, podría haberlo usado en solucionarlos. El SMP reconoce

que la elaboración de informes tiene un costo, y considera el

problema de tres diferentes maneras. Primero, selecciona solo los eventos más importantes sobre los que deben prepararse informes. Segundo, utiliza los formatos de informes que son breves y se orientan hacia estos eventos importantes claves. Tercero, genera informes en los momentos que son importantes para el proyecto, durante esos eventos claves.

B. ESTRUCTURA BASICA DE UNA ORGANIZACIÓN La estructura básica de la mayoría de las organizaciones se encuentra enmarcada en los lineamientos presentados en el Gráfico IV – 1. Naturalmente los títulos, número de niveles y número de unidades en cada nivel tienen variaciones. Sin embargo, la estructura por lo general se mantiene igual en la mayoría de las organizaciones del sector privado y público. A la cabeza está el director. El director que en el caso de un Ministerio sería el Ministro, es quien tiene la responsabilidad final sobre todas las actividades de su organización. Podemos llamar a la administración de este nivel “Jefes de División” y considerarlo el “Nivel II”.

Gráfico IV – 1 REDES DE ADMINISTRACIÓN SUPERIOR QUE RESUMEN LA INFORMACIÓN DETALLADA DE LOS NIVELES INFERIORES

NIVEL I Director de la Organización

NIVEL II Jefe de División

NIVEL III Gerente del Proyecto

PRODUCTO 1

PRODUCTO 2

PRODUCTO 3

PRODUCTO 4

Construcción Centro

Entrenamiento de

Inscripción de

Provisión Insumos y

de Entrenamiento

Agentes Extens.

Agricultores

A.B. a Agricultores

Si nuestra organización es el Ministerio de Agricultura, las divisiones podrían incluir la División de Alimentos en grano, División de Ganadería, División de Apicultura, etc. a menudo la organización por divisiones corresponde a programas. La responsabilidad sobre el proyecto podría estar en el siguiente nivel inferior, el nivel del gerente del proyecto. Dentro de la División de Alimentos en Grano podrían existir tres proyectos, uno que se refiere a arroz, otro a trigo y otro a maíz. Podemos considerar éste, el “Nivel III”. Las organizaciones reales son obviamente más complejas que este modelo simplificado, pero están organizadas sobre la misma base, mayor especialización y atención a proyectos y tareas individuales conforme bajamos en la jerarquía, y mayor responsabilidad global sobre todas las actividades que están abajo, conforme subimos en la jerarquía. Existen también funciones de asesoría o staff en las organizaciones reales, tales como finanzas, presupuesto, personal, administración, etc. las funciones de staff son diferentes de las funciones de línea. Las responsabilidades de staff generalmente son de apoyo a un aspecto especializado de todas las actividades de programa y organizacionales (tales como de personal), y no se concentran en asuntos específicos del proyecto o programas. Volveremos nuevamente a considerar esta estructura básica de organización para ilustrar los principios básicos del seguimiento y preparación de informes. En una situación real, la estructura de la organización se desviará de la que se muestra, pero los principios continuarán siendo los mismos. En cada nivel superior de la jerarquía administrativa, las responsabilidades e intereses son mayores, y el número de proyectos que uno debe vigilar es mayor. En nuestra estructura básica, cada gerente de proyecto del Nivel III se ocupa de un solo proyecto. Pero cada Jefe de División debe ocuparse de los tres proyectos de su división. Y el Director de la organización debe ocuparse y estar informado de todos los proyectos de la organización, en este caso simplificado, nueve proyectos separados. En organizaciones grandes, el número de proyectos podría llegar a los cientos.

La responsabilidad de administración diaria se la delega al gerente del proyecto. Obviamente no es práctico ni constituye una estrategia de administración sana el que los niveles superiores de la organización tengan que realizar seguimiento de cada proyecto al mismo nivel que lo hace el gerente del proyecto. Su superior, el Jefe de División, necesita ser informado del avance del proyecto en momentos claves, pero no necesita los mismos detalles que el gerente del Proyecto. Sus necesidades de información son una porción seleccionada de las necesidades de información del gerente del proyecto. Igualmente, el Director de la Organización necesita seguir el status del proyecto en cuanto a aspectos claves seleccionados. Sabe que el Jefe de División hará seguimiento del proyecto en un nivel mayor de detalle y que él será informado de los problemas que requieren su atención. El Jefe de División mantiene la misma relación con el gerente del proyecto.

C. LAS REDES DE ADMINISTRACION SUPERIOR RESUMEN LA INFORMACION MAS DETALLADA DE LOS NIVELES INFERIORES La información requerida por los altos niveles de administración para el seguimiento del proyecto y programas, es una porción cuidadosamente seleccionada del total de información usada por el nivel inferior inmediato. Supongamos que existe una organización de tres niveles como en el Gráfico IV-1. en el nivel de implementación más bajo, el gerente del proyecto, diseña un cronograma de redes que incluye todas la actividades y eventos que debe administrar. Su Jefe, el Jefe de División, revisa esta red y selecciona eventos de interés para él. Estos se convierten en eventos que él vigila y sobre los que recibe informes. De manera similar, el Director de la Organización selecciona los eventos que vigilará de la red del Jefe de División. Todos los eventos vigilados por los niveles superiores están contenidos e identificados en las redes de niveles inferiores. Este principio se da de arriba abajo en toda la estructura de administración sin importar cuán grande o compleja es la organización. ...to está en mejores condiciones para ver qué medidas deben tomarse para corregir la situación. Si el gerente del proyecto no pasa sus recomendaciones a sus

superiores, las decisiones se tomarán sin contar con la percepción clara de la persona en el terreno. La comunicación entre el gerente de un proyecto y sus superiores debe ser una comunicación de dos vías. El gerente de un proyecto debe conocer, y , cuando sea factible, ser un participante activo para determinar por qué el proyecto se está llevando a cabo. El Marco Lógico ayuda en esta comunicación especificando los objetivos de más alto nivel: Fin y Propósito. El gerente de un proyecto debe comprender cómo su proyecto contribuirá al logro del Propósito y el Fin. Si el gerente ve que su proyecto no tendrá el impacto esperado en niveles superiores, debe comunicar esto a sus superiores. A menudo, es difícil para un gerente hacerlo, porque ello podría significar que su proyecto podría ser descontinuado. Veamos un ejemplo: el Fin es “incremento del ingreso de los pequeños agricultores” y el Propósito “incremento de la producción de arroz de los pequeños agricultores”. El gerente de un proyecto ve que, aunque los pequeños agricultores están incrementando su producción de arroz, su ingreso no incrementa debido a una reciente declinación en el precio del arroz. Él debería transmitir esta información a sus superiores. Ellos entonces tienen una oportunidad, muy a tiempo, para examinar la situación y pueden ya sea añadir recursos o cancelar el proyecto a favor de una alternativa que tenga mayores probabilidades de éxito. a. Error en la Lógica Ocasionalmente se comete un error cuando se formula una hipótesis de Producto a Propósito. Esto ocurre si no se distingue entre el resultado sinergético esperado cuando todos los Productos se han logrado (ej. Propósito) y un simple resumen o reformulación de los Productos mismos. Si simplemente reformulamos los Productos entonces no tenemos hipótesis, tenemos un 100% de probabilidad de que “si Productos, entonces Productos”. Lo que estamos buscando es una formulación del Propósito que refleje los resultados de la hipótesis “si Productos, y ciertos factores importantes fuera de nuestro control, entonces Propósito”. En tal formulación nunca tenemos el 100% de probabilidad de que “si Productos, entonces Propósito”. Siempre existen variables intervinientes (y los supuestos que hacemos sobre ellos) que afectarán nuestra habilidad para lograr el Propósito deseado.

Los informes alertivos se envían bajo dos condiciones: cuando un evento está en peligro de no realizarse, y cuando no se ha realizado. Se debe considerar que estos son bandera amarilla y roja respectivamente. La bandera amarilla (como en los semáforos) es una señal de precaución. La bandera roja indica que el proyecto está esencialmente detenido hasta que se resuelva el problema. Los buenos administradores están siempre identificando, con la mayor anticipación, posibles problemas que podrían causar impedimentos al proyecto. La identificación oportuna de problemas es la mejor manera de resolverlos. No deberían existir nunca situaciones en las que un evento nos e realice sin que el nivel superior de administración haya sido informado por adelantado del problema. El informe alertivo incluye la identificación de problemas, una evaluación de su impacto sobre el proyecto, alternativas para resolveros, las acciones que el gerente del proyecto ya está llevando a cabo y aquellas que fueron requeridas.

F. EJEMPLO DEL FORMATO DE UN INFORME ALERTIVO El formato del informe alertivo del SMP (Gráfico IV-3) está diseñado para aclarar o hacer notar un problema y presenta la información requerida para tomar una decisión sobre la manera de resolverlo. El informe debe ser breve cuando hay un problema, la atención de los administradores debería centrarse en su resolución, no en informar sobre el mismo. Los informes largos pueden prepararse después de que el problema ha sido resuelto, no antes. El formato tiene cuatro partes. La primera se refiere al problema, discute su naturaleza y origen. La segunda discute el impacto que el problema tendrá sobre el proyecto. Aquí, el informante deberá haber identificado varias alternativas de solución para el problema, y discutir las ventajas y desventajas de cada una. Deberá también recomendar lo que él considera la mejor alternativa.

Gráfico IV-3 EJEMPLO DEL FORMATO DEL INFORME ALERTIVO

A: DE: FECHA: PROYECTO: SITUACION:

- Identifica por nombre y número el evento que está en peligro o no se ha realizado.

PROBLEMA:

- Discute la naturaleza y origen del problema sobre el que se informa.

EVALUACION DEL PROYECTO:

- Discute El impacto sobre el proyecto. - Presenta alternativas, ventajas y desventajas de cada una. - Recomienda la mejor alternativa.

ACCION:

- Especifica las acciones que ya se han realizado. - Especifica la acción requerida y la fecha en la que debe realizarse.

La tercera discute las acciones que el gerente del proyecto ha tomado para tratar de resolver el problema (o prevenir que empeore). También especifica las acciones que requieren de otras personas, así como las fechas para las que se requieren estas acciones. La cuarta es la parte de revisión donde deberá incluirse una evaluación del cronograma e identificarse cualquier cambio en eventos claves futuros. Un proyecto que llega a la situación de bandera roja, después que el problema se ha resuelto deberá ser revisado y reaprobado como si se tratara de un nuevo proyecto; en este sentido la resolución de un problema puede ser considerada y tratada por los administradores como un mini-proyecto. El Gráfico IV-4 proporciona un ejemplo de un informe alertivo.

Gráfico IV-4 EJEMPLO DE UN INFORME ALERTIVO (BANDERA ROJA) A:

Director de la Misión

DE:

Gerente de SMP

FECHA:

Mayo 30, 1980

PROYECTO:

Tehristan Millet Producción

SITUACION:

Evento Nº 32 -- “Recolección de Datos Básicos” – NO REALIZADO.

PROBLEMA:

los cuestionarios remitidos por los agentes de extensión son incompletos; los agentes informan que se requiere de dos horas para reunir todos los datos necesarios de los agricultores. Para asegurarse que todos los agricultores recibieron insumos antes del 15 de mayo, fecha de la plantación, los agentes de extensión se concentraron en la distribución de insumos y complementarán los cuestionarios, solo si el tiempo lo permite.

EVALUACION

El no haber obtenido datos básicos de por lo menos 89 agricultores,

DEL PROYECTO:

no permitirá realizar una evaluación, amplia al fin de la estación de cultivo. Una posible alternativa es que los agentes obtengan datos en visitas posteriores después de la plantación, pero el programa de visitas es demasiado apretado y puede que no haya tiempo para completar el cuestionario. Otra alternativa es la de acortar el cuestionario, pero de este modo no se podrían cubrir todos los aspectos de la evaluación. Una alternativa que se recomienda es solicitar al Ministerio de Agricultura que designe cinco personas para ser entrenadas por un período de dos semanas en junio.

ACCION:

Revisión del cuestionario para simplificar la codificación de respuestas. Solicitar al Director de la Misión que se ponga en contacto con el Subsecretario de Agricultura, con relación al posible empleo de las personas en entrenamiento. Respuesta del Ministerio requerida para el 10 de junio.

G. INFORMES DE LOGRO Los informes de logro son diseñados para señalar el logro de eventos claves (que han sido seleccionados por adelantado). Los informes de logro son enviados a los niveles administrativos que han seleccionado estos eventos para hacer seguimiento. Si tanto el Ministerio y el Jefe de División han seleccionado el mismo evento, el informe va a ambos. Estos informes incluyen una evaluación de la realización de estos eventos en tres dimensiones: calidad, cantidad y tiempo. El nivel planificado de logro ha sido determinado con anticipación, podemos llamar a éstos indicadores de comportamiento. Una parte importante del informe de logro es que define los tipos de acción que se requieren – si los hay.

H. EJEMPLO DEL FORMATO DEL INFORME DE LOGRO Este formato (Gráfico IV – 5) ha sido diseñado para ser usado en los sistemas de informes sobre logros del SMP y para hacer notar los puntos importantes sobre los que se informa, sin hacerlo excesivamente complejo o detallado. Tiene cinco partes principales, y el Gráfico IV – 5 resume el contenido de cada una. El Gráfico IV – 6 proporciona un ejemplo de un informe de Logro.

Gráfico IV – 5 EJEMPLO DEL FORMATO DE UN INFORME DE LOGRO

A: DE: FECHA: PROYECTO: SITUACIÓN:

- Identifica el evento realizado por nombre y número.

LOGRO:

- Discute el nivel de logro (cantidad y calidad). - Mide el logro frente a la expectativa pre-establecida de comportamiento. - Podría incluir la explicación o interpretación del logro.

EVALUACION DEL PROYECTO:

- Evalúa status actual del proyecto en general. - Alerta a los administradores sobre aspectos claves que se avecinan. - Ratifica o rectifica el cronograma de futuros eventos y adecuación de recursos.

ACCION:

- Especifica las acciones que se llevan a cabo actualmente. - Podría requerir que algunas acciones sean realizadas por otros, y la fecha requerida.

SIGUIETNE EVENTO SOBRE EL QUE SE INFORMARA:

- Identifica nombre y fecha del siguiente informe de logro programado.

Gráfico IV – 6 EJEMPLO DE UN INFORME DE LOGRO A:

Gerente del SMP

DE:

Director del Proyecto

FECHA:

Noviembre 15, 1980

PROYECTO:

Tehristan Millet Producción

SITUACION:

Evento Nº 7 realizado, entrenamiento de Agentes Extensionistas.

PROBLEMA:

Los agentes completaron con éxito tres semanas de entrenamiento en técnicas de cultivo, plantación y cosecha. 19 personas se inscribieron originalmente en la sesión de entrenamiento; una se retiró durante la segunda semana; dos no pudieron demostrar proficiencia y habilidad para enseñar efectivamente a los agricultores. Las personas en entrenamiento demostraron un gran interés y entusiasmo y ofrecieron datos muy útiles sobre la motivación de los agricultores, lo cual será utilizado para modificar la campaña entre estos.

EVALUACION DEL PROYECTO:

El proyecto está dentro de cronograma, sin cambios en el calendario de eventos futuros o requerimientos estimados de recursos. El supuesto de que las políticas favorables del gobierno sobre las adquisiciones puedan ser favorables para las cooperativas podría ser clave para asegurar un nivel adecuado (350) de participación de los agricultores en el primer año.

ACCION:

Actualmente se preparan materiales promocionales de campaña entre los agricultores. Se llevan a cabo charlas con el Ministerio de Agricultura; se espera el anuncio en 2 semanas. No se requieren acciones en esta oportunidad.

PROXIMO EVENTO A INFORMAR:

Técnicas de recolección de datos y de análisis elaboradas, Diciembre 15.

TABLEROS INFORMATIVOS PARA HACER SEGUIMIENTO DE LA SITUACION DE UN PROYECTO Los gerentes responsables de hacer seguimiento en forma individual de la situación de diversos proyectos, a menudo encuentran conveniente el identificar los “eventos claves” de cada proyecto en un solo cuadro explicativo. Los eventos claves y las fechas de cada uno se muestran para todos los proyectos en el Tablero de Resumen de la Situación de Proyectos. Esta expoliación permite que el gerente examine rápidamente los eventos claves próximos para proyectos que se llevarán a cabo en el período de tiempo de interés, a menudo 18 meses. Una herramienta compañera es el Tablero de Acción. El diseño del Tablero de Acción es flexible, pero generalmente incluye las siguientes entradas para cada proyecto: 

situación del proyecto (rojo, amarillo o verde)



descripción del problema (si lo hay) y el evento clave afectado.



acciones correctivas que se llevarán a cabo



quién es responsable de las acciones



fecha para la que se requiere la acción



otras entradas que se requieran.

El tablero de Acción se diseña para asegurar que cuando ocurren los asuntos e bandera roja ó amarilla, las acciones que se deciden realizar se registren para ser terminadas en una fecha específica, de modo que la resolución del problema puede ser seguida de la misma manera que el proyecto mismo. Además de proveer a la administración de un resumen de la situación del proyecto, los Tableros Informativos (ver Gráfico IV – 7) tienen un valor psicológico que motiva a los gerentes para que mantengan sus proyectos en status verde.

Gráfico IV – 7 TABLEROS INFORMATIVOS PARA HACER SEGUIMIENTO DE LA SITUACION DEL PROYECTO

TABLERO RESUMEN DE LA SITUACION DEL PROYECTO

TABLERO DE ACCION

EL MARCO LÓGICO UNA GUIA DE GERENTES PARA DISEÑAR Y EVALUAR PROYECTOS EN FORMA CIENTÍFICA

TABLA DE CONTENIDO PARTE I: ANTECEDENTES: ORIGEN DEL SISTEMA PCI DE MANEJO DE PROYECTOS ........................................................................................... 1

La planificación era demasiado imprecisa: ..................................... 1

La responsabilidad de la gerencia no era clara:............................. 1

La evaluación era un proceso adversativo: ..................................... 2

El Método del Marco Lógico: Resumen ............................................................ 3 PARTE II: EL MÉTODO DEL MARCO LOGICO ................................................... 6 A.

CONSIDERACIONES GENERALES SOBRE EL MÉTODO DEL MARCO LOGICO ................................................................................................... 6

Jerarquía de los Objetivos del Proyecto .......................................... 8

Hipótesis en Cadena.............................................................................. 9

Supuestos ............................................................................................... 11

Indicadores Objetivamente Verificables ........................................ 16 a.

Los Indicadores Miden lo que es Importante .............................. 19

Los Indicadores Deben ser Evidenciables...................................... 19

Los Indicadores Deben ser Especificados ...................................... 21

Los Indicadores son Independientes .............................................. 22

Medios de Verificación ....................................................................... 24

Esfera de Control .................................................................................. 26 a.

Error en la Lógica.................................................................................. 27

Delegación de la Responsabilidad de Obtener Productos ....... 28

ELABORACION DEL DISEÑO DE UN PROYECTO ......................... 31

EL MARCO LÓGICO Y LA EVALUACIÓN ......................................... 36

APÉNDICE A: EL MARCO LÓGICO Y LAS HIPÓTESIS DE CAUSA Y EFECTO EN UN MEDIO DE DESARROLLO ECONÓMICO O SOCIAL ..................38

PARTE A: Éxito del proyecto (Logro del Propósito).................................. 39 APÉNDICE B: LA RELACIÓN ENTRE EL MARCO LÓGICO Y LOS CONTRATOS ...............................................................................42

El Convenio ............................................................................................ 42

Productos Específicos a ser Entregados ....................................... 43

Reciprocidad .......................................................................................... 43

Provisiones para Problemas de Fuerza Mayor ............................. 43

APÉNDICE C: EL USO DEL PROCESO DE MARCO LÓGICO PARA LA INTEGRACIÓN DEL ANÁLISIS DE FACTIBILIDAD TÉCNICA, FINANCIERA Y SOCIO-ECONÓMICA ................................................46

EL MÉTODO DEL MARCO LÓGICO: EL PUNTO DE VISTA GERENCIAL ... 46 CONCEPTOS CLAVE .............................................................................................. 46

PARTE I ANTECEDENTES: ORIGEN DEL SISTEMA PCI DE MANEJO DE PROYECTOS “Si Usted no sabe hacia dónde se dirige, Cualquier camino lo llevará allí” Peter Drucker dijo una vez, que administrar es establecer objetivos. Esto es correcto, si usted no tiene objetivos, entonces el valor relativo de cualquier curso de acción que siga no puede ser comparado a cursos alternativos de acción. Todos los cursos de acción, todos los caminos, son los mismos, usted consume los recursos, usted está avanzando; pero ¿hacia dónde se dirige? En 1969, a fin de “descubrir hacia dónde se dirigía”, la Agencia Internacional para el Desarrollo de los Estados Unidos (AID) comisionó al personal de PCI el análisis de su sistema de evaluación de proyectos. Dicho análisis puso en descubierto tres problemas básicos que estaban afectando seriamente no sólo a la evaluación significativa de proyectos, sino también a su implementación.

La planificación era demasiado imprecisa: Los objetivos eran múltiples y no se relacionaban claramente con las actividades de los proyectos. No se tenía una imagen clara de lo que el proyecto debía ser si tenía éxito. Por tanto, los evaluadores no podían comparar, de manera objetiva, lo que se había planificado con los resultados que se había obtenido.

La responsabilidad de la gerencia no era clara: Los gerentes de proyectos tenían conciencia del hecho de que los proyectos se justifican en función de sus beneficios finales (impacto), sin embargo, se resistían a ser considerados responsables de impacto; habían demasiados factores importantes que escapaban a su control. Hallaban difícil el identificar aquello de lo cual ellos deberían ser responsables y terminaban por no aceptar ninguna responsabilidad por los resultados.

- 2 3.

La evaluación era un proceso adversativo: La evaluación de metas claras y frecuentes desacuerdos (aún entre los miembros de equipo del proyecto) acerca de lo que en realidad era el proyecto, los evaluadores terminaban usando su propio criterio en cuanto a lo que ellos consideraban eran los aspectos buenos y los aspectos malos. Los resultados subsecuentes de la evaluación, por tanto, frecuentemente se convertían en causa de mayores desacuerdos acerca de lo que era bueno o malo, en lugar de constituirse en acciones constructivas para el mejoramiento del proyecto.

El Método del Marco Lógico† para el diseño y evaluación de proyectos fue específicamente elaborado para responder a los problemas antes mencionados. Promueve la colaboración desde el principio y ayuda a evitar relaciones adversativas tanto en la formulación como en la evaluación de proyectos de la siguiente manera: 1.

Fomentando la descripción clara, explícita y medible de lo que ocurrirá si el proyecto tiene éxito;

Estableciendo claramente aquello de lo que el gerente del proyecto es responsable de lograr y porqué;

Mostrando los elementos claves del proyecto y sus relaciones entre sí, de manera que se facilite el análisis del proyecto;

Cambiando el enfoque de evaluación de ¿cuál es el plan más realista para este proyecto para el futuro, en base a la mejor evidencia disponible hoy? Este método convierte al gerente del proyecto en el usuario principal de los resultados de la evaluación. El Marco Lógico requiere objetivos claros y luego basa la evaluación en la evidencia. La evaluación se convierte en una herramienta de ayuda para el gerente del proyecto y no en un arma que lo amenaza.

El Marco Lógico fue probado por AID en 1970 en la evaluación de proyectos de asistencia técnica. Fue implementado en 30 programas de asistencia de AID en diversos países entre 1970 y 1971. en los años siguientes, el Método del Marco Lógico fue extendido a proyectos de préstamo en el terreno y proyectos de financiamiento desde la sede de AID. La Agencia

†

Los principales autores del Método del Marco Lógico son Leon J. Rosenberg y Lawrence D. Posner de PCI

(Practical Concepts Incorporated). Los conceptos se derivan en gran medida de la ciencia y experiencia obtenida en la administración de complejos programas de la era espacial, tales como los primeros lanzamientos de satélites y la construcción del submarino Polaris. Más importante aún es el hecho de que los conceptos ayudan a aplicar métodos científicos básicos (incluyendo la formulación y comprobación de hipótesis) a la administración de programas/proyectos y se complementan con otras herramientas gerenciales.

- 3 Canadiense de Ayuda Exterior (CIDA) aprobó el Método del Marco Lógico en 1974 y en 1975 decidió aplicarlo mundialmente. El Método del Marco Lógico se enseña ahora en instituciones gubernamentales y académicas de los Estados Unidos y de países en desarrollo‡. Se están elaborando nuevas aplicaciones. En Paquistán, se elaboró un Sistema de Manejo de Proyectos (SMP) completo añadiendo al Marco Lógico el uso de “redes de rendimiento” para sistemas de seguimiento e información. En Tailandia, Omán y Guatemala, el SMP fue adoptado en varios de los Ministerios. En Costa Rica, el Ministerio de Agricultura y Ganadería está trabajando en Programación Presupuestaria usando el Método del Marco Lógico. El banco Interamericano de Desarrollo tiene planificado incluir el marco Lógico en sus cursos de preparación y evaluación de proyectos para mejorar la administración de estudios de factibilidad.

El Método del Marco Lógico: Resumen El Método del Marco Lógico, es un conjunto de conceptos entrelazados que deben ser usados juntos de una manera dinámica para elaborar un proyecto bien diseñado, objetivamente descrito y evaluable. La incertidumbre dentro del proyecto se hace explícita. Los resultados del proceso de emplear conceptos del Marco Lógico pueden ser expuestos en una matriz de 4 x 4, proporcionando un resumen conciso de una página de los principales elementos del proyecto y sus relaciones entre sí (Cuadro I-1). Debe recordarse que el uso del Método del Marco Lógico permite una conceptualización paso a paso de elementos importantes del proyecto; no es simplemente un formulario que debe ser llenado. El uso adecuado de los conceptos facilita una comunicación más clara entre todos aquellos que participan en el diseño del proyecto. El Método del Marco Lógico debe considerarse una importante herramienta gerencial para planificadores y gerentes. No es difícil de usar. No requiere ninguna especialización en matemáticas o en el uso de computadoras. Descansa en la experiencia que tiene el usuario en proyectos de desarrollo así como la percepción de lo que constituye una buena administración, y la intuición. No proporciona respuestas o toma de decisiones, pero organiza la información de tal manera que pueden formularse importantes preguntas e identificar fallas del proyecto, y los encargados de la toma de decisiones pueden hacerlo en base a un conocimiento más profundo.

‡

El Marco Lógico es parte del Currículum de post-grado en tres Universidades Norteamericanas.

- 4 MARCO LÓGICO PARA EL RESUMEN DEL DISEÑO DEL PRODUCTO

Fecha estimada de terminación del Proyecto:___________ Fecha de este Resumen:______________________________

Título del Proyecto: MEDIOS DE VERIFICACIÓN

SUPUESTOS IMPORTANTES

Propósito del Proyecto: Objetivo General

Condiciones que indicarán que el Propósito se ha logrado: Situación final del Proyecto.

Que afectan el enlace Propósito-Fin.

Productos: Objetivos Específicos

Cantidades de los Productos Específicos que son necesarias y suficientes para alcanzar el Propósito

Que afectan Propósito.

Insumos: Actividades

Nivel de esfuerzo/gasto por actividad.

Que afectan el enlace Insumo-Producto.

Si existe el Propósito, entonces el Fin

Relacionadas con el valor a largo plazo del programa/proyecto

Si existen los Productos, entonces el Proposito

INDICADORES OBJETIVAMENTE VERIFICABLES Medidas del logro del Propósito

Si existen los Insumos, entonces los Productos

AREA DE ACCIÓN

HIPÓTESIS DE DESARROLLO

RESUMEN NARRATIVO Fin del Programa: Objetivo Final

enlace

Producto-

- 5 Los conceptos no necesitan estar restringidos sólo a proyectos, pueden ser aplicados en una variedad de situaciones, que incluye, aunque no se limitan, al diseño de planes y programas de desarrollo, elaboración de curriculum, clarificación de objetivos profesionales, diseño de estructuras de organización, etc.

- 6 -

PARTE II

EL MÉTODO DEL MARCO LOGICO

El núcleo conceptual del Método del Marco Lógico se describe en los párrafos que siguen. Este Método supone que los proyectos de desarrollo son instrumentos de cambio, que fueron seleccionados de entre instrumentos alternativos como los más costo-efectivos para lograr un resultado deseado y beneficioso. Nuestro método acepta la incertidumbre inherente en todos los proyectos de desarrollo identificando explícitamente la naturaleza de esa incertidumbre, las hipótesis de desarrollo. En base a la aplicación demostrada en cientos de proyectos de desarrollo económico y social, creemos que el concepto es factible y estratégicamente confiable.

CONSIDERACIONES GENERALES SOBRE EL MÉTODO DEL MARCO LOGICO

El Marco Lógico es una manera de organizar la información y actividades de modo que un número

diferentes

puntos

vista

pueden

ser

reunidos

simultáneamente

completándose en lugar de oponerse uno a otro. Estos puntos de vista son: -

Gerencia de Programa: Que estipula que se gerencia para lograr resultados y que se espera que los gerentes sean responsables por los mismos.

Método Científico Básico: Que estipula que en nada existe certeza, que toda actividad humana puede ser considerada como la comprobación de hipótesis.

Análisis de Sistemas: Que estipula que ningún sistema está definido hasta que hayamos definido el sistema mayor del cual forma parte.

A fin de simplificar los programas, primero reconocemos que existen tres niveles básicos de responsabilidad:

Insumos: Los recursos que consumimos y las actividades que llevamos a cabo.

Productos: Las cosas que, como buenos gerentes, estamos comprometidos a producir. Estos deben ser estipulados como resultados. Si fracasamos en producir aquellos resultados, entonces el gerente tiene la responsabilidad de mostrar la causa por la cual ha fracasado.

- 7 -

Propósito: La razón por la que producimos; el objetivo de más alto nivel que hace que invirtamos en la producción de resultados, es decir, si los resultados son bienes materiales, entonces nuestro Propósito podría ser la utilidad. Si nuestros Productos son servicios sociales, entonces nuestro Propósito podría ser el mejoramiento de la calidad de vida de la población a la que nos dirigimos.

Habiendo aclarado la jerarquía básica de objetivos para gerencia, introducimos el método científico básico: Todas las actividades humanas son inciertas. Por lo tanto, consideramos a nuestro proyecto como un conjunto de hipótesis en cadena; si Insumos, entonces Productos; si Productos, entonces Propósito. Debe notarse que lo que varía entre los niveles es la probabilidad de éxito. Es parte de la habilidad de un gerente responsable el asegurarse que los insumos resulten en productos; él es el responsable. Como hicimos notar antes, él debe mostrar la causa si es que fracasa. Por otra parte, la hipótesis si Productos, entonces Propósito, es problemática. Existe suficiente incertidumbre en esta hipótesis de modo que el gerente del proyecto responde solo hasta los límites razonables, él debe hacer lo que un hombre razonablemente haría para lograr el Propósito, pero no se le puede hacer responsable por ese resultado. Ahora, debemos añadir el tercer importante punto de vista al Marco Lógico, un punto de vista muy a menudo descuidado tanto en el método convencional de investigación de operaciones como en el de administración: El requerimiento de Análisis de Sistemas que nos dice que no hemos especificado un sistema hasta que no hayamos especificado la relación que este sistema tiene con un sistema mayor. Para hacer esto, añadimos a nuestra jerarquía gerencial de tres niveles de objetivos, un cuarto nivel superior llamado “Fin”. Definimos “Fin” de la siguiente manera: Es el objetivo de más alto nivel inmediatamente por encima del Propósito del proyecto. Es decir, es la frase “entonces” para la cual el Propósito del proyecto más los supuestos a dicho nivel de Propósito deben proporcionar un “si” factible. El Fin por tanto relaciona nuestras aspiraciones para el proyecto a las aspiraciones de aquellos para quienes nuestras actividades no tienen ningún interés intrínseco. Si nuestros Propósitos están a nivel de la institución, entonces nuestro Fin va más allá de la institución y relaciona nuestro programa a objetivos verdaderamente nacionales, objetivos que podrían ser comunes a varias instituciones.

- 8 Dado que existen muchas incertidumbres en la conexión entre Propósito y Fin, vemos también este último elemento de nuestra lógica proyecto/programa como una hipótesis comprobable (si Propósito, entonces Fin). Para incrementar nuestra comprensión de un proyecto identificamos y hacemos explícitas nuestros supuestos sobre aquellos factores necesarios para el éxito, pero que van más allá de nuestra habilidad de control en cada nivel de jerarquía del proyecto. Además, definimos explícitamente las condiciones que demostrarán logros en cada nivel (indicadores) y cómo verificaremos su cumplimiento (medios de verificación). La Lógica en Cadena del Marco Lógico se explica más a fondo en los párrafos que siguen. Debe recordarse que no está claro y tampoco interesa, si el Marco Lógico es una verdadera innovación en el sentido de que es diferente de lo que se ha hecho antes. Mejor es considerarlo, como lo hace PCI, como una cristalización de las mejores prácticas; una manera simple de reunir una multiplicidad de perspectivas analíticas y diagnósticas que incluye, pero no se limitan, a las cuatro antes mencionadas: gerencia para lograr resultados; método científico básico; análisis de sistemas; y ley contractual.

Jerarquía de los Objetivos del Proyecto

El Marco Lógico divide a un proyecto en cuatro niveles separados y distintos de objetivos. En el nivel más bajo están los insumos del Proyecto. Estos se refieren a las actividades a realizarse y que a su vez resultarán en un segundo nivel de objetivos que llamamos Productos. Los Productos son los resultados que se logran directamente mediante la administración de los Insumos. Los Productos son los resultados que se logran directamente mediante la administración de los Insumos. Por ejemplo, en un proyecto de educación podemos producir maestros entrenados, un edificio escolar equipado y administradores entrenados logramos esto administrando un conjunto específico de Insumos (por ejemplo, entrenamiento de maestros, construcción del edificio escolar, etc.).,sin embargo, los Productos por si mismos no tienen valor y no son un justificación del proyecto. Lo que realmente nos interesa es mejorar la educación. Ello, por tanto, representa un objetivo de más alto nivel que llamamos Propósito. El Propósito es lo que esperamos resulte del logro de los Productos. Los Productos son un conjunto de objetivos interrelacionados que, combinados, están orientados hacia el logro del Propósito del proyecto. Dentro del proyecto mismo tenemos, por tanto, tres niveles: Insumos, Productos y Propósito. El cuarto nivel en el Marco Lógico es un objetivo de más alto orden llamado Fin. El proyecto es una de las condiciones necesarias para el logro de este Fin, pero no será suficiente por sí

- 9 mismo para lograrlo. Usando el mismo ejemplo de un proyecto de educación, el Propósito específico del proyecto es una educación mejor y el Fin es satisfacer las necesidades de mano de obra de la industria local. Para lograr este Fin es posible que sea necesario que se lleven a cabo otros proyectos, como por ejemplo motivar a aquellos que tienen las habilidades requeridas para trabajar en la región en que se requieren dichas habilidades. De la misma manera en que debemos identificar todos los Productos necesarios para lograr el Propósito, debemos identificar todos los Propósitos (proyectos) necesarios para logra el Fin. Este es generalmente asociado con objetivos específicos de programas o sectores. La especificación de los Productos para lograr el Propósito y la gerencia para lograr el Propósito (y así lograr estos Productos) es normalmente función del gerente del proyecto. La especificación de todos los Propósitos para lograr el Fin y la gerencia para lograr el Fin (y así “producir” Propósitos”) es normalmente función del Director (o gerente) del programa.

Hipótesis en Cadena

Es importante notar que la relación entre niveles de objetivos no es accidental, ni al azar; existe una relación causal definitiva. Cuando identificamos nuestro Propósito, por ejemplo, y luego definimos cuáles son los Productos que necesitamos para lograrlo, estamos en efecto diciendo: “Si podemos obtener Productos, entonces deberíamos lograr éste Propósito”. En otras palabras seleccionamos estos Productos porque creemos que ellos pueden hacer que el Propósito ocurra. Estamos por lo tanto formulando la hipótesis de que si hay Productos, entonces hay Propósito. Una hipótesis se define como una predicción sobre una relación causal que implica incertidumbre. Un ejemplo de esto es la predicción de que si uno sube a su autobús regular de la mañana a las 8 en punto, entonces, uno llegará a su oficina a tiempo. Sin embargo, no es posible tener un cien por ciento de certeza de que esto ocurrirá, porque muchas cosas podrían ocurrir desde el momento de subir al autobús hasta el momento de llegar a la oficina como por ejemplo que el bus se descomponga o que haya un accidente. Cuando diseñamos un proyecto usando el Marco Lógico, hacemos una serie de predicciones que usualmente llamamos hipótesis. Estas son: 1.

Si los Insumos son administrados adecuadamente, ENTONCES, los Productos serán producidos.

Si se producen los Productos, ENTONCES se logra el Propósito.

Si se logra el Propósito, ENTONCES ello contribuirá al logro del Fin.

- 10 Esto puede ser visto gráficamente de la siguiente manera:

FIN SI PROPOSITO, ENTONCES FIN PROPÓSITO

PRODUCTOS

INSUMOS

SI PRODUCTOS, ENTONCES PROPOSITO

SI INSUMOS, ENTONCES PRODUCTOS

Las hipótesis tal como se las presenta aquí están demasiado simplificadas. Cada vez que formulamos dichas hipótesis, tenemos que aceptar que habrá un cierto grado de incertidumbre. La cantidad de incertidumbre es mayor en los niveles superiores de la jerarquía de objetivos del proyecto. Por lo tanto, es importante aclarar la naturaleza de la incertidumbre de modo que podamos seleccionar un diseño que tenga la mayor probabilidad de éxito. Esto se hace mediante la inclusión en nuestro diseño de los factores necesarios para lograr el éxito, pero que están más allá de nuestro control. Llamamos supuestos a estos factores adicionales. Por ejemplo, cuando uno predice que llegará a tiempo a la oficina tomando el bus regular de las 8 en punto, uno supone que el bus estará en buenas condiciones mecánicas y que no habrán accidentes. Debido a que reconocemos la existencia de la incertidumbre, necesitamos describir las dimensiones totales de las hipótesis que hacemos: En lugar de decir: Si uno toma el bus a tiempo, ENTONCES uno llegará a tiempo a la oficina. Debemos decir: Si uno toma el bus a tiempo, y (1) si el bus no se descompone, y (2) si no hay demoras en el tráfico, ENTONCES uno llegará a la oficina a tiempo.

- 11 Hemos descrito la naturaleza de la incertidumbre que afecta a nuestras hipótesis y la hemos expresado en forma de supuestos. (Ver Cuadros II-1, en el que se muestra un juego de hipótesis en cadena y supuestos para un Proyecto de Producción de Arroz). 3. Supuestos Los supuestos reflejan nuestro reconocimiento de que existen factores que van más allá de nuestro control y que son necesarios para el logro exitoso de objetivos en todos los niveles del proyecto. En el ejemplo anterior, podemos controlar el levantarse a tiempo, tomar el desayuno y llegar a la parada del autobús. No podemos controlar el tráfico o asegurarnos de que la compañía dueña de los buses los mantenga en buen estado de funcionamiento. De modo que al identificar nuestros supuestos hemos expandido nuestra hipótesis original para incluir la naturaleza específica de las incertidumbres más importante que podría afectar esa hipótesis. Una formulación más completa de las hipótesis y las incertidumbres contenidas en ellas se muestra en el diagrama siguiente:

FIN

SUPUESTOS

PROPÓSITO

PRODUCTOS

SUPUESTOS

INSUMOS

SUPUESTOS

Una vez identificados los supuestos, podemos trabajar con ellos de manera que aumentamos nuestra probabilidad de éxito y por tanto nuestra confianza en nuestro diseño del proyecto. En el caso del ejemplo del autobús, podemos levantarnos más temprano para evitar demoras en el tráfico o podríamos llamar a la compañía de autobuses y averiguar cuán a menudo se descomponen sus autobuses. Si nos indican que el 80% del tiempo se descomponen, quizás podríamos decidir tomar un taxi.

- 12 MARCO LÓGICO PARA EL RESUMEN DEL DISEÑO DEL PRODUCTO

Fecha estimada de terminación del Proyecto:___________ Fecha de este Resumen:______________________________

Título del Proyecto: RESUMEN NARRATIVO

Si existe el Propósito, entonces el Fin Si existen los Productos, entonces el Proposito Si existen los Insumos, entonces los Productos

AREA DE ACCIÓN

HIPÓTESIS DE DESARROLLO

Fin del Programa: El Objetivo más amplio al que contribuye el Proyecto

INDICADORES OBJETIVAMENTE VERIFICABLES

MEDIOS DE VERIFICACIÓN

SUPUESTOS IMPORTANTES

Medidas del logro del Fin

Relacionadas con importancia a largo plazo del programa/proyecto

Indicadores del logro del Propósito: Situación final del Proyecto.

Que afectan el enlace Propósito-Fin

Incremento en el Ingreso a Agricultores

Propósito del Proyecto: Incremento en la Producción

Productos

1. 2. 3.

Dimensión de Productos necesarios y suficientes para lograr el Propósito.

Sistema de distribución de fertilizantes y semilla de alto rendimiento (HUV) listo. Agricultores entrenados. Sistema crediticio listo.

Insumos: Actividades 1a. Diseñar sistema de Distribución. b. Construir facilidades de almacenamiento. c. Entrenar personal. 2a. Reclutar agricultores. b. Preparar facilidades de entrenamiento y materiales. 3a. Contratar especialista en crédito. b. Preparar procedimientos del Sistema c. Entrenar personal.

1. Precios permanecen estables. 2. Facilidades de Transporte adecuadas. 3. Facilidades de almacenamiento disponibles. Que afectan el enlace ProductoPropósito: 1. 2.

Nivel de esfuerzo/gasto por actividad.

Uso del fertilizante cuando se lo requiere. Precipitación pluvial adecuada. (Supuesto mejorado: Habrá una precipitación pluvial de 10 pulgadas entre mayo y octubre de cada año).

Que afectan el enlace Insumo-Producto. 1. 2.

Agricultores son receptivos a los nuevos métodos. Precios del fertilizante permanecen estables

- 13 -

Lo anterior es, por supuesto, un ejemplo sencillo. Sin embargo, los supuestos pueden ser el factor crítico en un proyecto de desarrollo. Lo importante es que debemos definir, a todo nivel, todas las condiciones necesarias y suficientes (ambas dentro de nuestro control, la hipótesis central, y fuera de nuestro control, supuestos), que deben tener lugar, a fin de que logremos el objetivo del nivel inmediato superior. Sigamos ahora este concepto considerando un proyecto de desarrollo más complejo. En el caso de proyectos de desarrollo estamos hablando de objetivos importantes de desarrollo y recursos escasos, de modo que vale la pena esforzarse en hacer que nuestras predicciones en el diseño del proyecto sean buenas. Antes de empezar el proyecto, debemos tener confianza en que podemos lograr nuestros objetivos. Por lo tanto, debemos considerar cuidadosamente qué es lo que estamos suponiendo acerca de aquellos factores fuera de nuestro control que podrían ser detrimentos para el logro de nuestros objetivos, identificándolos en la columna de supuestos del Marco Lógico en el mismo nivel donde se registra la porción “Si” de la Hipótesis. Por ejemplo:

RESUMEN NARRATIVO

SUPUESTOS

Fin Propósito Contrato importante firmado Productos. 1. Llegar a tiempo a la oficina.

1. Cliente aprueba ---------------Y

--------------------->

versión final del contrato.

Insumos. 1. Levantarse a tiempo para tomar el autobús

1. Autobús está en ---------------Y

--------------------->

buenas condiciones. 2. No hay demoras en el tráfico.

El Marco Lógico requiere que en cada “nivel”, las actividades o resultados planificados más los supuestos a ese nivel constituyen condiciones suficientes para lograr el siguiente nivel superior.

- 14 -

Una vez que hemos identificado tantos supuestos críticos como sean posibles con la información

disponible,

debe

considerarse

más

detalladamente

cada

supuesto.

Consideremos un supuesto del ejemplo de la producción de arroz en el Cuadro II-1, y veamos cómo se lo usa en el diseño del proyecto. Se necesita una cantidad adecuada de lluvia para cumplir con el Propósito del proyecto. Esto no es difícil entender, pero los planificadores y administradores de proyectos necesitan una mayor orientación para evaluar la validez de este supuesto. La primera pregunta que debe contestarse es ¿qué cantidad de lluvia es la adecuada? Debemos averiguar cuánta precipitación requerirán las cosechas. No será suficiente conocer cuantas pulgadas de precipitación pluvial se requiere. También debemos saber cuándo debe ocurrir la precipitación. Si descubrimos que las lluvias deben comenzar en Mayo durar hasta Octubre, con un promedio mensual de 12 pulgadas, el próximo paso es averiguar, si es razonable esperar este nivel y patrón de precipitación pluvial. Si el análisis cuidadoso de la historia climática de la región muestra que por ocho de los últimos 20 años, la precipitación pluvial fue de menos de ocho pulgadas en los meses de Junio y Julio, nuestro supuesto en cuanto a la precipitación pluvial adecuada no sería válido. Podríamos continuar con el proyecto tal cual está y aceptar una menor probabilidad de éxito, pero generalmente cuando la probabilidad de éxito rebaja substancialmente, debido a un supuesto sin validez, deberíamos tomar algunas medidas para rectificar la situación. Primero debemos preguntarnos si hay algo que el proyecto mismo pueda hacer para realizar el cambio necesario. En el ejemplo anterior tal vez un sistema de irrigación desarrollado por el proyecto proporcionaría una cantidad suficiente de agua a las cosechas. Los planificadores del proyecto deberían estudiar esto para determinar qué es lo que se requeriría para desarrollar el sistema de irrigación y si el proyecto cuenta con los recursos necesarios. Si el proyecto no puede permitirse ninguna expansión, tal vez otro proyecto podría hacerse cargo de esta tarea. Si no existen medios para rectificar el problema, entonces surgen otras dos posibilidades: (1) Los objetivos del proyecto podrían ser modificados (el nivel esperado de productividad en el ejemplo anterior podría ser reducido), o (2) El proyecto podría ser desechado como irrealizable, dejando de esta manera recursos libres para otros proyectos. Si cada uno de los supuestos en el diseño de un proyecto es manejado de esta manera durante la fase de diseño y el proyecto es mejorado en relación en esta forma, el gerente tendrá una idea realista de las probabilidades de éxito que tiene el proyecto y también estará en condiciones de anticipar el tipo de dificultades que podrían surgir durante el curso del proyecto.

- 15 Los supuestos son útiles no solo durante la etapa de diseño del proyecto sino también durante su ejecución y evaluación. Una vez iniciado el proyecto, su gerente debería seguir regularmente los supuestos para asegurarse de su continua validez. Si descubre que uno de los supuestos no es válido, debe tomar medidas para rectificar la situación. Un buen gerente de proyecto sigue los supuestos regularmente de modo que se puedan introducir correctivos oportunamente. Los supuestos son asimismo importantes en la fase de evaluación, puesto que su examinación puede darnos una mejor visión del por qué el proyecto ha tenido o no éxito en lograr sus objetivos. A fin de formular supuestos útiles, nos preguntamos: ¿Qué podría ocurrir para que este supuesto no tenga validez? Por ejemplo, si tenemos un supuesto muy general como “equipo disponible a tiempo”, nos preguntaríamos ¿Qué podría ocurrir que demore la disponibilidad del equipo? La respuesta podría ser, que es posible que ocurra una huelga en el puerto y por tanto nos damos cuenta que lo que estamos suponiendo es que la huelga en el puerto no ocurrirá. Entonces, formulamos otra pregunta: ¿Qué produciría una huelga en el puerto? Suponiendo que tenemos conocimiento de que el gobierno tiene programado firmar un contrato con el sindicato de trabajadores del puerto dos semanas antes de la fecha en que el equipo para el proyecto debe ser embarcado y que existe la posibilidad de que le gobierno no acepte las demandas del sindicato, el personal del proyecto podría entonces conversar con el sindicato y con las autoridades respectivas de gobierno para determinar la probabilidad de que el contrato sea firmado oportunamente. Si existe una alta probabilidad, en lugar del supuesto original (equipo disponible a tiempo), se haría el siguiente supuesto: “El gobierno y el sindicato de trabajadores del puerto firman contrato laborar el 28 de junio de 1982, a tiempo para la entrega del equipo”. El gerente del proyecto estará entonces advertido de mantenerse atento a las negociaciones entre el gobierno y los trabajadores del puerto y, si hay señales de que el contrato no sería firmado, puede replantear el proyecto en la forma más adecuada. La clarificación de supuestos permite una mejor comunicación entre el gerente del proyecto y sus superiores. Mediante el análisis cuidadoso de los aspectos inciertos del proyecto antes de que éste comience, los superiores del gerente del proyecto tienen bastante claro cuáles son los factores que están fuera del control de éste y como podrían afectar al proyecto. Cuando los superiores aprueban el proyecto, ellos aceptan el hecho de que los supuestos están fuera del control del gerente del proyecto. Asimismo comparten con él la opinión de que el proyecto tiene una alta probabilidad de éxito debido a la claridad y validez de los supuestos. Esta opinión compartida libera al gerente del proyecto de la responsabilidad

- 16 individual por el diseño total del proyecto. Si un supuesto luego demuestra no tener validez y causa un problema, el gerente del proyecto puede informar abiertamente sobre la situación sin temor de que solo él sea criticado por la equivocación. Un buen gerente debe sentirse libre de informar sobre tales problemas a sus superiores, sin el temor de que será injustamente acusado de una mala administración. Si el gerente oculta los problemas, especialmente aquellos que resultan de supuestos errados, entonces está eliminando la posibilidad de que sus superiores introduzcan correctivos. El gerente del proyecto y sus superiores deberían trabajar conjuntamente a fin de identificar los problemas y hallar las soluciones adecuadas. Si bien los supuestos están fuera del control del gerente del proyecto, no están necesariamente fuera del control de sus superiores. En una sección posterior se comentará más sobre el papel del gerente.

4. Indicadores Objetivamente Verificables No es suficiente definir la intención general del proyecto en términos de la hipótesis en cadena y supuestos relevantes para cada nivel del proyecto. La formulación de Fin, Propósito, Productos e Insumos, frecuentemente está sujeta a malentendidos o a interpretaciones diversas de parte de aquellos involucrados en el proyecto. La formulación de Fin y Propósito en particular tiende a ser ambigua. Ocurre a menudo que el Propósito de un proyecto es interpretado por las personas involucradas en él de muy diversas maneras. Por ejemplo, la formulación del Fin “mejores condiciones de vida para los pobladores” se presta a ser interpretada de diferente manera por las diferentes personas interesadas en un proyecto. Si pudiéramos visualizar exactamente cómo podríamos reconocer el éxito en cada nivel de un proyecto, podríamos mejorar el enfoque de los objetivos del proyecto y confiar en que todos los que están involucrados en él, comparten la misma imagen. Los Indicadores Objetivamente Verificables son el medio para establecer cuáles condiciones serán las que señalen el logro exitoso de los objetivos del proyecto. Se define a los Indicadores como a aquellas condiciones que están tan estrictamente asociadas con ciertas otras condiciones, que la presencia o variación en las primeras indica la presencia o variación en las segundas. Los Indicadores demuestran resultados. No son condiciones necesarias para lograr esos resultados. Por ejemplo, un aumento de la temperatura en el termómetro indicaría que hemos logrado exitosamente calentar el agua hasta un nivel deseado. El aumento de la temperatura en el termómetro, sin embargo, no es necesario para el logro del calentamiento del agua. Para ello se requiere del elemento calentador adecuado.

- 17 Por tanto, podemos usar indicadores para aclarar exactamente lo que queremos decir cuando formulamos objetivos narrativos en cada nivel de un proyecto (debe notarse que hay variación en los indicadores correspondientes al nivel de insumos, donde simplemente nos interesan los indicadores del consumo de los recursos del proyecto). Debido a que el Propósito del proyecto es de gran importancia, el conjunto de Indicadores a este nivel ha recibido el nombre especial de “Situación al Final del Proyecto” (SFP). Ello se debe a la importancia del Propósito, que hace que sea el principal motivo del proyecto y sirva de enfoque para la programación y el diálogo del proyecto. También se debe al hecho de que el Propósito es frecuentemente demasiado complejo, que involucra factores tales como la viabilidad de organización, mejoras netas en sistemas complejos, (ejemplo: humanos), etc. Es normal que para objetivos complejos, ningún Indicador por si sólo es suficiente, pueden atribuirse Indicadores relevantes a eventos alternativos o es que nuestra “especificación funcional” es multidimensional. De ahí que la regla para la selección de SFP es similar a aquella usada por cualquier buen gerente, administrador o científico en ciencias aplicadas. Si se satisfacen todas las condiciones SFP, entonces no existiría ninguna explicación alterna plausible (es decir ninguna explicación que no sea otra que aquella deseada – logro/propósito). El Marco Lógico, por tanto, incentiva al diseñador del proyecto a definir clara y explícitamente qué es lo que indicará que el proyecto sea considerado un éxito. Incluido directamente en el diseño del proyecto está el conjunto de condiciones que señalarán el logro exitoso del Propósito. Por ejemplo: PROPÓSITO Incremento en la producción de arroz

SFP 1.

30.000 agricultores con 7 hectáreas de tierra o menos incrementan el rendimiento de arroz en un 50% entre Octubre 1979 y Octubre 1981.

El arroz cosechado por los pequeños agricultores en 1981 es de la misma calidad (% partido) que le arroz cosechado por los mismos agricultores en 1979.

- 18 -

Nótese en el anterior ejemplo sobre arroz cómo los Indicadores añaden profundidad y dimensión a la formulación del Propósito. El propósito “incremento en la producción” es vago. Si logramos aumentar la producción en solo un 2% para un agricultor, se podría también considerar que hemos tenido éxito, hemos aumentado la producción. Sin los Indicadores, no tenemos forma de saber la intención específica del diseño original. También la forma en la que el Propósito está expresado, no aclara que estamos dirigiéndonos a la producción de los pequeños agricultores. Deberíamos por tanto reformular el Propósito así: Incremento de la producción de arroz de los pequeños agricultores de la región del Noreste. Cuando aclaramos la formulación del Propósito debemos nuevamente examinar nuestras Indicadores. Frecuentemente éstos necesitan ser pulidos. El proceso de pulirlos es esencial para la buena utilización de los conceptos. No deberíamos resistirnos a cambiar el Marco Lógico durante el diseño, más bien deberíamos considerar la necesidad de cambiarlo, en la medida en que el uso de los conceptos origina preguntas importante y nos obliga a refinar continuamente nuestro diseño hasta que tengamos un nivel alto de confianza en su validez. Es mucho mejor cometer los errores en papel. El proceso de usar los conceptos es mejor llevado a cabo en colaboración con otro. Requiere de la participación de todas las partes involucradas en el proyecto: persona de programación, alta dirección, administradores del proyecto, expertos y técnicos especializados, y con frecuencia los expertos en evaluación. Debe notarse también que una vez que hemos añadido Indicadores a nuestro diseño podemos juzgar mejor su adecuación. El cuadro II-2 presenta un Marco Lógico para el ejemplo agrícola en el cual se han añadido Indicadores, se ha aclarado el Propósito y el Fin, y se han explicitado los supuestos. Compárese este cuadro con el Cuadro II-1 para ver cómo estos conceptos se utilizan parar armar y mejorar el diseño. A menudo un número de Indicadores serán necesarios para medir el éxito. El número de Indicadores que son necesarios, es aquel número mínimo que nos hace confiar en que su existencia en efecto demostrará que hemos logrado nuestros objetivos para el proyecto y, además, señala al gerente del proyecto una meta clara hacia la cual se dirige. Solo cuando los objetivos están claramente definidos con metas, es que el gerente del proyecto puede juzgar si las condiciones en un nivel de diseño del proyecto son suficientes o no para lograr el objetivo del nivel superior.

- 19 Algunas reglas útiles de recordar son: 1. El resumen narrativo debe proporcionar un punto de dirección claro para todos los que participan en el proyecto, o sea algo que ellos puedan recordar con facilidad y consideren importante. 2. Los

Indicadores

Objetivamente

Verificables

añaden

profundidades

comprensión, estableciendo una especificación de desempeño tal, que aún los escépticos estarían de acuerdo en que el resultado que intentamos ha sido logrado (cuando los Indicadores son objetivamente verificados). A continuación se discuten cuatro características de los buenos Indicadores:

a. Los Indicadores Miden lo que es Importante Los indicadores deben medir lo que es importante en le objetivo. Por ejemplo, en nuestra formulación del Fin “incremento de los ingresos del pequeño agricultor” (Cuadro II-2), es más fácil medir el ingreso del agricultor, pero nosotros estamos interesados en el ingreso del pequeño agricultor; por tanto nuestros indicadores deben reflejar nuestro interés en los pequeños agricultores y estamos hablando de ingresos. Pero ¿a qué nos referimos, al ingreso en general o al ingreso real? Si nos referimos a éste último, esto debe especificarse de modo que podamos medir los aspectos importantes de nuestro proyecto.

b. Los Indicadores Deben ser Evidenciables Los indicadores que seleccionamos deben estar tan estrechamente relacionados a lo que estamos tratando de medir que podamos tener confianza en que nuestro proyecto fue un factor importante en los resultados observables. Por ejemplo, decir que la existencia de agricultores con grandes utilidades de debe al establecimiento de un sistema funcional de crédito, no es evidenciable. Los agricultores que tienen grandes utilidades podrían argüir que son otros los factores tales como cosecha exitosa, alto nivel de demanda y baja oferta de un producto determinado, fuerte actividad en productos de contrabando, etc. los que tuvieron influencia. Para demostrar que tenemos

sistema

crediticio

funcional,

debemos

buscar

indicadores

más

estrechamente relacionados con los que significa tener tal sistema, por ejemplo, el número de préstamos concedidos a los pequeños agricultores, nivel de mora, rapidez y eficiencia con la que se procesa y administrar los préstamos, etc.

- 20 MARCO LÓGICO PARA EL RESUMEN DEL DISEÑO DEL PRODUCTO

Fecha estimada de terminación del Proyecto:___________ Fecha de este Resumen:____________________________

Título del Proyecto: RESUMEN NARRATIVO

INDICADORES OBJETIVAMENTE VERIFICABLES

Si existe el Propósito, entonces el Fin Si existen los Productos, entonces el Propósito

Medidas del logro del Fin

MEDIOS DE VERIFICACIÓN

SUPUESTOS IMPORTANTES Relacionadas con importancia a largo plazo del programa/proyecto

Incremento en el Ingreso a Agricultores en la región del Noroeste

4. Ingreso de los agricultores promedio incrementado de $100/año en 1976 a $150/año en 1978. 5. Ingreso de los pequeños agricultores incrementado de $70 a $110 en el mismo período.

Propósito del Proyecto:

Indicadores del logro del Propósito: Situación final del Proyecto.

Que afectan el enlace Propósito-Fin

1. Precios del arroz no bajan de X $/ton en 1978 y X $/ton en 1978. 2. El mercado absorbe la producción total incrementada en cada cosecha. 3. No ocurre desperdicio o daño en el sistema de comercialización y almacenamiento.

Dimensión de Productos necesarios y suficientes para lograr el Propósito. 1a.10 centros de distribución construidos hasta 12/76. b. X toneladas de fertilizante y X toneladas de semilla distribuidas al grupo seleccionado hasta 12/76. c. 96% de todas las compras canceladas en el período de dos meses desde su adquisición. 2a. 35,000 agricultores entrenados hasta 12/76. b. 96% de aquellos entrenados usan adecuadamente nuevas técnicas de siembra y cultivo. 3a. 6m. de $ emitidos en créditos a 25,000 pequeños agricultores en 1978, por 30 oficinas de crédito de la región. b. La tasa de incumplimiento no excede 2% del total de los préstamos. c. Los términos de crédito son aceptables para los líderes agrícolas locales.

Que afectan el enlace Producto-Propósito:

Insumos: Actividades

Nivel de esfuerzo/gasto por actividad.

Que afectan el enlace Insumo-Producto.

1a. Diseñar sistema de Distribución. b. Construir facilidades de almacenamiento. c. Entrenar personal.

1a. b. c. 2

Incremento de la Producción de arroz de pequeños agricultores de la región Noroeste.

Si existen los Insumos, entonces los Productos

AREA DE ACCIÓN

HIPÓTESIS DE DESARROLLO

Fin del Programa: El Objetivo más amplio al que contribuye el Proyecto

los

Productos 1. 2. 3.

Sistema de distribución de fertilizantes y arroz de alto rendimiento, en sitio funcionando. Agricultores entrenados. Sistema crediticio en sitio funcionando.

2a. Reclutar agricultores. b. Preparar facilidades de entrenamiento y materiales. c. Llevar a cabo entrenamiento 3a. Contratar especialista en crédito. b. Preparar procedimientos del Sistema c. Entrenar personal.

6 12 36 24 24 36

meses/hombre meses/hombre meses/hombre meses/hombre meses/hombre meses/hombre TOTALES $.

$b. 15,000 600,000 “ 1,600,000 900,000 “ 150,000 1,200,000 “ 100,000 100,000 “ 200,000 “ 150,000 . otra moneda ………

1. La inflación no excede 12% anual. 2. Suficientes objetos “de lujo” para que los agricultores gasten su ingreso “disponible”. 3. Agricultores protegidos contra comerciantes inescrupulosos.

2. 3.

3. 4.

Los agentes extensionistas supervisan correctamente el uso de fertilizantes por los agricultores. Hay una precipitación pluvial de 10 pulgadas entre mayo y octubre de cada año. El precio de la semilla de soya permanece en los niveles de 1976 de modo que los agricultores permanecerán con el precio de arroz y no cambiarán a soya.

Los agricultores están dispuestos a aceptar nuevos métodos de cultivo. Los precios de fertilizantes no exceden de $. _____ por tonelada. Se puede reclutar localmente 150 agentes agrícolas extensionistas.

- 21 -

c. Los Indicadores Deben ser Especificados Los Indicadores deben especificarse en cuanto a la cantidad, calidad y tiempo (CCT). Si uno de estos tres factores no está presente no podemos tener objetividad para medir si hemos tenido éxito o no. Existe un proceso simple y progresivo para especificar un indicador, el mismo que se describe a continuación usando uno de lo sindicadores seleccionados en el Cuadro II-1 para indicar que se ha logrado el propósito: Primer Paso:

Identificar Indicador Los pequeños agricultores aumentan la producción de arroz.

Segundo Paso:

Cuantificar 30.000 pequeños agricultores (que poseen 7 hectáreas o menos) aumentan la producción de arroz en un 50%.

Tercer Paso:

Definir Calidad 30.000 pequeños agricultores (que poseen 7 hectáreas o menos) aumentan la producción de arroz en un 50% manteniendo la misma calidad de la cosecha de 1979.

Cuarto Paso:

Especificar Límite de Tiempo 30.000 pequeños agricultores (que poseen 7 hectáreas o menos) aumentan la producción de arroz en un 50% entre octubre de 1979 y octubre de 1981, manteniendo la misma calidad que existiría en la cosecha de 1979.

No todos los indicadores pueden incluir los tres factores (CCT). En el proceso progresivo que se describió, todos los CCT han sido incluidos, pero el indicador resultante es un tanto extraño. En el cuadro II-2 sin embargo, la calidad ha sido separada e incorporada en otro indicador. El mejor es aquel que simplifica. El aspecto de la calidad es muy importante, pero a menudo se lo ignora. En este ejemplo, la preocupación mayor está clara, si producimos más arroz a costa de la calidad habremos fracasado. Al especificar, debemos preguntarnos “¿Cuánto es suficiente para lograr el siguiente nivel de objetivos, de qué calidad debe ser y para cuándo lo necesitamos?” A fin de responder a estas preguntas, por supuesto, debemos conocer las metas de los niveles superiores. En nuestro ejemplo, sabemos cuál es el ingreso actual de los agricultores;

- 22 sabemos cuánto les cuesta actualmente satisfacer sus necesidades básicas (alimentación, semilla, ropa) y podemos estimar la que las costará de aquí a tres años. Por tanto, podemos estimar cuánto necesitarán ganar a fin de tener un ingreso real que se incremente lo suficiente para que el proyecto justifique su tiempo y esfuerzo. De ello podemos deducir cuánto arroz tendrán que vender y a qué precio (por lo tanto nuestros supuestos sobre precios de arroz) para 1981 y a la vez, podemos derivar cuánto arroz tendrá que producir. Este proceso se emplea para derivar metas para todos los componentes del proyecto, empezando por el nivel más alto para determinar lo que necesitamos, hasta el cálculo del costo de financiamiento del proyecto. Entonces, dado que muy rara vez obtenemos lo que necesitamos, tenemos que observar los recursos disponibles, y en forma ascendente considerar todo el proyecto para comprobar si en efecto, podemos lograr todos los niveles de resultados deseados, y si, una vez logrados, éstos justificarían su valor en relación al costo (costo-efectividad).

Los Indicadores son Independientes

Los Indicadores, que demuestran el logro de un objetivo a un nivel específico no pueden ser usados para demostrar logros en el próximo nivel superior. Aunque este es aparentemente uno de los conceptos más sencillos de la metodología del Marco Lógico, es también una de las debilidades más comunes en los diseños del Marco Lógico. Hay una tendencia común a demostrar el logro de un resultado, midiendo los medios empleados para conseguirlo. Se dice frecuentemente que el “edificio escolar construido” y los “maestros entrenados” (Productos) demuestran una mejora en la calidad de la educación en la escuela (Propósito). O por ejemplo, “centro de salud construido”, “provisión de medicinas” y “personal médico contratado” (Productos) demuestran que el centro de salud presta servicios (Propósito). Esto se debe a que es más fácil pensar en éxito cuando se trata de resultados tangibles de un proyecto, como edificios y gente. Los objetivos a nivel del Propósito son mucho más difíciles de definir. En lugar de luchar con algo difícil y quizás abstracto, se hace más lógico pensar, “Bueno, por supuesto, hemos mejorado la salud; sólo basta ver este edificio lleno de facilidades médicas, médicos y enfermeras de primera categoría trabajando para nosotros”. Es necesario pensar cuidadosamente acerca de cuáles indicadores verdaderamente demostrarían la “provisión de servicios de salud”, por ejemplo: número, tipo y calidad de atención en salud que actualmente se ofrece a determinados grupos, tales como el número de niños inmunizados, número de madres que reciben atención de salud preventiva, número de bebés que nacieron bien, etc.

- 23 Hemos hecho por lo tanto una predicción en sentido de que con la producción de Productos se logrará el Propósito, pero toda predicción incluye incertidumbre. Por tanto, no podemos decir que el producir Productos logra automáticamente el Propósito, ni tampoco podemos usar la obtención de Productos como prueba de que el Propósito se haya logrado. Debemos medir el logro del Propósito independientemente del logro de Productos. Una manera de controlar esta independencia es determinar si el conjunto de indicadores que hemos identificado para el nivel del Propósito presenta el medio para lograr el Propósito del proyecto, (en cuyo caso éstos son en realidad Productos, no así indicadores), o si en realidad describen las condiciones que existirían si el Propósito se hubiese logrado. Indicadores Especiales No siempre existen buenos indicadores disponibles. Un buen indicador es una medida directa de logro. Por ejemplo, el aumento en la productividad de las cosechas puede ser medido por el cambio en la producción por hectárea en campos donde el proyecto opera y los evaluadores pueden medir el éxito de este proyecto. Sin embargo, cuando el objetivo es el establecimiento de una industria viable se hace mucho más difícil medir el éxito del proyecto. Dicha industria podría haber sido desarrollada de manera tal que llegue a ser viable tres años después de haberse concluido el proyecto. Dicha, industria podría haber sido desarrollada de manera tal que llegue a ser viable tres años después de haberse concluido el proyecto. A fin de poder confiar en que el proyecto tenga éxito a su conclusión, es necesario hallar un indicador que pueda ser considerado capaz de predecir resultados posteriores. En este caso, tal indicador podría ser una tendencia a la reducción de los costos unitarios de producción y/o un constante incremento en los pedidos. Tales indicadores también pueden usarse para medir resultados cuando es demasiado costoso verificar los indicadores preferidos. Si un indicador preferido requiere una encuesta costosa para su verificación y si esto no está considerado dentro del presupuesto del proyecto, deben encontrarse indicadores indirectos o aproximados. Si el proyecto contempla evaluar la calidad de la educación en una escuela vocacional, pero no existe presupuesto para examinar a los graduados, los evaluados podrían investigar cuántos de los graduados están trabajando y con qué salario. Los indicadores indirectos no inspiran tanta confianza en el éxito como lo hacen los indicadores directos, pero representan una alternativa aceptable. Al usar indicadores indirectos debe tenerse cuidado en considerar qué otras variables podrían explicar el cambio en el indicador indirecto que hemos seleccionado. En el ejemplo anterior, los suelos de los graduados de una escuela vocacional podrían muy bien reflejar la satisfacción del empleador con la calidad del graduado, sin embargo, es posible que haya escasez de gente con este tipo de entrenamiento y la

- 24 demanda que existe esté elevando los precios excesivamente, aún cuando los graduados fuesen mediocres.

5. Medios de Verificación Como un paso adicional en el Método del Marco Lógico para aclarar objetivos, debemos preguntarnos. ¿Cómo podremos medir nuestros indicadores? Los indicadores prueban en logro de los objetivos, pero si no podemos hallar datos acerca de la cantidad de arroz cosechada por los agricultores, entonces no podemos demostrar que se hayan incrementado las cosechas y por tanto, no podemos mostrar un incremento en la producción en general. Y si no podemos medir éxito, o fracaso, deberíamos cuestionar la racionalidad de ejecutar el proyecto. Usualmente, podemos sustituir un indicador alterno que se correlaciona muy de cerca con el indicador preferido (por ejemplo: arroz comercializado). En muchos casos y si pensamos con cuidado, podemos con frecuencia encontrar datos apropiados, empleando diferentes medios de verificación. Si los agricultores no informan sobre la cosecha o si no hay medios para pesar los productos, podemos hacer una encuesta y contar el número de canastas recogidas. El valor de un indicador se limita por los medios que se dispongan para verificarlo. Como en el ejemplo anterior, si se requiere una encuesta amplia para obtener los datos necesarios para verificar el indicador, y si el proyecto no tiene fondos para pagar la encuesta, entonces debe encontrarse otro indicador. La verificación de algunos indicadores podría requerir simplemente una rápida revisión de registros del proyecto o del gobierno, mientras que otros indicadores requieren para su verificación de la recolección y análisis sofisticados de datos. Si la verificación va a costar al proyecto tiempo y dinero, entonces los medios de verificación deben ser identificados durante la etapa del diseño del proyecto y deben incluirse en los insumos del proyecto los recursos humanos y financieros requeridos. Si estos no son planificados al comenzar el proyecto, quizás no estén disponibles cuando se los necesite. Deben identificarse las fuentes de evidencia de todos los elementos importantes de un indicador.

- 25 Por ejemplo: Indicador Objetivamente Verificable

Medios de Verificación

2.000 nuevas viviendas para familias, adquiridas

Los registros de ventas de las oficinas

por residentes agricultores de bajos ingresos

de vivienda, número de ventas y

hasta junio de 1980.

fechas de las ventas. Datos sobre le nivel de ingresos del comprador, obtenidos de los registros de pagos de impuestos. Datos sobre la anterior residencia del comprador, obtenidos de la oficina de vivienda.

En el ejemplo anterior, cada elemento importante del indicador tiene un medio de verificación. Los medios de verificación deben ser cuidadosamente examinados para asegurarse de que los datos sean completos y fidedignos. A menudo los gerentes de proyectos confían en los registros gubernamentales, solo para posteriormente descubrir que (1) los registros no están al día o (2) los datos fueron recolectados informalmente, de modo que los datos no son confiables. La calidad de los datos disponibles debe ser verificada. En el ejemplo anterior, se encontró que los primeros dos medios de verificación estaban disponibles y eran confiables, pero se descubrió que la oficina de vivienda no mantenía registros sobre las residencias anteriores de los compradores. Este medio de verificación tuvo que ser descartado y debió encontrarse otro. Una posible alternativa sería visitar a los nuevos dueños para averiguar sobre su antigua residencia. También se podría organizar un sistema de información dentro del proyecto, de modo que se puedan obtener los datos necesarios en el curso de las operaciones regulares del proyecto. Tal sistema puede proporcionar información oportuna que puede ser usada por quienes toman las decisiones durante la ejecución del proyecto. Cualquier medio que utiliza el proyecto para obtener la información necesaria para verificar los indicadores de logro, el medio de verificación debe hacerse explícito en el diseño del proyecto. Ver el Cuadro II-3 para más ejemplos de los medios de verificación. El establecer los medios de verificación puede ser una tarea compleja y que exige mucho. Recomendamos que el gerente del proyecto sea el que seleccione las técnicas de

- 26 verificación que tengan sentido para él y sus colegas. Para aquellos que requieran un sistema de verificación más ajustado recomendamos documentos como “Manager’s Guide to Data Collection”, 1979.

6. Esfera de Control Hay una línea divisora invisible entre Productos y Propósito que permite distinguir los niveles de incertidumbre dentro del proyecto. Por debajo de la línea, por ejemplo, de producir Productos, existe un grado de certeza obtenido de todas nuestras experiencias anteriores, lo cual nos da la actitud de que “se puede hacer”. Un gerente puede aceptar la responsabilidad de producir Productos porque puede tener la certeza razonable de que con ciertos recursos él puede llevar a cabo las actividades correspondientes para transformar aquellos recursos en los Productos deseados. Por encima de la línea, por ejemplo de lograr el Propósito, es donde tenemos mucho menos experiencia y por tanto menos certeza de que “se puede hacer”, por tanto esperamos y confiamos que lograremos el Propósito. Hacemos lo más que podemos para definir todas las condiciones necesarias y suficientes para lograr aquel Propósito, pero hay aún algo de incertidumbre que no podemos expresar confiablemente en el sentido de que “se puede hacer”. Cuando decimos “esfera de control”, por tanto, nos referimos a ese complejo de actividades y recursos que el gerente controla en la producción de Productos para determinado Propósito. En efecto, el gerente competente acepta la responsabilidad de producir dichos Productos. Él no acepta la responsabilidad de lograr el Propósito: esa es responsabilidad de la Alta Gerencia o Dirección. Sin embargo, acepta la responsabilidad de hacer todo lo que pueda para vigilar el avance del proyecto en relación al logro de aquel Propósito y tratar de lograrlo. La especificación de lo que “se puede hacer”, “esfera de control”, y la “esperanza” de lograr lo que se desea lograr o sea el Propósito, facilita la clarificación de la tarea del gerente y permite un diálogo contractivo de la tarea del gerente y permite un diálogo constructivo y abierto entre los niveles de dirección. Esto a su vez permite a todos poder concentrarse en lo que el proyecto intenta lograr, cómo se lo puede lograr, qué factores están fuera del control del proyecto, quién es responsable de qué y cuándo deben participar los diferentes niveles de dirección. Esto crea una atmósfera orientada a tareas en la cual las oportunidades, avances y problemas que podrían impedir aquel avance, sean discutidos constructivamente. Debido a que el gerente sabe que no deberá responder por objetivos irreales, puede quedarse tranquilo y dedicar su energía a cumplir con su trabajo. No necesita preocuparse de que se lo responsabilizará por factores que están fuera de su control. Sin embargo, no se

- 27 lo libera de la responsabilidad de usar su buen juicio en el diseño del proyecto, de usar todos los medios a su disposición para influir favorablemente sobre los factores que están fuera de su control y comunicarse con sus superiores cuando vea que (1) los Productos quizás no sean producidos a tiempo o en calidad o cantidad suficiente, o (2) los Productos serán producidos tal como estaban planificados, pero que no están teniendo el efecto anticipado en el logro del Propósito. El gerente de un proyecto debería introducir todos los correctivos que tenga a su disposición y recomendar acciones correctivas a sus superiores cuando se las requiera. Es el gerente del proyecto el que está en contacto estrecho con su personal en el terreno y por tanto está en mejores condiciones para ver qué medidas deben tomarse para corregir la situación. Si el gerente del proyecto no pasa sus recomendaciones a sus superiores, las decisiones se tomarán sin contar con la percepción clara de la persona en el terreno. La comunicación entre el gerente de un proyecto y sus superiores debe ser una comunicación de dos vías. El gerente de un proyecto debe conocer, y, cuando sea factible, ser un participante activo para determinar por qué el proyecto se está llevando a cabo. El Marco Lógico ayuda en esta comunicación especificando los objetivos de más alto nivel: Fin y Propósito. El gerente de un proyecto debe comprender cómo su proyecto contribuirá al logro del Propósito y el Fin. Si el gerente ve que su proyecto no tendrá el impacto esperado en niveles superiores, debe comunicar esto a sus superiores. A menudo, es difícil para un gerente hacerlo, porque ello podría significar que su proyecto podría ser descontinuado. Veamos un ejemplo: el Fin es “incremento de ingreso de los pequeños agricultores”. El gerente de un proyecto ve que, aunque los pequeños agricultores están incrementando su producción de arroz, su ingreso no incrementa debido a una reciente declinación en el precio del arroz. El debería transmitir esta información a sus superiores. Ellos entonces tienen una oportunidad, muy a tiempo, para examinar la situación y pueden ya sea añadir recursos o cancelar el proyecto a favor de una alternativa que tenga mayores probabilidades de éxito.

a. Error en la Lógica Ocasionalmente se comete un error cuando se formula una hipótesis de Producto a Propósito. Esto ocurre si no se distingue entre el resultado sinergético esperado cuando todos los Productos se han logrado (ej. Propósito) y un simple resumen o reformulación de los Productos mismos. Si simplemente reformulamos los Productos entonces no tenemos hipótesis, tenemos un 100% de probabilidad de que “si Productos, entonces Productos”.

- 28 -

Lo que estamos buscando es una formulación del Propósito que refleje los resultados de la hipótesis “si Productos, y ciertos factores importantes fuera de nuestro control, entonces Propósito”. En tal formulación nunca tenemos el 100% de probabilidad de que “si Productos, entonces Propósito”. Siempre existen variables intervinientes (y los supuestos que hacemos sobre ellos) que afectarán nuestra habilidad para lograr el Propósito deseado.

MALA PRACTICA

BUENA PRACTICA

Propósito es la suma de productos.

Propósito es el resultado de los productos.

Propósito: Métodos modernos de

Propósito: Incremento en la producción

cultivo usados por los agricultores.

agrícola de los agricultores. Productos

Fertilizante usado por los agricultores.

Semilla de alto rendimiento plantada por agricultores.

Pesticidas usados por agricultores.

Fungicidas usados por agricultores.

Sistema de cosecha múltiple usado por agricultores.

b. Delegación de la Responsabilidad de Obtener Productos La responsabilidad de lograr cada uno de los Productos puede ser delegada por el gerente de un proyecto a otros, sean éstos los contratistas o subordinados. Los Productos pueden ser desglosados en el Marco Lógico enumerando las principales actividades que se requieren para lograr cada Producto. Esto es particularmente útil cuando el gerente del proyecto delega autoridad a varios contratistas o subordinados para un Producto, o cuando los Productos deben ser subdivididos para una adecuada asignación de recursos. Los insumos en el Marco Lógico deberían mostrar los recursos humanos, económicos y el equipo necesarios para cada una de las actividades. (Ver Cuadro II-3 – Niveles de Insumo y Producto, Columna de Indicadores de Insumos). El Marco Lógico puede ser usado como instrumento de comunicación, no solo entre el gerente de un proyecto y su superior como se describió anteriormente, sino también

- 29 entre el gerente de un proyecto y aquellos de los que depende en cuanto a cooperación para el logro de sus objetivos. Es especialmente útil cuando el gerente de un proyecto debe luchar con los numerosos factores que están fuera de su control. Por ejemplo, si el Propósito del proyecto es “incremento de la producción del arroz en un 50%” y sus Productos son (1) canales de irrigación construidos y (2) distribución de semillas de alto rendimiento, y el proyecto supone que habrá suficiente fertilizante en el mercado a un precio razonable y que las instituciones de crédito harán préstamos a los agricultores, quizás él necesite influir a los productores y distribuidores de fertilizantes y a las instituciones de crédito, sin tener autoridad directa sobre ellos. El gerente puede hacer esto compartiendo sus objetivos con ellos. Con el Marco Lógico él puede explicar cuál es el Propósito del proyecto, cuáles son los Productos que debe lograr y cuáles son los supuestos que son críticos para el éxito del proyecto. También debería compartir con ellos el Fin del proyecto de modo que puedan ver que están contribuyendo a una tarea significativa e importante. Finalmente, él debe compartir con ellos los supuestos del proyecto, para que ellos puedan entender mejor el papel que juegan ayudándole al gerente del proyecto en el logro de su contenido.

- 30 Fecha estimada de terminación del Proyecto:___________ Fecha de este Resumen:______________________________

MARCO LÓGICO PARA EL RESUMEN DEL DISEÑO DEL PRODUCTO Título del Proyecto: RESUMEN NARRATIVO

INDICADORES OBJETIVAMENTE VERIFICABLES

Fin del Programa: El Objetivo más amplio al que contribuye el Proyecto Si existe el Propósito, entonces el Fin

Incremento en el Ingreso a Agricultores en la región del Noroeste

Si existen los Productos, entonces el Propósito

Propósito del Proyecto:

Ingreso de los agricultores promedio incrementado de $100/año en 1976 a $150/año en 1978. Ingreso de los pequeños agricultores incrementado de $70 a $110 en el mismo período.

1a. Cifras de ventas y comercialización b. Cifras de impuestos. c. Informes de Agentes Extensionistas.

Indicadores del logro del Propósito: Situación final del Proyecto. los

Productos 1. 2. 3.

Sistema de distribución de fertilizantes y arroz de alto rendimiento, en sitio funcionando. Agricultores entrenados. Sistema crediticio en sitio funcionando.

Insumos: Actividades 1a. Diseñar sistema de Distribución. b. Construir facilidades de almacenamiento. c. Entrenar personal. 2a. Reclutar agricultores. b. Preparar facilidades de entrenamiento y materiales. c. Llevar a cabo entrenamiento 3a. Contratar especialista en crédito. b. Preparar procedimientos del Sistema c. Entrenar personal.

1. 50,000 agricultores (con 7 has o menos) incrementan rendimiento de producción de arroz en 50% entre octubre 1976 y octubre 1978. 2. El arroz cosechado por los pequeños agricultores en 1978 es de mejor o igual calidad (X% partido) que el arroz cosechado por los mismos agricultores en 1976. 3. 95% de los agricultores compran semilla de alto rendimiento para la estación de siembra 1979. Dimensión de Productos necesarios y suficientes para lograr el Propósito. 1a.10 centros de distribución construidos hasta 12/76. b. X toneladas de fertilizante y X toneladas de semilla distribuidas al grupo seleccionado hasta 12/76. c. 96% de todas las compras canceladas en el período de dos meses desde su adquisición. 2a. 35,000 agricultores entrenados hasta 12/76. b. 96% de aquellos entrenados usan adecuadamente nuevas técnicas de siembra y cultivo. 3a. 6m. de $ emitidos en créditos a 25,000 pequeños agricultores en 1978, por 30 oficinas de crédito de la región. b. La tasa de incumplimiento no excede 2% del total de los préstamos. c. Los términos de crédito son aceptables para los líderes agrícolas locales. Nivel de esfuerzo/gasto por actividad. 1a. b. c. 2 3

6 12 36 24 24 36

meses/hombre meses/hombre meses/hombre meses/hombre meses/hombre meses/hombre TOTALES $.

SUPUESTOS IMPORTANTES Relacionadas con importancia a largo plazo del programa/proyecto

2a. Igual que en 1.

Incremento de la Producción de arroz de pequeños agricultores de la región Noroeste.

Si existen los Insumos, entonces los Productos

HIPÓTESIS DE DESARROLLO

AREA DE ACCIÓN

MEDIOS DE VERIFICACIÓN

Medidas del logro del Fin

$b. 15,000 “ 1,600,000 “ 150,000 “ 100,000 “ 200,000 “ 150,000 otra moneda

600,000 900,000 1,200,000 100,000

1. La inflación no excede 12% anual. 2. Suficientes objetos “de lujo” para que los agricultores gasten su ingreso “disponible”. 3. Agricultores protegidos contra comerciantes inescrupulosos. Que afectan el enlace Propósito-Fin

1a. Registros de cosecha: Dpto. de Agricultura, encuestas de agentes extensionistas. b. Registros en 1876 del Dpto. de Agricultura. 2a. Revisión y análisis por expertos del Dpto. de Agricultura. 3a. Registros del Sistema Crediticio. b. Encuesta a Agricultores para satisfacción del Programa.

Que afectan el enlace Producto-Propósito: 1a. Registros del Proyecto. b. Registros de Proyectos, encuesta del agente extensionista. c. Registros cuentas por pagar. 2a. Registros del Proyecto b. Informes de agentes extensionistas. c. Cheques en sitio por el gerente del proyecto. 3a. Registros del Sistema Crediticio. b. Informe de agentes extensionistas.

2. 3.

Que afectan el enlace Insumo-Producto. 1a. Registros del gerente del Proyecto. b. Registros e informes de los subcontratistas. c. Informes del gerente del Proyecto.

1. 2. 3.

. ……………

- 31 -

ELABORACION DEL DISEÑO DE UN PROYECTO

Un proyecto debería ser diseñado muy rara vez por una sola persona en forma aislada. El diseño de un proyecto requiere habilidades administrativas y técnicas. Las personas que tienen las habilidades específicas requeridas deberían ser incluidas como miembros del equipo de diseño. El dónde comenzar cuando se elabora el Marco Lógico para un proyecto depende de la cantidad de decisiones que ya se hayan tomado en relación a los detalles de un proyecto. Idealmente, el Marco Lógico debería usarse antes de que el proyecto sea identificado. En tal caso, el Marco Lógico sería un instrumento de diseño para la planificación del programa/sector. Una vez que la Alta Dirección (programa/sector) hubiera identificado el Fin de un programa o sector, entonces se procedería a la identificación de el o los proyectos que se requerían para lograr el Fin. Si los gerentes en el nivel de programa estuvieran usando sus propios Marcos Lógicos para diseñar programas, la razón para el programa sería registrada con sus Marcos Lógicos como Propósito, y cada uno de los proyectos requeridos para lograr el Propósito sería un Producto. Cada Producto (o proyecto) entonces sería asignado al gerente de un proyecto. Su Fin sería, por supuesto, el Propósito dentro del Marco Lógico del gerente de un proyecto. Este mismo método podría usarse para delegar la responsabilidad de administrar

Productos

Individuales. Gráficamente esto puede verse a continuación, y en el Gráfico II-4.

PROGRAMA ML Fin

PROYECTO ML

Propósito

Fin

Producto1

Propósito

Fin

Producto1

Propósito

PRODUCTO ML

Producto2 Producto3

Insumos

Producto2 Producto3

Insumos

Producto1 Producto2

Insumos

- 32 -

Cuando se asigna un proyecto a un equipo de diseño (el cual, si es posible, debería incluir al director del proyecto) el Fin y el Propósito del Marco Lógico del proyecto ya están identificados. El equipo de diseño podría inicialmente querer aclara el Propósito mediante la elaboración de indicadores para la Situación al final de un Proyecto (SFP). Una vez que el alcance del propósito de un proyecto es comprendido, el siguiente paso es producir los productos del proyecto. El equipo de diseño debe preguntarse qué es lo que debe producirse para lograr el Propósito. Una vez que se han identificado los Productos, el siguiente paso es identificar las actividades y recursos requeridos para lograr los Productos. Hasta aquí se ha completado la primera etapa del Desarrollo del Marco Lógico. El Marco Lógico debería tener un Fin, un Propósito, Productos e Insumos identificados. La Situación Final de un Proyecto (SFP) debería ser lo suficientemente completa y los indicadores en el nivel de Productos e Insumos deben estar bastante bien identificados. Invariablemente, durante la etapa inicial del diseño de un proyecto, se identifican muchos supuestos, los cuales deben ser anotados a groso modo de manera que no se los olvide. La primera etapa es un diseño de arriba abajo, comenzando por el fin y bajando hasta los insumos. El Gráfico II-5 ilustra el diseño de arriba hacia abajo y los tópicos gerenciales que se tratan a cada nivel. La segunda etapa del diseño de un proyecto empieza desde abajo y asciende hasta el fin. Durante esta etapa el equipo de diseño debe preguntarse si se han identificado todas las condiciones necesarias y suficientes a un nivel, a fin de tener la confianza de que se cumplirán los objetivos del nivel superior inmediato. Se hace una revisión de cada conjunto de actividades junto con sus recursos para determinar si es necesario para lograr un Producto específico. Los supuestos deben aclararse aún más y el equipo debe determinar si es necesario para lograr un Producto específico. Los supuestos deben aclararse aún más y el equipo debe determinar si se han identificado todos los factores (tanto dentro, como fuera de la esfera de control) necesarios para lograr los Productos. En esta fase, debe llamarse cuando sea necesario a los expertos y técnicos de un proyecto para asesorar al equipo de diseño y/o al gerente de un proyecto. El equipo luego trabaja a nivel de los Productos y examina cada Producto para ver si es necesario para lograr el propósito de un proyecto. Deben elaborarse indicadores para cada Producto. Los supuestos que se hacen acerca de la hipótesis Producto-Propósito se clarifican aún más, y luego debe juzgarse si se han identificado todos los factores necesarios y suficientes para lograr el Propósito.

- 33 Gráfico II – 4: EL MARCO LÓGICO ESTABLECE LAS BASES PARA DEFINIR Y DELEGAR LAS RESPONSABILIDADES DE UN PROYECTO FIN PROPÓSITO PRODUCTOS 1. 2. 3. 4. INSUMOS

RESPONSABILIDAD PRODUCTO 1

PRODUCTO 3

1. Oficinas y Centros de Entrenamiento

3. Pequeños Agricultores Inscritos

Construidos INSUMOS

ASESOR

1a. Preparar Planes de Construcción 1b. Solicitar Propuestas Construcción

INSUMOS 3a. Preparar material publicitario.

CONTRATISTA

3b. Inscribir a interesados.

1c. Supervisar Construcción PRODUCTO 2

PRODUCTO 4

2. Agentes Extensionistas Entrenados

4. Insumos y Ayuda Proporcionados a los Agricultores

INSUMOS 2a. Reclutamiento Agentes Extensionistas

MINISTERIO DE AGRICULTURA

2b. Preparar Programa Entrenamiento 2c. Entrenar y Poner a Prueba a los Agentes

INSUMOS 4a. Concretar Requerimientos de Insumos. 4b. Obtener los Insumos.

MINISTERIO DE COOPERATIVAS

4c. Distribución a Agricultores.

- 34 -

El equipo luego analiza a nivel de Propósito de un proyecto y lo reexamina para determinar si es necesario para lograr el Fin. Todos los indicadores de la SFP deben estar totalmente identificados y señalados. Los supuestos para la predicción Producto-Propósito son aclarados más aún. Los otros proyectos que también contribuirán al logro del Fin deben ser incluidos en los supuestos. GRÁFICO II – 5 EL MARCO LÓGICO DE UN PROYECTO DE ASISTENCIA TÉCNICA INDICADOR

FIN DEL PROGRAMA

CONEXIÓN

TÓPICOS DE LA GERENCIA

Formulación Explícita

Porqué tiene este proyecto

del Fin

mayor prioridad que los proyectos que no tienen apoyo (Programación)

Si Propósito

¿Cómo podemos mejorar

entonces Fin

nuestra confianza de que llegaremos al Fin?

FIN DEL PROGRAMA

Condiciones que se esperan

Qué esperamos lograr con

al terminar el Proyecto

este Proyecto, (Programación y Diseño del Proyecto)

Si Productos

¿Cómo podemos incrementar

entonces Propósito

nuestra confianza en que el Propósito será logrado?

FIN DEL

Producto

¿Qué

PROGRAMA

Esperado

razonablemente produzca un

puede

esperar

gerente competente. (Diseño del Proyecto)

Si Insumos

¿Cómo podemos incrementar

entonces Productos

la eficiencia, lograr más productos de insumos comparables?

FIN DEL

Prespuesto y

¿Qué insumos se requieren?

PROGRAMA

Cronograma

¿Cuándo? (Presupuestación y Control)

que

- 35 El equipo de diseño* debe determinar si se ha identificado todos los factores necesarios para lograr el Propósito. A nivel de Fin los indicadores deben quedar totalmente identificados y determinados. Esto completa el primer ciclo del diseño del Marco Lógico. Para refinar, aún más, el diseño de un proyecto, se requieren dos actividades, y que pueden ser llevadas a cabo simultáneamente. Una de éstas es elaborar el plan de evaluación. Para esto, el primer paso es identificar los medios de verificación para cada uno de los indicadores. Si los medios de verificación requieren recursos y actividades adicionales para el proyecto, entonces ambos deben ser incluidos como Insumos del proyecto en el Marco Lógico. El gerente del proyecto debe anticipar decisiones que serán dependientes de los resultados de la evaluación. Si deben tomarse decisiones importantes en puntos específicos durante el curso del proyecto, entonces puede que se requieran evaluaciones parciales y metas deben desarrollarse para los indicadores. Deben identificarse los tipos de decisiones requeridas de modo que la información necesaria para tomar estas decisiones esté disponible a tiempo. Una evaluación simulada puede ser útil en la identificación de los tipos de decisiones y el tipo de información requerida. Puede descubrirse que es necesario incluir en el diseño de un proyecto indicadores y supuestos adicionales para proveer una base de medición en el futuro. La evaluación se orientará hacia la identificación del cambio que ha ocurrido como resultado de la ejecución de un proyecto. A fin de medir el cambio, es imperativo saber las condiciones que existían antes del proyecto. Para cada indicador que va a medir el cambio, el gerente de un proyecto debe tener datos completos sobre las condiciones iniciales. Si no hay datos disponibles, éstos deben recolectarse en su totalidad previo al inicio de otras actividades del proyecto. Si la recolección de datos básicos no es una actividad anterior al proyecto, entonces ésta debería estar incluida en el diseño del proyecto como actividad del mismo. Si esto a su vez, no es posible, entonces deben evaluarse las implicaciones de iniciar el proyecto sin tener suficientes datos básicos y considerar alternativas tales como la de no ejecutar el proyecto,

Los participantes en el proceso de diseño pueden provenir de diferentes niveles departamentales y áreas de

experiencia dependiendo del tipo de proyecto. Si un gerente de proyecto no ha sido oficialmente asignado, por lo menos un miembro del equipo de diseño debería ser nombrado responsable de hacer conocer el punto de vista de la dirección al equipo de diseño. Además, cuando se está refinando el Propósito y el Fin de un proyecto, la Dirección de alto nivel debería ser incluida en el diálogo para asegurar que la clarificación del nivel Fin responde a sus objetivos programados.

- 36 o la de recolectar datos de tendencias, de modo que, por lo menos, se pueda ver el cambio en un lapso de tiempo, aún cuando no podamos ver la situación inicial. La segunda actividad requerida para mejorar el diseño del proyecto se relaciona directamente con los supuestos. Cada supuesto debe ser totalmente aclarado y su probabilidad evaluada. Si el gerente de un proyecto considera que la probabilidad de que el supuesto sea válido es muy baja, entonces él debe tomar algunas medidas para incrementar la probabilidad de éxito del proyecto. Los tipos de acciones que él tiene a su disposición se discuten en la parte que trata de los supuestos. No hay una fórmula fija para determinar la probabilidad de un supuesto o para considerar las probabilidades combinadas de todos los supuestos del proyecto. En general, si un supuesto tiene baja probabilidad esto debería ser suficiente para indicar al gerente del proyecto que hay peligro. Si se ve que un número de supuestos no tiene altas probabilidades, entonces su probabilidad combinada tendría que ser considerada baja y esto también sería una señal de peligro para el gerente de un proyecto. Evaluar la probabilidad de un supuesto es una actividad que es algo subjetiva por naturaleza. Si el gerente del proyecto descubre que no puede evaluar la probabilidad de sus supuestos por no contar con la información necesaria, podría llevar a cabo más estudios hasta obtener la información. La información tiene un costo. Sin embargo, se debe ponderar éste con el costo para el proyecto si la información no se obtuviera. A largo plazo podría resultar más costoso el continuar sin información. Idealmente, el gerente del proyecto debería participar en la planificación del proyecto. A menudo un planificador diseña un proyecto y luego pasa el diseño terminado al gerente del proyecto. Cuando esto ocurre, el gerente del proyecto no tiene oportunidad de participar en el diseño y sin embargo, debe responsabilizarse por la implementación del proyecto. En tal caso, él debería examinar el diseño y alertar inmediatamente a la Alta Dirección sobre cualquier aspecto irreal en el diseño y problemas importantes que él prevea.

EL MARCO LÓGICO Y LA EVALUACIÓN

La disciplina de usar el Marco Lógico en el proceso de diseño facilita la producción de un diseño evaluable, los objetivos son claramente formulados, las hipótesis de desarrollo han sido explícitamente formuladas, y los indicadores de éxito a cada nivel de la jerarquía han sido establecidos. Más aún, estos indicadores expresan lo que los diseñadores llaman éxito;

- 37 así la tarea de evaluación es simplemente la recolección de datos para aquellos indicadores claves y la evaluación del proyecto frente a sus normas preestablecidas de éxito. El llamar a los evaluadores durante la fase de diseño para asegurarse de que los datos pueden en realidad ser recolectados, a costo razonable, ayuda a clarificar aún más el diseño del proyecto. También puede reducir los costos de evaluación mediante la incorporación de algunos aspectos de la recolección de datos en las operaciones rutinarias del proyecto.

- 38 APÉNDICE A

EL MARCO LÓGICO Y LAS HIPÓTESIS DE CAUSA Y EFECTO EN UN MEDIO DE DESARROLLO ECONÓMICO O SOCIAL La ciencia trata de establecer causalidad del siguiente tipo: A1 y A2 causan B; B causa C Si se establece dicha causalidad entonces el experimentador sabe que si se dan A1 y A2 debe resultar en C. ([A1,A2] B, B C, por tanto [A1, A 2] C) El método del Marco Lógico para el diseño de un proyecto se basa en el método científico. Para fines de este documento podemos asociar “A” con Productos, “B” con Propósitos y “C” con el Fin. El desafío para los planificadores del proyecto es elaborar una Lógica Vertical que contenga factores (causa) a cada nivel del Marco Lógico que sean tanto necesarios como suficientes para alcanzar logros (efecto) al siguiente nivel. Ver Gráfico A-1 abajo: Gráfico A - 1

FIN

SUPUESTOS

PROPÓSITO

PRODUCTOS

SUPUESTOS

INSUMOS

SUPUESTOS

- 39 -

PARTE A: Éxito del proyecto (Logro del Propósito) Cuando los resultados de la evaluación muestran que se han logrado resultados a nivel del propósito, es tarea del evaluador examinar la conexión causal (lógica vertical) entre los niveles de Productos y Propósito, así como identificar los factores no anticipados y no especificados en el Marco Lógico y que podrían haber influido en el logro del Propósito. El evaluador explora la posible ocurrencia de cualesquier factores no anticipados porque sabe que el conocimiento del planificador normalmente suficiente para predecir todo el conjunto de enlaces causales en la lógica vertical del Marco Lógico. Por tanto, es muy posible que los resultados de la evaluación demuestran la existencia de otros factores ((tanto hipótesis como supuestos implícitos) que hayan coadyuvado a lograr resultados a nivel del Propósito. Esta es la razón por la que decimos que el diseño exitoso de proyectos socioeconómicos es difícil y complejo. El gráfico A – 2 ilustra esta observación. El área encerrada en la línea punteada y que contiene (A1+A2) B1 C1 representa un determinado proyecto tal como fue originalmente concebido por el planificador del proyecto. A3 – A9 representan factores no anticipados que la evaluación demostró que habían contribuido al logro de B1. Puesto de otra manera: (A1+A2 B1 C1) representa el proyecto en el momento de su concepción. (A1 – A9) B1 C1 representa lo que realmente ocurrió para causar que se logre el Propósito.

- 40 Gráfico A – 2

HIPÓTESIS DEL PROYECTO B1

A2 A8

Relaciones de Causa y Efecto en un Medio de Desarrollo Económico y Social -

La Hipótesis del Proyecto es una vista limitada del mundo.

Se requirieron Productos Adicionales no anticipados (A3 – A9), para lograr el Propósito.

Estos (A3 – A9), deberían ser los Supuestos o Productos de un Marco Lógico “perfecto”.

La Hipótesis del Proyecto impone orden y no necesita incluir totalmente la causalidad.

- 41 Igualmente, podrían ocurrir los mismos fenómenos que afectan el propósito en relación con su enlace al Fin. Ello significa que los proyectos o supuestos adicionales, además de aquellos que el planificador del proyecto identificó en la Columna de supuestos a nivel de Propósito, ocurrieron e influyeron en el logro del Fin. En el abstracto ejemplo del Gráfico A – 3 suponemos que algún conjunto de eventos, A 1 hasta A9, es necesario y suficiente para causar B 1 y B4. B1 es una causa necesaria y suficiente de B 2 y B3, que juntamente con B4 son causas necesarias y suficientes de C1. Gráfico A – 3

A1 B2 B1

A2 B3

Relaciones de Causa y Efecto en una situación de desarrollo socio-económico -

Proyectos o supuestos adicionales B2 – B4 influyeron en el logro del Fin.

Un conjunto de proyectos con un Fin común se llama Programa”.

- 42 APENDICE B LA RELACIÓN ENTRE EL MARCO LÓGICO Y LOS CONTRATOS Un contrato es un convenio capaz de hacerse cumplir legalmente. La esencia de un buen contrato es por tanto su habilidad de ser comprendido por un miembro de poder judicial. Se puede suponer que un juez no sea una persona versada en aspectos técnicos del contrato, aunque si sea conocedor de los requerimientos e implicaciones de la ley. Por tanto, se deduce que para una revisión judicial, el contrato debe buscar que los aspectos técnicos sean los más claro posibles, que puedan ser comprendidos no solamente por el equipo del proyecto sino también por otras personas. A continuación demostramos cómo el Marco Lógico ayuda a aclarar los elementos de un contrato. Para hacerlo, debemos considerar que un contrato consiste de los siguientes elementos: 1. El convenio o intención. 2. Productos específicos a ser entregados. 3. Reciprocidad. 4. Fuerza mayor. La relación de cada uno de éstos con los términos del Marco Lógico es brevemente delineada a continuación:

1. El Convenio El Convenio, o intención de un contrato establece para revisión del poder judicial, el “por qué” se hizo el contrato. Sabiendo por qué las dos partes participan en el contrato, y sus objetivos a largo plazo, uno puede analizar las actividades de las partes del contrato para ver si han sido consistentes con el convenio. Las acciones que son inconsistentes con el convenio podrían dar lugar a un rompimiento o incumplimiento del contrato. El concepto del convenio en los contratos se acomoda exactamente al Propósito y al Fin del Marco Lógico. La razón por la que logramos Productos es porque esperamos que ellos resultarán en la realización del Propósito. Así, por implicación, se espera que el contratista obedezca la “regla del hombre razonable”, hacer todas las cosas que todo hombre

- 43 razonable haría (siempre que existen recursos disponibles) para modificar o añadir a la lista de Productos que sean necesarios para lograr el Propósito. El fin es, por supuesto, la razón por la cuál hemos definido el Propósito como el punto central del Proyecto. Además facilita el convenio aclarando a las partes * en el contrato sus objetivos a largo plazo. De la misma manera en que el patrocinador tiene el derecho razonable de esperar que el contratista hará todo lo que un hombre razonable haría para tratar de lograr el Propósito, el contratista espera que el país en desarrollo † y el patrocinador tratarán de llevar a cabo las acciones razonables necesarias para lograr el Fin. El contratista implícitamente acepta la responsabilidad de informar sobre situaciones en las que el logro del Propósito no satisfaga la intención a nivel del Fin.

2. Productos Específicos a ser Entregados Los productos a entregar, o ítems son esencialmente los Productos. Son las cosas que el contratista se ha comprometido a producir, considerando que sus supuestos a nivel de insumos son válidos. Es particularmente importante notara que los Productos a entregar deben ser resultados, no así actividades (o insumos). Además deben proporcionarse indicadores objetivamente verificables para cada Producto con metas cualitativas, cuantitativas y de tiempo.

3. Reciprocidad La esencia de un contrato, particularmente en términos de sus provisiones equitativas, es la reciprocidad. ¿Qué es lo que el contratista y el contratante se comprometen a proporcionar el uno al otro? La mínima garantía es, por supuesto, los insumos. Por una parte, el contratista conviene en proveer personal técnico, productos, llevar a cabo actividades, etc . Por otra parte, el patrocinador conviene en pagar al contratista ciertos honorarios, proveer apoyo en el terreno, etc.

4. Provisiones para Problemas de Fuerza Mayor El Marco Lógico aclara los problemas de fuerza mayor identificando aquellos factores que requerirán un reanálisis de la habilidad de desempeño, niveles en los cuales esos factores se tornan importantes. *

En el contexto de desarrollo, las “partes” en el contrato son esencialmente el país en desarrollo, el patrocinador

(AID, Banco Mundial, etc.) y el contratista (universidad, empresa privada, etc.). †

El país en vías de desarrollo es usualmente el cliente final del contratista.

- 44 -

Lo esencial aquí son los supuestos. A nivel de los insumos el contratista identifica los supuestos que debe hacer, a fin de garantizar su habilidad de lograr sus Productos. Si el contratista necesita suponer que el gobierno anfitrión proporcionará 10 vehículos y 10 choferes para lograr sus Productos, pero en realidad le proporciona solo cinco, entonces se debe esperar la correspondiente reducción en la calidad o cantidad de los Productos logrados.

- 45 Gráfico B – 1

FIN

Objetivo Nacional responsabilidad del anfitrión

Opinión compartida entre Anfitrión y Auspiciador

Responsabilidad del

PROPÓSITO

patrocinador ante el anfitrión: “regla razonable” para el contratista

El convenio entre las partes (país anfitrión, patrocinador o “cliente” y contratista)

Opinión compartida entre Patrocinador país anfitrión y el

Esfera de Control

PRODUCTOS

Responsabilidad del Contratista

contratista

Obligaciones mutuas,

INSUMOS

patrocinador y contratista Establece actividades, recursos y consideración.

El Marco Lógico ayuda aclarar las responsabilidades del contratista, patrocinador y anfitrión: El contratista es responsable de lograr Productos y de hacer evaluaciones técnicamente válidas con relación a la hipótesis (Si Producto entonces Propósito); la responsabilidad del patrocinador se centra en el Propósito y el Fin.

- 46 APENDICE C

EL USO DEL PROCESO DE MARCO LÓGICO PARA LA INTEGRACIÓN DEL ANÁLISIS DE FACTIBILIDAD TÉCNICA, FINANCIERA Y SOCIOECONÓMICA La Preparación y Análisis de proyectos se enseña y practica típicamente como una serie de análisis discretos, en forma de diferentes aspectos de un proyecto. El Método del Marco Lógico integra estos aspectos, clarificando sus relaciones recíprocas, como parte de un solo análisis. Este método facilita la enseñanza de análisis de proyectos y el manejo de los estudios de factibilidad por analistas especializados. Dicho método, asimismo, simplifica el proceso de revisión por parte de las instituciones de crédito. Una sola página puede resumir la esencia de un proyecto para gerentes que no cuentan con el tiempo para absorber extensos informes sobre cada proyecto.

EL MÉTODO DEL MARCO LÓGICO: EL PUNTO DE VISTA GERENCIAL El Método del Marco Lógico enfatiza el punto de vista gerencial, ya que el análisis dirige la atención a (1) los resultados del proyecto, una vez que haya sido completado con éxito, y (2) la estrategia para lograrlo. Existe una lógica implícita en cada proyecto, el Método del Marco Lógico hace explícita esa lógica y la comunica claramente a otras partes interesadas a fin de asegurar que sea realista y que dichas partes estén preparadas para hacer lo que se espera de ellas.

CONCEPTOS CLAVE JERARQUIZACIÓN DE OBJETIVOS Es útil pensar sobre un proyecto en términos de una jerarquización de objetivos. Los resultados que se logren en cada nivel de la jerarquía son medios para alcanzar los resultados en el nivel inmediatamente superior. El Proyecto tiene por objeto resolver un problema y es, frecuentemente, parte de un programa más amplio que tiene un Fin. El diseño del proyecto establece explícitamente qué solución se espera como resultado directo (el Propósito del proyecto), y medidas objetivas para alcanzarla (Situación Final del Proyecto). Para alcanzar el Propósito es necesario completar tareas específicas (obtener Productos), lo que a su vez requiere determinadas actividades (insumos). En un proyecto

- 47 bien diseñado, los resultados en cada nivel de la jerarquía son necesarios para alcanzar resultados en el nivel inmediatamente superior. Sin embargo, puede haber factores externos al proyecto que también sean necesarios para alcanzar los resultados en el nivel inmediatamente superior. En el proceso de diseño del proyecto, se deben hacer explícitos los supuestos importantes relativos a factores externos al proyecto. En un proyecto bien diseñado, los resultados a cada nivel de la jerarquía conjuntamente con los supuestos importantes sobre factores externos deberían ser suficientes para alcanzar los resultados esperados en el nivel inmediatamente superior. Indicadores Objetivos Verificables son esenciales en todos los niveles de la jerarquía. Un ejemplo: Una Cooperativa Agrícola – Resultados Esperados de un Proyecto Organizado Jerárquicamente Los resultados están especificados en una forma jerárquica a cuatro niveles (Cuadro C – 1 ). El problema básico es el bajo ingreso y la falta de empleos en un área rural de Costa Rica. El Fin es la creación de empleos e ingresos en el Distrito Sardinal. Este proyecto creará una exitosa cooperativa de productores de uvas. Los Productos que se requieren son: 1. Establecimiento de la cooperativa para proveer los insumos y comercializar el producto. 2. Establecimiento de un vivero de vid. 3. Establecimientos de viñedos en las tierras de los miembros de la cooperativa. 4. Adiestramiento de agricultores y de agentes de extensión agrícola en la producción de uvas 5. Análisis periódicos de rendimiento a fin de actualizar planes. Las “actividades” (insumos) requeridas para cada Producto pueden ser estimadas junto con el costo y la mano de obra requeridos para la actividad. Indicadores Objetivos Verificables de Efectividad En cada nivel jerárquico es necesaria una medición objetivo de resultados. En un proyecto determinado, se incluirán objetivos específicos para todos los niveles. Análisis de Factibilidad – Eficiencia

- 48 “Análisis de Factibilidad” es la medición de los resultados esperados por cada unidad de insumo; esto es, comparando la eficiencia en el uso del dinero y otros recursos con inversiones alternativas. GRAFICO C – 1 INDICADORES OBJETIVOS VERIFICABLES DE EFECTIVIDAD RESULTADOS ESPERADOS FIN Beneficios para los pequeños agricultores y los

pobres del Distrito Sardinia.

Ganancias netas para miembros de la cooperativa.

Beneficios a terceros en el Distrito Sardinia a través de los empleos creados: a.

Efectos de gastos

b. Efectos del Proyecto PROPÓSITO Producción

comercialmente

exitosa

Beneficios de la Producción.

comercialización de la uva por los miembros de

Beneficios adicionales de la operación de

la cooperativa.

la cooperativa: a.

Distribuidos a los miembros

b. Retenidas en la Cooperativa 3.

Rentabilidad de la inversión 12% o mejor.

PRODUCTOS Tareas Cumplidas: 1.

La Cooperativa proveyendo los insumos

Venta de insumos

que se necesitan. 2.

Vivero establecido.

Producción de vid.

Viñedos establecidos.

Uvas producidas.

Agricultores adiestrados

Estudios hechos.

Estudios

ACTIVIDADES Establecer la cooperativa. 1.1 Adiestrar a los agricultores

1.1 Seis meses-hombres: $3.000

1.2 Etc.

Establecer el vivero 2.1 Etc.

4.1 Doce meses-hombres:$36.000 + $100.000 = $136.000

2.2 Etc.

4.2 Etc.

2.3 Etc.

4.3 Etc.

- 49 La Factibilidad Técnica requiere el análisis de los resultados del “nivel de producción” comparado con los insumos. Es decir, ¿Cuántas libras de uvas producirá la vid en esta área? ¿Está la tecnología probada? ¿Con qué rapidez puede desarrollarse el vivero? ¿Se necesita regadío? La “eficiencia ingenieril” es pertinente. La Factibilidad Financiera requiere el análisis de los resultados del “nivel de Propósito” comparado con los insumos. Es decir, ¿Ganarán más los miembros de la cooperativa produciendo uvas en vez de maíz? ¿Habrá suficiente demanda cuando la producción de uva aumente? ¿Puede una cooperativa aumentar substancialmente la rentabilidad a través de compras de insumos, venta de uvas, procesamiento de uvas y otras funciones? ¿Qué tipo de financiamiento es necesario para que los productores de uvas tengan éxito? Para el análisis de la factibilidad financiera, los costos y los beneficios para los miembros de la cooperativa son elementos centrales en el análisis. ¿Es la rentabilidad económica suficiente como para motivar a los agricultores a participar? ¿Es realmente beneficioso para él, considerando usos alternativos de su dinero, tierra y trabajo? Se podrá justificar un subsidio siempre que un proyecto produzca beneficios importantes que no sean reconocidos por los agricultores; y se diseñará un subsidio eficiente para hacer un proyecto “comercialmente factible” con un subsidio mínimo. El tamaño y el tipo de subsidio necesario para diferentes proyectos variaría, pudiendo consistir en asistencia para organizaciones cooperativas, agentes de extensión agrícola, préstamos a bajo interés, e incluso una donación de fondos para el desarrollo del vivero. La Factibilidad Socio-Económica requiere el análisis de los resultados a nivel del Fin comparado con los insumos. Si el proyecto genera empleos en un área rural con un alto nivel de desempleo, los empleos generados son un beneficio a nivel del Fin, aunque estos gestos sean tratados como costos en el análisis de la factibilidad financiera desde el punto de vista de los miembros de la cooperativa. Utilizando métodos de trabajo intensivo se incrementará la factibilidad socioeconómica tanto en la preparación del vivero y los viñedos (“efecto de gastos”) como posteriormente en la operación de los viveros y de la cooperativa (“efectos de proyecto”). Si una tecnología de mano de obra intensiva es más cara que una tecnología de capital intensivo, ello hace necesario mayores análisis a fin de juzgar si subsidios adicionales son necesarios para la factibilidad comercial y si los beneficios socio-económicos son suficientes para justificar el subsidio adicional.

- 50 Los costos a considerar para la factibilidad socio-económica incluyen todos los subsidios además de los costos pagados por los miembros de la cooperativa. El punto central del análisis es el uso racional de estos subsidios a fin de obtener el máximo impacto socioeconómico de los recursos limitados para subsidiar la organización cooperativa. El trabajo de extensión, la infraestructura rural, y créditos de producción agraria incluyendo costos exteriores al proyecto. El “análisis costo/beneficio social” utilizará los resultados a nivel del Fin y el concepto amplio de costos.

- 51 Resumen El método del Marco Lógico integra los distintos tipos de análisis requeridos para el análisis de proyecto. El proceso proporciona un procedimiento útil para organizar el trabajo en estudios de factibilidad. Queda clarificado qué clase de información es necesaria para cada tipo de análisis, a fin de medir la efectividad y eficiencia del proyecto desde el punto de vista técnico, financiero y socio-económico. Un Beneficio Adicional – Un Plan Completo de Gerencia Además de un Proceso para la Ejecución y Evaluación Además de integrar los componentes tradicionales del análisis de proyectos, el Método del Marco Lógico provee además un plan completo de gerencia. Los gerentes se quejan de que la preparación tradicional de proyectos es abstracta y deja muy pocas cosas de importancia los gerentes responsables de la ejecución de proyectos. El método del Marco Lógico es un proceso gerencial para la definición de un objetivo realista y de los medios para alcanzarlo. El resultado es un plan realista al inicio del proyecto. El plan es compatible con los tradicionales sistemas gerenciales para presupuesto, programación, redes, sistemas de información y evaluación. Existen variaciones prácticas e innovadoras en estas técnicas tradicionales de gerencia que están especialmente destinadas a ser usadas con el Marco Lógico. Estos sistemas de Gerencia de Proyectos extienden el Método del Marco Lógico a la evaluación, la red de desempeño, sistema de informes de desempeño e informes de excepción, presupuesto por programas y sistemas de gerencia de recursos.

- 52 DIAGRAMA I: EJEMPLAR DE MARCO LÓGICO MARCO LÓGICO PARA EL RESUMEN DEL DISEÑO DEL PRODUCTO

Fecha estimada de terminación del Proyecto:___________ Fecha de este Resumen:____________________________

Título del Proyecto: MEDIOS DE VERIFICACIÓN

SUPUESTOS IMPORTANTES

Propósito del Proyecto: Objetivo General

Condiciones que indicarán que el Propósito se ha logrado: Situación final del Proyecto.

Que afectan el enlace PropósitoFin.

Productos: Objetivos Específicos

Cantidades de los Productos Específicos que son necesarias y suficientes para alcanzar el Propósito

Que afectan el enlace ProductoPropósito.

Insumos: Actividades

Nivel de esfuerzo/gasto por actividad.

Que afectan el Producto.

Si existe el Propósito, entonces el Fin

Relacionadas con el valor a largo plazo del programa/proyecto

Si existen los Productos, entonces el Proposito

INDICADORES OBJETIVAMENTE VERIFICABLES Medidas del logro del Propósito

Si existen los Insumos, entonces los Productos

AREA DE ACCIÓN

HIPÓTESIS DE DESARROLLO

RESUMEN NARRATIVO Fin del Programa: Objetivo Final

enlace

Insumo-

- 53 PROYECTO PLANTA DESHIDRATADORA DE FRUTAS DIAGRAMA 6. EJEMPLAR DE MARCO LÓGICO TERMINADO MARCO LÓGICO Marco Lógico de: PLANTA DESHIDRATADORA DE FRUTAS RESUMEN NARRATIVO Fin del Programa: El Objetivo más amplio al que contribuye el Proyecto.

Si existe el Propósito, entonces el Fin

Propósito del Proyecto: Objetivo General Reducir las pérdidas de comercialización de la producción frutícola de los productores del Valle de Cinti.

Si existen los Productos, entonces el Proposito

HIPÓTESIS DE DESARROLLO

Mejorar los ingresos de los fruticultores del Valle de Cinti.

Productos:

Fecha estimada de terminación del Proyecto: Fecha de este Resumen: Febrero de 1983

INDICADORES OBJETIVAMENTE VERIFICABLES

MEDIOS DE VERIFICACIÓN

Medidas del logro del Fin Los ingresos brutos de aprox. 473 productores frutícolas que venden fruta fresca a la planta se incrementan en la siguiente forma durante los primeros 5 años de operación del proyecto (1983-1988). Más del 7% de estos productores beneficiados son propietarios de áreas de menos de 2 Has. cada uno.

Las pérdidas de durazno, higo, uva y otras que ocurren durante el período entre la recolección y la comercialización, se estiman en más de 3.000 ton anuales. El proyecto intenta reducir esas pérdidas comprando oportunamente alos productores los siguientes volúmenes de fruta fresca para transformarlas en fruta seca.

1. a. Reformular estudio b. Revisar y aprobar estudio c. Constituir sociedad. d. Gestionar financiamiento. e. Realizar obras civiles f. Equipar plantas g. Contratar personal h. Adquirir insumos i. Realizar pruebas j. Iniciar operaciones.

Registros de compra de fruta fresca de la planta.

2. a. b. c.

Almacenar producción Transportar producción Distribuir producción

AREA DE ACCIÓN Si existen los Insumos, entonces los Productos

Inspección de planta en periodo de iniciación de operaciones.

Registros de ventas de la planta.

plazo

del

Los precios de venta de la fruta seca continúan permitiendo operar la planta en forma viable desde el punto de vista financiero.

Registros de control presupuestal y de costos.

Los fruticultores cumplen oportunamente con el cronograma de entrega de fruta fresca establecido por el proyecto. No se presentan problemas de transporte en época de cosecha de frutas. Que afectan el enlace Insumo-Producto. 1.

(%)

largo

Que afectan el enlace Producto-Propósito. 1.

Nivel de esfuerzo/gasto para cada actividad

Mater.

Que afectan el enlace Propósito-Fin. -

(En TM) Año Durazno Higo Uva Otros Total ---------------------------------------------------3 600 90 570 256 1.719 4 946 107 673 303 2.289 5 1.091 123 777 350 2.341 6 1.236 139 831 376 2.653 7-15 1.435 154 1.036 416 3.328 ----------------------------------------------------Nota: Año 3 del proyecto representa 1983. Dimensión de productos necesarios para lograr el propósito

FALTA CUADRO

importancia

Encuestas anuales realizadas en la zona del proyecto por extensionistas de CORDECH.

Año No. Productores Increm. Increm. Prom. Beneficiados Ingresos por Productor ----------------------------------------------------3 470 304.605 349 4 470 375.257 507 5 470 460.616 660 6 470 549.424 1.172 7 470 680.583 1.408 ----------------------------------------------------Nota: Año 3 del proyecto representa 1983. Indicadores del logro del propósito: Situación final – Del Proyecto.

Planta Deshidratadora funcionando. Comercialización de fruta efectuada.

Insumos: Actividades

SUPUESTOS IMPORTANTES Relacionadas con programa/proyecto

FALTA CUADRO 1. 2.

Noviembre de 1984

Los fruticultores son receptivos ala formación de sociedad. El margen entre los precios de venta de la fruta seca y los de compra de fruta fresca permite cubrir los costos operativos y financieros de la planta.

- 54 ANEXO 5 PROYECTO PLANTA DESHIDRATADORA DE FRUTAS PLAN DE EJECUCIÓN DEL PROYECTO 1.

DIAGRAMAR LA RED DE DESEMPEÑO ACTIVIDADES

a. b. c. d. e. f. g. h. i. j.

ACTIVIDAD PRECEDENTE

Reformular estudio Revisar y aprobar estudio Constituir sociedad Gestionar financiamiento Realizar obras civiles Equipar planta Contratar personal Adquirir insumos Realizar pruebas Iniciar Operaciones

a b b d e f g h i

c a

1 < 2.

3 <

b b b b b b b b

c c c c c c c

d d d d d d

e e e e e

f fg fgh fghi

5 <

6 <

h i

7 <

9 j

HACER EL CÁLCULO DE LA RED DE DESEMPEÑO

1 <

(1)

3 <

(1)

4 <

(4)

d (5)

5 <

6 <

(6)

7 <

(5)

(1)

i (1)

(3)

ENCONTRAR EL CAMINO CRÍTICO

c 1a

1 <

a a a a a a a a a

4 <

ACTIVIDADES QUE DEBEN HABER TERMINADO

1 (1)

3 <

2 (1)

4 <

(4)

e13

5 <

(5)

6 <

(6)13

g 19

7 <

(5) 16

h 20

(1) 19

(1) 20 20

(1)

(3)

PREPARAR EL DIAGRAMA DE GANTT MESES

ENE

ACTIVIDADES

0 a.

Reformular estudio

Revisar y aprobar estudio

Constituir sociedad

Gestionar financiamiento

Realizar obras civiles

Equipar planta

Contratar personal

Adquirir insumos

Realizar pruebas

Iniciar Operaciones

RECURSOS DISPONIBLES

ENE

84 1

RECURSOS REQUERIDOS

ENE

83 2

85 14

- 55 5.

PREPARAR CUADRO DE RESPONSABILIDADES MESES

ENE 83 1

ACTIVIDADES

a. Reformular estudio

ENE 84 2

RESPONSABILIDADES 14

P E

Jefe Proyecto… Dpto. Planif..

FALTA CUADRO

b. Revisar y aprobar estudio

P E

c. Constituir sociedad

P E

d. Gestionar financiamiento

P E

e. Realizar obras civiles

P E

Gerente Proyecto Contratista

Equipar planta

P E

Gerente Proyecto Contratista

g. Contratar personal

P E

Gerente Proyecto Dir, Personal …..

h. Adquirir insumos

P E

Gerente Proyecto Técnico Producción

Realizar pruebas

P E

Gerente Proyecto Técnico Producción

Iniciar Operaciones

P E

Gerente Proyecto Técnico Producción

NOTA: Este proyecto ha sido desarrollado considerando el Producto 1 del proyecto solamente para claridad de demostración.

Pdte. Gerente General Directorio … Gerencia Legal…

FALTA CUADRO FALTA CUADRO ……

- 56 ANEXO 6 PROYECTO PLANTA DESHIDRATADORA DE FRUTAS SISTEMA DE INFORMACIÓN PARA SEGUIMIENTO 1.

INFORMAR A LOS DISTINTOS NIVELES NIVEL III GERENTE GRAL.

1 <

DE CORDECH 11

NIVEL II GERENTE DE

1 <

2 9

DEPARTAMENTO DE CORDECH NIVEL I JEFE DE DIVISIÓN

1 <

2 9

DE CORDECH

ESTUDIO DE FACTIBILIDAD SE TERMINA DE FORMU-LAR EL 31 DE ENERO DE 1985

DEFINIR LOS EVENTOS DE IMPORTANCIA SELECCIONADOS

1 <

LAS OBRAS CIVILES SE TERMINAN DE CONSTRUIR EN ENERO 31 DE 1984

LAS PRUEBAS DEL FUNCIONAMIENTO DE LA PLANTA SE CONCLUYEN EN JULIO 31 DE 1984

EL EQUIPO DE LA PLANTA SE INSTALA HASTA JUNIO 30 DE 1984

LA FASE DE PRUEBA A PLENA CAPACIDAD DE LA PLANTA CONCLUYE EN NOVIEMBRE 30 DE 1984

< 10

c 1 < 3.

a (1)

b (1)

3 <

(4)

d (5)

4 < 5 <

e (6)

6 <

f (5)

g 7 <

(1)

h i (1)

(1)

j 11

10 (3)

SELECCIONAR EVENTOS DE IMPORTANCIA (Hitos) QUE SE ENCUENTRAN EN EL CAMINO CRÍTICO

EJECUCIÓN

- 57 ANEXO 6 (Pag. 2) EJEMPLO DEL FORMATO DE UN INFORME DE LOGRO

A: DE: PROYECTO: SITUACIÓN:

- Identifica el evento realizado por nombre y número.

LOGRO:

- Discute el nivel de logro (cantidad y calidad). - Mide el logro frente a la expectativa preestablecida de comportamiento. - Podría incluir la explicación o interpretación del logro

EVALUACIÓN DEL PROYECTO:

ACCIÓN:

- Especifica las acciones que se llevan a cabo actualmente. - Podría requerir que algunas acciones sean realizadas por otros, y la fecha requerida.

SIGUIENTE EVENTO SOBRE EL QUE SE INFORMARÁ:

- Identifica nombre y fecha del siguiente informe de logro programado.

- 58 ANEXO 6 (Pag. 3) EJEMPLO DEL FORMATO DEL INFORME ALERTIVO

A: DE: FECHA: PROYECTO: SITUACIÓN:

- Identifica por nombre y número el evento que está en peligro o no se ha realizado.

PROBLEMA:

- Discute la naturaleza y origen del problema sobre el que se informa.

EVALUACIÓN DEL PROYECTO:

- Discute el impacto sobre el proyecto. - Presenta alternativas, ventajas y desventajas de cada una. - Recomienda la mejor alternativa.

ACCIÓN:

- Especifica las acciones que ya se han realizado. - Especifica la acción requerida y la fecha en la que debe realizarse.

- 59 IX. SISTEMA DE INFORMACIÓN PARA SEGUIMIENTO 2.06 Se entiende por “seguimiento” en este Manual a la labor de vigilancia o supervisión de la ejecución de un proyecto. En la terminología del marco Lógico, “seguimiento” significa vigilar o supervisar la realización de actividades (Insumos) para el logro de los Productos de un proyecto. 2.07 El objetivo de un sistema de información es proveer a las personas adecuadas la

información específica, en el momento oportuno. 2.08 Las personas adecuadas, son todas aquellas que por algún propósito necesitan mantenerse informadas acerca del progreso de un proyecto. Ellas pueden ser desde los miembros de un grupo ejecutor, sus superiores, jerarquía en una institución. A quienes se debe mantener informados sobre el progreso de la ejecución de un proyecto, depende en todo caso del tipo de proyecto, del tipo de organización administrativa a la cual pertenece un proyecto y el tipo de exigencias externas que tenga un proyecto por parte de instituciones crediticias, fiscalizadoras, aseguradoras, etc. 2.09 La información específica, es aquella que es necesaria proporcionar para que aquellas personas o instituciones que la reciben puedan llevar a cabo sus obligaciones o ejercer sus responsabilidades. El grado de detalle de la información específica que debe administrarse debe ir acorde con las necesidades del nivel jerárquico de las personas que la reciben. 2.10 El momento oportuno, es aquel en el cual se informa sobre resultados obtenidos o también aquel en el cual se informa sobre la existencia de problemas que podrían poner en peligro el logro de los objetivos de un proyecto. 2.11 Informar sin embargo, implica costos, no sólo de tiempo sino de recursos de aquellas personas que preparan la información y de aquellas que la reciben y la leen. Es necesario por ello, que cualquier sistema de información que un proyecto adopte, tome en cuenta ese costo y haga algo para minimizarlo sin afectar al mismo tiempo la calidad y la oportunidad de la información. 2.12 El SMP provee tal sistema y este Manual recomienda a sus usuarios diseñarlo y utilizarlo en todos los proyectos que sean preparados para ser financiados con recursos del Programa. La vigilancia o supervisión de la ejecución de dichos proyectos sería entonces llevada a cabo mediante la utilización de ese sistema. 2.13 Dicho sistema es el llamado Sistema de Información para Seguimiento (SIS), el cual es el tercer componente de los cuatro instrumentos gerenciales que incorpora el SMP para llevar control del ciclo de un proyecto. Se lo utiliza para hacer seguimiento de la ejecución de un proyecto y consiste básicamente en seleccionar solamente los eventos más importantes de un proyecto e informar sobre ellos a las personas o instituciones adecuadas en la oportunidad que ocurren o están en peligro de no ocurrir. Para ello, el sistema proporciona

- 60 dos tipos de informes con formatos uniformes y breves. Un ejemplo práctico completo se proporcionó en Anexo 6. 2.14 El SIS de un proyecto se establece tomando como punto de partida el Camino Crítico de su red de desempeño. Se hace esto porque todas las actividades y eventos que ocurren en la ejecución de un proyecto, aquellos que se encuentran en el recorrido del Camino Crítico son los que tienen más importancia y urgencia de ser vigilados por la Administración de un proyecto. Para ello, primero se seleccionan los eventos claves (hitos) que ocurren en el recorrido del Camino Crítico; segundo, se definen los eventos claves seleccionaos en términos de cantidad, calidad y tiempo; y tercero, se definen los niveles jerárquicos de una institución e identifican las personas a las cuales se debe enviar información explicitando además el grado de detalle en que ésta debe ser enviada. 2.15 Seleccionar los eventos clave (hitos) que ocurren en el recorrido del Camino Crítico de la red de desempeño de un proyecto, significa identificar todos aquellos eventos que son importantes para el éxito de un proyecto y en especial aquellos que son de interés para la alta administración. Se seleccionan eventos en lugar de actividades porque el interés de un supervisor debe concentrarse en medir resultados alcanzados y no meramente actividades realizadas. 2.16 Definir los eventos clave (hitos) en términos de indicadores, significa especificar las metas de los eventos seleccionados, de manera que se tenga una idea clara cuantitativa de lo que se espera alcanzar y el tiempo en el que se quiere lograr eso. 2.17 Definir los niveles jerárquicos de una institución e identificar las personas a quienes se debe enviar la información de seguimiento, significa organizar a qué niveles de organización (u organizaciones) personas se debe enviar la información y en qué grado de detalle. Normalmente la información requerida por los altos niveles de la administración para el seguimiento de un proyecto es una porción cuidadosamente seleccionada del total de información utilizada por el nivel inferior inmediato. 2.18 Establecido el SIS de un proyecto en la forma arriba descrita, la administración de un proyecto durante la ejecución del mismo, está en condiciones de informar a las personas o niveles de una organización adecuados, sobre los eventos seleccionados (hitos) conforme estos ocurren en la forma programada o conforme ocurren problemas que impiden que éstos se alcancen en la forma programada. 2.19 Las acciones de informar se realizan utilizando los dos tipos de informes que el SIS requiere que son: Informe de Logro e Informe Alertivo. El Informe de Logro es el medio con el cual se hace saber que en cierto evento seleccionado se ha alcanzado en la cantidad, calidad y oportunidad programadas. El Informe Alertivo es el medio con el cual se informa que un cierto evento seleccionado no se ha cumplido o está a punto de no cumplirse.

- 61 X. PLAN DE EVALUACIÓN DE UN PROYECTO 2.20 Evaluar, en general, es analizar el pasado para predecir y controlar mejor el futuro. Sirve para determinar qué es lo que pasó y por qué, haciendo una comparación del desempeño real frente al planificado. 2.21 Evaluar, sin embargo, no debe ser un fin en sí mismo, sino más bien un medio con el cual se pueda influenciar decisiones y obtener información para a) tomar mejores decisiones, b) hacer mejor uso de recursos limitados para lograr el mayor impacto con el menor costo y c) asistir a los ejecutivos en la toma de decisiones apropiadas y oportunas. En proyectos, los resultados de una evaluación deben conducir a reafirmar la confianza en el diseño original de un proyecto o a cambiarlo de manera que éste pueda aumentar la probabilidad de alcanzar sus objetivos. 2.22 Para propósitos de este Manual, se entiende por evaluación de un proyecto, al proceso de comprobar si las hipótesis de un proyecto enunciadas durante la fase de su preparación son o eran válidas y si las causas seleccionadas dieron lugar a los efectos deseados. Dependiendo de si las respuestas a ambos aspectos son o no afirmativas, los resultados de una evaluación deben permitir tomar las decisiones de ratificar el proyecto en su forma original, modificarlo hasta acercarse a la alternativa con más probabilidades de éxito, o cancelarlo. 2.23 El modelo de evaluación que sugiere este Manual para un proyecto, parte del Marco Lógico de éste y pone énfasis a la comprobación del logro del Propósito. Hace esto, porque el propósito es el objetivo que justifica un proyecto y el éxito o fracaso del mismo se comprueba evaluando el cumplimiento de sus metas. Durante el proceso, este modelo de evaluación trata de determinar lo siguiente: 1. Si los insumos fueron provistos en la forma planificada, y si lo fueron, si dieron lugar realmente a la producción de los Productos planificados (y si no, ¿por qué no?). 2. El valor de los Productos logrados. 3. Si los Productos producidos, realmente hicieron posible el logro del Propósito planificado (y si no, ¿por qué no?). 4. El valor del Propósito logrado. 5. Si el logro del Propósito contribuyó (o contribuirá) al logro del Fin planificado (y si no ¿por qué no?). 6. El valor del Fin logrado. 2.24 La evaluación de un proyecto sin embargo, de acuerdo con el criterio de este Manual, no debe constituirse en un acto accidental. Su realización debe ser planificada cuidadosamente tan pronto como sea posible durante el proceso de preparación de un proyecto, para que ella, cuando se realiza sea eficiente y útil. Este Manual recomienda a los usuarios adoptar

- 62 esta modalidad de hacer la planificación de la evaluación de un proyecto, una parte integral del proceso de preparación de los proyectos. 2.25 La planificación de la evaluación de un proyecto permite generalmente: establecer los objetivos de la evaluación, identificar los factores importantes de un proyecto que resultarán necesarios para una evaluación, seleccionar los datos que deberían ser recabados para una evaluación, esquematizar cómo se presentarían los resultados de una evaluación para la toma de decisiones, y llamar la atención oportunamente acerca de las debilidades o inconsistencia en el diseño original de un proyecto. 2.26 De acuerdo con los criterios de este Manual, para preparar el plan de evaluación de un proyecto es necesario que el grupo de trabajo primero cuente con un Marco Lógico bien

elaborado y segundo siga los pasos que se describen a continuación. Antes, es necesario aclarar que si no se cuenta con dicho Marco Lógico o un documento comparable, la realización del trabajo requerido a continuación se convierte en un ejercicio fútil.

Paso 1. Determinar cuando resulta más útil la evaluación de un proyecto. 2.27 En este paso, el grupo de trabajo encargado de la preparación de un proyecto debe definir

cuando durante la vida útil de un proyecto se tendrán que tomar decisiones para las cuales sería necesario contar con los resultados de una evaluación. Algunas ideas a este respecto pueden orientar al usuario a determinar cuándo es exactamente el tiempo de evaluar un proyecto. Por Ejemplo: a) si un proyecto depende del financiamiento en base a presupuesto anual, el tiempo apropiado podría ser previo a tomar la decisión de continuar o no financiando el proyecto, b) si un proyecto se desarrolla en etapas, la oportunidad adecuada podría ser después de terminar una etapa y antes de tomar la decisión de comenzar la siguiente, c) si un proyecto pretende lograr un Producto importante, el tiempo adecuado podría ser el momento en que esto se alcanza. Finalmente, otro momento adecuado para realizar la evaluación de un proyecto podría ser aquel en que se piensa que los objetivos a nivel de Propósito y Fin estarían a punto de lograrse. 2.28 Normalmente, las columnas uno y dos del Marco Lógico y la red de desempeño del proyecto diagramada pueden ayudar grandemente al grupo de trabajo a determinar cuándo pueden ser exactamente esos momentos claves en los cuales es necesario llevar a cabo evaluaciones.

Paso 2. Definir quiénes son los que deben tomar decisiones y qué tipo de decisiones. 2.29 Para cada una de las oportunidades en las cuales se determina que es útil en una evaluación, el grupo de trabajo debe definir quiénes serían los ejecutivos (o unidades) que tendrían que tomar las decisiones en ese momento y qué tipo de decisiones tendrían que tomar. Los tipos de decisiones a los que se refiere este paso son tres básicamente: a) continuar con el proyecto como está, b) continuar con el proyecto pero modificad, o c) cancelar el proyecto.

- 63 Paso 3. Qué preguntas debe responder una evaluación. 2.30 Para que los ejecutivos puedan tomar cualquiera de las decisiones mencionadas en el paso anterior, el grupo de trabajo debe formular un listado de preguntas apropiadas a las cuales tendría que responder una evaluación. Asimismo, debe formular una lista de aquellos indicadores necesarios y suficientes que tendría que utilizar una evaluación para responder a cada una de las preguntas formuladas. El listado de preguntas como las que se mencionan a continuación, las cuales deben ser tan específicas como sea posible en relación al proyecto en estudio. a) ¿Se lograron todas las metas esperadas? (a nivel de Fin, Propósito, Productos e Insumos). b) Si no se lograron todas las metas esperadas ¿por qué no? c) ¿Cuál fue la relación entre los diferentes niveles de objetivos del proyecto? d) ¿Fueron los objetivos de un nivel inferior los responsables para el logro del objetivo u objetivos del nivel inmediatamente superior? e) ¿Fueron suficientes los Insumos provistos para producir los Productos? f)

¿Cuál fue la relación costo/beneficio para cada nivel?

g) ¿Hubieron beneficios secundarios atribuibles al proyecto? 2.31 Anticipando que las respuestas a algunas de las preguntas mencionadas podrían ser negativas, el grupo de trabajo debe también incorporar al listado algunas preguntas acerca del cumplimiento de los supuestos del proyecto en todos los niveles de éste. Normalmente, si la evaluación encuentra que algún objetivo no se ha cumplido, ello debe dar lugar al análisis de los supuestos.

Paso 4. Determinar los datos específicos que tendrá que recolectar una evaluación. 2.32 Para cada indicador y supuesto enunciado en el Marco Lógico de un proyecto que tenga importancia para una determinada evaluación, el grupo de trabajo debe seleccionar los tipos de datos que serían absolutamente necesarios recabar para que una evaluación compruebe su cumplimiento. Cualquier otro dato adicional que se deseara recabar, tendría que analizarse su conveniencia en función de su importancia, costo de obtención y de su utilidad para la toma de decisiones.

Paso 5. Determinar los métodos que se tendrían que utilizar para recolectar los datos. 2.33 El grupo de trabajo debe determinar los métodos que se tendrían que utilizar en una evaluación para recolectar los tipos de datos requeridos en los pasos anteriores. El enfoque de los métodos a utilizarse debe ser práctico, confiable y poco costoso.

Paso 6. Desarrollar un plan de análisis. 2.34 Antes de iniciar una evaluación y de recabar los datos requeridos, es esencial que el grupo de trabajo prepare un plan de análisis que especifique cuáles son los objetivos de la evaluación: qué datos se van a recabar en total y en función de qué; cómo se van a recabar;

- 64 cuál es la estrategia que se va a utilizar para llevar a cabo la evaluación y como se va a presentar la información a los ejecutivos que toman las decisiones.

Paso 7. Revisar el diseño del proyecto a la hora haber hecho el plan de evaluación. 2.35 El ejercicio de hacer el plan de evaluación debe permitir al grupo de trabajo revisar el Marco Lógico del proyecto y hacer los ajustes necesarios basados en un mayor y más profundo conocimiento del proyecto. Si por cualquier razón ya no es posible hacer los ajustes, por lo menos se debe hacer un listado de las recomendaciones que se deben implementar para mejorar el diseño del proyecto. 2.36 Habiendo seguido los pasos recién mencionados para la preparación del plan de evaluación de un proyecto, el grupo de trabajo debe esperar que cuando se produzcan las evaluaciones programadas, los resultados de estas sean presentados en las formas sugeridas en el plan de evaluación e incluyan además un capitulo de conclusiones y recomendaciones el cual puede ser conformado utilizando el instrumento denominado Diagrama de Congruencia. 2.37 Un Diagrama de Congruencia es un instrumento poderoso que permite sacar conclusiones y hacer recomendaciones acerca de un proyecto comparando sus resultados obtenidos frente a los planificados en los cuatro niveles del Marco Lógico. Ejemplos de algunas conclusiones y recomendaciones utilizando Diagramas de Congruencia se presentan en el Anexo 7. 2.38 Finalmente, cualquier evaluación de un proyecto debe ser efectuada por un grupo de profesionales preferiblemente compuesto por personas que sean empleados de la institución ejecutora y por personas que no lo sean. Esta composición mixta del equipo evaluador, responde a las recomendaciones de las mejores experiencias en el campo de evaluación ex-post de proyectos.

- 65 VIII.

PLAN DE EJECUCIÓN DE UN PROYECTO

1.90

Ejecutar significa realizar actividades para lograr resultados. En la terminología del Marco Lógico, ejecutar significa transformar Insumos en productos, es decir llevar a cabo actividades y consumir recursos para producir bienes y servicios. Un plan de ejecución es una serie programada de actividades y eventos que son necesarios para completar un proyecto. Su exhaustiva elaboración y su estricto cumplimiento en el tiempo, son condiciones necesarias para evitar problemas típicos de logro inadecuado de objetivos, desconocimiento de responsabilidades por parte del personal ejecutor, sobrecostos y retrasos en relación a lo previsto.

1.91

El Plan de ejecución de un proyecto se deriva directamente de su Marco Lógico final elaborado. Las actividades listadas en la columna de Resumen Narrativo a nivel de Insumos juntamente con los indicadores Objetivamente Verificables a nivel de Productos se convierte en los elementos básicos con los cuales se alimentan a los instrumentos que sirven para elaborar el plan de ejecución de un proyecto. Se recomienda a los usuarios de este Manual adoptar este sistema para la preparación de los planes de ejecución de proyectos.

1.92

Preparar el plan de ejecución de un proyecto, tal como puede observarse con un ejemplo práctico completo en el Anexo 5, consiste en hacer lo siguiente: a) Diagramar la red de desempeño, b) Hacer el cálculo de la red de desempeño, c) Encontrar el Camino Crítico, d) Preparar el Cuadro Gantt y, e) Preparar el Cuadro de responsabilidades. Cada una de estas tareas se explica a continuación:

a) Diagramar la red de desempeño. 1.93

Una red de desempeño es un diagrama que representa las actividades y eventos necesarios para completar un proyecto. Las actividades están organizadas de manera que muestran la secuencia en que se realizan

y su interdependencia. Los eventos son

objetivos intermedios que representan actividades terminadas. 1.94

A diferencia de las redes que conforman métodos tradicionales como el CPM o PERT , que están orientadas principalmente a las actividades de un proyecto, las redes de desempeño se concentran fundamentalmente en resultados, señalando claramente en la red, en términos de cantidad, calidad y oportunidad, todos aquellos eventos importantes (hitos) que deben ser logrados por un proyecto.

1.95

La diagramación de una red de desempeño surge directamente del Marco Lógico. De la casilla de Insumos, se extrae el listado de las actividades que son necesarias para lograr los Productos de un proyecto. Normalmente, estas actividades están listadas en la

- 66 secuencia lógica en que ellas deben ocurrir y por grupos en función del Producto respectivo que se quiere lograr. El grado de desagregación depende del tamaño de un proyecto, de su complejidad y del grado de control que se quiera tener de la ejecución del mismo. 1.96

Estas actividades se las organiza de acuerdo con los requerimientos metodológicos del Método del Camino Crítico y luego se diseña la red para cada uno de los Productos de un proyecto por separado. Las redes individuales de cada Producto posteriormente se combinan para formar una sola red que representa el proyecto en su totalidad.

1.97

Una vez diseñada la red de desempeño del proyecto, se procede a señalar con indicadores de desempeño aquellos eventos (hitos) a los cuales se quiere hacer seguimiento. Los indicadores de desempeño especifican las metas de los eventos claves que se quieren lograr en términos de cantidad, calidad y tiempo.

b) Hacer el cálculo de la red de desempeño 1.98

Hecho el diagrama de la red de desempeño, es necesario calcular la duración de un proyecto. Para ello, se debe estimar el tiempo que se necesita para completar cada actividad. Los tiempos estimados se los debe registrar, entre paréntesis, debajo del vector que identifica cada actividad en la red de desempeño.

c) Encontrar el Camino Crítico 1.99

El Camino Crítico es el recorrido de una red que representa la secuencia más larga de actividades y eventos conectados, que determinan el tiempo mínimo necesario para completar un proyecto.

2.00

Para encontrar el Camino Crítico en la red de desempeño de un proyecto se suman los tiempos necesarios para completar cada una de las actividades de cada recorrido de la red. El recorrido de la red que toma el tiempo más largo hasta completar un proyecto, representa el Camino Crítico de la red de desempeño de un proyecto.

2.01

Las actividades y eventos que se encuentran en el recorrido del Camino Crítico de la red deben ser observados cuidadosamente durante la etapa de ejecución de un proyecto, ya que ellas al no tener ninguna holgura no pueden retrasarse. Un retraso en una de ellas determina un retraso en la determinación de un proyecto en su conjunto.

d) Preparar el cuadro Gantt 2.02

El Cuadro Gantt es un instrumento gerencial que facilita el planteamiento y la administración de las actividades y recursos relacionados con un proyecto. El cuadro Gantt permite al director o gerente de un proyecto asignar recursos disponibles y comparar los progresos alcanzados, con las actividades planeadas. El cuadro Gantt se deriva fácilmente del diagrama de la red de desempeño de un proyecto y tiene la ventaja de ser un instrumento de comunicación más sencillo para aquellos que no manejan adecuadamente el sistema de redes de desempeño.

- 67 2.03

El cuadro Gantt ofrece un calendario indicativo de las fechas en que debe llevarse a cabo cada actividad de un proyecto. Cada actividad se encuentra representada por un segmento paralelo a la escala que representa el tiempo. La longitud del segmento es proporcional a la duración de la actividad. La posición del segmento a lo largo del eje que representa el tiempo, indica el comienzo y el final de la actividad.

e) Preparar el Cuadro de Responsabilidades 2.04

Este cuadro

es muy sencillo de preparar una vez que se tienen determinadas las

actividades que un proyecto debe realizar y los tiempos de duración de cada actividad. En realidad, es el mismo Cuadro Gantt al cual se le añade una columna. En esa columna se registran los nombres de las personas o de las unidades de una institución que tienen la responsabilidad específica por la realización de cada una de las actividades programadas de un proyecto. 2.05

Asimismo, se añade al Cuadro Gantt una línea por debajo de cada actividad programada, la cual se utiliza posteriormente para registrar mediante segmentos los progresos reales alcanzados en la ejecución de un proyecto y compararlos con aquellos programados.

- 68 PROYECTO PLANTA DESHIDRATADORA DE FRUTAS EJEMPLOS DE DIAGRAMAS DE CONGRUENCIA DE UNA EVALUACIÓN LLEVADA A CABO AL FINAL DEL TERCER AÑO DEL PROYECTO

RESULTADOS OBTENIDOS F

METAS PLANIFICADAS ▬ 470

beneficiarios

CONCLUSIONES

aumentan

ingresos en $us. 648 c/u. Pp

TM. fruta seca. 0%

50%

100%

beneficiarios

aumentan

TM. fruta seca. 0%

50%

100%

beneficiarios

aumentan

TM.

100%

beneficiarios

aumentan

fruta seca. 50%

100%

Analizar

supuestos

nivel de Producto. ▬

Continuar Proyecto.

▬

Modificar presupuesto y continuar Proyecto.

se debe a alguna causa ajena ▬ Rendimientos

fueron

▬ Se gastan $us. 516.932 en operación de la planta.

CONCLUSIONES

RECOMENDACIONES

▬ Falla gerencial o supuestos

▬ Modificar diseño, cambiar

▬ El

proyecto

logra

éxito

solamente en un 50%.

▬ Proyecto comercializa 289 TM de

▬ El proyecto logró éxito en un

erróneos a nivel de insumos.

TM.

▬

▬ Proyecto reduce pérdidas en 1719

▬ Rentabilidad por debajo de

METAS PLANIFICADAS ▬ 470

30 %

Producto - Propósito.

▬ Mala hipótesis o supuestos

operación de la planta.

ingresos en $us. 648 c/u. Pp

Modificar relación causal

estimados correctamente.

▬ Se gastan $us. 516.932 en

RESULTADOS OBTENIDOS F

▬

al Proyecto.

fruta seca. 50%

▬ El proyecto fue exitoso en un

100%. Sin embargo su éxito

▬ Proyecto comercializa 289 TM de

30 %

correctas.

ingresos en $us. 648 c/u.

80 %

bien

operación de la planta.

▬ Proyecto reduce pérdidas en 1719 Pp

fue

la planificada.

▬ Se gastan $us. 516.932 en

▬ 470 F

diseño

errados a nivel de Producto.

▬ Proyecto comercializa 289 TM de

proyecto

concebido.

75%.

▬ Proyecto reduce pérdidas en 1719

como está.

operación de la planta.

ingresos en $us. 648 c/u.

Continuar

▬ Sus relaciones causales son

▬ Se gastan $us. 516.932 en

▬ 470 F

▬

100%. ▬ Su

▬ Proyecto comercializa 289 TM de

▬ El proyecto logró con éxito todos sus objetivos en un

▬ Proyecto reduce pérdidas en 1719

RECOMENDACIONES

▬ Relación causal PropósitoFin errada.

gerente Proyecto.

continuar

- 69 -