A1. Una Metodología para La Gestión de Proyectos IESE

Este documento es una de las 37 copias autorizadas para utilizar en el Master en Gestión de la Innovación Empresarial, Proyecto Final, Ezequiel
Beneït, 2013-2014, 2014-05-08
PN-493
Rev. 1/2014
Una metodología para la gestión de proyectos
La gestión de proyectos es una actividad tan antigua como el mundo, ya que su génesis fue
el primero de todos. Seguramente por eso son muchos los que consideran la gestión
de proyectos como una cuestión de sentido común y experiencia. Sin embargo, ¿por qué
entonces tantos proyectos no cumplen con sus plazos, costes u objetivos? ¿Qué podemos
hacer mejor de cara a la gestión de nuestros próximos proyectos?
Ante este reto, el objetivo principal de la presente nota técnica es presentar una metodología de
gestión de proyectos que le sirva de guía al directivo. La nota pretende ser, por tanto, sobre
todo un documento de consulta. La metodología descrita se desarrolla a lo largo de las
principales fases del ciclo de vida de un proyecto tipo y ha sido aplicada con éxito en
numerosos casos prácticos. Complementamos la metodología con herramientas de utilidad
en las diferentes fases del ciclo de vida y ofrecemos recomendaciones prácticas para
implementar la metodología con éxito en las empresas.
1. Proyectos frente a procesos: definiciones clave

Conceptualmente, las actividades realizadas en una empresa pueden ser clasificadas en dos
categorías fundamentales: procesos y proyectos. Como proceso clasificaríamos una secuencia
de actividades interconectadas que tiene un carácter repetitivo y prolongado en el tiempo,
es decir, se realiza una y otra vez de forma similar durante bastante tiempo. Hablaríamos, en
cambio, de un proyecto cuando las actividades se realizan exactamente de esta forma una
única vez, y después de cumplir el propósito del proyecto, el sistema operativo se
desmantela1.
1 Ello no significa que los recursos no sigan operativos (por ejemplo, los empleados), sino simplemente que se termina la configuración
del equipo responsable del proyecto con exactamente esa configuración y para ese propósito.
Nota técnica preparada por los profesores Philip G. Moscoso y Jaume Ribera. Octubre de 2013. Todo el material, ya sea en el
grueso del texto o en los anexos, es de elaboración propia a no ser que se indique lo contrario. Revisado en enero de 2014.
Esta nota técnica se ha escrito con la colaboración de la Cátedra Eurest de Excelencia en los Servicios.
Copyright © 2013 IESE. Para pedir copias de este documento diríjase a IESE Publishing a través de www.iesep.com,
escriba a iesep@iesep.com, envíe un fax al +34 932 534 343 o llame al +34 932 534 200.
No está permitida la reproducción total o parcial de este documento, ni su tratamiento informático, ni la transmisión de
ninguna forma o por cualquier medio, ya sea electrónico, mecánico, por fotocopia, por registro o por otros medios.
Última edición: 17/1/14

1
Este documento es una de las 37 copias autorizadas para utilizar en el Master en Gestión de la Innovación Empresarial, Proyecto Final, Ezequiel Beneït, 2013-2014, 2014-05-08
PN-493 Una metodología para la gestión de proyectos
Un proyecto como tal se define, por tanto, por:
Tener un objetivo o propósito específico y único, para cuyo cumplimiento se realiza la

secuencia de actividades.
Tener una duración determinada, con una fecha inicial y una final previstas.
Disponer de unos recursos limitados, tanto materiales como de trabajo o económicos.
Un proyecto tiene tres dimensiones principales: (1) un alcance (lo que incluye el proyecto y lo
que no, así como con qué calidad o especificaciones), que debe ser alcanzado en (2) un plazo
(duración máxima del proyecto), y con (3) un presupuesto (coste de la ejecución) determinado
(véase la Figura 1).
Figura 1
Principales dimensiones de la gestión de un proyecto
En la práctica, estas tres dimensiones de la gestión suelen estar en competencia. Se puede

acelerar la ejecución de un proyecto, por ejemplo, bien reduciendo su alcance o bien
aumentando sus costes (más recursos). Como comprobaremos más adelante, es por tanto
función del gestor del proyecto saber equilibrar correctamente la tensión entre estas
dimensiones en cada caso. Definiremos por ello la gestión de proyectos como:
«La aplicación de conocimientos, competencias y técnicas de gestión a la realización de

proyectos. Consiste, primeramente, en decidir qué proyectos se deben realizar (típicamente
para cumplir los objetivos estratégicos de la organización). En segundo lugar, consiste en
organizar y administrar los recursos de manera tal que se puedan conseguir los objetivos
(alcances) de los proyectos seleccionados dentro de las restricciones de tiempo y coste
definidas».
Esta definición se concreta, por lo general, en que la gestión de proyectos busca:
la satisfacción del cliente y un impacto positivo en los participantes del proyecto

(satisfacción, retención, crecimiento personal y profesional…),
resultados de negocio positivos (ROI, incremento de participación en el mercado,
crecimiento de la empresa…) o que beneficien al futuro de la empresa (desarrollo de
nuevas tecnologías y competencias…).
2 IESE Business School-Universidad de Navarra

Una metodología para la gestión de proyectos PN-493
Aunque cada proyecto es diferente, en el Anexo 1 presentamos algunas clasificaciones que

consideramos útiles en cuanto a que determinan algunas características que inciden sobre la
forma de gestionarlos. Para diferentes clases de proyectos puede ser, por tanto, recomendable
asignar diferentes perfiles de gestores, utilizar distintos tipos de metodologías, técnicas o
procedimientos de gestión de proyectos, o simplemente adecuar los colchones (en tiempo
o dinero), por ejemplo.
2. ¿Por qué una metodología de gestión de proyectos?

La gran mayoría de los directivos han gestionado algún proyecto en su carrera profesional y,
de hecho, algunos le dedican a ello la mayor parte de su tiempo. Pero muchas personas
gestionan proyectos sin ser realmente conscientes de ello, porque, por ejemplo, no utilizan
explícitamente ninguna metodología. De hecho, hasta los años cincuenta no se definieron
métodos sistemáticos y específicos para la gestión de proyectos , alimentándose de prácticas
existentes en la construcción civil, en la industria y en el entorno militar. Al igual que en
otras áreas del management, con el tiempo se ha visto que existen importantes argumentos a
favor de utilizar una metodología para la gestión de proyectos (pero, al igual que en las otras
áreas del management, no existe un consenso sobre cuál es la metodología óptima).
Decíamos que los proyectos tienen una naturaleza diferente a los procesos en algunos
aspectos, y su gestión debe tener en cuenta esas particularidades: en los proyectos, por
ejemplo, realizamos cosas por primera vez. Afortunadamente, el hecho de que cada proyecto
sea único en su configuración no significa que no haya similitudes entre ellos. El principal
beneficio de una metodología de gestión consiste, por tanto, en centrarse en las similitudes y
buscar oportunidades de mejora que sean generalizables a otros casos.
La envergadura del potencial de mejora existente en la gestión de proyectos se intuye ya a partir

del hecho de que una gran mayoría de proyectos terminan sin haber cumplido los requerimientos
establecidos a su inicio en términos de alcance, plazo o coste. La construcción del túnel bajo el
canal de la Mancha, por ejemplo, finalizó dos años más tarde de lo previsto y con un coste de
17.500 millones de dólares, cuando el presupuesto inicial era de 7.500 millones. Como iremos
desgranando, hay múltiples razones para este tipo de desviaciones, pero muchas de ellas son
consecuencia de la falta de metodología y sistematización en la gestión de los proyectos. Como
explicaremos más adelante, ello no tiene por qué estar reñido con aspectos como la creatividad o
la autonomía de los miembros del proyecto.
Un argumento adicional a favor de una metodología de proyectos suele ser la forma en la

que están organizadas tradicionalmente muchas empresas. Mientras que lo que predomina
suelen ser los departamentos funcionales, los proyectos a menudo requieren de cooperación y
coordinación transversal. Una clara metodología, auspiciada por la dirección, suele ayudar a
superar barreras de este tipo.
Otro aspecto relacionado que se beneficia del uso de una metodología es la interconexión de
las actividades. Esta interconexión puede ser más compleja o menos conocida que en el caso
de los procesos, por lo que una metodología ayuda a mejorar la planificación y coordinación de
los esfuerzos. Unido a ello está la importancia de una buena comunicación en la gestión
de proyectos, tanto interna como externa, y que una metodología ayuda a reforzar y
IESE Business School-Universidad de Navarra 3

sistematizar. De modo similar, una metodología también suele mejorar el seguimiento del
avance del proyecto, tanto para los integrantes del equipo como para la dirección de la
empresa.
Un último punto a favor del uso de metodologías está ligado al resultado de los proyectos. La
mayoría de ellos buscan generar un cambio en la empresa con, por ejemplo, un nuevo
producto, una renovación de las aplicaciones informáticas o un cambio en algún proceso.
Pero sin una buena metodología de gestión que abarque hasta la correcta finalización del
proyecto, el riesgo de que los proyectos no acaben vertebrando el cambio deseado es mayor.
2.1. Implantar una metodología de proyectos

A la hora de decidirse a implantar una metodología de proyectos como la aquí descrita,
recomendamos hacerlo de forma escalonada. En primer lugar, no suele ser recomendable
tratar de reencauzar proyectos ya en curso para que se ajusten a la nueva metodología; es
preferible reservar ésta para proyectos nuevos que se vayan originando a partir de una fecha
establecida para la implantación de la metodología.
En segundo lugar, puede ser aconsejable empezar con dos o tres proyectos piloto para refinar
y afianzar la nueva metodología. Ello permitirá también diseminar los conocimientos de
gestión en la organización paulatinamente 2 . Eso sí: después de esta fase inicial, conviene
definir y comunicar un hito de aplicación generalizada de la nueva metodología, para que
exista claridad y unidad al respecto en la organización.
En tercer lugar, recomendamos empezar con una metodología sencilla, que se puede ir
sofisticando más adelante en la medida de lo requerido. A menudo la implantación de un
método de gestión de proyectos fracasa debido a metodologías demasiado ambiciosas (y
«burocráticas»), que son rechazadas en la organización por su alta carga de trabajo adicional.
Es importante conseguir transmitir a los futuros usuarios de una (nueva) metodología de
gestión de proyectos que ésta no es sólo beneficiosa para la empresa en su conjunto, sino que
también lo es para los propios responsables del proyecto, ya que el trabajo adicional que toda
metodología conlleva inicialmente se compensará con la mejora en la eficacia y eficiencia en
la gestión de los proyectos.
Aunque, idealmente, la metodología utilizada debe ser relativamente uniforme para toda la
organización, en algunos casos puede ser de interés, no obstante, diferenciar unos (pocos)
tipos de proyectos, con el fin de facilitar la implantación y limitar el esfuerzo organizativo
derivado. Se puede, por ejemplo, distinguir entre proyectos que solamente afectan a una
unidad organizativa y aquellos que son interdepartamentales, o diferenciar del resto de
proyectos a los que superan un determinado nivel de costes. A partir de esa diferenciación, se
puede establecer una versión reducida de la misma metodología de proyectos para aquellos
que no requieren su aplicación completa.
2 Como profesores, lógicamente, recomendamos complementar la implantación con formación a los empleados, tanto en
aspectos generales como en la metodología específica a implantar en la empresa. Dicha formación puede dirigirse de manera
diferenciada a dos colectivos: quienes habitualmente serán gestores de proyectos (o al menos integrantes de equipos de
proyectos) y el resto de empleados que se verán «afectados» por la gestión de proyectos.

En empresas que no migran por completo hacia una organización por proyectos suele ser
conveniente, de igual forma, que en los diferentes departamentos o áreas funcionales
se nombren «expertos» en gestión de proyectos, similares a los power users en informática o a
los «cinturones negros» en la gestión de calidad. Serán los responsables de velar por
el cumplimiento de la metodología establecida, resolver dudas metodológicas y supervisar que
se mantiene al día la información relacionada con los proyectos del departamento.
A las organizaciones que se plantean evolucionar hacia una mejor gestión por proyectos, a
menudo les recomendamos crear una oficina de gestión de proyectos o PMO (del inglés
project management office). Ésta puede estar formada por una sola persona con dedicación
total o parcial, o bien constituirse como una unidad completa, con muchos recursos, que sea
parte importante del organigrama de la compañía: todo depende de la misión que se le
encargue, el alcance de su autoridad y su dependencia funcional. Habitualmente los objetivos
de la oficina se pueden agrupar en tres grandes líneas: (a) la reducción de riesgos en los
proyectos, (b) la mejora de la productividad, y (c) la alineación estratégica de los proyectos.
Mientras que una oficina «ligera» habitualmente se limita a proporcionar apoyo metodológico
a los equipos de proyectos, sin dirigir directamente ninguno de ellos, las oficinas «pesadas»,
en el otro extremo, tienen una gestión directa sobre todos los proyectos importantes de la
compañía.
Dentro de este abanico de posibles configuraciones de las oficinas de proyectos, podemos

clasificar sus funciones críticas en dos grandes ámbitos:
1. Funciones enfocadas a los proyectos concretos: por ejemplo, complementar los déficits
de conocimiento en gestión de proyectos de los miembros de los diversos equipos,
tutorizar a los directores de proyecto con menos experiencia o ejercer de consultora
ocasional sobre determinados aspectos del proyecto (por ejemplo, la contratación de
servicios externos).
2. Funciones enfocadas a la gestión de proyectos en la empresa en general, tales como

promocionar la cultura de gestión por proyectos, archivar la información sobre
proyectos anteriores, codificar las lecciones aprendidas, instruir en las buenas prácticas,
definir procedimientos y guías o formar en la gestión de proyectos.
Muy a menudo, con la implantación de una metodología de proyectos las empresas

se plantean la conveniencia de implantar también herramientas informáticas para la gestión
de proyectos. En nuestra opinión esto no es un requerimiento imprescindible, pero no cabe
duda de que estas herramientas, bien empleadas, pueden aportar importantes ventajas a la
gestión, como pueden ser la mejora de la planificación de proyectos, de la visibilidad y del
detalle de la información, o el refuerzo de la comunicación y el aprendizaje entre los
diferentes proyectos (para una información más detallada sobre el uso de herramientas
informáticas en la gestión de proyectos remitimos a otras notas técnicas).
3. El ciclo de vida de un proyecto

Existen proyectos de todo tipo, desde más sencillos como organizar una fiesta de cumpleaños
para un niño hasta tan complejos como construir un cohete para el turismo espacial. Pero
todos los proyectos se parecen en cuanto a que conceptualmente se desarrollan a lo largo de

un ciclo de vida, que comprende del inicio al final del proyecto y transcurre por una serie de
fases similares (véase la Figura 2).
Figura 2
Ciclo de vida de un proyecto
Es por ello que las metodologías de gestión de proyectos más establecidas se centran en la
gestión de los proyectos a lo largo de dichas fases. No obstante, existen otras metodologías
con enfoques algo diferentes, tales como las denominadas lean project management, SCRUM
o PRiSM (del inglés projects integrating sustainable methods), que pueden estar centradas en
ciertos aspectos de la gestión (por ejemplo, en el cálculo de la duración de actividades), o que
se centran en las particularidades de ciertos sectores (como el desarrollo de software). Estas
metodologías pueden ser combinadas con la aquí presentada3. A continuación revisaremos
cómo afrontar cada una de las principales fases del ciclo de vida, y qué herramientas de
gestión (por ejemplo, diagramas) nos pueden ayudar en ello.
Como veremos, las primeras tres fases de la metodología presentada suponen realmente una
preparación a la ejecución del proyecto. Ello se debe al hecho, corroborado por numerosos
estudios, de que la preparación insuficiente o inadecuada es la principal razón del fracaso de
los proyectos, incluso por encima de los errores cometidos durante la propia ejecución.
3.1. Selección de proyectos4

La primera fase consiste en la selección de los proyectos a desarrollar (y, por tanto, también
de los que serán descartados). Para poder seleccionar, primero necesitaremos identificar todos
los proyectos existentes en la empresa (realizar un censo), ya que suelen existir muchos que
3 Incluso dentro de las metodologías centradas en las fases del ciclo de vida existen ciertas diferencias en cuanto a las fases o la
nomenclatura empleada.
4 Para más detalle, véase la nota técnica de Jaume Ribera, «El ciclo de vida del proyecto: selección», PN-459, IESE, febrero de 2011.
(Disponible en IESEP)

no están catalogados formalmente como proyectos5 y, por tanto, no son susceptibles de ser
seleccionados ni eliminados. La selección realizada teniendo a la vista todos los proyectos
candidatos al mismo tiempo es siempre más eficiente que la selección secuencial, en la que se
nos van presentando proyectos por separado y debemos decidir si cada uno se realiza o no,
sin tener conocimiento de qué otros proyectos aparecerán posteriormente.
La selección final de proyectos tiene que recaer en la dirección de la empresa, ya que implica
decidir a qué iniciativas se destinan recursos y a cuáles no 6 . El reto suele residir en que
existen más oportunidades de proyectos de las que los recursos permiten sacar adelante. Por
tanto, habrá que priorizar los esfuerzos en función del impacto (estratégico7) esperado y los
recursos (dinero y tiempo) disponibles. Gestionar demasiados proyectos a la vez no es
recomendable para la productividad de los recursos ni para los plazos de los proyectos.
Frecuentemente se tiende a querer realizar más proyectos de lo que sería factible y, además, a
asignárselos a un número reducido de responsables de proyectos (que han destacado por su
buen hacer); evidentemente, ello acaba generando a posteriori problemas derivados de la
sobrecarga de los recursos8.
Del mismo modo, tampoco es deseable tener demasiados pocos proyectos, debido a que,
como afirma la Ley de Parkinson de 1955, «el trabajo siempre se expande hasta ocupar todo
el tiempo disponible»: es decir, los recursos ociosos tienden a invertir más tiempo del
necesario para realizar sus cometidos o, en el peor de los casos, acaban dedicándose a
actividades superfluas. No debe extrañar, por tanto, que muchos de los problemas que surgen
en un proyecto tengan su origen en una selección equivocada.
3.1.1 Dimensiones de la selección de proyectos: capacidad e impacto
Como hemos avanzado, existen dos aspectos fundamentales a considerar de cara a la

selección de proyectos: (1) el impacto estratégico esperado del proyecto en términos de
negocio, y (2) la capacidad disponible para realizar proyectos. El reto está en que al final
de esta fase hay que decidir cuántos proyectos se pueden realizar, y evaluar si el proyecto «A»
tiene mayor o menor prioridad que el proyecto «B», en base a estas dos dimensiones que no
siempre son fácilmente cuantificables.
Impacto de los proyectos
La priorización de proyectos por su impacto estratégico requiere de la definición de los

pertinentes criterios. Existen métodos cuantitativos, como, por ejemplo, el valor actual neto
(VAN), y otros cualitativos, como la valoración de expertos en una matriz de ponderación.
Ninguno suele ser perfecto por sí solo, por lo que a menudo es recomendable combinarlos. Si
un proyecto «A» tiene un VAN más alto que el «B», por ejemplo, puede ser conveniente
5 Incluso si en una empresa existe un repositorio de proyectos, ello no es garantía de que no haya proyectos gestionados al
margen del sistema «oficial». A menudo una buena forma de identificar los proyectos activos consiste en trazar la asignación de
gastos a actividades con el fin de ver qué iniciativas pasan gastos y pueden tener carácter de proyecto.
6 Por ello, a menudo se utiliza la denominación «gestión de la cartera de proyectos».
7 Los proyectos internos son la vía principal para implantar la estrategia de una empresa. Por ello, su priorización vendrá
marcada por su contribución a este respecto.
8 Conviene recordar que, al igual que en una carretera con demasiados coches el atasco producirá el retraso de todos, cuando
seleccionamos demasiados proyectos no sólo se retrasarán los que «sobran», sino, habitualmente, todos ellos.

analizar los supuestos numéricos de cada uno, pero también puede interesar más el «B» si
conlleva el desarrollo de nuevos conocimientos para la empresa o si su probabilidad de éxito
es mayor. Dependiendo del método de priorización, a menudo será necesario recabar primero
dicha información sobre los proyectos a evaluar.
Disponibilidad y demanda de proyectos
De cara a determinar la capacidad 9 disponible en la organización para realizar proyectos,

tendremos que identificar cuáles son los recursos que pueden ejercer de «cuello de botella»,
ya sean recursos materiales (la disponibilidad de una determinada materia prima, como puede
ser el suelo urbanizable en proyectos inmobiliarios), recursos financieros (para sufragar el
capital circulante durante la vida de los proyectos) o recursos de trabajo (personal cualificado
o equipos de fabricación). Deberemos establecer la capacidad disponible de cada recurso
y, después, traducir cada proyecto en las necesidades que genera para cada uno de ellos.
En lo que respecta a los recursos de trabajo es recomendable traducir en horas de trabajo tanto
las capacidades como los requerimientos de los proyectos. Computar las horas de trabajo
disponibles para hacer proyectos por un lado y las horas demandadas por el otro, en la práctica
no resulta tan trivial como pudiera parecer. Para empezar, es necesario estimar la cantidad de
horas que requiere una actividad que puede no haberse realizado con anterioridad, pero,
además, hay que considerar que las personas tendemos a subestimar las sobrecargas a futuro.
Si, por ejemplo, le pedimos a un compañero que dedique a un proyecto seis horas de trabajo la
semana que viene, es mucho menos probable que acepte que si se las pedimos para dentro de
dos meses; pero, en la práctica, no sólo es muy probable que dentro de dos meses le resulte
igualmente difícil dedicar dichas horas a nuestro proyecto, sino que, además, el hecho de no
haberlas «reservado en su capacidad» le ha podido llevar a prometer igualmente las mismas
horas a muchos otros proyectos, lo que a su vez le generará retrasos en otros requerimientos.
Otro aspecto a tener en cuenta es que puede resultar diferente dedicarle treinta horas a la
semana a un proyecto que dedicar diez horas a cada uno en tres proyectos diferentes. Por
ejemplo, tener dos o tres proyectos en curso simultáneamente puede mejorar el rendimiento
si ello aporta flexibilidad para asignar el tiempo en función de los avances de cada proyecto,
pero, del mismo modo, suele implicar un tiempo de cambio, al tener que retomar repetidas
veces un proyecto diferente.
Debido a estas numerosas causas de incertidumbre, generalmente el objetivo no consiste en

computar con la máxima exactitud las horas que serán necesarias y en qué instante, sino
en hacer una estimación razonable y práctica. Ello se puede realizar, por ejemplo, a través de
una planificación agregada de proyectos con una curva de carga acumulada en la que
se compara la evolución de la disponibilidad y la demanda a lo largo del tiempo, utilizando
periodos de tiempo razonables (véase el Anexo 2 para un ejemplo).
3.1.2. Puertas de control
La selección concluye con la configuración de una cartera de proyectos aprobados. Por tanto,
puede ser considerada como una primera compuerta de control en la gestión de proyectos.
9 Para más información, véase también la nota técnica de Alejandro Lago, Philip Moscoso y Marc Sachon, «Gestión de la
capacidad en sistemas de operaciones», PN-464, IESE, abril de 2010. (Disponible en IESEP)

Durante el desarrollo del proyecto pueden incumplirse los avances previstos o acontecer
eventos no esperados; por ello, es conveniente definir, igualmente, compuertas en las otras
fases del ciclo de vida, en las que se deberá decidir si se continúa o no con el proyecto.
Evidentemente, el objetivo radica en no invertir esfuerzos en proyectos que finalmente no se
completen con éxito, por lo que interesa desechar (o «congelar») los proyectos lo antes
posible en su ciclo de vida, de manera que el número de proyectos «vivos» se vaya
restringiendo a aquellos que parezcan ir mejor encaminados (o que, al menos, cumplen lo
previsto). De ahí que el diagrama habitualmente tenga forma de embudo (véase la Figura 3,
donde el tamaño del círculo representa a la carga de trabajo de los proyectos).
Figura 3
Embudo resultante de las compuertas de control
La «anchura» del tubo estará relacionada con la capacidad de gestionar proyectos de la unidad
organizativa o empresa, y la forma del embudo reflejará la estrategia de proyectos que se desee
implantar. El embudo tendrá una u otra forma en función de la relación entre el porcentaje de los
proyectos que se descartan en la selección y los que no pasan de la definición u otras fases, lo
cual, asimismo, deberá tener en consideración la disponibilidad de recursos en la empresa.
Empresas con un marcado carácter de I+D, por ejemplo, tienden a ser más generosas en las
primeras fases, conscientes del alto grado de incertidumbre que suelen tener sus proyectos,
mientras que en otros contextos, como la construcción, se suele preferir pasar a la fase de
definición solamente aquellos proyectos que saldrán adelante con casi total seguridad. Asimismo,
distintos tipos de proyectos (como construcción o I+D) necesitarán una diferente definición de las
compuertas.

3.2. Definición de proyectos10

La definición de un proyecto se puede entender como la elaboración de un «contrato» para el
proyecto en el que se recogen sus aspectos más relevantes.
El primer paso de la definición se realiza habitualmente de forma previa, para disponer de la

información esencial para la fase de selección del proyecto, y, una vez seleccionado, se
completa con los apartados que describimos en esta sección.
Las preguntas estratégicas iniciales en la definición de un proyecto son las siguientes:

(1) ¿qué intentamos conseguir con el proyecto, y por qué lo hacemos?, (2) ¿cómo mediremos
su éxito?, (3) ¿qué condiciones o factores externos deben darse para tener éxito?, y (4) ¿cómo
lo vamos a hacer? Un instrumento muy útil es el denominado marco lógico (logical
framework), que se presenta en la Figura 4.
A la izquierda del diagrama se presentan los bloques de objetivos (los objetivos de alto nivel a
los que el proyecto contribuye), propósitos (los cambios que se prevén con la consecución de
los resultados del proyecto), resultados (aquello que directamente debe conseguir el proyecto),
actividades (las tareas que se realizarán en el proyecto) y recursos (personas, materiales,
equipos, etc., necesarios para realizar las actividades del proyecto). Un repaso de estos bloques
de forma ascendente justifica el porqué del proyecto, mientras que revisados de forma
descendente explican cómo se realizará. Cada paso ascendente puede leerse como una
sentencia condicional: «Si (…), entonces (…)». Por ejemplo: «Si contratamos a un comercial y lo
dedicamos a ventas (recursos), entonces conseguiremos contactar a más clientes»;
«Si contactamos a más clientes (actividades), entonces aumentarán las ventas (resultados)»; «Si
aumentan las ventas (resultados), entonces mejorará el valor de la acción (propósitos)»; etc.
Figura 4
El marco lógico de un proyecto
entonces …
OBJETIVOS y… SUPUESTOS
Si…
PROPOSITO entonces … y… SUPUESTOS
Cómo
Si…
Por qué
RESULTADOS entonces … y… SUPUESTOS
Si…
ACTIVIDADES entonces … y… SUPUESTOS
RECURSOS Si…
A la derecha del diagrama aparecen los supuestos, es decir, las hipótesis sobre factores
externos inciertos que deben producirse para que se completen las relaciones lógicas. Por
ejemplo, en la cadena lógica para un curso podríamos establecer la siguiente relación: «Si el
profesor presenta los conceptos de gestión de proyectos de forma clara (actividades),
10 Para más detalle, véase la nota técnica de Jaume Ribera, «El ciclo de vida del proyecto: definición», PN-460, IESE, febrero de 2011.

entonces los participantes aprenderán a usar estas herramientas en sus proyectos

(resultados)». Sin embargo, deberíamos también incorporar los siguientes supuestos: «Siempre
que haya tiempo suficiente para practicar en clase, los participantes estén motivados, las
instalaciones permitan a los participantes ver la presentación, etc.».
Un elemento final en el marco lógico es el de la medida de éxito, ya que, por lo general, los
objetivos tienden a ser bastante ambiguos. Tan sólo cuando nos ponemos de acuerdo en cómo
los mediremos y en el valor que esperamos generar con su realización, se convierten en metas
concretas. Cada uno de los niveles del marco lógico debería, por tanto, traducirse en un
conjunto de métricas y metas de calidad, cantidad y plazo11. En resumen, el marco presentado
nos permite poner sobre el papel la lógica estratégica de un proyecto (que demasiado a menudo
tan sólo está en la mente de algunos directivos) y cuestionarnos su validez y lógica.
La fase de definición incorpora esta lógica en un documento que sirve, asimismo, como
herramienta de comunicación (dentro y fuera del proyecto) para transmitir en qué consiste
esencialmente el proyecto, dando respuesta a preguntas sobre el objetivo del proyecto, sus
entregables o los roles de cada uno de los integrantes del equipo de proyecto. Presentamos
aquí, de forma resumida, los principales apartados de la definición12:
Nombre del proyecto: idealmente el nombre tiene que reflejar el propósito del proyecto,
pero a la vez debería ser fácil de comunicar y no demasiado largo. Por ejemplo:
«Oficina de proyectos».
Misión: consiste en explicar el porqué del proyecto. Se puede construir sobre lo

elaborado en la fase de selección, usando el marco lógico, y también, a veces, se puede
complementar detallando qué pasaría si no se realiza el proyecto. Por ejemplo:
«Desarrollar e implantar el uso de la metodología de gestión de proyectos en la empresa».
Entregables: representan lo que el proyecto debe producir (outputs o resultados).

A menudo incluyen resultados tangibles. Por ejemplo: "el manual de proyectos", "el
repositorio de proyectos", etc.
Alcance: corresponde a los límites del proyecto. Es crucial definir claramente lo que
entra y lo que no en un proyecto, ya que una de las principales causas de fracaso
radica en ir añadiendo poco a poco elementos nuevos al contenido del proyecto (scope
creep). Por ejemplo: «La nueva metodología se utilizará en todos los proyectos con un
coste superior a 50.000 euros o que impliquen, al menos, dos departamentos».
Implicados (stakeholder): representan a cualquier persona (o grupo) que será

influenciada por el proyecto o debe influir en él. Cada caso es diferente, pero
habitualmente existen cinco tipos generales:
11 Fue Lord Kelvin (William Thomson) quien, en lenguaje muy científico, expresó lo siguiente: «Cuando puedes medir aquello de
lo que hablas, y expresarlo en números, sabes algo; si no puedes expresarlo en números, tu conocimiento es pobre y no
satisfactorio; puede ser el inicio del conocimiento, pero en tus pensamientos has avanzado muy poco en el estrado de la
ciencia». En términos más cotidianos, podría expresarse como «si no puedes medir algo, no sabes de lo que estás hablando».
12 Para más detalle, véase la nota técnica de Jaume Ribera, «El ciclo de vida del proyecto: definición», PN-460, IESE, febrero de 2011.

o Patrocinador: el máximo responsable hacia fuera, no necesariamente con rol

operativo, al que se debe tener informado y que ayudará en caso de conflictos. Por
ejemplo: “el director de medios y recursos humanos".
o Cliente: el beneficiario o usuario de los resultados del proyecto. Junto al
patrocinador, a menudo es quien financia el proyecto. Por ejemplo: “los
responsables de proyectos que aplicarán la metodología a implantar".
o Responsable: el jefe operativo del proyecto. Coordina al equipo de proyecto y
asegura también la comunicación externa.
o Directivos de área: aquéllos que controlan los recursos requeridos por el proyecto
y esperan ser informados sobre el avance del mismo.
o Equipo: las personas que realizarán el trabajo operativo. Su composición
dependerá del proyecto, y puede incluir también personal externo a la empresa.
Objetivos: son una versión detallada de la misión del proyecto. No conseguiremos

cumplir la misión si no alcanzamos los objetivos del proyecto. Para poder comprobar
que se cumplen, los objetivos deben de ser S.M.A.R.T.13 (del inglés specific, measurable,
attainable, relevant, time-bound):
o Específicos: concretos, aludiendo a problemas definidos.

o Medibles: su cumplimiento debe poder medirse de alguna forma.
o Alcanzables: si los objetivos no son realistas desmotivarán al equipo.
o Relevantes: importantes para la misión del proyecto (y para los stakeholders y la
empresa en general).
o Limitados en tiempo: fijados temporalmente, por ejemplo, en forma de hitos.
Criterios de éxito: se debe definir y acordar entre los diferentes stakeholders qué
debería conseguirse para que se pueda decir que el proyecto ha sido exitoso. En caso de
no existir consenso, se puede inferir que existe una falta de visión compartida respecto
al proyecto. El éxito de un proyecto se puede referir tanto a los resultados del mismo
(resultados, propósitos y objetivos en el marco lógico) como al proceso de su desarrollo
(actividades y recursos). Un ejercicio para identificar los criterios puede consistir en
imaginarse el final del proyecto y tratar de elaborar una nota de prensa sobre
el proyecto que, en unas breves líneas, explique por qué el proyecto ha sido un éxito.
Por ejemplo: “la empresa XYZ ha implementado con éxito una nueva metodología para
la gestión de proyectos que entrará en funcionamiento general a partir del día…”.
Supuestos y riesgos: en la fase de planificación recomendaremos realizar un análisis

detallado de este aspecto, pero ya en la propia fase de definición interesa llevar a cabo
una identificación preliminar, realizada en el marco lógico. A modo de ayuda, se
pueden agrupar los riesgos por tipologías utilizando, por ejemplo, el análisis PESTEL
(riesgos políticos, económicos, sociales, tecnológicos, ecológicos y legales).
13 Término inglés que significa inteligente. Para más información, véase P. J. Meyer (2003), «What would you do if you knew you
couldn’t fail? Creating S.M.A.R.T. Goals», en Attitude is everything: If you want to succeed above and beyond, Meyer Resource Group.

Impacto económico: en un sentido amplio, puede ser el resumen de un business case, es

decir, un análisis económico completo del proyecto considerado. Ello a menudo
se concreta en un cálculo del retorno de la inversión. En otras ocasiones, un análisis así
resulta demasiado precoz, y la definición se limita a fijar un presupuesto y realizar una
primera estimación del impacto de los resultados esperados (por ejemplo, «reducción de
los costes por transacción gracias a la nueva aplicación IT»).
La definición del proyecto no debe considerarse como algo definitivo e inamovible. Es

perfectamente lícito realizar ajustes de la misma (sin llegar a convertirlo en un borrador
permanente, ya que perdería su función), pero siempre de forma consensuada por la partes
implicadas.
3.2.1. Mandato y equipo de proyecto adecuado
Un resultado de la fase de definición es, asimismo, la posibilidad de verificar si el proyecto

tiene un mandato claro para, a partir de allí, configurar el equipo adecuado para los
requerimientos de su desarrollo. Estos dos aspectos son críticos para el éxito de cualquier
proyecto. El mencionado scope creep (la ampliación progresiva del alcance del proyecto), un
apoyo insuficiente por parte de la dirección o la circunstancia de que los stakeholders
consideren la misión del proyecto algo secundario para la empresa son ejemplos de señales
de alarma anticipada, que deberían llevar incluso a cuestionar el proyecto.
Asimismo, en esta fase del proyecto debemos identificar a los principales miembros del equipo
requeridos para ejecutarlo. De modo similar a la diferenciación habitual entre conocimientos y
capacidades (o habilidades), se debe identificar aquellas dimensiones que necesitan estar
cubiertas por el equipo del proyecto debido a su naturaleza y contexto. A menudo habrá que
complementar las capacidades de carácter directivo y de gestión (por ejemplo, la gestión de
presupuestos o la relación con terceros) con la necesidad de conocimientos de naturaleza más
técnica, como los referentes a las aplicaciones IT (véase la Figura 5).
Figura 5
Perfiles del equipo de proyecto
Del mismo modo, ya que los proyectos suponen un trabajo en equipo, es deseable que existan
una serie de roles de comportamiento cubiertos entre los miembros del equipo (como el de
impulsor o coordinador). En el Anexo 3 presentamos un listado de roles que también puede
ser útil revisar de cara a la configuración del equipo del proyecto.

El objetivo final es definir para cada miembro, y de forma coordinada por el jefe del
proyecto, los roles y responsabilidades que a cada uno se le asignarán en el equipo. Aunque
no será hasta la siguiente fase (la de planificación) cuando analicemos en detalle la
dedicación que se requiere de cada integrante, sí es conveniente hacer una revisión
preliminar de la disponibilidad real de los miembros seleccionados en el periodo previsto para
la ejecución.
3.3. Planificación de proyectos14

Esta fase supone el cierre de la preparación de un proyecto. En ella se comienza a especificar
cómo se va a realizar, así como el cuándo y el quién. Antes de entrar en los detalles de la
etapa de planificación, es importante diferenciar tres tipos de proyectos para los que las
tareas de planificación deberán ser más o menos flexibles en función de dicha diferenciación:
Los proyectos en cascada, también llamados lineales, se corresponden con aquellos que
hemos denominado «pintar por números» (véase la tercera clasificación del Anexo 1),
es decir, aquellos de los que se conoce tanto el qué como el cómo y en los que, por
tanto, lo que falta por determinar es la secuencia de tareas a realizar, para poder
después desplegarlas según se ha previsto. Así, las tareas o paquetes de trabajo se irán
desarrollando «en cascada», cada una siguiendo a la anterior de una forma más
o menos lineal.
Los proyectos iterativos se corresponden con aquellos con un alto nivel de indefinición
en el qué, en el cómo o en ambas dimensiones. En este caso tan sólo se podrá hacer
una planificación de alto nivel, sin entrar en los detalles de las distintas fases, ya que
lo que habrá que realizar, o cómo se tendrá que realizar, dependerá de los resultados
o de lo aprendido en las fases anteriores; por tanto, este nivel de detalle sólo se irá
iterando a medida que avance el proyecto.
Finalmente, los proyectos paralelos son habitualmente aquellos que se corresponden con
proyectos «extremos» por su urgencia temporal (consúltese la clasificación NTCP —del
inglés novelty, technology, complexity and pace— en el Anexo 1). Son aquellos en los
que su comienzo se produce (casi) demasiado tarde. El rescate de treinta y tres mineros
sepultados en una mina en Chile a más de setecientos metros de profundidad, o el
desarrollo de un misil atómico antes de que lo desarrolle el enemigo, son ejemplos de
este tipo de proyectos. En estos casos, el proyecto se planifica mediante unas secuencias
de actividades redundantes y en paralelo, para aumentar la probabilidad de que alguna
de ellas resulte exitosa en un plazo razonable.
En general, en todos estos casos se podrá (y se deberá) realizar la mayoría de las tareas que
describimos en esta sección, aunque su nivel de detalle y orden podrá variar en mayor o
menor medida. La Figura 6 resume en un diagrama las distintas etapas a cubrir en esta fase
de planificación, así como su interdependencia.
14 Para más detalle, véase la nota técnica de Jaume Ribera, «El ciclo de vida del proyecto: planificación», PN-461, IESE, febrero
de 2011. (Disponible en IESEP)

Figura 6
Detalle de la planificación
Partiendo de la definición del proyecto, las tareas más importantes en la fase de planificación
son:
Descomposición de un proyecto: se suele hacer, esencialmente, por motivos prácticos, y

consiste en la división del proyecto en paquetes más manejables y asignables para
facilitar su ejecución y seguimiento. Si nos hemos propuesto como proyecto escribir un
libro, podemos dividir esto en actividades tales como buscar un título, definir el índice,
buscar editor, escribir los capítulos, etc. Como regla general, el nivel de detalle deseable
es aquel que genera actividades cuya duración corresponde al «pulso natural» del
proyecto, es decir, el intervalo de tiempo con el que deberíamos hacer el seguimiento
del avance del mismo. En el caso de una obra civil, por ejemplo, no «controlaríamos» el
avance (o gasto) cada hora, pero tampoco esperaríamos un mes para hacerlo. Existen
herramientas, como el mapa mental (mindmap), que facilitan el proceso de
descomposición (en equipos) y aseguran una mayor coherencia en ello.
Plan de calidad: a menudo conviene definir un conjunto de especificaciones para los

niveles de calidad requeridos, ya que suele ser necesario no sólo realizar ciertas tareas,
sino hacerlo con una calidad determinada. Puede ser útil, como primer control de
calidad, elaborar tablas para comparar las actividades definidas en el proyecto con los
entregables, objetivos, stakeholders, etc.
Diagrama de precedencias: las actividades en las que se ha descompuesto el proyecto a

menudo son interdependientes. Pueden ser dependencias lógicas (por ejemplo, no se
puede buscar editor hasta conocer el tema del libro) o por limitación de recursos (si una
persona tiene que hacer dos actividades en sitios diferentes, éstas tendrán que ocurrir

de forma secuencial), o dependencias fijadas intencionadamente (es recomendable

mantenerlas al mínimo, ya que reducen la flexibilidad). Todas estas dependencias se
pueden recoger en un diagrama, para lo cual, en casos complejos, se puede utilizar
herramientas informáticas. La Figura 7 muestra un diagrama de precedencias para el
ejemplo simplificado de una merienda infantil, donde cada actividad se presenta como
un nudo y las flechas entre ellos indican dependencias. Nótese que el lector puede no
coincidir con las precedencias tal como las hemos mostrado. Éste es uno de los
beneficios de realizar la fase de planificación en equipo, ya que se ponen sobre la mesa
aspectos en los que quizá no hay un acuerdo unánime y ello permite su revisión.
Figura 7
Diagrama de precedencias
A - Lista C - Comprar
invitados bocadillos
D - Comprar
Inicio Fin
bebida
B - Alquilar E - Montar
salón mesas
Estimaciones: para poder planificar el proyecto, debemos estimar la duración, el coste

y la necesidad de recursos de cada actividad identificada en la descomposición, y, a
menudo, con el reto adicional de no haber realizado dicha actividad con anterioridad.
En algunas ocasiones esto consistirá, más que en realizar una estimación, en fijar un
objetivo (como el presupuesto de gasto o la duración de la actividad). En ocasiones lo
difícil es gestionar la interrelación entre la duración, el coste y los recursos. Existen
métodos, como el Delphi (un proceso para buscar el consenso entre expertos), que
pueden ayudar en las estimaciones.
Camino crítico y cadena crítica: el camino crítico corresponde al recorrido más largo en
una red de actividades y, por tanto, determinará la duración total del proyecto. Si la
duración de una de las actividades en el camino crítico aumenta, todo el proyecto
incrementará su duración en la misma proporción. El resto de actividades no críticas,
en cambio, poseen cierta holgura (hasta alcanzar el punto en el que su incremento sea
tan grande que las convierta en críticas15). Herramientas como el diagrama de Gantt
facilitan este tipo de análisis. En la Figura 8 se muestra el diagrama de precedencias
con la duración de cada actividad (en el círculo, en horas laborables) y su diagrama de
Gantt correspondiente. Podemos ver que las actividades «Alquilar salón» y «Montar
mesas» son actividades críticas (juntas forman el camino crítico) y determinan, por
tanto, que la duración mínima del proyecto sea de seis horas.
15 Efecto similar al de los cuellos de botella en los procesos (véase la nota técnica de Alejandro Lago, Philip Moscoso y Marc
Sachon, «Gestión de la capacidad en sistemas de operaciones», PN-464, IESE, abril de 2010). (Disponible en IESEP)

Figura 8
Camino crítico del proyecto
A -Lista 1 C - Comprar 2
invitados bocadillos
D - Comprar 2
Inicio Fin
bebida
B - Alquilar E - Montar
salón 4 mesas 2
Actividades
E - Montar
mesas
D - Comprar
bebida
C - Comprar
bocadillos
B - Alquilar
salón
A - Lista
invitados
Horas
1 2 3 4 5 6 7
Obsérvese que las tareas no críticas (por ejemplo, «Comprar bocadillos») podrían demorarse o
alargarse hasta una hora (como muestra la barra más clara en el diagrama de Gantt) sin que
esto tuviera ningún impacto en la duración total del proyecto.
Si, adicionalmente, tomamos en consideración los recursos necesarios para realizar las tareas,
surgirán ocasiones en las que la secuencia de actividades asumida no será practicable.
Deberemos, entonces, proceder a eliminar los conflictos por el uso de recursos (es decir, nivelar
los recursos; por ejemplo, porque un recurso es requerido para dos actividades paralelas). La
secuencia de actividades que determina la duración una vez consideradas las precedencias
y necesidades de recursos se denomina cadena crítica. En el ejemplo de la merienda que hemos
usado hasta ahora, si quien compra los bocadillos también compra la bebida (y asumiendo que
no se pueden realizar ambas actividades en el mismo sitio), el diagrama de Gantt debería
modificarse para reflejar esta nueva información teniendo en cuenta la limitación de recursos,
lo que resultaría en una duración de siete horas y una cadena crítica compuesta por las
actividades «Lista de invitados», «Comprar bocadillos», «Comprar bebida» y «Montar mesas»,

como se muestra en la Figura 9. La falta de realización (o realización incorrecta) de este tipo de

análisis es una de las causas principales de los retrasos en los proyectos.
Figura 9
Cadena crítica del proyecto
Actividades
E - Montar
mesas
D - Comprar
bebida
C - Comprar
bocadillos
B - Alquilar
salón
A - Lista
invitados
Horas
1 2 3 4 5 6 7
Planes y presupuestos del proyecto: una vez resueltos los conflictos entre los recursos y
el tiempo, se pueden elaborar presupuestos y planes (de actuación, comunicación,
calidad, etc.) detallados para el proyecto.
Hitos: un hito es un evento que representa un logro importante en el avance del proyecto
(generalmente de interés para el conjunto de sus stakeholders). El comienzo y el final son
dos hitos fundamentales en todo proyecto. Los hitos también sirven de punto de control,
y pueden ser asociados con decisiones sobre continuar o no con el proyecto según la
valoración del cumplimiento del hito (véase el apartado sobre compuertas de control).
3.3.1. Riesgos e incertidumbres en la gestión de proyectos16
Todo proyecto, por muy buena que sea su gestión, se enfrenta a cierta incertidumbre y
riesgos que pueden afectar al desarrollo del mismo. Es conveniente diferenciar, al menos,
estos dos tipos de fenómenos en la gestión de proyectos:
Incertidumbre: representa posibles variaciones de elementos conocidos en términos de

coste, tiempo, etc. En nuestro ejemplo, en función del tráfico podemos tardar más
o menos tiempo en ir a comprar las bebidas. La medida habitual frente a la
incertidumbre consiste en incorporar colchones en el plan para poder absorber estas
variaciones. Por ejemplo, en el plan de preparación de la merienda, podemos querer
16 Para más detalle, véase la nota técnica de Jaume Ribera, «El ciclo de vida del proyecto: la incertidumbre y la gestión del riesgo»,
PN-462, IESE, febrero de 2011. (Disponible en IESEP)

incorporar un colchón de una hora al final del proyecto para compensar las posibles
desviaciones por incertidumbre, y por tanto planificar la realización del proyecto en
ocho horas.
Riesgos: son eventos específicos que pueden ocurrir con una determinada probabilidad
y tendrán un consiguiente impacto en alguna de las características del proyecto
(duración, coste o alcance). Como se trata de eventos específicos, la actuación habitual
consiste en lo siguiente: (1) identificarlos, (2) estimar su impacto y probabilidad, y
(3) preparar planes de actuación para los más significativos. De este modo, en el
ejemplo de la merienda, podemos imaginar que ninguno de los salones que conocemos
está disponible para acogerla. En este evento, podríamos contemplar la posibilidad de
(a) cancelar la merienda, o (b) hacerla en casa, lo que requeriría un trabajo adicional
de preparación previa y de limpieza posterior.
Es muy conveniente realizar un estudio de incertidumbres y riesgos al planificar el proyecto,

ya que de esta forma se mejora mucho la probabilidad de éxito del mismo, al poder modificar
el proyecto para eliminar algunos riesgos, disponer de tiempo para preparar los planes
alternativos y no tener que improvisar en situaciones de crisis.
3.4. Ejecución y seguimiento de proyectos17

Esta fase engloba la ejecución y el seguimiento del proyecto. La ejecución consiste en asignar
recursos a las actividades de manera que se realicen dentro de su ventana de tiempo
(asignada por el plan de trabajo), e indicando al responsable qué otras actividades y recursos
dependen de la misma para que puedan ser informados en caso de incidencias. El
seguimiento consiste en comprobar que se está consiguiendo lo que el plan del proyecto
preveía en el plazo establecido y dentro de los presupuestos, y, en caso contrario, detectar las
variaciones y evaluarlas con prontitud para poder corregirlas (o corregir los planes si fuera
preciso). Un sistema de seguimiento debería: (1) dar una información lo bastante completa a
quien debe tomar las decisiones sin crear una carga excesiva de trabajo a los que realizan
el proyecto; (2) presentar avisos con la antelación suficiente para que se pueda actuar lo
antes posible cuando sea necesario; (3) ser aceptado por el equipo del proyecto y la dirección,
proporcionándoles información comprensible y adecuada a sus necesidades; y (4) permitir
que se agreguen diversos niveles de detalle a partir de la misma información.
En todos los proyectos habrá desviaciones de especificaciones (de alcance y/o de calidad),
plazos y costes. Por tanto, lo fundamental no consiste en saber si hay desviaciones, sino si
éstas son tan relevantes como para que el responsable del proyecto tenga que actuar.
El sistema de seguimiento debe, por tanto, diferenciar el ruido de la señal y detectar si la
variación requiere atención o se trata de una desviación ya cubierta con los colchones de
incertidumbre que se han considerado en la fase de planificación. Para ello es preciso
identificar en cada momento las actividades que pueden tener un mayor impacto en el
proyecto, bien porque sufran demoras, incrementen su coste o afecten a la calidad
o el alcance. A menudo se utiliza una codificación de tipo semáforo, indicando en rojo
aquellos apartados del proyecto que presentan dificultades, en amarillo los que se están
17 Para más detalle, véase la nota técnica de Jaume Ribera «El ciclo de vida del proyecto: seguimiento», PN-463, IESE, febrero
de 2011. (Disponible en IESEP)

desviando y pudieran ser rojos en un futuro cercano, y en verde los que siguen el plan
establecido. En algunas ocasiones se puede incorporar también el color azul para indicar
aquellas partes que superan ampliamente las expectativas, a fin de que también se puedan
revisar y, de este modo, se pueda aprender de ellas.
3.4.1. Mecanismos de seguimiento
Para el seguimiento del proyecto, es útil determinar al inicio la frecuencia con la que se
deseará realizarlo (por ejemplo, con periodicidad semanal o mensual). El responsable
administrativo del proyecto deberá recopilar y sintetizar convenientemente la información
sobre el avance y los costes, así como las incidencias y variaciones acontecidas desde el
último informe de seguimiento que se realizó.
El seguimiento en especificaciones (de alcance y calidad) suele ser muy técnico y específico
para cada proyecto. Como ya hemos mencionado en la sección de planificación, para algunas
partes del proyecto en las que exista menor consenso o experiencia previa es conveniente
haber definido previamente unas métricas de calidad, que podrán ser evaluadas en el
momento del seguimiento para establecer su cumplimiento.
Para el seguimiento en costes, todas las actividades «suman» proporcionalmente a su peso. De

cara al seguimiento del proyecto en términos de plazos, en cambio, no todas las actividades
tienen el mismo impacto (las actividades no críticas no lo afectan). Por ello, presentamos a
continuación algunas herramientas para este tipo de seguimiento.
La herramienta más extendida es el diagrama de Gantt doble, que muestra la posición en el

tiempo de cada actividad de acuerdo con el plan inicial y su posición real (para las
actividades ya completadas) o la situación prevista (para las que aún no se han completado).
Así, la Figura 10 muestra, para el proyecto de la merienda, el plan previsto inicialmente
(barra lisa) y la situación al cabo de la tercera hora transcurrida (barra con rayas).
Observamos que las tareas «Lista de invitados» y «Alquilar salón» ya se han completado (la
segunda con antelación a lo previsto, aunque esto no tendrá impacto en el proyecto),
mientras que la actividad «Comprar bocadillos», que según el plan ya debía haber finalizado,
empezó con retraso y sólo se ha completado al 80%, por lo que se estima que finalizará
media hora más tarde y arrastrará al resto de actividades. En el momento analizado se prevé,
por tanto, la finalización del proyecto con media hora de demora. Este análisis permite no
sólo anticipar acontecimientos, sino también evaluar la necesidad de posibles ajustes.

Figura 10
Diagrama de Gantt de seguimiento
Actividades Instante de
seguimiento
E - Montar 0%
mesas
D - Comprar 0%
bebida
C - Comprar
80%
bocadillos
B - Alquilar 100%
salón
A - Lista 100%
invitados
Horas
1 2 3 4 5 6 7
Una versión simplificada del mecanismo anterior consiste en el seguimiento de hitos,

definidos como eventos (habitualmente, el inicio o final de una actividad importante) que
marcan un punto significativo en el desarrollo de un proyecto. Así, un proyecto complejo de
construcción que incluya un millar de actividades se puede resumir en unos pocos hitos
(como el inicio del proyecto, la finalización de la cimentación, la finalización del tejado, etc.,
y por último la finalización del proyecto), y de este modo se podría centrar el seguimiento del
proyecto en comparar cuándo estaban previstos estos hitos, según el plan, y cuál es en cada
momento la mejor previsión de cuándo se alcanzarán (o si han sido alcanzados con retraso).
Otra forma simple y eficiente de seguimiento de un proyecto consiste en centrarse en la

cadena crítica (o el camino crítico, si los recursos no son una limitación) y determinar en
cada instante (1) el porcentaje de ejecución del camino crítico, y (2) el porcentaje utilizado
del colchón para las incertidumbres en la duración de las actividades (véase la Figura 11).
Siguiendo con nuestro ejemplo de la merienda, al finalizar la tercera hora se ha completado
un 51,4% de la cadena crítica (el 100% de «A», el 80% de «C», y el 0% de «D» y «E»), y hemos
utilizado un 50% del colchón de una hora que habíamos previsto (véase la sección 3.3.1).
Mientras la utilización del colchón no supere al avance en la cadena crítica, en general el
proyecto estará progresando razonablemente bien. Como se muestra en la Figura 11, con un
ejemplo de las tres primeras horas de duración del proyecto de la merienda, se pueden dividir
las áreas con los colores de un semáforo y así crear un diagrama (denominado «de fiebre»)
para visualizar el seguimiento de estas dos variables.

Figura 11
Diagrama de fiebre
% Uso
Colchón
100
75
H2
50 H3
25
0 H1
0 25 50 75 100
% Cadena
Crítica
Para el seguimiento de costes también se puede aplicar un diagrama de fiebre equivalente,

indicando el porcentaje de proyecto realizado (en coste presupuestado) y el colchón de coste
utilizado (si se definió uno). En el seguimiento de costes también es habitual una descripción
por partidas (por ejemplo: salarios, compras de materiales, subcontrataciones, etc.). Por cada
una de las partidas se presentarán, al final de un determinado periodo de seguimiento, los
costes presupuestados para dicho periodo y los costes reales, así como los acumulados hasta
la fecha, tanto presupuestados como reales. Es importante observar que en este tipo de
seguimiento no se supervisa el progreso realizado, por lo que podría suceder que los costes
presupuestados y los reales estén en línea (por ejemplo por el pago de servicios externos),
aunque en realidad el progreso del proyecto fuera insatisfactorio. Para tener en cuenta tanto
el progreso como los costes se utilizan los cálculos de «valor ganado»18.
Adicionalmente a los seguimientos de proyecto descritos, es recomendable incorporar a la

agenda de las reuniones de seguimiento (o al informe de seguimiento19) una actualización de
los riesgos del proyecto, así como de cualquier cambio que se haya acordado en la definición
del proyecto.
3.4.2. Resolución de conflictos
Existen muchas causas de posibles conflictos en los proyectos, y algunas de ellas son
inherentes a la naturaleza de los mismos. Es muy habitual, por ejemplo, que en la
planificación se olviden actividades que luego resultan necesarias. Sin embargo, hay
bastantes conflictos que podrían ser evitados mediante una buena gestión y favoreciendo una
actitud de honestidad y apertura ante los problemas que se van encontrando. Aparte del ya
18 Para una descripción detallada de las técnicas de valor ganado, véase la nota técnica de Jaume Ribera, «El ciclo de vida del
proyecto: seguimiento», PN-463, IESE, febrero de 2011. (Disponible en IESEP)
19 El informe puede limitarse a una sola página, como se sugiere en C. Campbell y M. Campbell (2013), The new one-page
project manager, John Wiley & Sons, Nueva Jersey.

mencionado scope creep en el alcance, hay algunos comportamientos y actitudes habituales

de los que todos deberían ser conscientes para tratar de evitarlos (en el Anexo 4 aludimos a
algunos errores típicos en la gestión de proyectos).
El principal antídoto para muchos de los conflictos que pueden aparecer en un proyecto
consiste en mantener reuniones periódicas en las que, de forma breve, cada miembro del
equipo informa sobre las partes bajo su responsabilidad. En estas reuniones se debe fomentar
la comunicación honesta, con la convicción de que un problema detectado a tiempo y
compartido con el resto del equipo es siempre más fácil de resolver que uno escondido.
Otra fuente de conflictos reside en las diferencias entre las expectativas de comunicación y
participación que tienen los distintos stakeholders y lo que realmente luego sucede. Muchos
directivos esperan que se les informe en detalle sobre los avances de un proyecto en el que
participen subordinados suyos, y si esta comunicación no se produce se pueden sentir
«puenteados» y, en consecuencia, pueden decidir reducir la dedicación de su gente al
proyecto. Por ello es útil planificar también las comunicaciones que generará el proyecto
(a quién, qué, cuándo, etc.).
Una vez identificado un problema en el proyecto, las opciones de recuperación pueden

consistir en una de estas opciones, en función de la gravedad del problema:
1. Tratar de volver al plan previsto, habitualmente repitiendo algunas de las actividades

defectuosas y con un mayor consumo de recursos.
2. Modificar los objetivos del proyecto, ya sea reduciendo las especificaciones,

aumentando el presupuesto y/o extendiendo los plazos.
3. Abandonar el proyecto. Esta última opción (detener un proyecto antes de su

finalización) debería ser más común de lo que realmente es en la práctica, ya que a
menudo, una vez eliminada la incertidumbre inicial, los hechos pueden sugerir que el
proyecto no debiera realizarse. Sin embargo, existen numerosos factores que dificultan
la detención de un proyecto. En primer lugar está la propia motivación de los
implicados, así como las presiones sociales para evitar mostrarse como «los que no
terminan sus proyectos». A ello se une a menudo el hecho de que numerosos proyectos
se definen inicialmente de una forma que no permite detenerlos sin incurrir en unos
costes muy elevados, y también la no consideración de los costes a fondo perdido
(sunk costs).
3.5. Finalización de proyectos

Decíamos que todo proyecto tiene un hito natural, que es su finalización. Pero este hito
realmente da paso a una última fase que comprende una serie de actividades a realizar y
cuya gestión tiene una gran importancia, no sólo para el éxito del proyecto en cuestión, sino
también en relación con el aprendizaje para proyectos futuros. Demasiado a menudo, sin
embargo, esta fase en la práctica sufre por las prisas y los atajos metodológicos, ya que los
responsables priorizan nuevos cometidos.
Lo primero que hay que acometer en esta fase final es una revisión en profundidad de los
resultados alcanzados y así contrastarlos con los objetivos acordados con los stakeholders.

Hay que evaluar conjuntamente si los objetivos marcados siguen siendo válidos y en qué
medida han sido realmente alcanzados. De hecho, en ocasiones, durante la finalización se
consiguen reencauzar algunos proyectos a ojos del cliente gracias a estas revisiones
conjuntas; por ejemplo, explicando en profundidad el porqué y el cómo de modificaciones
o cambios que se hayan producido en el alcance, fecha o coste. Pero, al mismo tiempo, el
equipo del proyecto tendrá que evitar que el cliente intente aprovechar esta revisión para
añadir elementos nuevos a la definición del proyecto que no fueran acordados así al
comienzo.
A continuación de dicha revisión, habitualmente se ofrecen tres vías para el cierre de un

proyecto:
1. Se concluye que el proyecto no ha cumplido los objetivos y se decide detener todas las
actividades (como ya indicamos, esto puede ocurrir en cualquier fase de la vida de un
proyecto). Esto puede significar, por ejemplo, que no se implantarán los resultados del
proyecto en la organización o que no se comercializarán los productos desarrollados.
2. El equipo del proyecto se «transfiere» a sí mismo los resultados de éste y pasa a ser
quien utiliza o vende dichos resultados (por ejemplo, en cuanto a nuevos productos o
servicios desarrollados).
3. El equipo transfiere o integra los resultados en el área operativa de la empresa. Esta

vía, a su vez, puede requerir un gran número de actividades a realizar, que habrá que
gestionar cuidadosamente. Por ejemplo, si en el proyecto se ha definido un nuevo
proceso administrativo, en esta fase se deberá gestionar la transferencia e implantación
del proceso al correspondiente departamento. En ocasiones, el alcance es tan grande
que hace recomendable definirlo desde el inicio como una fase más de la ejecución.
En tercer lugar, esta última fase ofrece la oportunidad de resumir las lecciones aprendidas del
proyecto, lo cual debe:
Cubrir los diferentes aspectos del proyecto, tanto en relación con el «contenido» del
proyecto como con el proceso de gestión del mismo. Hay que revisar las lecciones
aprendidas, por tanto, desde la perspectiva del business case, pero también desde la
metodología de gestión empleada o el rendimiento de los integrantes del proyecto.
Tener lugar relativamente pronto, para que el proyecto siga fresco en la memoria de los
implicados. En el caso de proyectos muy largos, puede ser recomendable realizar
sesiones intercaladas durante el proyecto sobre lecciones aprendidas.
Incluir, en cierta medida, en la reflexión a todos los stakeholders que puedan aportar
reflexiones interesantes.
Codificar las lecciones aprendidas de alguna forma que facilite su diseminación a

terceros dentro de la organización.
Finalmente, en los casos en los que se considere que el proyecto ha cumplido lo fijado,
recomendamos cerrar el proyecto con alguna celebración. Incluso en aquellos casos en los
que no todo ha salido a la perfección, si el equipo ha trabajado duro se merece un
reconocimiento en alguna forma. Celebrar el éxito genera ganas de nuevos éxitos y anima a

los empleados a realizar nuevamente un buen trabajo en el futuro, y al mismo tiempo envía
una señal positiva a otros equipos.
4. La mejora en la gestión de proyectos

Concluiremos esta nota técnica con algunas ideas adicionales sobre principios de gestión
operativa que pueden ayudar a mejorar la gestión de proyectos, como complemento de las
ideas y herramientas concretas que hemos presentado en las secciones anteriores. No
olvidemos que los proyectos son una de las formas en las que la empresa organiza sus
operaciones y, por tanto, son susceptibles a la aplicación de los métodos de mejora tipo lean
que se han desarrollado en el ámbito de la gestión de operaciones.
4.1. Eliminar la muda

Uno de los conceptos clave en la gestión lean es la eliminación del despilfarro (muda en la
terminología original de Toyota). Aquellas actividades que consumen tiempo, esfuerzo o coste
pero no contribuyen a añadir valor al cliente del proyecto, en principio, se consideran muda.
Para llevar a cabo esta identificación habrá que verificar qué es lo que valora el cliente y qué
no, y de este modo ver si las actividades realmente pueden ser eliminadas. En términos
generales podemos, por tanto, clasificar las actividades de un proyecto en cuatro categorías:
1. Aquellas que añaden valor al proyecto: en el proyecto de preparar una merienda, la

compra de los bocadillos añade valor, ya que es un elemento deseado en el resultado
del proyecto.
2. Aquellas que son necesarias pero no añaden valor: en el proyecto de la merienda, el

desplazamiento desde la tienda de bocadillos a la tienda de bebidas puede ser
necesario, pero no añade valor al proyecto.
3. Aquellas que no son necesarias ni añaden valor: la acción de envolver los bocadillos
en la tienda de uno en uno, cuando después tendremos que desenvolverlos para
colocarlos en la bandeja en la mesa, añade tiempo y coste pero no valor para el cliente
(consumidor) final.
4. Las esperas entre actividades: esperar durante quince minutos la llamada de nuestro
compañero para que nos indique qué tipo de bocadillos hay que comprar una vez
llegamos a la tienda sería, deseablemente, algo a evitar.
En un proyecto podemos identificar y clasificar las actividades en estas cuatro categorías, y a

continuación determinar qué se puede hacer para (a) eliminar las actividades de los tipos 3 y
4, (b) eliminar, o al menos minimizar, las actividades del tipo 2, y (c) potenciar, de forma que
añadan más valor o reduzcan su coste y tiempo, las actividades del tipo 1.
Puede resultar un ejercicio útil desarrollar, dentro de una empresa, una lista (o clasificación)
específica de las mudas en la gestión de proyectos, ya que, al ser desarrollada por las propias

personas que trabajan en los proyectos, es más fácil que después identifiquen la muda y
actúen sobre ella20.
4.2. Revisar los supuestos

Otra línea de investigación que ha resultado productiva en la mejora de la gestión de
proyectos ha sido el descubrimiento de que algunos supuestos implícitos en ésta no eran
lógicos y, por tanto, se podía mejorar mucho con enfoques alternativos. Por ejemplo, en la
contratación de obras se acostumbra a preparar un pliego de condiciones en el que se
especifica en detalle lo que se desea construir y se establecen un plazo máximo y un coste
orientativo. A partir de este pliego, las compañías que se presentan al concurso preparan
propuestas que cumplan los requisitos de especificaciones y plazos con el menor coste
posible, ya que, salvo en casos de bajas temerarias en las ofertas, se concede el proyecto a
quien se comprometa a realizarlo con el menor coste. Esto conduce a la denominada
«maldición del ganador», ya que quien finalmente se lleva el proyecto lo hace a un coste con
el que los demás contendientes creen que no es realista hacerlo. Ello, por lo general, suele
llevar a dos situaciones: o bien el proyecto acaba siendo más caro de lo que inicialmente
se estableció (el ofertante esgrimirá, sin duda, sus justificaciones), o bien el proyecto no
cumplirá las especificaciones acordadas. Adicionalmente, con un presupuesto a la baja, en el
momento en que aparece un evento no previsto está asegurada una discusión entre el cliente
y el constructor para dilucidar quién asume el coste de los riesgos no contemplados, lo que
habitualmente termina en demandas judiciales y en un retraso del proyecto.
En la construcción de la terminal 5 del aeropuerto de Heathrow21 en Londres, la entidad BAA

(British Airport Authorities) siguió un enfoque novedoso al desarrollar un tipo de contrato de
coste más incentivo, denominado «T5 Agreement»22, en el que el cliente se comprometía a
pagar al constructor los costes incurridos más un margen de beneficio. Con este formato, los
riesgos los asumía el cliente, BAA, que trabajaba en colaboración con los equipos del primer
nivel de contratación para crear soluciones innovadoras que pudieran reducir los plazos,
mejorar las prestaciones o reducir los costes sin que el constructor viera amenazados su
márgenes. Al gestionar así el riesgo, se evitaron las relaciones de confrontación y se crearon
incentivos de colaboración para motivar a los equipos a trabajar conjuntamente en la
solución de problemas en vez de buscar maneras de generar pagos adicionales o lanzarse
a disputas judiciales sobre cambios en el alcance.
Enfoques similares, basados en un cambio de principios, permitieron a Visteon, en China,

rediseñar con éxito el interior del automóvil Buick Regal en un tiempo récord, o a Reson23, un
fabricante danés especializado en sonares acuáticos , conseguir reducir el plazo de desarrollo de
20 En esta línea es interesante citar el Manual contra el despilfarro, desarrollado por encargo de Rafael del Pino y Moreno para
la empresa Ferrovial en el año 1962 con el objetivo de guiar a sus directivos y mandos intermedios en la identificación y
eliminación de la muda en sus proyectos. Puede consultarse su reedición online en www.ferrovial.com.
21En este ejemplo de la T5 nos centramos en el proyecto de construcción, que consideramos un éxito, y no en el de la puesta en
marcha operativa, que, como el lector conocerá por la prensa, no lo fue tanto.
22 Para una información más detallada, véase el artículo de A. Davies, et al. (2009), «Innovation in megaprojects: Systems
integration at London Heathrow Terminal 5», California Management Review; o el caso de N. Gil (2008), «BAA: The T5 project
agreement», Manchester Business School.
23 Para más información sobre Reson, véase el caso de T. Vollman, et al. (2000), «Reson: Making development teams
accountable for short project cycles», IMD.

nuevos productos de tres años a tres meses. Un cambio de principios parecido se aplicó en
Novo Nordisk Engineering 24 , que pasó de construir plantas de producción de productos
farmacéuticos en plazos que oscilaban entre los treinta y los treinta y seis meses a alcanzar un
tiempo récord de once meses.
Cuando enfocamos los proyectos buscando conjuntamente formas creativas que permitan
reducir el plazo y mejorar las especificaciones controlando los costes, en lugar de ceñirnos a
cumplir las especificaciones y plazos con el menor coste, nos acercamos mucho más a lo que
genera valor para los stakeholders. Este enfoque precisa de una nueva visión de los proyectos,
ya que aporta más valor para el cliente pero, habitualmente, también mayores riesgos para el
proveedor. Ello exige, por tanto, que se definan mecanismos compensatorios que sean
satisfactorios para las diferentes partes. En este tipo de enfoque se requiere una cultura de
emprendimiento que anime a todos los participantes a proponer novedades y tomar riesgos
controlados.
Finalmente, también existen voces críticas que afirman que una sistematización de la gestión
excesivamente secuencial y por fases puede limitar negativamente la flexibilidad y la innovación
en los proyectos en entornos que requieren de ellas25 (los que, en el Anexo 1, denominamos
«perdidos en la niebla»). Personalmente, recomendamos que no se olvide el carácter de
aprendizaje organizacional que un proyecto tiene para una empresa, y asimismo aconsejamos
complementar los enfoques por fases con procesos en paralelo o iterativos, así como procesos de
exploración por prueba y error en el caso de este tipo de proyectos más innovadores. Nuestra
experiencia nos sugiere que sistemática no está reñida con creatividad e innovación.
5. Resumen y conclusiones
La gestión de proyectos es una actividad a la que muchos directivos le dedican una parte muy
importante de su tiempo, pero que, desgraciadamente, a menudo presenta una tasa de éxito
más bien baja. En la presente nota hemos presentado una metodología para la gestión de
proyectos. En primer lugar, hemos argumentado las ventajas de implantar una sistematización
así en las empresas, y a continuación hemos detallado la metodología a lo largo del ciclo de
vida tipo de un proyecto. Hemos hecho hincapié en que el éxito de un proyecto, en gran
medida, se dilucida antes de haberlo empezado siquiera a ejecutar, es decir, a partir de su
adecuada selección, definición y planificación. Asimismo, hemos detallado una serie
de herramientas que pueden facilitar en la práctica la gestión de los proyectos en cada una de
las fases.
Confiamos en que una metodología como la aquí presentada (o variantes de la misma) pueda
ayudar a los directivos a aumentar la tasa de proyectos completados con éxito. La
metodología, no obstante, sólo puede ser una ayuda a la verdadera clave para conseguir
gestionar proyectos con éxito de forma consistente y sostenible en una empresa: el desarrollo
de una buena cultura de gestión de proyectos.
24 Véase C. Cordon, et al. (2006), «Novo Nordisk Engineering: Running for fast-track project execution», IMD.
25 Véase el artículo de S. Lenfle y C. Loch (2010), «Lost roots: How project management came to emphasize control over
flexibility and novelty», California Management Review, 53(1), pp. 32-55.

Anexo 1
Clasificaciones de tipos de proyectos
Existen numerosas clasificaciones de proyectos y, a continuación, revisaremos algunas de las

más relevantes. En primer lugar, podemos diferenciar entre proyectos internos y externos:
los externos son aquellos que tienen un cliente organizativamente externo a la organización
y reconocido formalmente como tal. Este cliente evaluará lo que recibe, y puede negarse a
pagar o exigir compensaciones si no se cumplen las condiciones de alcance, plazo o coste
acordadas. La existencia de un cliente externo suele conllevar un mayor rigor en la gestión
del proyecto, ya que su falta de éxito tiene consecuencias muy tangibles. Los proyectos
internos, por contra, son más proclives a no ser llevados con el mismo rigor en la práctica.
No recomendamos utilizar una metodología de gestión diferente para los proyectos internos,
sino definir igualmente la figura de un cliente formal (véase el apartado sobre la definición).
Una segunda clasificación, abreviada NTCP26 (del inglés novelty, technology, complexity and
pace), tiene en consideración cuatro dimensiones:
a) Novedad: el grado de novedad que conlleva el proyecto comparativamente a lo que la

organización ha llevado a cabo con anterioridad. En esta dimensión se clasifican los
proyectos como: (i) derivados, consistentes en la modificación de alguna característica
menor de productos o procesos ya existentes; (ii) plataforma, basados en la creación de
una nueva generación de productos, lo que requiere un mayor análisis e investigación
previa; y (iii) rompedores (breakthrough), en los que los diseños iniciales son sólo
indicativos y los ciclos de ensayo y error serán una parte importante del proyecto.
b) Tecnología: el tipo de tecnología que se utilizará, su disponibilidad y la experiencia

que tiene la organización en su uso. En esta dimensión los proyectos se clasifican en
tres categorías: (i) baja tecnología, cuando el proyecto utiliza una tecnología bien
conocida o tecnología nueva pero en un área no crucial; (ii) tecnología media, cuando
el proyecto usa una tecnología no utilizada habitualmente en la organización en un
área importante del proyecto; y (iii) alta tecnología, cuando es preciso desarrollar una
tecnología nueva, no existente aún, que será crucial en el proyecto.
c) Complejidad: el grado de complejidad del proyecto, el producto, el proceso, las

relaciones que se deben establecer entre los participantes, etc. En esta dimensión
los proyectos serán: (i) de ensamble, cuando existe integración entre los componentes
(productos, departamentos…) o éstos fueron ya diseñados para ser integrados; (ii) de
sistema, cuando el proyecto incluye elementos y subsistemas que realizan diversas
funciones no coordinadas en la actualidad y que tendrán que integrarse para el éxito del
proyecto; y (iii) de colección, cuando el proyecto precisa una colección de sistemas u
organizaciones dispersas que hay que aunar con vistas a un objetivo común que no
necesariamente es compartido.
26 Definida en D. Dvir y A. J. Shenhar (2007), Reinventing project management, Harvard Business School Press.

Anexo 1 (continuación)
d) Ritmo: la urgencia del proyecto, en comparación con lo que se entiende como su plazo
normal o natural. En esta dimensión, los proyectos son: (i) normal, cuando se dispone
de un plazo que habitualmente es considerado razonable para la ejecución del
proyecto; (ii) crítico, cuando el cumplimiento de la fecha límite es esencial para el éxito
del proyecto y una demora significa un gran problema; y (iii) extremo, cuando el
proyecto responde a una situación de crisis grave con unos plazos extremadamente
urgentes.
En base a estas cuatro dimensiones se puede establecer el diamante de un proyecto, como se

muestra en la Figura 12. A mayor superficie, más complicada será la gestión del proyecto, lo
que, por ejemplo, puede hacer recomendable un gestor más experto. Esta clasificación
se adecua bien a proyectos en los que se desarrollan nuevos productos o se implementan
nuevos procesos de negocio.
Figura 12
Clasificación de proyectos NTCP
Tecnología
Alta
Media
Baja
Complejidad Colección Sistema Ensamble
Novedad
Derivado Plataforma Rompedor

Normal
Crítico
Extremo
Ritmo
Finalmente, una tercera clasificación, sencilla pero útil, es la que resulta de considerar si, en
el proyecto, sabemos de partida qué se pretende conseguir y cómo se puede conseguir, tal
como se muestra en la Figura 13.

Figura 13
Clasificación en qué y cómo
SI B A
Sabemos qué
NO D C
NO SI
Sabemos cómo
Los proyectos «A», aquellos en los que se conoce de entrada qué se va a hacer y cómo se va a
conseguir, son los más simples ya que, en este caso, se trata sólo de desplegar las actividades
ya conocidas, algo similar a «pintar uniendo números» un dibujo. Los proyectos «B»,
denominados «de búsqueda», son aquellos en los que se conoce lo que se desea pero no se sabe
aún cómo se debe realizar, por lo que, en este caso, una parte importante del proyecto consiste
en buscar la forma de realizarlo. Los proyectos «C», denominados «del síndrome del martillo»27,
consisten en descubrir una posible aplicación para una tecnología o un proceso ya existente.
Son proyectos en los que existe una «solución» y lo que se busca son problemas que se puedan
resolver con ella, como sucede habitualmente en empresas de I+D o de consultoría. Finalmente,
los proyectos «D», también llamados «perdidos en la niebla»28, son los más complejos, ya que en
ellos se debe tratar primero de definir el qué y después el cómo, o viceversa, y conllevan un
proceso iterativo de aprendizaje en el que cada fase se apoya sobre lo aprendido en la fase
anterior. Por lo general son los proyectos que representan un mayor riesgo.
27 Se denominan así porque, habitualmente, quien tiene un martillo (el cómo) se dedica a buscar clavos (el qué), y le parece que
todo puede resolverse con la herramienta de que dispone.
28 Cuando estamos perdidos en un campo con mucha niebla no sabemos qué buscamos realmente, ya que muchas cosas nos
pueden ayudar (una carretera, un pueblo, una vía de tren, una granja…), y tampoco sabemos cómo salir del problema (andando
hacia la derecha, hacia la izquierda, no movernos y esperar que alguien nos encuentre…).

Anexo 2
Planificación agregada de la carga de un proyecto. Ejemplo
A modo de ejemplo, la Figura 14 muestra la previsión de carga acumulada (en días de

trabajo) de los proyectos que tiene asignados un técnico especializado a lo largo de los
próximos ocho meses. En la misma figura, se muestra con una segunda curva la
disponibilidad acumulada del técnico, suponiendo veinte días por mes (el resto asumimos que
los precisa para las actividades relacionadas con su responsabilidad funcional). En el gráfico
podemos ver que existen dificultades a partir del cuarto mes, ya que la curva de demanda
supera a la de capacidad disponible. El problema, además, no es puntual, debido a que su
falta de capacidad se alarga hasta el octavo mes. Esto es una señal clara de que se han
aceptado más proyectos de los realizables con la capacidad disponible. Si no se cambia nada,
los proyectos se demorarán debido a la falta de capacidad del técnico.
Figura 14
Planificación agregada de la carga
200
180
160
140
120
Días de trabajo
100
Dem. Ac.
80
Cap. Ac.
60
40
20
0
0 1 2 3 4 5 6 7 8
Meses
Es importante observar que, en el caso de que las curvas acumuladas demuestren factibilidad,
ésta puede desaparecer cuando se realice el análisis en un periodo más corto (por ejemplo, la
carga promedio en un mes puede ser correcta, pero si toda se concentra en la primera semana
del mes no será factible) o cuando sea imposible avanzar trabajo (por ejemplo, si no se puede
realizar en horas disponibles en enero una carga planificada para febrero).

Anexo 3
Roles de comportamiento en el equipo
Meredith Belbin29 desarrolló a lo largo de los años una identificación de los roles de equipo,
clasificando a las personas en nueve roles de comportamiento (que no de personalidad) que
se dividen a su vez en las siguientes categorías:
Roles de acción:
Impulsor (shaper): personas que desafían al equipo a mejorar, proporcionando la

energía necesaria para mantener al equipo en movimiento.
Implementador (implementer): personas eficaces en conseguir que las cosas se hagan,

trabajando de forma sistemática y eficiente.
Finalizador (finisher): personas con la habilidad de terminar los proyectos. Son buenas
para pulir los trabajos, localizar errores y finalizar las tareas con altos estándares de
calidad.
Roles de relación:
Coordinador (coordinator): personas eficientes en presidir reuniones, coordinar sesiones

de trabajo y en guiar a los otros miembros hacia la consecución de los objetivos.
Cohesionador (teamworker): personas que apoyan al equipo y se aseguran de que todos

sus miembros trabajen conjuntamente de forma efectiva; son buenos negociadores,
diplomáticos y perceptivos.
Investigador de recursos (resource investigator): personas que proporcionan

conocimiento sobre aspectos externos al equipo y que, al mismo tiempo, son capaces
de comunicar las ideas del equipo al exterior.
Roles de pensamiento:
Cerebro (plant): personas altamente creativas que destacan resolviendo problemas de

manera poco convencional y, a veces, tienden a ignorar ciertas restricciones o barreras.
Monitor/evaluador (monitor/evaluator): personas que proporcionan una visión lógica,

pueden realizar juicios imparciales y sopesar las distintas opciones de una forma
desapasionada.
Especialista (specialist): personas que tienen un conocimiento especializado de lo que

se precisa para el proyecto, enfocándose en su área de especialización.
29 Esta parte de la nota se basa en R. M. Belbin (2010), Team roles at work, Butterworth Heinemann (disponible en español bajo
el título Roles de equipo en el trabajo).

Para determinar qué rol es el preferido y adecuado para cada persona existen cuestionarios
de autopercepción y de evaluación30. Es interesante anotar que, en su investigación, Belbin
descubrió que todos los papeles eran esenciales para conseguir el éxito de un equipo, y que la
clave reside en conseguir un buen equilibrio. Así, cuando se configura un equipo de proyecto
es importante no limitar el análisis a los conocimientos de las personas, sino también
considerar el comportamiento de sus miembros y, en caso de ser necesario, reasignar algunos
participantes para mejorar el equilibrio a este respecto.
30 Para mayor información consulte http://www.belbin.com.

Anexo 4
Principales errores en la gestión de proyectos
Existen infinidad de causas que pueden explicar el fracaso de un proyecto, y a menudo se
presentan en combinación. Resumimos aquí simplemente algunos errores importantes que
se presentan habitualmente en la gestión de proyectos, y referimos a otras notas técnicas para
mayor detalle.
En la preparación del proyecto
1. Falta de rigor en el análisis del impacto estratégico de los proyectos (que lleva a
seleccionar proyectos que no se justifican realmente en relación con su consumo de
recursos).
2. Desconocimiento o valoración inadecuada de la disponibilidad de recursos de cara a

realizar los proyectos (lo que conduce a sobrecargar recursos y demorar proyectos).
3. Incapacidad de priorizar los proyectos (que lleva a dispersarse en demasiados

proyectos a la vez para contentar a todos).
4. Definición de los proyectos sin la suficiente claridad y el consenso necesario para

evitar un scope creep (si el alcance es muy amplio debería dividirse en varios
proyectos).
5. Gestión inapropiada de las expectativas de los stakeholders antes, durante y después

de finalizar el proyecto (habitualmente debido a una comunicación insuficiente).
6. Equipo de proyecto inadecuado (u otros stakeholders ignorados) o sin atribuciones

claras.
7. Planificación inapropiada del proyecto (por ejemplo, duraciones negociadas y

no estimadas, duraciones impuestas desde la dirección, exceso de optimismo,
desconsideración de los colchones, etc.).
8. Evaluación de riesgos no sistemática (y ausencia de diferenciación de la incertidumbre).
En la ejecución del proyecto
9. Demora en el inicio de las actividades del proyecto, alargada tanto como permita el
plan («síndrome del estudiante»), que anula los posibles colchones de protección ante
la incertidumbre.
10. Demora máxima en la comunicación de problemas (o, directamente, ocultación de

éstos), que provoca que, cuando se descubren, sea ya demasiado tarde para poder
actuar y resolverlos sin que afecten a todo el proyecto.
11. Seguimiento insuficiente del avance del proyecto, a menudo unido a la ausencia de
una gestión del cambio adecuada (para la evolución del proyecto).

12. Comunicación insuficiente sobre el proyecto (hacia dentro y hacia fuera).
13. Comprobación insuficiente de los resultados antes de su generalización (por ejemplo,

con pilotos o prototipos).
En la finalización del proyecto
14. Falta de decisión para cerrar proyectos hasta que no queda más remedio.
15. Cierre inadecuado del proyecto, sin la pertinente revisión de los resultados alcanzados
y las lecciones aprendidas (y sin la aprobación por parte de los stakeholders).
16. Confianza en que, en la siguiente ocasión, todo funcionará mejor (incluso lo que no
funcionó esta vez y sin plantear cambios en el enfoque).

A1. Una Metodología para La Gestión de Proyectos IESE

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

A1. Una Metodología para La Gestión de Proyectos IESE

Cargado por

Copyright:

Formatos disponibles

Este documento es una de las 37 copias autorizadas para utilizar en el Master en Gestión de la Innovación Empresarial, Proyecto Final, Ezequiel

Beneït, 2013-2014, 2014-05-08

Una metodología para la gestión de proyectos

1. Proyectos frente a procesos: definiciones clave

Última edición: 17/1/14

PN-493 Una metodología para la gestión de proyectos

Un proyecto como tal se define, por tanto, por:

Tener un objetivo o propósito específico y único, para cuyo cumplimiento se realiza la

Disponer de unos recursos limitados, tanto materiales como de trabajo o económicos.

En la práctica, estas tres dimensiones de la gestión suelen estar en competencia. Se puede

«La aplicación de conocimientos, competencias y técnicas de gestión a la realización de

Esta definición se concreta, por lo general, en que la gestión de proyectos busca:

la satisfacción del cliente y un impacto positivo en los participantes del proyecto

2 IESE Business School-Universidad de Navarra

Una metodología para la gestión de proyectos PN-493

Aunque cada proyecto es diferente, en el Anexo 1 presentamos algunas clasificaciones que

2. ¿Por qué una metodología de gestión de proyectos?

La envergadura del potencial de mejora existente en la gestión de proyectos se intuye ya a partir

Un argumento adicional a favor de una metodología de proyectos suele ser la forma en la

IESE Business School-Universidad de Navarra 3

PN-493 Una metodología para la gestión de proyectos

2.1. Implantar una metodología de proyectos

4 IESE Business School-Universidad de Navarra

Una metodología para la gestión de proyectos PN-493

Dentro de este abanico de posibles configuraciones de las oficinas de proyectos, podemos

2. Funciones enfocadas a la gestión de proyectos en la empresa en general, tales como

Muy a menudo, con la implantación de una metodología de proyectos las empresas

3. El ciclo de vida de un proyecto

IESE Business School-Universidad de Navarra 5

PN-493 Una metodología para la gestión de proyectos

3.1. Selección de proyectos4

6 IESE Business School-Universidad de Navarra

Una metodología para la gestión de proyectos PN-493

3.1.1 Dimensiones de la selección de proyectos: capacidad e impacto

Como hemos avanzado, existen dos aspectos fundamentales a considerar de cara a la

Impacto de los proyectos

La priorización de proyectos por su impacto estratégico requiere de la definición de los

IESE Business School-Universidad de Navarra 7

PN-493 Una metodología para la gestión de proyectos

Disponibilidad y demanda de proyectos

De cara a determinar la capacidad 9 disponible en la organización para realizar proyectos,

Debido a estas numerosas causas de incertidumbre, generalmente el objetivo no consiste en

3.1.2. Puertas de control

8 IESE Business School-Universidad de Navarra

Una metodología para la gestión de proyectos PN-493

IESE Business School-Universidad de Navarra 9

PN-493 Una metodología para la gestión de proyectos

3.2. Definición de proyectos10

El primer paso de la definición se realiza habitualmente de forma previa, para disponer de la

Las preguntas estratégicas iniciales en la definición de un proyecto son las siguientes:

RESULTADOS entonces … y… SUPUESTOS

10 IESE Business School-Universidad de Navarra

Una metodología para la gestión de proyectos PN-493

entonces los participantes aprenderán a usar estas herramientas en sus proyectos

Misión: consiste en explicar el porqué del proyecto. Se puede construir sobre lo

Entregables: representan lo que el proyecto debe producir (outputs o resultados).

Implicados (stakeholder): representan a cualquier persona (o grupo) que será

IESE Business School-Universidad de Navarra 11

PN-493 Una metodología para la gestión de proyectos

o Patrocinador: el máximo responsable hacia fuera, no necesariamente con rol

Objetivos: son una versión detallada de la misión del proyecto. No conseguiremos

o Específicos: concretos, aludiendo a problemas definidos.

Supuestos y riesgos: en la fase de planificación recomendaremos realizar un análisis