Sistema de Manejo de Proyectos
120
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
-
Upload
marco-antonio -
Category
Documents
-
view
235 -
download
6
description
Ministerio de Agricultura Lima, Perú, 1986
Transcript of Sistema de Manejo de Proyectos
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 los
instrumentos y mecanismos de comunicación para tramitar 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.
S I S T E M A D E M A N E J O D E
P R O Y E C T O S (SMP)
UN MÉTODO INTEGRADO DE SISTEMAS PARA
LA ADMINISTRACION DEL CICLO DE UN PROYECTO
- 5 -
TABLA DE CONTENIDO
PARTE I: INTRODUCCION AL SISTEMA DE MANEJO DE PROYECTOS (SMP)
DE PRACTICAL CONCEPTS INCORPORATED .................................... 7
A. INTRODUCCION ................................................................................................... 7
B. EL CICLO DE UN PROYECTO ........................................................................... 8
C. 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
B. MARCO LOGICO ................................................................................................. 20
1. La Lógica Vertical del Marco Lógico ............................................................ 21
2. Verificación Objetiva: La Lógica Horizontal ............................................... 22
C. REDES Y PROGRAMACION ............................................................................ 23
1. Ruta Crítica ............................................................................................................ 23
2. Holgura Libre ........................................................................................................ 23
D. ADMINISTRACION DE RECURSOS ............................................................. 24
E. INFORMES DE LOGROS Y ALERTIVOS ...................................................... 26
F. 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
B. PROYECTOS EN ORGANIZACIONES FUNCIONALES .......................... 29
C. SITUACIONES EN LA ADMINISTRACION DE PROYECTOS: ............. 30
D. GERENTES DE PROYECTO .............................................................................. 31
1. Funciones ............................................................................................................... 31
2. Liderazgo ................................................................................................................ 31
E. POR QUE FRACASAN LOS PROYECTOS ................................................... 32
1. Planificación Inadecuada .................................................................................. 32
2. Control Inadecuado durante la Implementación..................................... 32
3. Seguimiento Inadecuado de parte de los Administradores de Alto
Nivel: ........................................................................................................................ 32
- 6 -
4. Ausencia en el equipo del Proyecto de Personas que se beneficiarían
de los Resultados del Proyecto. ..................................................................... 33
5. Falta de uso de la Información de Evaluación de Proyectos Similares
conduce a la Repetición de Errores. ............................................................. 33
6. Mala Conformación del Equipo de un Proyecto. ..................................... 33
7. Ausencia de un Conjunto Formalizado de Procedimientos para la
comunicación y Documentación. .................................................................. 33
8. Incompetencia del Gerente del Proyecto. .................................................. 33
PARTE IV: INFORMES Y SEGUIMIENTO – REVISION DETALLADA .............. 34
A. TODOS LOS INFORMES TIENEN UN COSTO ............................................. 35
B. ESTRUCTURA BASICA DE UNA ORGANIZACIÓN .................................... 36
C. LAS REDES DE ADMINISTRACION SUPERIOR RESUMEN LA
INFORMACION MAS DETALLADA DE LOS NIVELES INFERIORES ...... 39
F. EJEMPLO DEL FORMATO DE UN INFORME ALERTIVO ......................... 41
G. INFORMES DE LOGRO ....................................................................................... 44
H. EJEMPLO DEL FORMATO DEL INFORME DE LOGRO ............................. 44
I. TABLEROS INFORMATIVOS PARA HACER SEGUIMIENTO DE LA
SITUACION DE UN PROYECTO ....................................................................... 47
- 7 -
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 un 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.
- 8 -
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.
- 9 -
2. EJECUCIÓN
1. DISEÑO
3. EVALUACIÓN
OBJETIVOS
LOGRADOS
EN EL
PROYECTO
Gráfico 1-1
EL CICLO DE UN 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 re-
diseño, seguido de una ejecución mejorada hasta que se logren los objetivos del
proyecto.
- 10 -
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.
- 11 -
2. EJECUCIÓN
1. DISEÑO
3. EVALUACIÓN OBJETIVOS
LOGRADOS
EN EL
PROYECTO
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
SISTEMA DE EVALUACIÓN SISTEMA DE INFORMES
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.
LÓGICO
ALERTIVO
- 12 -
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 a profundos cambios en la perspectiva de los organizadores y
administradores. Por ejemplo, las bibliotecas eran tradicionalmente organizadas
alrededor del concepto central de que la biblioteca era un almacén o repositorio de
- 13 -
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.
- 14 -
Cuadro II - 1
CARACTERÍSTICAS DE OPERACIONES Y PROYECTOS
CARACTERÍSTICAS OPERACIONES PROYECTOS
Orientación o Estilo Tasas de producción fijas o
variables
Investigación, desarrollo,
experimentación,
actividades únicas,
construcciones de nuevas
aplicaciones de
tecnología
Diseño Optimización de la
eficiencia mediante
acciones repetitivas
simplificadas (cronograma
de barras)
Pasos, acciones y tiempos
lógicamente
dependientes y
organizados para un
propósito limitado (redes)
Informes Informes periódicos,
tiempo,, materiales, mano
de obra, fondos
empleados, inventarios,
producción
Regulares: Logro o
realización de actividades,
prevenciones, cambios en
condiciones,
recapitulaciones y
revisiones
Presupuestación Por unidad y sub-unidad
organizacional
Por pasos, metas y
actividades específicas
lógicas
Contabilidad Flujos de dinero en
efectivo, inversiones de
capital, proporción de
créditos, determinación de
costos
Centros para costos: uso
regular de recursos
Criterios de Éxito Pérdidas o ganancias,
ventas, unidades de trabajo
cumplidas
Logro de un fin global en
base a medidas
independientes.
- 15 -
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.
- 16 -
Cuadro II - 2
PROCESOS ADMINISTRATIVOS APLICADOS
A OPERACIONES Y PROYECTOS
PROCESOS OPERACIONES PROYECTOS
Aprobación Concedido anualmente
para el funcionamiento
continuado con posibles
modificaciones. Diferentes
grupos de aprobación, para
diferentes aspectos
Concedido una sola vez en
base al diseño total de
pasos lógicos conectados
hacia el logro del
propósito, una sola
institución de aprobación
Control y Revisión Examen periódico y
evaluación del desempeño
Predeterminados por el
diseño del proyecto como
el indicador de eventos
mayores
Fondos Flujo regular establecido en
base al nivel de
operaciones.
Programados en el diseño
del proyecto al momento
de su aprobación.
Informes Periódicos calculados en
tiempo para reflejar el uso
regular de los recursos y el
desempeño
Programados en el diseño
del proyecto, muestran el
logro de metas o alertan
toda vez que se amenaza al
desempeño
Evaluación Por lo general sigue el
resumen anual para la
renovación de la
aprobación
Evaluación para factibilidad
previa a la aprobación y
programada en el diseño
para eventos críticos a fin
de asegurar que se haga
frente a problemas
Administración de recursos Procedimientos generales
contables e informes.
Asignación de recursos de
acuerdo a la realización de
actividades en base a pasos
de desempeño diseñados
previamente
- 17 -
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 acá en términos de los siguientes
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
- 18 -
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. El
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
- 19 -
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*.
- 20 -
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.
- 21 -
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.
- 22 -
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 la naturaleza del evento en 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.
- 23 -
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
- 24 -
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
- 25 -
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
- 26 -
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.
- 27 -
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 la
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.
- 28 -
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 detrás de estos términos no son nuevas. Las empresas del
sector 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.
- 29 -
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, el siguiente modelo ilustra cómo un
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.
A
C
D
A B
C
D
E
F
- 30 -
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.
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.
B. 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.
A B
C
D
E
F
PROYECTO 1
PROYECTO 2
PROYECTO 3
PROYECTO 5
PROYECTO 4
PROYECTO 6
- 31 -
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;
b. Elaborar un plan general de trabajo;
c. Seleccionar participantes y delegar responsabilidades;
d. Revisar los planes detallados de los participantes;
e. Establecer un sistema de vigilancia e informes;
f. Comunicar los planes detallados a los gerentes senior y determinar sus
requerimientos de información;
g. Implementar, vigilar y controlar;
h. 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.
- 32 -
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:
1. Planificación Inadecuada
a. Las estimaciones de tiempo para actividades no fueron establecidas
por los individuos responsables de llevar a cabo las operaciones.
b. Las estimaciones de costo no toman en cuenta las tendencias
inflacionarias y del mercado.
c. Todas las actividades necesarias o las limitaciones no fueron
anticipadas durante la fase de planificación.
d. Fueron ignorados factores externos (limitaciones y supuestos) que
eran probables y críticos y que deberían haber impedido llevar a cabo
la iniciativa.
e. La relación causal entre insumos, productos, productos y propósitos
no fue lógica; no se realizo ningún estudio de factibilidad.
2. Control Inadecuado durante la Implementación
a. Seguimiento irregular y toma de decisiones lenta.
b. Falta de flexibilidad en el plan del proyecto.
c. Comunicación inadecuada de los problemas a los participantes.
3. Seguimiento Inadecuado de parte de los Administradores de Alto Nivel:
a. Falta de habilidad para comprender los planes iniciales.
b. La falta de habilidad para identificar fechas claves, conduce a un
seguimiento irregular y a cambio en los planes.
- 33 -
4. Ausencia en el equipo del Proyecto de Personas que se beneficiarían de
los Resultados del Proyecto.
5. Falta de uso de la Información de Evaluación de Proyectos Similares
conduce a la Repetición de Errores.
6. Mala Conformación del Equipo de un Proyecto.
a. La capacidad de los participantes está por debajo de los estándares
requeridos.
b. Falta de capacidad de los participantes para trabajar juntos.
c. Los miembros del equipo cambian durante el proyecto.
7. Ausencia de un Conjunto Formalizado de Procedimientos para la
comunicación y Documentación.
8. Incompetencia del Gerente del Proyecto.
a. Falta de entrenamiento en administración
b. Falta de habilidad para controlar y motivar a los empleados sin tener
autoridad formal.
- 34 -
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
- 35 -
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.
- 36 -
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”.
- 37 -
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
Construcción Centro
de Entrenamiento
PRODUCTO 2
Entrenamiento de
Agentes Extens.
PRODUCTO 3
Inscripción de
Agricultores
PRODUCTO 4
Provisión Insumos y
A.B. a Agricultores
- 38 -
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.
- 39 -
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
- 40 -
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.
- 41 -
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.
- 42 -
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.
- 43 -
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.
- 44 -
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.
- 45 -
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.
- 46 -
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.
- 47 -
I. 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.
- 48 -
Gráfico IV – 7
TABLEROS INFORMATIVOS PARA HACER SEGUIMIENTO DE LA SITUACION DEL
PROYECTO
TABLERO RESUMEN DE LA TABLERO DE ACCION
SITUACION DEL PROYECTO
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
1. La planificación era demasiado imprecisa: ..................................... 1
2. La responsabilidad de la gerencia no era clara:............................. 1
3. 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
1. Jerarquía de los Objetivos del Proyecto .......................................... 8
2. Hipótesis en Cadena .............................................................................. 9
3. Supuestos ............................................................................................... 11
4. Indicadores Objetivamente Verificables ........................................ 16
a. Los Indicadores Miden lo que es Importante .............................. 19
b. Los Indicadores Deben ser Evidenciables...................................... 19
c. Los Indicadores Deben ser Especificados ...................................... 21
d. Los Indicadores son Independientes .............................................. 22
5. Medios de Verificación ....................................................................... 24
6. Esfera de Control .................................................................................. 26
a. Error en la Lógica .................................................................................. 27
b. Delegación de la Responsabilidad de Obtener Productos ....... 28
B. ELABORACION DEL DISEÑO DE UN PROYECTO ......................... 31
C. 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
1. El Convenio ............................................................................................ 42
2. Productos Específicos a ser Entregados ....................................... 43
3. Reciprocidad .......................................................................................... 43
4. 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.
1. 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.
2. 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;
2. Estableciendo claramente aquello de lo que el gerente del proyecto es responsable
de lograr y porqué;
3. Mostrando los elementos claves del proyecto y sus relaciones entre sí, de manera
que se facilite el análisis del proyecto;
4. 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:
RESUMEN NARRATIVO INDICADORES OBJETIVAMENTE VERIFICABLES MEDIOS DE VERIFICACIÓN SUPUESTOS IMPORTANTES
Fin del Programa: Objetivo Final
Medidas del logro del Propósito Relacionadas con el valor a largo plazo
del programa/proyecto
HIP
ÓTESIS
DE D
ESA
RR
OLLO
Si exi
ste
el Pro
pósito,
ento
nces e
l Fin
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.
Si exi
ste
n los P
roducto
s,
ento
nces e
l Pro
posito
Productos: Objetivos Específicos
Cantidades de los Productos Específicos que son
necesarias y suficientes para alcanzar el Propósito
Que afectan el enlace Producto-
Propósito.
AR
EA
DE A
CC
IÓN
Si exi
ste
n los Insum
os,
ento
nces los P
roducto
s
Insumos: Actividades
Nivel de esfuerzo/gasto por actividad. Que afectan el enlace Insumo-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.
A. 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 de diferentes puntos de 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.
1. 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.
2. 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.
2. Si se producen los Productos, ENTONCES se logra el Propósito.
3. Si se logra el Propósito, ENTONCES ello contribuirá al logro del Fin.
- 10 -
FIN
PROPÓSITO
PRODUCTOS
INSUMOS
Esto puede ser visto gráficamente de la siguiente manera:
SI PROPOSITO, ENTONCES FIN
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:
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.
FIN
SUPUESTOS
PROPÓSITO
PRODUCTOS
INSUMOS
SUPUESTOS
SUPUESTOS
Y
Y
Y
- 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 INDICADORES OBJETIVAMENTE VERIFICABLES MEDIOS DE VERIFICACIÓN SUPUESTOS IMPORTANTES
Fin del Programa: El Objetivo más amplio al
que contribuye el Proyecto
Incremento en el Ingreso a Agricultores
Medidas del logro del Fin Relacionadas con importancia a largo
plazo del programa/proyecto
HIP
ÓTESIS
DE D
ESA
RR
OLLO
Si exi
ste
el Pro
pósito,
ento
nces e
l Fin
Propósito del Proyecto:
Incremento en la Producción
Indicadores del logro del Propósito: Situación final del
Proyecto.
Que afectan el enlace Propósito-Fin
1. Precios permanecen estables.
2. Facilidades de Transporte
adecuadas.
3. Facilidades de almacenamiento
disponibles.
Si exi
ste
n los P
roducto
s,
ento
nces e
l Pro
posito
Productos
1. Sistema de distribución de fertilizantes y
semilla de alto rendimiento (HUV) listo.
2. Agricultores entrenados.
3. Sistema crediticio listo.
Dimensión de Productos necesarios y suficientes para
lograr el Propósito.
Que afectan el enlace Producto-
Propósito:
1. Uso del fertilizante cuando se lo
requiere.
2. Precipitación pluvial adecuada.
(Supuesto mejorado: Habrá una
precipitación pluvial de 10 pulgadas
entre mayo y octubre de cada año).
AR
EA
DE A
CC
IÓN
Si exi
ste
n los Insum
os,
ento
nces los P
roducto
s
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.
Nivel de esfuerzo/gasto por actividad. Que afectan el enlace Insumo-Producto.
1. Agricultores son receptivos a los
nuevos métodos.
2. 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.
---------------Y
--------------------->
1. Cliente aprueba
versión final del
contrato.
Insumos.
1. Levantarse a tiempo
para tomar el autobús
---------------Y
--------------------->
1. Autobús está en
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.
2. 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 y
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 un 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 MEDIOS DE VERIFICACIÓN SUPUESTOS IMPORTANTES
Fin del Programa: El Objetivo más amplio al que
contribuye el Proyecto
Incremento en el Ingreso a Agricultores en la región
del Noroeste
Medidas del logro del Fin
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.
Relacionadas con importancia a largo plazo del
programa/proyecto
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.
HIP
ÓTESIS
DE D
ESA
RRO
LLO
Si exi
ste
el Pro
pósito,
ento
nces e
l Fin
Propósito del Proyecto:
Incremento de la Producción de arroz de los
pequeños agricultores de la región Noroeste.
Indicadores del logro del Propósito: Situación final del Proyecto.
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.
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.
Si exi
ste
n los P
roducto
s,
ento
nces e
l Pro
pósito
Productos
1. Sistema de distribución de fertilizantes y arroz
de alto rendimiento, en sitio funcionando.
2. Agricultores entrenados.
3. Sistema crediticio en sitio funcionando.
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:
1. Los agentes extensionistas supervisan
correctamente el uso de fertilizantes por los
agricultores.
2. Hay una precipitación pluvial de 10 pulgadas
entre mayo y octubre de cada año.
3. 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.
AREA D
E A
CC
IÓN
Si exi
ste
n los Insum
os,
ento
nces los P
roducto
s
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.
Nivel de esfuerzo/gasto por actividad.
1a. 6 meses/hombre $b. 15,000 600,000
b. 12 meses/hombre “ 1,600,000 900,000
c. 36 meses/hombre “ 150,000 1,200,000
2 24 meses/hombre “ 100,000 100,000
24 meses/hombre “ 200,000
3 36 meses/hombre “ 150,000 .
TOTALES $. otra moneda ………
Que afectan el enlace Insumo-Producto.
2. Los agricultores están dispuestos a aceptar
nuevos métodos de cultivo.
3. Los precios de fertilizantes no exceden de $.
_____ por tonelada.
4. 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).
d. 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
2.000 nuevas viviendas para familias, adquiridas
por residentes agricultores de bajos ingresos
hasta junio de 1980.
Medios de Verificación
Los registros de ventas de las oficinas
de vivienda, número de ventas y
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: Métodos modernos de
cultivo usados por los agricultores.
Propósito es el resultado de los productos.
Propósito: Incremento en la producción
agrícola de los agricultores.
Productos
1. Fertilizante usado por los agricultores.
2. Semilla de alto rendimiento plantada por agricultores.
3. Pesticidas usados por agricultores.
4. Fungicidas usados por agricultores.
5. 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 -
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 MEDIOS DE VERIFICACIÓN SUPUESTOS IMPORTANTES
Fin del Programa: El Objetivo más amplio al que
contribuye el Proyecto
Incremento en el Ingreso a Agricultores en la región
del Noroeste
Medidas del logro del Fin
1. Ingreso de los agricultores promedio incrementado de
$100/año en 1976 a $150/año en 1978.
2. 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.
2a. Igual que en 1.
Relacionadas con importancia a largo plazo del
programa/proyecto
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.
HIP
ÓTESIS
DE D
ESA
RRO
LLO
Si exi
ste
el Pro
pósito,
ento
nces e
l Fin
Propósito del Proyecto:
Incremento de la Producción de arroz de los
pequeños agricultores de la región Noroeste.
Indicadores del logro del Propósito: Situación final del Proyecto.
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.
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 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.
Si exi
ste
n los P
roducto
s,
ento
nces e
l Pro
pósito
Productos
1. Sistema de distribución de fertilizantes y arroz
de alto rendimiento, en sitio funcionando.
2. Agricultores entrenados.
3. Sistema crediticio en sitio funcionando.
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.
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.
Que afectan el enlace Producto-Propósito:
1. Los agentes extensionistas supervisan
correctamente el uso de fertilizantes por los
agricultores.
2. Hay una precipitación pluvial de 10 pulgadas
entre mayo y octubre de cada año.
3. 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.
AREA D
E A
CC
IÓN
Si exi
ste
n los Insum
os,
ento
nces los P
roducto
s
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.
Nivel de esfuerzo/gasto por actividad.
1a. 6 meses/hombre $b. 15,000 600,000
b. 12 meses/hombre “ 1,600,000 900,000
c. 36 meses/hombre “ 150,000 1,200,000
2 24 meses/hombre “ 100,000 100,000
24 meses/hombre “ 200,000
3 36 meses/hombre “ 150,000 .
TOTALES $. otra moneda ……………
1a. Registros del gerente del Proyecto.
b. Registros e informes de los
subcontratistas.
c. Informes del gerente del Proyecto.
Que afectan el enlace Insumo-Producto.
1. Los agricultores están dispuestos a aceptar
nuevos métodos de cultivo.
2. Los precios de fertilizantes no exceden de $.
_____ por tonelada.
3. Se puede reclutar localmente 150 agentes
agrícolas extensionistas.
- 31 -
B. 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
Propósito
Producto1
Producto2
Producto3
Insumos
PROYECTO ML
Fin
Propósito
Producto1
Producto2
Producto3
Insumos
PRODUCTO ML
Fin
Propósito
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
RESPONSABILIDAD
FIN
PROPÓSITO
PRODUCTOS
1.
2.
3.
4.
INSUMOS
PRODUCTO 1 PRODUCTO 3
1. Oficinas y Centros de Entrenamiento
Construidos
3. Pequeños Agricultores Inscritos
INSUMOS
1a. Preparar Planes de Construcción
1b. Solicitar Propuestas Construcción
1c. Supervisar Construcción
ASESOR
CONTRATISTA
INSUMOS
3a. Preparar material publicitario.
3b. Inscribir a interesados.
PRODUCTO 2 PRODUCTO 4
2. Agentes Extensionistas Entrenados 4. Insumos y Ayuda Proporcionados a los
Agricultores
INSUMOS
2a. Reclutamiento Agentes Extensionistas
2b. Preparar Programa Entrenamiento
2c. Entrenar y Poner a Prueba a los Agentes
MINISTERIO DE
AGRICULTURA
MINISTERIO DE
COOPERATIVAS
INSUMOS
4a. Concretar Requerimientos de Insumos.
4b. Obtener los Insumos.
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 CONEXIÓN TÓPICOS DE LA GERENCIA
Formulación Explícita Porqué tiene este proyecto
del Fin mayor prioridad que los pro-
yectos que no tienen apoyo
(Programación)
Si Propósito ¿Cómo podemos mejorar
entonces Fin nuestra confianza de que
llegaremos al Fin?
Condiciones que se esperan Qué esperamos lograr con
al terminar el Proyecto este Proyecto, (Programa-
ción y Diseño del Proyecto)
Si Productos ¿Cómo podemos incrementar
entonces Propósito nuestra confianza en que el
Propósito será logrado?
Producto ¿Qué se puede esperar que
Esperado razonablemente produzca un
gerente competente. (Diseño
del Proyecto)
Si Insumos ¿Cómo podemos incrementar
entonces Productos la eficiencia, lograr más
productos de insumos
comparables?
Prespuesto y ¿Qué insumos se requieren?
Cronograma ¿Cuándo? (Presupuestación y
Control)
FIN DEL
PROGRAMA
FIN DEL
PROGRAMA
FIN DEL
PROGRAMA
FIN DEL
PROGRAMA
- 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.
C. 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
INSUMOS
SUPUESTOS
SUPUESTOS
Y
Y
Y
- 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
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.
A3
A1
A5 A4
A2
A8
A7
A6 A9
C1 B1
HIPÓTESIS DEL PROYECTO
- 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, A1 hasta
A9, es necesario y suficiente para causar B1 y B4. B1 es una causa necesaria y suficiente de B2 y
B3, que juntamente con B4 son causas necesarias y suficientes de C1.
Gráfico A – 3
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”.
A3
A1
A
5 A4
A2
A8
A7
A6 A9
C1 B1
B2
B3
B4
- 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
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.
El convenio entre las partes
(país anfitrión, patrocinador
o “cliente” y contratista)
Opinión compartida entre
Anfitrión y Auspiciador
Opinión compartida entre
Patrocinador país anfitrión y el
contratista
Objetivo Nacional
responsabilidad del anfitrión
Responsabilidad del
patrocinador ante el anfitrión:
“regla razonable” para el
contratista
Esfera de Control
Responsabilidad del Contratista
Obligaciones mutuas,
patrocinador y contratista
Establece actividades, recursos y
consideración.
FIN
PROPÓSITO
PRODUCTOS
INSUMOS
- 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.
1. Ganancias netas para miembros de la
cooperativa.
2. 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 y
comercialización de la uva por los miembros de
la cooperativa.
1. Beneficios de la Producción.
2. Beneficios adicionales de la operación de
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
que se necesitan.
2. Vivero establecido.
3. Viñedos establecidos.
4. Agricultores adiestrados
5. Estudios hechos.
1. Venta de insumos
2. Producción de vid.
3. Uvas producidas.
4. Agricultores adiestrados
5. Estudios
ACTIVIDADES
Establecer la cooperativa.
1.1 Adiestrar a los agricultores
1.2 Etc.
Establecer el vivero
2.1 Etc.
2.2 Etc.
2.3 Etc.
1.1 Seis meses-hombres: $3.000
1.2 Etc.
4.1 Doce meses-hombres:$36.000 +
$100.000 = $136.000
4.2 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 socio-
econó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:
RESUMEN NARRATIVO INDICADORES OBJETIVAMENTE VERIFICABLES MEDIOS DE VERIFICACIÓN SUPUESTOS IMPORTANTES
Fin del Programa: Objetivo Final
Medidas del logro del Propósito Relacionadas con el valor a largo
plazo del programa/proyecto
HIP
ÓTESIS
DE D
ESA
RR
OLLO
Si exi
ste
el Pro
pósito,
ento
nces e
l Fin
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.
Si exi
ste
n los P
roducto
s,
ento
nces e
l Pro
posito
Productos: Objetivos Específicos
Cantidades de los Productos Específicos que
son necesarias y suficientes para alcanzar el
Propósito
Que afectan el enlace Producto-
Propósito.
AR
EA
DE A
CC
IÓN
Si exi
ste
n los Insum
os,
ento
nces los P
roducto
s
Insumos: Actividades
Nivel de esfuerzo/gasto por actividad. Que afectan el enlace Insumo-
Producto.
- 53 -
PROYECTO PLANTA DESHIDRATADORA DE FRUTAS
DIAGRAMA 6. EJEMPLAR DE MARCO LÓGICO TERMINADO
MARCO LÓGICO
Fecha estimada de terminación del Proyecto: Noviembre de 1984
Fecha de este Resumen: Febrero de 1983
Marco Lógico de: PLANTA DESHIDRATADORA DE FRUTAS
RESUMEN NARRATIVO INDICADORES OBJETIVAMENTE VERIFICABLES MEDIOS DE VERIFICACIÓN SUPUESTOS IMPORTANTES
Fin del Programa: El Objetivo más amplio al que contribuye el
Proyecto.
Mejorar los ingresos de los fruticultores del Valle de Cinti.
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.
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.
- Encuestas anuales realizadas en la zona del
proyecto por extensionistas de CORDECH.
Relacionadas con importancia a largo plazo del
programa/proyecto
HIP
ÓTESIS
DE D
ESARRO
LLO
Si exi
ste
el Pro
pósito,
ento
nces e
l 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.
Indicadores del logro del propósito: Situación final – Del Proyecto.
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.
(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.
- Registros de compra de fruta fresca de la
planta.
Que afectan el enlace Propósito-Fin.
- Los precios de venta de la fruta seca continúan
permitiendo operar la planta en forma viable desde
el punto de vista financiero.
Si exi
ste
n los P
roducto
s,
ento
nces e
l Pro
posito
Productos:
1. Planta Deshidratadora funcionando.
2. Comercialización de fruta efectuada.
Dimensión de productos necesarios para lograr el propósito
FALTA CUADRO
1. Inspección de planta en periodo de iniciación de
operaciones.
2. Registros de ventas de la planta.
Que afectan el enlace Producto-Propósito.
- 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.
AREA D
E
AC
CIÓ
N
Si exi
ste
n los
Insum
os,
ento
nces los
Pro
ducto
s
Insumos: Actividades
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.
2. a. Almacenar producción
b. Transportar producción
c. Distribuir producción
Nivel de esfuerzo/gasto para cada actividad
FALTA CUADRO
(%)
Mater.
- Registros de control presupuestal y de costos.
Que afectan el enlace Insumo-Producto.
1. Los fruticultores son receptivos ala formación de
sociedad.
2. 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 ACTIVIDAD
PRECEDENTE
ACTIVIDADES QUE DEBEN
HABER TERMINADO
a. Reformular estudio
b. Revisar y aprobar estudio
c. Constituir sociedad
d. Gestionar financiamiento
e. Realizar obras civiles
f. Equipar planta
g. Contratar personal
h. Adquirir insumos
i. Realizar pruebas
j. Iniciar Operaciones
-
a
b
b
d
e
f
g
h
i
-
a
a b
a b c
a b c d
a b c d e
a b c d e f
a b c d e f g
a b c d e f g h
a b c d e f g h i
2. HACER EL CÁLCULO DE LA RED DE DESEMPEÑO
3. ENCONTRAR EL CAMINO CRÍTICO
4. PREPARAR EL DIAGRAMA DE GANTT
MESES
ACTIVIDADES
ENE ENE ENE
83 84 85
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
0
a. Reformular estudio 1
b. Revisar y aprobar estudio 1
c. Constituir sociedad 4
d. Gestionar financiamiento 5
e. Realizar obras civiles 6
f. Equipar planta 5
g. Contratar personal 1
h. Adquirir insumos 1
i. Realizar pruebas 1
j. Iniciar Operaciones 3
RECURSOS REQUERIDOS
RECURSOS DISPONIBLES
1
1
a b c
d
e f g h
i j
2 3
<
4
<
6
<
7
<
8 9
11
5
<
10
1
<
a b c
d e f g h
i j
(4)
(5) (6) (5)
(1) (1) (1) (1)
(1) (3)
2 3
<
4
<
6
<
7
<
8 9
11
5
<
10
1
<
2
2
7
7 13
13
16
16 19
19
20
20
20
20 20 22
22
(4)
(5) (6) (5)
(1) (1) (1) (1)
(1) (3)
a b c
e f g h
i j
d 2 3
<
4
<
6
<
7
<
8 9
11
5
<
10
1
<
- 55 -
5. PREPARAR CUADRO DE RESPONSABILIDADES
MESES
ACTIVIDADES
ENE ENE
83 84 RESPONSABILIDADES
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
a. Reformular estudio
P
E
Jefe Proyecto…
Dpto. Planif..
FALTA CUADRO
b. Revisar y aprobar estudio P
E
Pdte. Gerente General
Directorio …
c. Constituir sociedad
P
E
Gerencia Legal…
FALTA CUADRO
d. Gestionar financiamiento P
E
FALTA CUADRO ……
e. Realizar obras civiles P
E
Gerente Proyecto
Contratista
f. 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
i. Realizar pruebas P
E
Gerente Proyecto
Técnico Producción
j. 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.
- 56 -
(4)
(5) (6) (5)
(1) (1)
(1) (1)
(1) (3)
a b c
e f g h
i j
d 2 3
<
4
<
6
<
7
<
8 9
11
5
<
10
1
<
3<
7
<
8
10
1
<
5 6
11
2
9
1
<
11
2
9
1
<
5
11
2
9
1
<
11
2
ANEXO 6
PROYECTO PLANTA DESHIDRATADORA DE FRUTAS
SISTEMA DE INFORMACIÓN PARA SEGUIMIENTO
1.
INFORMAR A LOS
DISTINTOS NIVELES
NIVEL III
GERENTE GRAL.
DE CORDECH
NIVEL II
GERENTE DE
DEPARTAMENTO
DE CORDECH
NIVEL I
JEFE DE DIVISIÓN
DE CORDECH
2.
DEFINIR LOS
EVENTOS
DE IMPORTANCIA
SELECCIONADOS
3.
SELECCIONAR EVENTOS
DE IMPORTANCIA (Hitos)
QUE SE ENCUENTRAN EN
EL CAMINO CRÍTICO
EJECUCIÓN
ESTUDIO DE FACTI-BILIDAD
SE TERMINA DE FORMU-LAR EL 31 DE ENERO
DE 1985
LAS OBRAS CIVI- LES SE TERMINAN DE CONSTRUIR EN
ENERO 31 DE 1984
EL EQUIPO DE LA PLANTA
SE INSTALA HASTA JUNIO
30 DE 1984
LAS PRUEBAS DEL FUNCIONA-
MIENTO DE LA PLANTA SE CON-CLUYEN EN JULIO
31 DE 1984
LA FASE DE PRUEBA A PLENA
CAPACIDAD DE LA PLANTA CONCLUYE EN NOVIEMBRE 30
DE 1984
- 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: - 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.
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
F
Pp
Pd
I
RESULTADOS OBTENIDOS
0% 50% 100%
METAS PLANIFICADAS
▬ 470 beneficiarios aumentan
ingresos en $us. 648 c/u.
▬ Proyecto reduce pérdidas en 1719
TM.
▬ Proyecto comercializa 289 TM de
fruta seca.
▬ Se gastan $us. 516.932 en la
operación de la planta.
CONCLUSIONES
▬ El proyecto logró con éxito
todos sus objetivos en un
100%.
▬ Su diseño fue bien
concebido.
▬ Sus relaciones causales son
correctas.
RECOMENDACIONES
▬ Continuar el proyecto
como está.
F
Pp
Pd
I
0% 50% 100%
▬ 470 beneficiarios aumentan
ingresos en $us. 648 c/u.
▬ Proyecto reduce pérdidas en 1719
TM.
▬ Proyecto comercializa 289 TM de
fruta seca.
▬ Se gastan $us. 516.932 en la
operación de la planta.
▬ El proyecto fue exitoso en un
75%.
▬ Mala hipótesis o supuestos
errados a nivel de Producto.
▬ Rentabilidad por debajo de
la planificada.
▬ Modificar relación causal
Producto - Propósito.
▬ Analizar supuestos a
nivel de Producto.
▬ Continuar Proyecto.
F
Pp
Pd
I
80 %
30 %
0% 50% 100%
▬ 470 beneficiarios aumentan
ingresos en $us. 648 c/u.
▬ Proyecto reduce pérdidas en 1719
TM.
▬ Proyecto comercializa 289 TM de
fruta seca.
▬ Se gastan $us. 516.932 en la
operación de la planta.
▬ El proyecto logró éxito en un
100%. Sin embargo su éxito
se debe a alguna causa ajena
al Proyecto.
▬ Rendimientos no fueron
estimados correctamente.
▬ Modificar presupuesto y
continuar Proyecto.
F
Pp
Pd
I
RESULTADOS OBTENIDOS
30 %
0% 50% 100%
METAS PLANIFICADAS
▬ 470 beneficiarios aumentan
ingresos en $us. 648 c/u.
▬ Proyecto reduce pérdidas en 1719
TM.
▬ Proyecto comercializa 289 TM de
fruta seca.
▬ Se gastan $us. 516.932 en la
operación de la planta.
CONCLUSIONES
▬ Falla gerencial o supuestos
erróneos a nivel de insumos.
▬ El proyecto logra éxito
solamente en un 50%.
▬ Relación causal Propósito-
Fin errada.
RECOMENDACIONES
▬ Modificar diseño, cambiar
gerente y continuar
Proyecto.
- 69 -
