COLEGIO DE INGENIEROS DEL PERU Consejo Departamental de Lima Captulo de Ingeniera Econmica

Marco Lgico

Ing. Juan Carbonel V.

PRESENTACION

La asignacin de recursos para el desarrollo de programas y proyectos debe ser garantizada a travs de un buen sistema manejo de proyectos que contribuya al diseo, ejecucin y evaluacin efectiva. Uno de los instrumentos que han demostrado eficacia es el Marco Lgico o sistema jerarquizado de fines, objetivos y actividades a realizar debidamente interrelacionados, adems de conocer con bastante precisin los indicadores y supuestos que complementan este mtodo. El presente documento contiene el mtodo del marco lgico, basado en establecer para un programa o proyecto el fin, propsito, productos e insumos, sus medios de verificacin y supuestos importantes, de manera que los proyectos cuenten con un instrumento para su control y evaluacin. Prcticamente, todas las agencias y organismos de cooperacin internacional exigen en la presentacin de proyectos de desarrollo el mtodo del marco lgico como la matriz de planificacin por excelencia. En este sentido, el Centro de Investigacin y Desarrollo de Proyectos (CIDEPRO) pone a disposicin de las ONGs e investigadores sociales este importante mtodo de planificacin y evaluacin de proyectos de desarrollo. CIDEPRO

CONTENIDO PRESENTACION I. II. ANTECEDENTES METODO DEL MARCO LOGICO A. Consideraciones Generales 1. Jerarqua de los Objetivos del Proyecto 2. Hiptesis en Cadena 3. Supuestos 4. Indicadores Verificables 5. Medios de Verificacin 6. Esfera de Control B. DISEO DEL PROYECTO C. EL MARCO LOGICO Y LA EVALUACION D. MARCO LOGICO. CASOS

MARCO LOGICO III. ANTECEDENTES

Si usted no sabe hacia dnde 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 accin que siga no puede ser comparado a cursos alternativos de accin. Todos los cursos de accin, todos los caminos, son los mismos, usted consume los recursos, usted est avanzando, pero, hacia dnde se dirige? En 1969, a fin de descubrir hacia dnde se diriga, la Agencia Internacional para el Desarrollo de los Estados Unidos (AID), comision su personal el anlisis de su sistema de evaluacin de proyectos. Dicho anlisis puso al descubierto tres problemas bsicos que estaban afectando seriamente no slo a la evaluacin significativa de proyectos, sino tambin a su implementacin. 1. La planificacin era demasiado imprecisa : Los objetivos eran mltiples y no se relacionaban claramente con las actividades de los proyectos. No se tena una imagen clara de lo que el proyecto deba ser si tena xito. Por tanto, los evaluadores no podan comparar, de manera objetiva, lo que se haba planificado con los resultados que se haban obtenido. 2. La responsabilidad de la gerencia no era clara: Los gerentes de proyectos tenan conciencia del hecho de que los proyectos se justifican en funcin de sus beneficios finales (impacto), sin embargo, se resistan a ser considerados responsables del impacto; haban demasiados factores importantes que escapaban a su control. Hallaban difcil el identificar aquello de lo cual ellos deberan ser responsables y terminaban por no aceptar ninguna responsabilidad por los resultados. 3. La evaluacin era un proceso adversativo: Ante la ausencia de metas claras y frecuentes desacuerdos (an entre los miembros del 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 aspectos malos. Los resultados subsecuentes de la evaluacin, por tanto, frecuentemente se convertan 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 Mtodo del Marco Lgico para el diseo y evaluacin de proyectos fue especficamente elaborado para responder a los problemas antes mencionados. Promueve la colaboracin desde el principio y ayuda a evitar relaciones adversativas tanto en la formulacin como en la evaluacin de proyectos de la siguiente manera:

1. Fomentando la descripcin clara, explcita y medible de lo que ocurrir si el proyecto tiene xito 2. Estableciendo claramente aquello de que el gerente del proyecto es responsable de lograr y por qu 3. Mostrando los elementos claves del proyecto y sus relaciones entre s, de manera que se facilite el anlisis del proyecto 4. Cambiando el enfoque de evaluacin de quin es el culpable? Al de cul es el plan ms realista para este proyecto para el futuro, en base a la mejor evidencia disponible hoy? Este mtodo convierte al gerente del proyecto en el usuario principal de los resultados de la evaluacin. El Marco Lgico requiere objetivos claros y luego basa la evaluacin en la evidencia. La evaluacin se convierte en una herramienta de ayuda para el gerente del proyecto y no en un arma que lo amenaza.

El Marco Lgico fue aprobado por AID en 1970, en la evaluacin de proyectos de asistencia tcnica. Fue implantado en 30 programas de asistencia de AID en diversos pases entre 1970 y 1971. En los aos siguientes, el Mtodo del Marco Lgico fue extendido a proyectos de prstamo en el terreno y proyectos de financiamiento desde la sede de AID. La Agencia Canadiense de Ayuda Exterior (CIDA) aprob el Mtodo del Marco Lgico en 1974 y en 1975 decidi aplicarlo mundialmente.

El Mtodo del Marco Lgico se ensea ahora en instituciones gubernamentales y acadmicas de los Estados Unidos y de pases en desarrollo (*). Se estn elaborando nuevas aplicaciones. En Paquistn, se elabor un Sistema de Manejo de Proyectos (SMP) completo, aadiendo al Marco Lgico el uso de redes de rendimiento para sistemas de seguimiento e informacin. En Tailandia, Omn y Guatemala, el SMP fue adoptado en varios de los Ministerios. En Costa Rica, El Ministerio de Agricultura y Ganadera esta trabajando en Programacin Presupuestaria usando el Mtodo del Marco Lgico. El Banco Interamericano de Desarrollo tiene planificado incluir el Marco Lgico en sus cursos de preparacin y evaluacin de proyectos para mejorar la administracin de estudios de factibilidad. (*) El Marco Lgico es parte del Currculum de post grado en varias Universidades Norteamericanas.

El Mtodo del Marco Lgico Resumen

El mtodo del Marco Lgico, es un conjunto de conceptos entrelazados que deben ser usados juntos, de manera dinmica para elaborar un proyecto bien diseado, objetivamente descrito y evaluable. La incertidumbre dentro del proyecto se hace explcita. Los resultados del proceso de emplear conceptos de Marco Lgico pueden ser expuestos en una matriz de 4 x 4, proporcionando un resumen conciso de una pgina de los principales elementos del proyecto y sus relaciones entre s (Cuadro I 1). Debe recordarse que el uso del Mtodo del Marco Lgico permite una conceptualizacin 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 comunicacin ms clara entre todos aquellos que participan en el diseo del proyecto.

El Mtodo del Marco Lgico debe considerarse una importante herramienta gerencial para planificadores y gerentes. No es difcil de usar. No requiere ninguna especializacin en matemticas o en el uso de computadoras. Descansa en la experiencia que tiene el usuario en proyectos de desarrollo as como la percepcin de lo que constituye la buena administracin y la intuicin. No proporciona respuestas o toma de decisiones, pero organiza la informacin 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 ms profundo. Los conceptos no necesitan estar restringidos slo a proyectos, pueden ser aplicados en una variedad de situaciones, que incluyen, aunque no se limitan, al diseo de planes y programas de desarrollo, elaboracin de currculum, clarificacin de objetivos profesionales, diseo de estructuras de organizacin, etc.

MARCO LGICO PARA

Fecha de terminacin del Proyecto ______________ Fecha de este resumen _______________________

EL RESUMEN DEL DISEO DEL PROYECTO

Ttulo del Proyecto: _______________________________________________ RESUMEN NARRATIVO Fin del Programa. Objetivo Final. INDICADORES VERIFICABLES OBJETIVAMENTE Medidas del logro del propsito: MEDIOS DE VERIFICACIN SUPUESTOS IMPORTANTES Relacionadas con el valor a Largo plazo del programa/ Proyecto: Que afectan al enlace Propsitp-Fin:

Propsito del Proyecto: Objetivo General

Condiciones que indicarn que el Propsito se ha logrado: Situacin Final del proyecto

Productos: Objetivos Especficos.

Cantidades de los Productos especficos que son necesarias y suficientes para alcanzar el Propsito.

Que afectan al enlace Producto-Propsito:

Insumos. Actividades.

Nivel de esfuerzo/gasto por actividad.

Que afectan al enlace Insumo-Producto:

IV.

EL METODO DEL MARCO LOGICO

El ncleo conceptual del Mtodo del Marco Lgico se describe en los prrafos que siguen. Este Mtodo supone que los proyectos de desarrollo son instrumentos de cambio, que fueron seleccionados de entre instrumentos alternativos como los ms costo-efectivos, para lograr un resultado deseado y beneficioso. Nuestro mtodo acepta la incertidumbre inherente en todos los proyectos de desarrollo identificando explcitamente la naturaleza de esa incertidumbre, las hiptesis de desarrollo. En base a la aplicacin demostrada en cientos de proyectos de desarrollo econmico y social, creemos que el concepto es factible y estratgicamente confiable.

A. CONSIDERACIONES GENERALES SOBRE EL METODO DEL MARCO LOGICO

El Marco Lgico es una manera de organizar la informacin y actividades de modo que un nmero de diferentes puntos de vista pueden ser reunidos simultneamente, complementndose en lugar de oponerse uno a otro. Estos puntos de vista son:

Gerencia de Programas. Que estipula que se gerencia para lograr resultados y que espera que los gerentes sean responsables por los mismos. Mtodo Cientfico o Bsico. Que estipula que en nada existe certeza, que toda actividad humana puede ser considerada como la comprobacin de hiptesis. Anlisis de sistemas. Que estipula que ningn sistema est definido hasta que hayamos definido el mayor del cual forma parte.

A fin de simplificar los programas, primero reconocemos que existen tres niveles bsicos 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.

Propsito. La razn por la que producimos el objetivo de ms alto nivel que hace que invirtamos en la produccin de resultados, es decir, si los resultados son bienes materiales, entonces nuestro Propsito podra ser la utilidad. Si nuestros Productos, son servicios sociales, entonces nuestro Propsito podra ser el mejoramiento de la calidad de vida de la poblacin a la que nos dirigimos.

Habiendo aclarado la jerarqua bsica de objetivos para gerencia, introducimos el mtodo cientfico bsico. Todas las actividades humanas son inciertas. Por lo tanto, consideramos a nuestro proyecto como un conjunto de hiptesis en cadena; si Insumos, entonces Productos; si Productos, entonces Propsito. Debe notarse que lo que vara 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 hiptesis si Productos, entonces Propsito, es problemtica. Existe suficiente incertidumbre en esta hiptesis de modo que el gerente del proyecto responde slo hasta los lmites razonables, l debe hacer lo que un hombre razonablemente hara para lograr el Propsito, pero no se le puede hacer responsable por ese resultado. Ahora, debemos aadir el tercer importante punto de vista al Marco Lgico, punto de vista muy a menudo descuidado tanto en el mtodo convencional investigacin de operaciones como en el de administracin: El requerimiento Anlisis de Sistemas que nos dice que no hemos identificado un sistema hasta que hayamos especificado la relacin que este sistema tiene con un sistema mayor. un de de no

Para hacer esto, aadimos a nuestra jerarqua gerencial de tres niveles de objetivos, un cuarto nivel superior llamado Fin. Definimos Fin de la siguiente manera: Es el objetivo de ms alto nivel inmediatamente por encima del Propsito del proyecto. Es decir, es la frase entonces para la cual el Propsito del proyecto ms los supuestos a dicho nivel de Propsito deben proporcionar un s factible. El Fin, por tanto, relaciona nuestras aspiraciones para el proyecto a las aspiraciones de aquellos para quienes nuestras actividades no tienen ningn inters intrnseco. Si nuestros Propsitos estn al nivel de la institucin, entonces nuestro Fin va ms all de la institucin y relaciona nuestro programa a objetivos verdaderamente nacionales, objetivos que podran ser comunes a varias instituciones.

Dado que existen muchas incertidumbres en la conexin entre Propsito y Fin, vemos tambin este ltimo elemento de nuestra lgica proyecto/programa, como una hiptesis comprobable (si Propsito, entonces Fin). Para incrementar nuestra comprensin de un proyecto identificamos y hacemos explcitos nuestros supuestos sobre aquellos factores necesarios para el xito, pero que van ms all de nuestra habilidad de control en cada nivel de jerarqua del proyecto. Adems, definimos explcitamente las condiciones que demostrarn logros en cada nivel (indicadores) y cmo verificaremos su cumplimiento (medios de verificacin). La Lgica en Cadena del Marco Lgico se explica ms a fondo en los prrafos que siguen. Debe recordarse que no est claro y tampoco interesa, si el Marco Lgico es una verdadera innovacin en el sentido de que es diferente de lo que se ha hecho antes. Mejor es considerarlo, como lo hace el Ministerio de Planeamiento y Coordinacin como una cristalizacin de las mejores prcticas; una manera simple de reunir una multiplicidad de perspectivas analticas y diagnsticas que incluyen, pero no se limitan, a las cuatro antes mencionadas: gerencia para lograr resultados; mtodo cientfico bsico; anlisis de sistemas; y ley contractual.

1. Jerarqua de los Objetivos del Proyecto

El Marco Lgico divide a un proyecto en cuatro niveles separados y distintos de objetivos. En el nivel ms bajo estn los insumos del proyecto. Estos se refieren a las actividades a realizarse y que a su vez resultarn en un segundo nivel de objetivos que llamamos Productos . Los Productos, son los resultados que se logran directamente mediante la administracin de los Insumos. Por ejemplo, en un proyecto de educacin podemos producir maestros entrenados, un edificio escolar equipado y administradores entrenados. Logramos esto administrando un conjunto especfico de Insumos (por ejemplo, entrenamiento de maestros, construccin del edificio escolar, etc.). Sin embargo, los Productos por s mismos no tienen valor y no son una justificacin del proyecto. Lo que realmente nos interesa es mejorar la educacin. Ello, por tanto, representa un objetivo de ms alto nivel que llamamos Propsito. El Propsito es lo que esperamos resulte del logro de los Productos. Los Productos son un conjunto de objetivos interrelacionados que, combinados, estn orientados hacia el logro del Propsito del proyecto. Dentro del proyecto mismo tenemos, por tanto, tres niveles: Insumos, Productos y Propsito.

El cuarto nivel en el Marco Lgico es un objetivo de ms alto orden, llamado Fin. El proyecto es una de las condiciones necesarias para el logro de este Fin, pero no ser suficiente por s mismo para lograrlo. Usando el mismo ejemplo de un proyecto de educacin, el Propsito especfico del proyecto es una educacin 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 regin en que se requieren dichas habilidades. De la misma manera en que debemos identificar todos los Productos necesarios para lograr el Propsito, debemos identificar todos los Propsitos (proyectos), necesarios para lograr el Fin. Este es generalmente asociado con objetivos especficos de programas o sectores.

La especificacin de los Productos para lograr el Propsito y la gerencia para lograr el Propsito (y as lograr estos Productos), es normalmente funcin del gerente del proyecto. La especificacin de todos los Propsitos para lograr el Fin y la gerencia para lograr el Fin (y as producir Propsitos), es normalmente la funcin del Director (o gerente) del programa.

2. Hiptesis en Cadena
Es importante notar que la relacin, entre niveles de objetivos no es accidental, ni al azar; existe una relacin causal definitiva. Cuando identificamos nuestro Propsito, por ejemplo, y luego definimos cules son los Productos que necesitamos para lograrlo, estamos en efecto, diciendo: Si podemos obtener estos Productos, entonces deberamos lograr este Propsito. En otras palabras, seleccionamos estos Productos porque creemos que ellos pueden hacer que el Propsito ocurra. Estamos por lo tanto, formulando la hiptesis de que si hay Productos, entonces hay Propsito.

Una hiptesis se define como una prediccin sobre una relacin causal que implica incertidumbre. Un ejemplo de esto es la prediccin de que si uno sube a su autobs regular de la maana 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 podran ocurrir desde el momento de subir al autobs hasta el momento de llegar a la oficina como por ejemplo, que el bus se descomponga o que haya un accidente.

Cuando diseamos un proyecto usando el Marco Lgico, hacemos una serie de predicciones que usualmente llamamos hiptesis. Estas son: 1. Si los Insumos son administrados adecuadamente, ENTONCES, los Productos sern producidos 2. Si se producen los Productos, ENTONCES se logra el Propsito 3. Si se logra el Propsito, ENTONCES ello contribuir al logro del Fin Esto puede ser visto grficamente de la siguiente manera:

FIN SI PROPOSITO, ENTONCES FIN PROPOSITO

SI PRODUCTOS, ENTONCES PROPOSITO PRODUCTOS

SI INSUMOS, ENTONCES PRODUCTOS INSUMOS

Las hiptesis tal como se las presenta aqu estn demasiado simplificadas. Cada vez que formulamos dichas hiptesis, tenemos que aceptar que habr un cierto grado de incertidumbre. La cantidad de incertidumbre es mayor en los niveles superiores de la jerarqua de objetivos del proyecto. Por lo tanto, es importante aclarar la naturaleza de la incertidumbre de modo que podamos seleccionar un diseo que tenga la mayor probabilidad de xito. Esto se hace mediante la inclusin en nuestro diseo de los factores necesarios para lograr el xito, pero que estn ms all de nuestro control. Llamamos supuestos a stos 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 mecnicas y que no habrn accidentes.

Debido a que reconocemos la existencia de la incertidumbre, necesitamos describir las dimensiones totales de las hiptesis 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 trfico, ENTONCES uno llegar a la oficina a tiempo. Hemos descrito la naturaleza de la incertidumbre que afecta a nuestras hiptesis y la hemos expresado en forma de supuestos (ver Cuadro II 1, en el que se muestra un juego de hiptesis en cadena y supuestos para un proyecto de Produccin de Arroz).

3. Supuestos
Los supuestos reflejan nuestro reconocimiento de que existen factores que van ms 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 autobs. No podemos controlar el trfico o asegurarnos que la compaa duea de los buses los mantenga en buen estado de funcionamiento. De modo que al identificar nuestros supuestos, hemos expandido nuestra hiptesis original para incluir la naturaleza especfica de las incertidumbres ms importantes que podran afectar esa hiptesis. Una formulacin ms completa de las hiptesis y las incertidumbres contenidas en ellas, se muestra en el diagrama siguiente:

FIN

PROPOSITO

------------ Y ---------------

SUPUESTOS

PRODUCTOS

------------ Y ---------------

SUPUESTOS

INSUMOS

------------ Y ---------------

SUPUESTOS

Lo anterior es, por supuesto, un ejemplo sencillo. Sin embargo, los supuestos pueden ser el factor crtico 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 hiptesis 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 ms 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 diseo 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 podran ser detrimentes para el logro de nuestros objetivos. Entonces, registramos estos supuestos, identificndolos en la columna de supuestos del Marco Lgico en el mismo nivel donde se registra la porcin Si de la Hiptesis. Por ejemplo

RESUMEN NARRATIVO

SUPUESTOS

Fin

Propsito Contrato importante Firmado

Productos 1. Llegar a tiempo a -------------- y ------------------ la oficina.

1. Cliente aprueba versin final del Contrato.

Insumos 1. Levantarse a tiempo para tomar el autobs.

---------------- y -----------------

1. Autobs est en buenas condiciones 2. No hay demoras en el trfico.

El Marco Lgico requiere que en cada nivel las actividades o resultados planificados ms los supuestos a ese nivel constituyan condiciones suficientes para lograr el siguiente nivel superior. Una vez que hemos identificado tantos supuestos crticos como sean posibles con la informacin disponible, debe considerarse ms detalladamente cada supuesto. Consideremos un supuesto del ejemplo de la produccin de arroz en el Cuadro II-1, y veamos cmo se lo usa en el diseo del proyecto. Se necesita una cantidad adecuada de lluvia para cumplir con el Propsito del proyecto. Esto no es difcil entender, pero los planificadores y administradores de proyectos necesitan una mayor orientacin para evaluar la validez de este supuesto. La primera pregunta que se debe contestar es qu cantidad de lluvia es la adecuada? Debemos averiguar cunta precipitacin requerirn las cosechas. No ser suficiente conocer cuntas pulgadas de precipitacin pluvial se requiere. Tambin debemos saber cundo se debe ocurrir la precipitacin. Si descubrimos que deben comenzar en Mayo y durar hasta Octubre, con un promedio mensual de 12 pulgadas, el prximo paso es averiguar, si es razonable esperar este nivel y patrn de precipitacin pluvial. Si el anlisis cuidadoso de la historia climtica de la regin muestra que por ocho pulgadas en los meses de Junio y Julio, nuestro supuesto es cuanto a la precipitacin pluvial adecuada no sera vlido. Podramos continuar con el proyecto tal cual est y aceptar una menor probabilidad de xito, pero generalmente cuando la probabilidad de xito rebaja sustancialmente, debido a un supuesto sin validez, deberamos tomar algunas medidas para rectificar la situacin. 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 irrigacin desarrollado por el proyecto proporcionara una cantidad suficiente de agua a las cosechas. Los planificadores del proyecto deberan estudiar esto para determinar qu es lo que se requerira para desarrollar el sistema de irrigacin y si el proyecto cuenta con los recursos necesarios. Si el proyecto no puede permitirse ninguna expansin, tal vez otro proyecto podra hacerse cargo de esta tarea. Si no existen medios para rectificar el problema, entonces surgen otras dos posibilidades: (1) Los objetivos del proyecto podran ser modificados (el nivel esperado de productividad en el ejemplo anterior podra ser reducido), o (2) El proyecto podra ser desechado como irrealizable, dejando de esta manera recursos libres para otros proyectos. Si cada uno de los supuestos en el diseo de un proyecto es manejado de esta manera durante la fase de diseo y el proyecto es mejorado en relacin en esta forma, el gerente tendr una idea realista de las probabilidades de xito que tiene el proyecto y tambin estar en condiciones de anticipar el tipo de dificultades que podran surgir durante el curso del proyecto. Los supuestos son tiles no slo durante la etapa de diseo del proyecto, sino tambin durante su ejecucin y evaluacin. Una vez iniciado el proyecto, su gerente debera seguir regularmente los supuestos para asegurarse de su continua validez. Si descubre que uno de los supuestos no es vlido, debe tomar medidas para rectificar la situacin. 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 evaluacin, puesto que su examen puede darnos una mejor visin del por qu el proyecto ha tenido o no xito en lograr sus objetivos.

A fin de formular supuestos tiles, nos preguntamos: Qu podra ocurrir para que este supuesto no tenga validez? Por ejemplo, si tenemos un supuesto muy general como equipo disponible a tiempo, nos preguntaramos Qu podra ocurrir que demore la disponibilidad del equipo? La respuesta podra 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 producira 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 el gobierno no acepte las demandas del sindicato, el personal del proyecto podra, 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 hara el siguiente supuesto: El gobierno y el sindicato de trabajadores del puerto firman contrato laboral 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 seales de que el contrato no sera firmado, puede replantear el proyecto en la forma ms adecuada. La clarificacin de supuestos permite una mejor comunicacin entre el gerente del proyecto y sus superiores. Mediante el anlisis cuidadoso de los aspectos inciertos del proyecto antes de que ste comience, los superiores del gerente del proyecto, tienen bastante claro cules son los factores que estn fuera del control de ste y cmo podran afectar al proyecto. Cuando los superiores aprueban el proyecto, ellos aceptan el hecho de que los supuestos estn fuera del control del gerente del proyecto. Asimismo, comparten con l la opinin de que el proyecto tiene una alta probabilidad de xito debido a la claridad y validez de los supuestos. Esta opinin compartida libera al gerente del proyecto de la responsabilidad individual por el diseo total del proyecto. Si un supuesto luego demuestra no tener validez y causa un problema, el gerente del proyecto puede informar abiertamente sobre la situacin sin temor de que slo l sea criticado por la equivocacin. 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 administracin. Si el gerente oculta los problemas, especialmente aquellos que resultan de supuestos errados, entonces est limitando la posibilidad de que sus superiores introduzcan correctivos. El gerente del proyecto y sus superiores deberan trabajar conjuntamente a fin de identificar los problemas y hallar las soluciones adecuadas. Si bien los supuestos estn fuera del control del gerente del proyecto, no estn necesariamente fuera del control de sus superiores. En una seccin posterior se comentar ms sobre el papel del gerente.

4. Indicadores Objetivamente Verificables

No es suficiente definir la intencin general del proyecto en trminos de las hiptesis en cadena y supuestos relevantes para cada nivel del proyecto. La formulacin de Fin, Propsito, Productos e Insumos, frecuentemente est sujeta a malentendidos o a interpretaciones diversas de parte de aquellos involucrados en el proyecto. La formulacin de Fin y Propsito en particular, tiende a ser ambigua. Ocurre

a menudo que el Propsito de un proyecto es interpretado por las personas involucradas en l de muy diversas maneras. Por ejemplo, la formulacin 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 pudiramos visualizar exactamente cmo podramos reconocer el xito en cada nivel de un proyecto, podramos mejorar el enfoque de los objetivos del proyecto y confiar en que todos los que estn involucrados en l, comparten la misma imagen. Los Indicadores Objetivamente Verificables, son el medio para establecer cules condiciones sern las que sealen el logro exitoso de los objetivos del proyecto. Se define a los Indicadores como a aquellas condiciones que estn tan estrictamente asociadas con ciertas otras condiciones, que la presencia o variacin en las primeras indica la presencia o variacin en las segundas. Los Indicadores demuestran resultados. No son condiciones necesarias para lograr esos resultados. Por ejemplo, un aumento de la temperatura en el termmetro indicara que hemos logrado exitosamente calentar el agua hasta un nivel deseado. El aumento de la temperatura en el termmetro, sin embargo, no es necesario para el logro del calentamiento del agua. Para ello se requiere del elemento calentador adecuado. 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 variacin 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 Propsito del proyecto es de gran importancia, el conjunto de Indicadores a ese nivel ha recibido el nombre especial de Situacin Final del Proyecto (SFP). Ello se debe a la importancia del Propsito, que hace que sea el principal motivo del proyecto y sirva de enfoque para la programacin y el dilogo del proyecto. Tambin se debe al hecho de que el Propsito es frecuentemente demasiado complejo, que involucra a factores tales como la viabilidad de organizacin, mejoras netas en sistemas complejos (ejemplo: humanos), etc. Es normal que para objetivos complejos, ningn Indicadores por s solo es suficiente, pueden atribuirse Indicadores relevantes a eventos alternativos o es que nuestra especificacin funcional es multidimensional. De ah que la regla para la seleccin del SFP es similar a aquella usada por cualquier buen gerente, administrador o cientfico en ciencias aplicadas. Si se satisfacen todas las condiciones SFP, entonces no existira ninguna explicacin alterna plausible (es decir, ninguna explicacin que no sea otra que aquella deseada logro/propsito). El Marco Lgico, por tanto, incentiva al diseador del proyecto a definir clara y explcitamente qu es lo que indicar que el proyecto sea considerado un xito. Incluido directamente en el diseo del proyecto est el conjunto de condiciones que sealarn el logro exitoso del Propsito. Por ejemplo: Incremento en la produccin de arroz PROPSITO

SFP 1. 30,000 agricultores con 7 hectreas de tierra o menos, incrementan el rendimiento de arroz en un 50 por ciento, entre Octubre 1999 y Octubre 2001. 2. El arroz cosechado por los pequeos agricultores en 2001, es de la misma calidad (porcentaje partido), que el arroz cosechado por los mismos agricultores en 1999.

Ntese en el anterior ejemplo sobre arroz, como los Indicadores aaden profundidad y dimensin a la formulacin del Propsito. El Propsito incremento en la produccin es vago. Si logrramos aumentar la produccin en slo un 2 por ciento para un agricultor, se podra tambin considerar que hemos tenido xito, hemos aumentado la produccin. Sin los Indicadores, no tenemos forma de saber la Intencin especfica del diseo original. Tambin la forma en la que el Propsito est expresado, no aclara que estamos dirigindonos a la produccin de los pequeos agricultores. Deberamos, por tanto, reformular el Propsito as: Incremento de la produccin de arroz de los pequeos agricultores de la regin del Noreste. Cuando aclaramos la formulacin del Propsito, debemos nuevamente examinar nuestros indicadores. Frecuentemente stos necesitan ser pulidos. El proceso de pulirlos es esencial para la buena utilizacin de los conceptos. No deberamos resistirnos a cambiar el Marco Lgico durante el diseo, mas bien, deberamos considerar la necesidad de cambiarlo, en la medida en que el uso de los conceptos origina preguntas importantes y nos obliga a refinar continuamente nuestro diseo hasta que tengamos un nivel alto de confianza en su validez. Es mucho mejor cometer los errores en el papel. El proceso de usar los conceptos es mejor llevado a cabo en colaboracin con otros. Requiere de la participacin de todas las partes involucradas en el proyecto: personal de programacin, alta direccin, administradores del proyecto, expertos y tcnicos especializados, y con frecuencia los expertos en evaluacin. Debe notarse tambin que una vez que hemos aadido Indicadores a nuestro diseo, podemos juzgar mejor su adecuacin. A menudo un nmero de indicadores sern necesarios para medir el xito. El nmero de Indicadores que son necesarios, es aquel nmero mnimo que nos hace confiar en que su existencia en efecto demostrar que hemos logrado nuestros objetivos para el proyecto y, adems, seala el gerente del proyecto una meta clara hacia la cual se dirige. Slo cuando los objetivos estn claramente definidos con metas, es que el gerente del proyecto puede juzgar si las condiciones en un nivel del diseo del proyecto son suficientes o no para lograr el objetivo del nivel superior. Algunas reglas tiles de recordar, son: 1. El resumen narrativo debe proporcionar un punto de direccin 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 aaden profundidad y comprensin, estableciendo una especificacin de desempeo tal, que an los escpticos estaran de acuerdo en que el resultado que intentamos ha sido logrado (cuando los Indicadores son objetivamente verificados).

A continuacin se discuten cuatro caractersticas de los buenos Indicadores. a) Los Indicadores Miden lo que es Importante Los Indicadores deben medir lo que es importante en el objetivo. Por ejemplo, en nuestra formulacin del Fin incremento de los ingresos del pequeo agricultor, es

ms fcil medir el ingreso del agricultor, pero nosotros estamos interesados en el ingreso del pequeo; por tanto, nuestros Indicadores deben reflejar nuestro inters en los pequeos agricultores y estamos hablando de ingresos. Pero, a qu nos referimos, al ingreso en general o al ingreso real? Si nos referimos a este 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 los 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 se debe al establecimiento de un sistema funcional de crdito, no es evidenciable. Los agricultores que tienen grandes utilidades podran argir 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 indicadores ms estrechamente relacionados con lo que significa tener tal sistema, por ejemplo, el nmero de prstamos concedidos a los pequeos agricultores, nivel de mora, rapidez y eficiencia con la que se procesan y administran los prstamos, etc. 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 continuacin, para indicar que se ha logrado el propsito: Primer Paso: Identificar Indicador Los pequeos agricultores aumentan la produccin de arroz. Segundo Paso: Cuantificar 30,000 pequeos agricultores (que poseen 7 hectreas o menos) aumentan la produccin de arroz en un 50 por ciento. Tercer Paso: Definir Calidad 30,000 pequeos agricultores (que poseen 7 hectreas o menos) aumentan la produccin de arroz en un 50 por ciento, manteniendo la misma calidad de la cosecha de 1999.

Cuarto Paso:

Especificar Lmite de Tiempo 30,000 pequeos agricultores (que poseen 7 hectreas o menos) aumentan la produccin de arroz en un 50 por ciento, entre octubre de 1999 y octubre de 2001, manteniendo la misma calidad que exista en la cosecha de 1999.

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 extrao. El mejor es aquel que simplifica. El aspecto de la calidad es muy importante, pero a menudo se lo ignora. En este ejemplo, la preocupacin mayor est clara, si producimos ms arroz a costa de la calidad, habremos fracasado. Al especificar, debemos preguntarnos Cunto es suficiente para lograr el siguiente nivel de objetivos, de que calidad debe ser y para cundo lo necesitamos?. A fin de responder a estas preguntas, por supuesto, debemos conocer las metas en los niveles superiores. En nuestro ejemplo, sabemos cul es el ingreso actual de los agricultores; sabemos cunto les cuesta actualmente satisfacer sus necesidades bsicas (alimentacin, semilla, ropa) y podemos estimar lo que costar de aqu a tres aos. Por tanto, podemos estimar cunto necesitarn 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 cunto arroz tendrn que vender y a qu precio (por lo tanto, nuestros supuestos sobre precios de arroz) para 1981 y a la vez, podemos derivar cunto arroz tendr que producir. Este proceso se emplea para derivar metas para todos los componentes del proyecto, empezando por el nivel ms alto para determinar lo que necesitamos, hasta el clculo 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 justificaran su valor en relacin al costo (costo-efectividad). d) Los Indicadores son Independientes Los indicadores, que demuestran el logro de un objetivo a un nivel especfico, no pueden ser usados para demostrar logros en el prximo nivel superior. Aunque este es aparentemente uno de los conceptos ms sencillos de la metodologa del Marco Lgico, es tambin una de las debilidades ms comunes en los diseos del Marco Lgico. Hay una tendencia comn 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 educacin en la escuela (Propsito). O por ejemplo, centro de salud construido, provisin de medicinas y personal mdico contratado (Productos) demuestran que el centro de salud presta servicios (Propsito). Esto se debe a que es ms fcil pensar en xito cuando se trata de resultados tangibles de un proyecto, como edificios y gente. Los objetivos a nivel del Propsito son mucho ms difciles de definir, se hace ms lgico pensar Bueno, por supuesto, hemos mejorado la salud, slo basta ver este edificio lleno de facilidades mdicas, mdicos y enfermeras de primera categora, trabajando para nosotros. Es necesario pensar cuidadosamente acerca de cules indicadores verdaderamente demostraran la provisin de servicios de salud, por ejemplo nmero, tipo y calidad de atencin en salud que actualmente se ofrece a determinados grupos, tales como el nmero de nios inmunizados, nmero de madres que reciben atencin de salud preventiva, nmero de bebes que nacieron bien, etc. Hemos hecho por lo tanto, una prediccin en sentido de que con la produccin de Productos se lograr el Propsito, pero toda prediccin incluye incertidumbre. Por tanto, no podemos decir que el producir Productos logra automticamente el Propsito, ni tampoco podemos usar la obtencin de Productos como prueba que el Propsito se haya logrado. Debemos medir el logro del Propsito 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 Propsito, presenta el medio para lograr el Propsito del proyecto (en cuyo caso stos son en realidad Productos, no as Indicadores), o si en realidad describen las condiciones que existiran si el Propsito 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 produccin por hectrea 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 ms difcil medir el xito del proyecto. Dicha industria podra hacer sido desarrollada de manera tal que, llegue a ser viable tres aos despus de haberse concluido el proyecto. A fin de poder confiar en que el proyecto tenga xito a su conclusin, es necesario hallar un indicador que pueda ser considerado capaz de predecir resultados posteriores. En este caso, tal indicador podra ser una tendencia a la reduccin de los costos unitarios de produccin y/o un constante incremento en los pedidos. Tales indicadores tambin pueden usarse para medir resultados cuando es demasiado costoso verificar los indicadores preferidos. Si un indicador preferido requiere una encuesta costosa para su verificacin 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 educacin de una escuela vocacional, pero no existe presupuesto para examinar a los graduados, los evaluadores podran investigar cuntos de los graduados estn 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 podran explicar el cambio en el indicador indirecto que hemos seleccionado. En el ejemplo anterior, los sueldos de los graduados en una escuela vocacional podran muy bien reflejar la satisfaccin del empleador con la calidad del graduado, sin embargo, es posible que haya escasez de gente con este tipo de entrenamiento y la demanda que existe est elevando los precios excesivamente, an cuando los graduados fuesen mediocres.

5. Medios de Verificacin
Como un paso adicional en el Mtodo del Marco Lgico, para aclarar objetivos, debemos preguntarnos: Cmo podremos medir nuestros indicadores? Los indicadores prueban el logro de los objetivos, pero si no podemos hallar datos acerca de la cantidad de arroz cosechado por los agricultores, entonces no podemos demostrar que se hayan incrementado las cosechas y por tanto, no podemos mostrar un incremento de la produccin en general. Y si no podemos medir xito, o fracaso, deberamos 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 verificacin. Si los agricultores no informan sobre la cosecha o si no hay medios para pesar los productos, podemos hacer una encuesta y contar el nmero 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 indicado, y si el proyecto no tiene fondos para pagar por la encuesta, entonces debe encontrarse otro indicador. La verificacin de algunos indicadores podra requerir simplemente una rpida revisin de registros del proyecto o del gobierno, mientras que otros indicadores requieren para su verificacin de la recoleccin y anlisis sofisticado de datos. Si la verificacin va a costar al proyecto tiempo y dinero, entonces los medios de verificacin deben ser identificados durante la etapa de diseo 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, quizs no estn disponibles cuando se los necesite. Deben identificarse las fuentes de evidencia de todos los elementos importantes de un indicador. Por ejemplo:

Indicador Objetivamente Verificable

Medios de Verificacin

2,000 nuevas viviendas para familias, adquiridas por residentes agricultores de bajos ingresos hasta junio del 2000.

Los registros de ventas de las oficinas de vivienda, nmero de ventas y fecha de las ventas. Datos sobre el nivel de ingresos del comprador, obtenidos de los registros de pago 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 verificacin. Los medios de verificacin deben ser cuidadosamente examinados para asegurarse de que los datos sean completos y fidedignos. A menudo, los gerentes de proyectos confan en los registros gubernamentales, slo para posteriormente descubrir que (1) los registros no estn al da 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 verificacin estaban disponibles y eran confiables pero se descubri que la oficina de vivienda no mantena registros sobre las residencias anteriores de los compradores. Este medio de verificacin tuvo que ser descartado y debi encontrarse otro. Una posible alternativa sera visitar a los nuevos dueos para averiguar sobre su antigua residencia. Tambin se podra organizar un sistema de informacin 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 informacin oportuna que puede ser usada por quienes toman las decisiones durante la ejecucin del proyecto. Cualquier medio que utiliza el proyecto para obtener la informacin necesaria para verificar los indicadores de logro, el medio de verificacin debe hacerse explcito en el diseo del proyecto. El establecer los medios de verificacin puede ser una tarea compleja y que exige mucho. Recomendamos que el gerente del proyecto sea el que seleccione las tcnicas de verificacin que tengan sentido para l y sus colegas. Para aquellos que requieran un sistema de verificacin ms ajustado, recomendamos documentos como Manager s Guide to Data Collection, 1979.

6. Esfera de Control Existe una lnea divisoria invisible entre Producto y Propsito, que permite distinguir los niveles de incertidumbre dentro del proyecto. Por debajo de la lnea, 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 lnea, por ejemplo, de lograr el Propsito, es done tenemos mucho menos experiencia y por lo tanto, menos certeza de que de que se puede hacer por lo cual esperamos y confiamos que lograremos el Propsito. Hacemos lo ms que podemos para definir todas las condiciones necesarias y suficientes para lograr aquel Propsito, pero hay an 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 produccin de Productos para un determinado Propsito. En efecto, el gerente competente acepta la responsabilidad de producir dichos Productos. El no acepta la responsabilidad de lograr el Propsito; esa es responsabilidad de la Alta Gerencia o Direccin. Sin embargo, acepta la responsabilidad de hacer todo lo que pueda para vigilar el avance del proyecto con relacin al logro de aquel Propsito y tratar de lograrlo. La especificacin de lo que se puede hacer, esfera de control, y la esperanza de lograr lo que se desea lograr, o sea, el Propsito, facilita la clarificacin de a tarea del gerente y permite un dilogo constructivo y abierto entre los niveles de direccin. Esto a su vez, permite a todos poder concentrarse en lo que el proyecto intenta lograr, cmo se lo puede lograr, qu se factores estn fuera de control del proyecto, quin es responsable de qu y cundo deben participar los diferentes niveles de direccin. Esto crea una atmsfera orientada a tareas en la cual las oportunidades, avances y problemas que podran 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 energa a cumplir con su trabajo. No necesita preocuparse de que se lo responsabilizar por factores que estn fuera de su control. Sin embargo, no se lo libera de la responsabilidad de usar su buen juicio en el diseo del proyecto, de usar todos los medios a su disposicin para influir favorablemente sobre los factores que estn fuera de su control y comunicarse con sus superiores cuando vea que: (1) los Productos quizs no sean producidos a tiempo o en la calidad o cantidad suficiente, o (2) los Productos sern producidos tal como estaban planificados, pero que no estn teniendo en efecto anticipado en el logro del Propsito. El gerente de un proyecto debera introducir todos los correctivos que tenga a su disposicin 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 lo tanto est en mejores condiciones para ver qu medidas deben tomarse para corregir la situacin. Si el gerente del proyecto no pasa sus recomendaciones a sus superiores, las decisiones se tomarn sin contare con la percepcin clara de la persona en el terreno. La comunicacin entre el gerente de un proyecto y sus superiores debe ser una comunicacin de dos vas. Debe conocer y, cuando sea factible, ser un participante activo para determinar por qu el proyecto se est llevando a cabo. El Marco Lgico ayuda en esta comunicacin especificando los objetivos de ms alto nivel: Fin y Propsito. El gerente de un proyecto debe comprender cmo su proyecto contribuir al logro del Propsito y el Fin. Si el gerente ve que el proyecto no tendr el impacto esperado en los niveles superiores, debe comunicar esto a sus superiores. A menudo, es difcil para un gerente hacerlo, porque ello podra significar que su proyecto sea discontinuado. Veamos un ejemplo: el Fin es incremento del ingreso de los pequeos agricultores y el Propsito: incremento de la produccin de arroz de los pequeos agricultores. El gerente de un proyecto ve que, aunque los pequeos agricultores estn incrementando su produccin de arroz, su ingreso no incrementa debido a una reciente declinacin en el precio del arroz. Ellos, entonces, tienen una oportunidad, muy a tiempo, para examinar la situacin y puedan ya se aadir recursos o cancelar el proyecto a favor de una alternativa que tenga mayores probabilidades de xito. a. Error en la Lgica Ocasionalmente se comete un error cuando se formula una hiptesis de Producto a Propsito. Esto ocurre si no se distingue entre el resultado sinergtico esperado, cuando todos los productos se han logrado (ejemplo: Propsito) y un simple resumen o reformulacin de los Productos mismos. Si simplemente reformulamos los productos, entonces no tenemos hiptesis, tenemos un 100% de probabilidad de que Si productos, entonces Productos. Lo que estamos buscando es una formulacin del Propsito que refleje los resultados de la hiptesis Si productos y ciertos otros factores importantes fuera de nuestro control, entonces Propsito. En tal formulacin nunca tenemos el 100% de probabilidad de que Si Productos, entonces Propsito. Siempre existen variables intervinientes (y los supuestos que hacemos sobre ellos), que afectarn nuestra habilidad para lograr el Producto deseado. MALA PRACTICA Propsito es la suma de productos Propsito: Mtodos modernos de cultivo usados por los agricultores BUENA PRACTICA Propsito es el resultado de los Productos Propsito: Incremento en la produccin agrcola de los agricultores

PRODUCTOS 1. Fertilizante usado por los agricultores 2. Semilla de alto rendimiento plantada

3. Pesticidas usados por agricultores 4. Fungicidas usados por agricultores 5. Sistema de cosecha mltiple usado por agricultores b. Delegacin de Responsabilidad La responsabilidad de lograr cada uno de los productos, puede ser delegada por el gerente de un proyecto a otros, sean estos los contratistas o subordinados. Los Productos pueden ser desglosados en el Marco Lgico 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 asignacin de recursos. Los insumos en el Marco Lgico deberan mostrar los recursos humanos, econmicos y el equipo necesarios para cada una de las actividades. El Marco Lgico puede ser usado como instrumento de comunicacin, no slo entre el gerente de un proyecto y su superior como se describi anteriormente, sino tambin entre el gerente y aquellos en los que depende en cuanto a cooperacin para el logro de sus objetivos. Es especialmente til cuando el gerente debe luchar con los numerosos factores que estn fuera de control. Por ejemplo, si el Propsito del proyecto es incrementar la produccin de arroz en 50% y sus Productos son: (1) canales de irrigacin construidos y (2) distribucin de semilla de alto rendimiento, y el proyecto supone que habr suficiente fertilizante en el mercado a un precio razonable y que las instituciones de crdito harn prstamos a los agricultores, quizs l necesite influir a los productores y distribuidores de fertilizantes y las instituciones de crdito, sin tener autoridad directa sobre ellos. El gerente puede hacer esto compartiendo sus objetivos con ellos. Con el Marco Lgico l puede explicar cul es el Propsito del Proyecto, cuales son los Productos que debe lograr y cules son los supuestos que son crticos para el xito del proyecto. Tambin debera compartir con ellos el Fin del proyecto de modo que puedan ver que estn contribuyendo con 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 ayudndole al gerente del proyecto en el logro de su cometido. B. DISEO DEL PROYECTO Un proyecto debera ser diseado muy rara vez por una sola persona en forma aislada. El diseo de un proyecto requiere habilidades administrativas y tcnicas. Las personas que tienen las habilidades especficas requeridas, deberan ser incluidas como miembros del equipo. El dnde comenzar cuando se elabora el Marco Lgico para un proyecto depende de la cantidad de decisiones que ya se hayan tomado en relacin a, los detalles de un proyecto. Idealmente, el Marco Lgico debera usarse antes de que el proyecto sea identificado. En tal caso, el Marco Lgico sera un instrumento de diseo para la planificacin del programa / sector. Una vez que la Alta direccin hubiera identificado el Fin de un programa o

sector, entonces se procedera a la identificacin de los proyectos que se requeriran para lograr el Fin. Si los gerentes en el nivel de programa estuvieran usando sus propios Marcos Lgicos para disear programas, la razn para el programa sera registrada en sus Marcos Lgicos como Propsito, y cada uno de los proyectos requeridos para lograr el Propsito sera un Producto. Cada Producto (o proyecto) entonces sera asignado al gerente de un proyecto. Su Fin sera, por supuesto, el Propsito dentro del Marco Lgico del gerente de un Proyecto. Este mismo mtodo podra usarse para delegar la responsabilidad de administrar Productos individuales.

PROGRAMA ML FIN Propsito Producto 1 Producto 2 Producto 3 Insumos PROYECTO ML Fin Propsito PRODUCTO ML Fin

Producto 1 Producto 2 Producto 3 Insumos

Propsito

Producto 1 Producto 2 Insumos

Cuando se asigna un proyecto a un equipo de diseo (el cual, si es posible, debera incluir al director del proyecto), el Fin y el Propsito del Marco Lgico ya estn identificados. El equipo podra inicialmente querer aclarar el Propsito mediante la elaboracin de indicadores para la Situacin Final de un Proyecto (SFP). Una vez que el alcance del Propsito es comprendido, el siguiente paso es producir los Productos del proyecto. El equipo debe preguntarse qu es lo que debe producirse para lograr el Propsito. 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 Lgico. El Marco Lgico debera tener un Fin, un Propsito, Productos e Insumos identificados. La Situacin Final de un Proyecto debera ser lo suficientemente completa y los indicadores en el nivel de Productos e Insumos deben estar bien identificados. Invariablemente, durante la etapa inicial del diseo de un proyecto, se identifican muchos supuestos, los cuales deben ser anotados grosso modo de manera que no se los olvide. La primera etapa es un diseo de arriba hacia abajo, comenzando por el Fin y bajando hasta los Insumos.

La segunda etapa del diseo de un proyecto empieza desde abajo y asciende hasta el Fin. Durante esta etapa, el equipo de diseo debe preguntarse si se han identificado todas las condiciones necesarias y suficientes a un nivel, a fin de tener la confianza de que se cumplirn los objetivos del nivel inmediato superior. Se hace una revisin de cada conjunto de actividades junto con sus recursos para determinar s es necesario para lograr un Producto especfico. Los supuestos deben aclararse an ms 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 tcnicos de un proyecto para asesorar al equipo de diseo y/o al gerente de un proyecto. El equipo luego trabaja al nivel de los Productos y examina cada Producto para ver si es necesario para lograr el Propsito de un proyecto. Deben elaborarse indicadores para cada Producto. Los supuestos que se hacen acerca de la hiptesis Producto-Propsito, se clarifican an ms y luego debe juzgarse si se han identificado todos los factores necesarios y suficientes para lograr el Propsito. Luego debe analizarse a nivel de Propsito de un proyecto, y lo reexamina para determinar si es necesario para lograr el Fin. Todos los indicadores de la SFP deben ser totalmente identificados y sealados. Los supuestos para la prediccin Producto-Propsito, son aclarados an ms. Los otros proyectos que tambin contribuirn al logro del Fin deben ser incluidos en los supuestos. El equipo debe determinar si se han identificado todos los factores necesarios para lograr el propsito. A nivel de Fin, los Indicadores deben quedar totalmente identificados y determinados. Esto completa el primer ciclo del diseo del Marco Lgico. Para refinar an ms el diseo de un proyecto, se requieren dos actividades que pueden llevarse simultneamente. La primera es elaborar el plan de evaluacin. Para esto, el primer paso es identificar los medios de verificacin para cada uno de los indicadores. Si los medios de verificacin requieren recursos y actividades adicionales para le proyecto, entonces ambos deben ser incluidos como Insumos del proyecto en el Marco Lgico. El gerente del proyecto debe anticipar decisiones que sern dependientes de los resultados de la evaluacin. Si deben tomarse decisiones importantes en puntos especficos 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 informacin necesaria para tomar estas decisiones est disponible a tiempo. Una evaluacin simulada puede ser til en la identificacin de los tipos de decisiones y el tipo de informacin requerida. Puede descubrirse que es necesario incluir en el diseo de un proyecto, indicadores y supuestos adicionales para proveer una base de medicin en el futuro. La evaluacin se orienta hacia la identificacin del cambio que ha ocurrido como resultado de la ejecucin de un proyecto. A fin de medir el cambio, es imperativo

saber las condiciones que existan 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 recoleccin de datos bsicos no es una actividad anterior al proyecto, entonces sta debera estar incluida en el diseo 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 bsicos y considerar alternativas tales como la de no ejecutar el proyecto, o la de recolectar datos de tendencias, de modo que, por lo menos, se pueda ver el cambio en un lapso de tiempo, an cuando no podamos ver la situacin inicial. La segunda actividad requerida para mejorar el diseo 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 vlido 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 disposicin se discuten en la parte que trata de los supuestos. No existe una frmula 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 debera ser suficiente para indicar al gerente del proyecto que hay peligro. Si se ve que un nmero de supuestos no tienen altas probabilidades, entonces su probabilidad combinada tendra que ser considerada baja y esto tambin sera una seal 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 avaluar la probabilidad de sus supuestos por no contar con la informacin necesaria, podra llevar a cabo ms estudios hasta obtener la informacin. La informacin tiene un costo. Sin embargo, se debe ponderar ste con el costo para el proyecto si la informacin no se obtuviera. A largo plazo podra resultar ms costoso el continuar sin informacin. Idealmente, el gerente del proyecto debera participar en la planificacin de un proyecto. A menudo un planificador disea un proyecto y luego pasa el diseo terminado al gerente del proyecto. Cuando esto ocurre, el gerente no tiene oportunidad de participar en el diseo del proyecto. En tal caso, l debera examinar el diseo y alertar inmediatamente a la Alta Direccin sobre cualquier aspecto irreal en el diseo y problemas importantes que el prevea.

C. EL MARCO LOGICO Y LA EVALUACION

La disciplina de usar el Marco Lgico en el proceso de diseo, facilita la produccin de un diseo evaluable, los objetivos son claramente formulados, las hiptesis de desarrollo han sido explcitamente formuladas y los indicadores de xito a cada nivel de la jerarqua han sido establecidos. Ms an, estos indicadores expresan lo que los diseadores llaman xito; as la tarea de evaluacin es simplemente la recoleccin de datos para aquellos indicadores claves y la evaluacin del proyecto frente a sus normas preestablecidas de xito. El llamar a los evaluadores durante la fase de diseo para asegurarse de que los datos pueden en realidad ser recolectados, a costo razonable, ayuda a clarificar an ms el diseo del proyecto. Tambin puede reducir los costos de evaluacin mediante la incorporacin de algunos aspectos de la recoleccin de datos en las operaciones rutinarias del proyecto.

D. MARCO LOGICO. CASOS

El MARCO LOGICO constituye una herramienta eficaz para los gerentes o administradores del proyecto de desarrollo. Se basa en la experiencia que tiene el planificador en proyectos de desarrollo, as como la percepcin de lo que constituye una buena administracin. No sustituye a la toma de decisiones, pero es importante para identificar probables errores, es decir, complementa el proceso decisional.

MARCO LOGICO: Proyecto de Agua y Alcantarillado

Resumen de Objetivos Incremento de la calidad de vida de la poblaci n de Huamancaca Disminuci n de los casos de enfermedades diarreicas y parasitosis , asociadas al abast . de agua y alc.

Indicadores Al Ao 10: Disminuc . de las necesid . b sicas insatisf . Asociadas al saneam b sico, del 68% al 30% Al a o 5: Disminuci n de la tasa de morbilidad asociada a los servicios de saneamiento de 30% a 10% -Al a o 1: Incremento en 14% de la cobertura de servicio de ag.pot. -Incremeto en 10% de la cobertura del serv. de alcant . -100% de aguas residuales son tratadas -60% de poblac . capacitada en prcticas de higiene.

Medios de verificaci n

Supuestos

FIN

Encuestas a hogares, Censos Bolet n epidemiol gi co del centro de salud de Huamancac a Chico

PROPOSITO

Se mantienen los ingresos reales de la poblaci n,

COMPONEN TES

Agua: -Cobertura de agua pota. incrementada -Servicio de agua potable mejorado Alcantarillado: -1 sist. de alcantarillado implemetado . -1 laguna de oxidaci n.termianda -% Poblaci n con Educac . Sanitaria incrementada.

Informe de la entidad administrado ra de los servicios. Informes de capacitaci n

La poblaci n paga oportunamente las tarifas fijadas por la empresa

X . M T IZD M R OL IV A R E A C
R m d O jetivos esu en e b In icad d ores

G O IC
M ios d ed e verificaci n S p estos uu

AC NS C IO E

-A plia nd m ci e re e ds e is n s d a u x te te e g a e in ta ci nd n ev s s la e u a co ex d m ria n . o icilia s. -Im lan ci nd p ta e g le asF+ a r a F+ s in rc n xi n te o e d e n siste a ex m s isten s d te e d trib ci nd a a is u e gu . -Im lem ta nd p en ci e re e d a a ta do d s e lc n rilla c nc n x n s o o e io e d m ria o icilia s. -C stru on cci nd e L g n s d O id ci aua e x a n. -C p cita i n C a c a n dl e p rso al a ca o d la e n rg e o e ci nd l sistem . p ra e a -C fo a nd la on rm ci e U ida G s nid d e ti n a S rvicio e s. -P g m d ro ra a e E u a nSa ita . d c ci nS nita . an ria

A ao 1 l : -1 K s d re e 0 m e ds d e a u c stru a y g a on id s 1 1 co exion s 1 n e n ev s in la s. u a sta da -8 K s d re e d m e ds e a ta d lcan rilla o co stru a y 8 n id s 0 co exion s in lad s. n e sta a -1 g le a filtra te a r a n co stru a n id . -1 la u a d gn e n id . o id ci n co stru a x a -8 0 e e to d vn s e c p c ci n a a ita re liza s a do -1 0 2 e e to d vn s e e d ca c a s d e u ci n h rla sa ita e ctu d s. n ria fe a a

R p rte d eo s e aac v n e d la e U id d na E cu ra je to (M n a a u icip lid d D istrita l) -Ac de cta d ta e re e c n d cpi e o ra b s V lo c n s a riza io e d o ra e b s

P rticip ci nd l a a e g b rn lo l y d o ie o ca e la co u id d enla mn a d si nd ifu e a e a o h b s d cu d s ito d h ey e igien v riz ci nd l alo a e au. . ga