INTRODUCCIÓN

Como el propio nombre lo indica, la disciplina Fundamentos para

la Dirección de Proyectos le brinda al alumno una base uniforme para la
posterior comprensión de los aspectos técnicos del área. Establece la
debida correlación entre la historia de la humanidad y la existencia de
proyectos, que adolecían de técnicas refinadas o metodologías.
Ya en el siglo XX, la gestión de proyectos de mayor complejidad y
riesgo hace de esta disciplina una de las bases de sustentación más útiles
para el alumno, tanto en materia de formación profesional como de las
competencias a desarrollar. En este contexto, veremos los innumerables
temas que orbitan en el universo de los proyectos, desde los factores
motivadores hasta su relación directa con las decisiones estratégicas de las
compañías. De este modo, abordaremos los diversos procesos de gestión
de proyectos presentados en la Guía PMBOK, 6a edición, y de qué modo
se pueden aprovechar mejor los recursos tecnológicos.
En pleno siglo XXI, estamos inundados por variadas metodologías
y guías con mejores prácticas de gestión, así como por asociaciones y
centros de estudio. Cada vez más, las organizaciones invierten en la
ciencia de la gestión de proyectos, que se traduce en crear y dar poder a
sus oficinas de proyectos e incentivar la calificación de sus profesionales.
Esto no ocurre por casualidad: estas entidades constataron la correlación
directa que existe entre la gestión profesional de sus proyectos y el mayor
grado de éxito de esos esfuerzos.
En este contexto, este material tiene como objetivo presentar los
conceptos fundamentales de la gestión de proyectos y ofrecer reflexiones
acerca de su aplicación, así como una visión de conjunto del proceso de
gestión de las adquisiciones en un entorno de proyectos, de modo de
facilitar la comprensión de sus mecanismos y su dinámica. Para ello,
vamos a:
 conocer los conceptos fundamentales acerca de proyectos,
gestión de subproyectos, programas y carteras;
 conocer cómo nace el proyecto en las organizaciones y su
evolución histórica en paralelo con la de la raza humana;
 analizar la importancia de los stakeholders en el escenario de
cualquier proyecto;
 relacionar los procesos de gestión con planificación estratégica y los 49 procesos de gestión
de proyectos;
 conocer las principales técnicas y buenas prácticas de planificación, organización y
controles, y adquisiciones de un proyecto;
 conocer los elementos principales de los procesos licitatorios privados y públicos;
 conocer los elementos principales de selección y administración de contratos, y
 revisar las diez áreas de conocimiento y cómo los recursos tecnológicos disponibles hoy
pueden asistir al gerente de proyectos en el proceso de control y toma de decisiones.
ÍNDICE
MÓDULO I – FUNDAMENTOS DE LA GESTIÓN DE PROYECTOS .................................................... 7

EVOLUCIÓN DE LA GESTIÓN DE PROYECTOS ................................................................................ 7

Historia ........................................................................................................................................ 7
Definición de proyecto .............................................................................................................. 9
Exclusividade……………………………..………………………………………………………………………. 10
Temporalidad………………………………………………….…………………………………………………. 10
Diferencias y semejanzas entre los proyectos y los trabajos operativos.........................15
SUBPROYECTOS, PROGRAMAS Y CARTERA DE PROYECTOS ......................................................17
Subproyectos ............................................................................................................................17
Programas.................................................................................................................................18
Cartera de proyectos ...............................................................................................................22

MÓDULO II – PROCESOS DE GESTIÓN DE PROYECTOS Y CICLO DE VIDA .................................. 27

ALINEAMIENTO EMPRESARIAL PARA LA GESTIÓN DE PROYECTOS ..........................................27

Planificación estratégica y proyectos .......................................................................................27
Factores motivadores de proyectos ......................................................................................33
Stakeholders .............................................................................................................................. 37
Habilidades y competencias del gerente de proyectos ......................................................40
Project Management Office (PMO) .............................................................................................47
Estructuras organizacionales .................................................................................................51
Organización funcional…………………………………………………………………………………...…. 51
Organización matricial…………………………………………………………………………....…………. 54
Organización por proyectos……………………………………………………………………………….. 59
PROCESOS DE GESTIÓN DE PROYECTOS ......................................................................................62
Grupos de procesos .................................................................................................................62
Ciclo de vida de un proyecto .................................................................................................. 65
Diez áreas de conocimiento de la gestión de proyectos, según la 6ª edición del PMBOK
....................................................................................................................................................74
Documentos clave: Acta de constitución del proyecto y plan de gestión del proyecto ........81
Acta de constitución del proyecto (ACP)…………………………… ……………………………… 81
Plan de gestión del proyecto.......................................................................................... 83
La línea base y la triple restricción ...........................................................................................86
Control general de cambios ................................................................................................... 88
Criterios de un proyecto exitoso ...........................................................................................91

MÓDULO III – ADQUISICIONES EN PROYECTOS .......................................................................... 93

INTRODUCCIÓN ...............................................................................................................................93
 ADQUISICIONES EN PROYECTOS ................................................................................................... 94
PLANIFICACIÓN DE ADQUISICIONES EN PROYECTOS .............................................................. 100
¿QUÉ necesitamos?............................................................................................................... 100
¿DÓNDE conseguiremos lo que necesitamos? ................................................................. 100
¿CÓMO obtendremos lo que necesitamos? ...................................................................... 101
¿CUÁNDO tendremos lo que necesitamos? ...................................................................... 101
¿CUÁNTO nos costará lo que necesitamos?...................................................................... 102
¿QUÉ riesgos corremos al adquirir lo que necesitamos? ................................................ 102
PROCESOS LICITATORIOS ............................................................................................................ 104
Preselección de proveedores .............................................................................................. 104
Términos de referencia ........................................................................................................ 105
Obtención de propuestas .................................................................................................... 107
Análisis de propuestas ......................................................................................................... 110
MODELOS DE CONTRATOS Y SU APLICACIÓN .......................................................................... 112
PRÁCTICAS DE ADMINISTRACIÓN DE CONTRATOS .................................................................. 117
Funciones ............................................................................................................................... 117
Eje de la adhesión ................................................................................................................. 118
Eje de la comunicación ......................................................................................................... 119
Eje de la modificación........................................................................................................... 120
Eje del conflicto ..................................................................................................................... 120
TERMINACIÓN DE LOS CONTRATOS .......................................................................................... 121
Conclusión en tiempo y forma ............................................................................................ 121
Rescisión ................................................................................................................................ 122
Resolución.............................................................................................................................. 122
Desistimiento voluntario...................................................................................................... 122
Aceptación de alcance .......................................................................................................... 123
Transferencia de custodia ................................................................................................... 123

MÓDULO IV – RECURSOS TECNOLÓGICOS DE GESTIÓN DE PROYECTOS ................................ 125

DEMOSTRACIÓN DE LAS PRINCIPALES HERRAMIENTAS DE GESTIÓN DE PROYECTOS....... 125

WBS o EAP .............................................................................................................................. 125
Cronograma ........................................................................................................................... 133

CONCLUSIÓN ............................................................................................................................... 145

BIBLIOGRAFÍA.............................................................................................................................. 147

BIBLIOGRAFÍA INDICADA PARA ADQUISICIONES ..................................................................... 150

PROFESORES-AUTORES ............................................................................................................... 151 

MÓDULO I – FUNDAMENTOS DE LA
GESTIÓN DE PROYECTOS

En el presente módulo, abordaremos la evolución de los proyectos en la historia de la

humanidad, con relación a su complejidad y forma de gestión. A continuación, reflexionaremos
sobre diferentes conceptos de proyecto así como de cartera, stakeholders y otros. También
presentaremos la Gestión Estratégica y su influencia en los proyectos a ser seleccionados en las
empresas. Por último, abordaremos las características clave de un gerente de proyectos exitoso y de
un departamento de proyectos.

Evolución de la gestión de proyectos

Historia
Desde los primeros registros de presencia humana en la Tierra, se encuentran evidencias de
realización de proyectos. No caben dudas de que varias obras de gran magnitud, como la Gran
Muralla China o el templo de Dendur (actualmente en el Museo Metropolitano de Nueva York),
demuestran que los proyectos han evolucionado prácticamente en forma paralela a la raza humana.
Desafortunadamente, otros ejemplos de la antigüedad no corrieron la misma suerte, como los
Jardines Flotantes de Babilonia, cuya existencia se conoce por medio de citas, pero sin rastros físicos
de su grandiosidad. Otros proyectos se ubican en un punto intermedio entre estos extremos ya que
solo permanecen algunas ruinas como testimonio de su pasado, tal como lo ilustran algunas obras
de los pueblos griegos y romanos.
Con el transcurso de los siglos, otras empresas humanas incrementaron el uso de la tecnología
y, cada vez más, se apoyaron en las mejores prácticas antes que en la improvisación. Los grandes
viajes –por ejemplo, los movimientos expansionistas de países como Portugal y España, y
posteriormente Inglaterra– son casos de proyectos exitosos realizados entre los siglos XIV y XVII.
A medida que el hombre fue implementando proyectos, de diversa naturaleza o de mayor o menor
porte, los índices de fracaso se redujeron. Sin embargo, fue en realidad en el siglo XX cuando los
proyectos y su gestión pasaron a ser objeto de debida atención y merecido análisis por parte de la
ciencia de la Administración. Muchas empresas comenzaron a invertir fuertemente en proyectos,
cuya gestión no tenía sentido si no se recurría a un mínimo de técnica y metodología. El hecho de
que los errores acarrearan perjuicios impulsó la realización de estudios más profesionales en la
flamante área, bautizada "gestión de proyectos". No fue diferente lo que ocurrió en la NASA, la
Agencia Espacial Norteamericana, en la que a partir del desarrollo de varios de sus programas,
especialmente el Apolo, se trabajó intensamente en el campo de la gerencia de proyectos.
No fue por casualidad que en 1969 se creó el PMI (Project Management Institute), una
entidad para compartir las mejores prácticas en materia de gestión de proyectos. Sus fundadores
decidieron que no podían seguir gestionando proyectos en sus respectivas empresas de manera
informal y, así, comenzaron a redactar textos y a reunirse en forma presencial para intercambiar
experiencias sobre cómo trabajaban, con foco en la estandarización de los procesos. Nacido con
cinco voluntarios en Pensilvania, Estados Unidos, el PMI alcanzó luego una participación global,
con miles de miembros o asociados que se comunican en su plataforma, gracias a la tecnología y la
virtualización del siglo XX. Este increíble aumento de participantes impulsó a la entidad a lanzar la
primera versión de su guía llamada PMBOK (Project Management Book of Knowledge), que
contiene una estructura básica de mejores prácticas. Cada 4 años, aproximadamente, los miembros
del PMI y sus voluntarios se reúnen para editar el PMBOK y lanzar una nueva versión. Hoy en día,
hay interacciones virtuales en todo el mundo y en tiempo real para discutir modificaciones y
adiciones a las versiones anteriores. En septiembre de 2017, fue lanzada la 6ª edición del PMBOK,
en diez idiomas, que es la versión actualmente vigente.
Dado que se convirtió en una entidad de referencia en la gestión de proyectos, es decir, un
benchmark mundial en este campo, el PMI también creó un “paquete de conocimiento” al lanzar una
certificación, el Project Management Professional (PMP por sus siglas en inglés), que sirve hasta la
actualidad como sello de expertise reconocido y aceptado mundialmente. La certificación PMP ha sido
una meta para innumerables profesionales que actúan con proyectos, aunque también hay otras
certificaciones creadas más recientemente que atienden demandas más específicas de profesionales del
medio, entre las cuales se destacan:
 certificación CAPM – técnico certificado en gestión de proyectos;
 certificación PfMP® – profesional de gestión de cartera;
 certificación PMI-SP – profesional en gestión de cronograma;
 certificación PMI-RMP – profesional en gestión de riesgos del PMI;
 certificación PgMP – profesional de gestión de programas y
 certificación PMI-ACP – profesional certificado en métodos ágiles del PMI.

8
 Otra entidad que también ha contribuido a la evolución de la ciencia de la gestión de proyectos,
dando su apoyo como difusora verdaderamente global de las mejores prácticas, es la IPMA
(International Project Management Association). Recientemente, en 1989, del otro lado del
Atlántico, el gobierno del Reino Unido creó y desarrolló el PRINCE2 (Project IN Controlled
Environments), que constituye una metodología británica más enfocada en un modelo estructurado
y prescriptivo que el postulado por el PMBOK, y que también goza de una buena aceptación mundial.
Además, hay algunas certificaciones emitidas por la organización del PRINCE2 que, al igual que las
del PMI, aportan valor agregado y enriquecen la carrera de los profesionales que las alcanzan.
La Organización Internacional de Normalización publicó en 1997 la norma 10006, en la que
asocia la gestión de proyectos con la política de calidad y, asimismo, se han desglosado procesos de
gestión. Cabe señalar que la versión final de esta norma no entra en conflicto con las pautas del
PMBOK, ya que es complementaria aunque de menor tamaño.
Recientemente, la historia de la gestión de proyectos ha sido testigo del nacimiento de las
metodologías ágiles. Estas se hicieron muy conocidas a partir de 2001, cuando un grupo de expertos
en desarrollo creó la llamada Alianza Ágil, en la que presentaron una serie de conceptos comunes a
todos los métodos que empleaban. El abordaje Scrum, uno de los ejemplos más conocidos de las
metodologías ágiles, ha sido empleado en varias corporaciones, de manera exclusiva o en alianza
con los modelos más tradicionales, como el del PMI o bien de otras entidades difusoras de la gestión
de proyectos.
Independientemente de la entidad de gestión de proyectos o de las universidades que apoyan
la formación y calificación de profesionales en este campo, resulta evidente que nunca se ha
invertido tanto en proyectos en las organizaciones. Según el renombrado autor Ricardo Vargas,
“hoy en día se emplean alrededor de 15 billones de dólares en proyectos. Esto implica alrededor del
25% de toda la economía mundial”. Esta sorprendente estadística corrobora la creciente demanda
global de profesionales altamente calificados en esta área y aleja la idea de que esta disciplina sea
una moda pasajera.
En la actualidad, la gestión de proyectos es universal, aplicable a cualquier sector de
actividades, tanto en el ámbito profesional como en el personal. En pleno siglo XXI, los beneficios
de la gestión de proyectos, obtenidos a partir de la aplicación de técnicas, tienen una repercusión
indiscutible y sin excepciones.

Definición de proyecto
Según el PMBOK, un proyecto es un esfuerzo temporal practicado con el fin de crear un
producto, servicio o resultado exclusivo. El autor Gozzi complementa esta definición afirmando
que un proyecto es un conjunto de actividades coordinadas “con limitaciones y restricciones de
tiempo, costo y recursos”.

9
Exclusividad
La exclusividad o unicidad, es decir, la producción de un output único, constituye una de las
características más destacadas de los proyectos. De hecho, ningún proyecto es idéntico a otro, en
gran parte porque sus productos o servicios finales presentan profundas diferencias entre sí. Por más
que comparemos proyectos de una misma empresa o de una misma industria, como los de la
construcción civil, cada obra tendrá su rasgo diferencial. Por ejemplo, si consideramos el caso de
una empresa de ingeniería que construye edificios residenciales en Perú desde hace 15 años,
ninguno de sus proyectos será idéntico, debido a que los mismos no se levantarán al mismo tiempo,
utilizarán diversas tecnologías, se destinarán a clientes (residentes) distintos, con diseño,
terminación y metraje específicos, en terrenos diferentes y, en definitiva, construidos por equipos
de obreros, ingenieros y arquitectos diferentes.
Un proyecto como la campaña de marketing de la sofisticada marca Louis Vuitton ejemplifica
muy bien esta característica de la unicidad: cada producto comercializado es distinto del anterior,
la apelación publicitaria es inédita, son otras las características de distribución, no se repiten los
lugares escogidos para los eventos de lanzamiento para los medios, ni tampoco los equipos creativos,
entre otros.
Del mismo modo, la unicidad existe en proyectos personales y familiares, como un viaje.
Aunque se visite la misma ciudad en distintos años, el viaje será otro. El proyecto cambió. Aunque
el destino sea el mismo, la misma ciudad puede haber sufrido cambios, el hotel en el que se
hospedará la familia puede ser otro, habrá una duración específica, el itinerario puede variar, los
miembros de la familia cambian cada una de las veces, la forma de financiación difiere, etc. Los
viajes, como proyectos que son, también son exclusivos, no se repiten.
Así, los proyectos son únicos, exclusivos, singulares. Nunca un proyecto hecho un día
determinado se repetirá exactamente con el mismo molde con en el que fue concebido originalmente,
incluso porque la tecnología habrá evolucionado, el equipo de ejecución y el gerente podrán ser otros,
y así sucesivamente.

Temporalidad
Los proyectos son finitos, es decir, tienen una duración limitada. Por ejemplo, se puede
identificar claramente esta característica en las pirámides en Egipto, que si bien fueron construidas
de principio a fin con extrema dificultad, tuvieron una conclusión. Algunos autores atribuyen la
característica de finitud a los esfuerzos “en etapas”, como el autor Gozzi al referirse a la Copa
Mundial de Fútbol de 2014 en Brasil cuando afirma que “algunos estadios fueron reformados, otros
se construyeron. Se mejoró la infraestructura de los aeropuertos y del transporte en las ciudades en
las que habría partidos. Se reservaron lugares de entrenamiento y alojamiento para 32 selecciones.

10
Se prepararon hoteles y restaurantes para recibir a millones de turistas”. Estas sucesivas etapas, es
decir, las etapas desde el inicio hasta el final del proyecto, comprueban la finitud de la Copa
Mundial de 2014, enmarcándola dentro del concepto de proyecto. En suma, todos los proyectos
tienen fin.
La construcción de las pirámides mayas en Guatemala en el siglo VIII, el lanzamiento del
nuevo modelo de avión ERJ-145 de Embraer a comienzos de este siglo, y la campaña para las
elecciones generales de México de 2018, aunque separados en el tiempo y en el espacio, son tres
ejemplos de proyectos, ya que se atienen a la atribución de temporalidad (inicio y final claros) de
los proyectos, tan destacada por el PMBOK.
Los tres proyectos arriba citados fueron temporales, cada uno con una duración acotada y
elaborados progresivamente, desde el primer día hasta su conclusión final. En el caso de las
pirámides mayas, destinadas a ser templos religiosos, los primeros momentos del proyecto fueron
dedicados al diseño que, probablemente, fue concebido por quien habría sido el gerente del
proyecto y, luego, las etapas siguientes se concentraron en el transporte de las piedras hasta el
emplazamiento de la construcción y el necesario desplazamiento de la mano de obra para comenzar
los trabajos. Una vez reunidos los demás recursos físicos para la tarea, tuvo lugar la efectiva
construcción de las pirámides y, finalmente, su conclusión exitosa.
De la misma manera, desde el lanzamiento del nuevo avión de Embraer, tras años de diseño
y pre-proyecto, estudios y pruebas, pasando por la concreta construcción de la “máquina” y las
pruebas consideradas exitosas “en el aire”, hasta la campaña de marketing ante diversos gobiernos
para su futura venta, el proyecto no llegó a ser definitivo hasta el lanzamiento oficial del nuevo
modelo. No es diferente el caso de las elecciones mexicanas de 2018, en las que también se verificó
el rasgo de temporalidad. De hecho, todos los candidatos competidores trataron la elección como
un proyecto, con la especificidad (o incluso el agravante) de tener, efectivamente, una fecha final,
la de la elección, que fue el día final de la campaña.
Es conveniente añadir aquí que para algunos sectores de la economía y algunos tipos de
proyectos, como la organización de eventos, el factor temporalidad es aún más importante que
cualquier otra faceta del concepto total de proyecto. Una fiesta de casamiento o un festival, como
Rock in Rio, son ejemplos de proyectos, que prácticamente no tienen ningún margen de maniobra
en cuanto a la temporalidad, es decir, no se pueden posponer. Así, una vez que se establece la fecha
del casamiento difícilmente se la pueda modificar, principalmente a causa de todas las reservas
hechas para un día y un horario determinados. Hay contrataciones de peso, como la de la iglesia (u
otro templo religioso elegido por la pareja), el salón de fiestas y el servicio de comidas y bebidas.
Además, esa fecha aparecerá en la participación entregada a todos los invitados, algunos de los cuales
quizá deban desplazarse grandes distancias para llegar a la celebración, lo cual implica una

11
planificación. Se trata de un proyecto temporal y con escaso margen en caso de ocurrir algún
contratiempo.
El festival Rock in Rio, del 27 de septiembre al 6 de octubre de 2019, es otro ejemplo de
proyecto en el que los tiempos deben respetarse a rajatabla. Hecho el anuncio en diversos medios
sociales y en las principales redes de televisión brasileñas e internacionales, todas las entradas se
vendieron rápidamente. Las fechas de los diversos shows fueron establecidas con anticipación y
algunas se difundieron al público, así como algunas de las atracciones principales (cantantes y
grupos locales e internacionales). El montaje diario de los diversos shows, del 27 de septiembre al
6 de octubre, debe respetar el programa difundido públicamente, como los plazos del proyecto. La
organización de este tipo de proyecto tiene muy poco margen de maniobra si surgen imprevistos
en dicho período.
En la última edición de Rock in Rio en 2017, hubo un episodio que fue, como mínimo,
curioso: Lady Gaga, una de las mayores estrellas esperadas del evento, tuvo problemas de salud en la
víspera de su presentación y no pudo participar. Ante el imprevisto, los gestores del proyecto
decidieron anunciar públicamente el problema y, al mismo tiempo, el reemplazo del show de Lady
Gaga por otra atracción, la banda Maroon Five. A los que ya tenían entradas pero no deseaban aceptar
la alternativa se les dio la opción del reembolso. Si bien esta táctica de la organización del proyecto
fue claramente paliativa, resultó funcional para lo que había disponible con tan poco tiempo. Esta
alternativa propuesta al gran público del festival evidencia que cuando se trata de eventos, incluso en
vivo, la temporalidad de este tipo de proyectos constituye una fuerza difícil de soslayar.
Un punto adicional que se debe destacar sobre los proyectos es que la temporalidad se
diferencia de la rapidez. Aunque los proyectos sean temporales, esto no significa que sean rápidos
¡De ninguna manera! El proyecto, el emprendimiento, la iniciativa en sí llevan su tiempo. Cuando
una empresa lleva a cabo un proyecto, sabe que hasta tanto entregue los productos o servicios la
iniciativa continuará en marcha. El cierre del proyecto solamente tiene lugar cuando están
cumplidos sus objetivos. Sin embargo, esto puede llevar días o un intervalo razonable de tiempo.
Cabe subrayar que hay proyectos de duración muy variada, que pueden demandar desde días
hasta años. Hay sectores económicos cuyos proyectos son bastante rápidos, como los vinculados
con la tecnología, cuyos esfuerzos pueden llevar de dos a tres semanas, con cronogramas divididos
en días y hasta en horas justamente para garantizar un mayor control. Sin embargo, es importante
destacar que no son cortos todos los proyectos de firmas o sectores tecnológicos, o que son
motivados por un cambio de tecnología. Puede haber megaproyectos de implementación en
corporaciones multinacionales de carácter tecnológico, como una modificación de todas las
plataformas físicas o los modelos de notebooks de todos los usuarios. Evidentemente, se tratará de
un proyecto más extenso para los estándares del mundo tecnológico, que se prolongará tanto por la
complejidad como la dispersión geográfica.

12
 En comparación, los proyectos realizados en otros rubros de actividad económica pueden tener
una duración media más extensa, de años a décadas inclusive. La industria farmacéutica es un área
con proyectos reconocidamente largos, ya que los medicamentos comercializados por las empresas del
sector necesitan por lo menos varios años antes de ser lanzados en las farmacias para el consumidor
final. De hecho, esto suele demorar décadas, ya que hasta llegar a las góndolas y estar disponibles para
la venta, los medicamentos se someten a innumerables y extensos estudios, además de otras exigencias
y prerrequisitos gubernamentales de alta complejidad que deben ser respetados por este tipo de
proyectos. En Brasil, el lanzamiento de un medicamento nuevo por parte de una compañía
farmacéutica solo se podrá implementar con efectividad, es decir, solo se podrá permitir su venta,
después de que el proyecto sea aprobado por la ANVISA (Agencia Nacional de Vigilancia Sanitaria).
La esfera pública en todos los niveles –municipal, estatal y federal– también suele dedicarse a
proyectos de mayor duración, respondiendo a las demandas de los ciudadanos y a causa de su mayor
magnitud. Una obra gubernamental de construcción de una planta hidroeléctrica será invariablemente
un proyecto de gran duración, aunque parte de su capital sea privado. Cuando un gobernante asume
un cargo de intendente, por ejemplo, se espera que tome medidas rápidas para mejorar el municipio,
lo que sin duda se alcanzará a través de la ejecución de proyectos y de la calidad en la gestión de los
mismos. El votante que apostó por este intendente y que lo puso en su puesto no solo le da un voto de
confianza sino que, naturalmente, tiene expectativas sobre los proyectos que el elegido efectivizará en
su mandato. Muchos políticos llegan a usar la duración de su mandato como una excusa para ser
reelegidos, alegando que no lograron concretar todos sus proyectos en el primero y que, por lo tanto,
necesitan el segundo para implementar todo lo que planificaron y que aún queda pendiente.
Las empresas de explotación y extracción de recursos minerales, incluso las petroleras,
también plantean proyectos de duración bastante extensa. Según la autora Jennifer Fogaça, en los
proyectos de refinación de petróleo, primero hay una etapa de estudios geológicos para evaluar el
nivel de petróleo disponible. Si es económicamente viable (si la reserva es voluminosa), se iniciarán
las perforaciones, que podrán ser tanto en el mar como en tierra. Posteriormente, continúa la etapa
del proyecto denominada purificación, momento en que el petróleo pasa por las torres de
fraccionamiento o destilación en varias ocasiones. Normalmente, en esta etapa de destilación se
obtiene gas, gasolina, aceites lubricantes y querosén, como se muestra a continuación:

13
 Figura 1 - Refinación de petróleo

Fuente: FOGAÇA, Jennifer Rocha Vargas. Refinamento do petróleo. Brasil Escola. Disponible en:
<https://brasilescola.uol.com.br/quimica/refinamento-petroleo.htm>. Acceso: enero 2019.

Aunque no todos los proyectos de una empresa de tecnología son cortos, ni todos los
emprendimientos farmacéuticos, gubernamentales o petroquímicos son largos, cada vez es más
habitual la tendencia de que estos negocios sigan dichas generalizaciones.
Aquí es menester diferenciar entre los conceptos de proyecto por un lado y producto del proyecto
por el otro. “El producto del proyecto es aquello que se le entregará al cliente y que debe estar
mencionado en el objetivo del proyecto. El producto es el nuevo bien o servicio creado por el
proyecto” (VALERIANO, 2001, p. 123). Mientras que la construcción de las pirámides de Egipto
fue un proyecto emprendido hace miles de años, lo que en la actualidad permanece en pie en Guiza
son las pirámides, que constituyen el producto del proyecto. El proyecto, es decir, su construcción,
ya concluyó, según la definición de temporalidad vista anteriormente. La temporalidad, como
característica destacable de los proyectos, no se extiende necesariamente a sus productos tal como
lo demuestra, hasta el día de hoy, el producto de dicho proyecto que se puede contemplar en Guiza.
Un gobernador decide construir una nueva avenida en la capital de su estado y emprende con
éxito el proyecto. Tan pronto como inaugure la avenida, el proyecto quedará concluido, pero la
avenida recién construida que será utilizada por los ciudadanos es el producto del proyecto. La
intención y lo deseable es que este producto sea útil para los residentes durante décadas e incluso por
más de un siglo. Esto nos lleva a la conclusión de que la temporalidad de los proyectos no debe
necesariamente extenderse a la temporalidad de sus resultados. Por el contrario, la meta de la mayoría
de los gestores debe ser que los productos o servicios generados por los proyectos sean duraderos.
Para el desarrollo de un software, por ejemplo, el proyecto estaría compuesto por su diseño,
su desarrollo, la prueba de concepto y la implementación piloto en un entorno restringido, como

14
en un único departamento. Una vez terminado con éxito el piloto, el proyecto concluiría. El
software en sí con sus funcionalidades, el producto del proyecto, podrá ser utilizado en adelante por
los sectores interesados de dicha empresa mientras sea útil (CAMARGO, 2014).

Diferencias y semejanzas entre los proyectos y los trabajos operativos

Ya sabemos que los proyectos son temporales y únicos, a diferencia de los trabajos rutinarios
o procesos. Mientras que los proyectos no se repiten, los procesos se distinguen por la repetición
estandarizada de sus entregas o una entrega continua. La construcción de una filial de CAF en una
nueva ciudad sería un evento único, ya que se construiría un edificio exclusivo, diferente de
cualquier otro hecho en el pasado o en el futuro, y debería ser entregado en un plazo (rasgo
temporal); se trataría entonces de un proyecto.
Por una parte, el control diario del inventario de una empresa de pintura o el análisis
crediticio de los clientes de una institución financiera serían ejemplos de trabajos rutinarios o
procesos, debido a su carácter esencialmente repetitivo y cíclico. Por otra parte, una fusión entre
dos enormes empresas automotrices sería un megaproyecto, por tratarse de un esfuerzo único e
irrepetible. No obstante, después de que la fusión se concrete con éxito, la actividad cotidiana de la
nueva empresa fusionada dependería de procesos, de acciones rutinarias.
La operación diaria de una cinta transportadora en una fábrica de fertilizantes sería un trabajo
operativo, ya que los productos finales de la cinta serían idénticos, estandarizados y repetitivos. Sin
embargo, si esta cinta transportadora sufriera una renovación en el 80% de sus piezas el próximo
año, estaríamos encarando un proyecto.
Otro aspecto que diferencia los dos conceptos es el foco. Normalmente, en el proyecto, el
foco está puesto en el cambio, en la expansión del negocio, en las mejoras. En cambio, para el
trabajo rutinario la prioridad termina siendo el mantenimiento de la organización, la regularidad
de lo cotidiano. Según Valeriano (2001, p. 12),

… las operaciones corrientes se componen de varios procesos productivos

y administrativos ejecutados por equipos permanentes dedicados a cada
uno de los procesos, metódicamente repetidos (...) y constituyen el trabajo
característico de las fábricas de bienes de consumo (automóviles,
medicamentos, productos electrodomésticos, de entretenimiento, etc.), de
las instituciones prestadoras de servicios (salud, enseñanza, transportes,
comunicaciones), de las empresas proveedoras de energía (electricidad,
combustibles), del comercio, de los bancos, etc. Otros tipos de operaciones
son las actividades de administración: administración de personal,
finanzas, compras, etc…

15
 Esta distinción entre proyectos y procesos es muy importante para aplicar debidamente las
buenas prácticas de gestión de proyectos. La siguiente es una breve lista de ejemplos de proyectos:
 lanzamiento de una nueva opción de inversión;
 creación de un nuevo modelo de evaluación del desempeño;
 demolición de un centro comercial;
 reforma de la casa veraniega de una familia;
 ejecución de una nueva vía férrea;
 fundación de una plaza;
 expansión de un parque industrial;
 instalación de células fotovoltaicas;
 inauguración de una feria de productos; e
 instalación de unidades de autoservicio en sucursales bancarias.

A continuación, se presenta una lista de ejemplos de trabajos operativos (procesos):

 emisión de facturas;
 compra de material de oficina;
 inspección visual de la cinta transportadora;
 venta de mercaderías;
 recuento automatizado de existencias;
 control de identificación de pasaporte;
 entrevista para una vacante en la empresa;
 expedición de autorización de salida de embarcaciones;
 firma de contrato de renovación con un proveedor; y
 validación automática de documentos en una institución financiera.

A pesar de las diferencias aquí citadas, hay tres puntos de convergencia entre los proyectos y
los procesos. La primera semejanza radica en que los dos son realizados por personas. Por más
automatizada que esté una unidad bancaria, por más moderna que sea su tecnología, aún se necesita
la presencia del ser humano, es decir, la fuerza de trabajo que ejecute sus diversas funciones y
procesos. Tal vez resulte más claro en el caso del ambiente de proyectos, en donde la participación
humana es esencial, en la ejecución de las tareas por parte tanto del equipo como del gerente del
proyecto con su experiencia técnica y toma de decisiones.
El segundo punto en común es que tanto los procesos como los proyectos tienen
limitaciones de tiempo y de recursos; ello afecta su gestión, ya que ninguno de los dos cuenta con
recursos ilimitados. Estamos hablando de cualquier tipo de recurso: financiero, humano, material
(o físico) e intangible (conocimiento, habilidades e información). Ni los proyectos ni los procesos

16
tienen todos los recursos a su entera disposición, por lo que se hace necesario que las empresas
establezcan prioridades.
Como tercera semejanza entre los proyectos y los trabajos operativos, podemos mencionar
que ambos se planifican y controlan debidamente a fin de obtener un mejor resultado. Es difícil
que hoy en día se permita la improvisación en la gestión de ambos. En los dos ámbitos, hay estudios
previos de viabilidad y planificación. Aunque esté en marcha un proceso simple en algún sector, no
se prescinde de las evaluaciones continuas de desempeño. En los proyectos no podemos darnos el
lujo de eliminar la planificación ni la supervisión de las entregas. Ello sería inaceptable en la mayoría
de las empresas.
En el siguiente cuadro, se comparan procesos y proyectos en forma resumida:

Cuadro 1 – Semejanzas y diferencias entre proceso y proyecto

Trabajo a ser realizado

Tipos Proceso (trabajo rutinario) Proyecto

Semejanzas  realizados por personas

 limitados por los recursos disponibles
 planificados, ejecutados y controlados

Diferencias continuo y repetitivo temporal y exclusivo

Subproyectos, programas y cartera de proyectos

Subproyectos
El concepto de proyecto fue visto anteriormente, pero es necesario cubrir otros conceptos muy
comunes en la vida diaria de los proyectos y que forman parte de la jerga de la ciencia de la gestión.
El primero es el concepto de subproyectos. De hecho, existen proyectos que se dividen en partes
menores con el fin de facilitar su gestión. A estas partes menores las denominamos subproyectos.
Según Vargas, “los subproyectos son responsables de una pequeña parte del proyecto total o de etapas
sumamente específicas del proyecto que, la mayoría de las veces, pueden ser tercerizadas o
desarrolladas por grupos aislados”. Es importante destacar que los subproyectos deben ser gestionados
como proyectos y no como una misión menor a cargo de fuerza de trabajo inferior. En cuanto a su
gobernanza, se debe nombrar a un líder para cada subproyecto, que en su carácter de coordinador o
subgerente será responsable del desempeño de su subproyecto ante el gerente de proyecto.

17
 El concepto de subproyecto también aparece con frecuencia cuando el proyecto tiene varios
frentes regionales y entonces se divide en, por ejemplo, “Subproyecto Región A”, “Subproyecto
Región B”, y así sucesivamente. Otro ejemplo sería la división de un proyecto en varios
subproyectos, como “un proyecto de mejora en la satisfacción del cliente, que puede incluir tres
subproyectos, los cuales están interrelacionados y deben ser administrados de modo coordinado y
centralizado: 1) perfeccionamiento de funcionalidades del producto; 2) capacitación del equipo de
pre-venta; y 3) mejora de la atención post-venta” (GOZZI, 2016).
Por su lado, el autor Torres da otros ejemplos:

… subproyectos basados en el proceso del proyecto, como una etapa

específica en el ciclo de vida del proyecto; subproyectos que satisfacen
requisitos en materia de calificaciones de recursos humanos, como
plomeros o electricistas necesarios en un proyecto de construcción;
subproyectos que exigen el uso de tecnología especializada, como pruebas
automatizadas de programas informáticos en un proyecto de desarrollo de
software…

Programas
Un segundo concepto, mundialmente utilizado en el ámbito de los proyectos, es el de
programa, definido por el PMBOK como “un grupo de proyectos relacionados, cuya gestión se
realiza de manera coordinada para obtener beneficios que no se obtendrían si se gestionaran en
forma individual”. Esto significa que un grupo de proyectos, por sí solo, no sería necesariamente
un programa. Solo cabe el concepto de programa cuando los proyectos forman parte de un todo y
están interrelacionados, tienen cohesión y, por lo tanto, garantizan una mayor sinergia.
El término programa se emplea normalmente en iniciativas de mayor tamaño, de alto riesgo
o que presentan valor para el negocio de la organización como un todo. De este modo, como la
magnitud de tales emprendimientos es mayor, el uso de esta denominación tiene sentido. Todos
los proyectos que estén contenidos en el programa, también denominado estructura de paraguas,
serán los necesarios para que la empresa alcance la finalidad definida a nivel macro.
La NASA, Agencia Espacial Norteamericana, es un excelente ejemplo de utilización del
concepto, puesto que su programa aeroespacial se compone de diversos proyectos de exploración in
situ, y ha llevado adelante varios proyectos de investigación y desarrollo en las últimas décadas.

18
 Otros ejemplos serían:

… las empresas de servicios públicos, que a menudo hablan de un

“programa de obras” anual, una serie de proyectos desarrollados sobre la
base de esfuerzos anteriores. Muchas organizaciones sin fines de lucro
poseen un “programa de recaudación de fondos” para obtener apoyo
financiero destinado a una serie de proyectos distintos, como una campaña
para atraer nuevos socios o una subasta. La publicación de un periódico o
una revista también es un programa en el que cada problema específico es
gestionado como un proyecto… (TORRES, p. 113)

En una empresa automotriz como Ford, el lanzamiento de un nuevo modelo de automóvil

puede ser considerado un programa, divido en proyectos como estudio de mercado, diseño,
actualización de los componentes, etc. En la Marina de Brasil existe el Programa Nuclear de la
Marina, integrado por dos proyectos: (1) Proyecto de Construcción del Núcleo del Poder Naval, y
(2) Sistema de Gestión de la Amazonía Azul (SisGAAz). El objetivo del primero es incrementar el
poder naval de la Marina a través de diversas acciones, como la adquisición de tecnología más
moderna y la construcción de astilleros. El del segundo proyecto es “ampliar la capacidad de
monitoreo y control de las aguas jurisdiccionales y de las regiones de búsqueda y salvamento bajo
responsabilidad de Brasil”1. Solamente se considerará que el Programa Nuclear ha sido coronado
con éxito cuando ambos proyectos hayan concluido en su totalidad, comprobando la naturaleza de
la interdependencia entre ellos.
Un punto adicional que se debe destacar es que los programas pueden o no tener fin, a
diferencia de los proyectos que, como sabemos, son temporales. Los programas (como el de la
NASA) virtualmente no tienen fin, ya que exploran el espacio. Lo mismo sucede con un programa
de recursos humanos de su empresa. Este puede contener proyectos de diversos frentes
(capacitación, reclutamiento, promociones, etc.), que terminan y se renuevan año a año, o bien en
plazos mayores. Evidentemente, para algunos programas hay un final predefinido, normalmente
vinculado con la entrega de sus proyectos constituyentes y el real alcance de sus objetivos.

1
Disponible en: https://www.defesa.gov.br/industria-de-defesa/paed/projetos-estrategicos/projetos-estrategicos-da-
marinha-do-brasil Acceso: enero 2019.

19
 A continuación, las figuras ilustran la relación entre los tres conceptos: subproyectos,
proyectos y programas.

Figura 2 - Distinción de los conceptos

Figura 3 - Programas, proyectos y subproyectos

20
 Figura 4 - Gestión de programas

Fuente: TORRES, p. 69.

Para una mejor diferenciación entre los conceptos de proyectos y programas, vale la pena
leer una parte del texto de Clay Susini Aquino Junior, en donde el autor explica que:

… en Brasil y, principalmente, en el sector corporativo privado, a los

Proyectos se los define erróneamente como Programas solo por ser grandes.
Pero en realidad el tamaño es la consecuencia y no el motivo para que
exista el Programa. Otras justificaciones utilizadas para transformar
conjuntos de Proyectos en un Programa son el aprovechamiento de la
dinámica común de varios recursos y la existencia de innumerables frentes
de trabajo con más de un equipo. En verdad, hay programas que tienen
estas características, pero solo como consecuencia de un factor mayor: la
concepción de una idea generadora de un beneficio estratégico, que da
origen a un conjunto de iniciativas independientes responsables de
concretar el beneficio idealizado. Antes de convertirse en un conjunto de
Proyectos, un Programa nace como una idea estratégica generadora de un
beneficio singular, sin la verdadera certeza de que llegará a convertirse en
dos, cinco o decenas de Proyectos independientes. En el momento de la
concepción del Programa no sabemos con certeza qué es lo que se debe
hacer para alcanzar el beneficio idealizado, ni tampoco cómo hacerlo. Solo
sabemos que una serie de tareas independientes generará un beneficio

21
 estratégico y único. Y es común que un Programa, en plena ejecución, aun
genere nuevos Proyectos con el propósito de consolidar el beneficio
estratégico definido anteriormente... 2

De hecho, si lo comparamos con el concepto de proyecto analizado anteriormente, el esfuerzo

de un proyecto es más palpable y concreto que el de un programa. Aun considerando los beneficios
obtenidos por el emprendimiento, es más fácil y predecible enumerar las ventajas que reporta un
proyecto. Esta tarea no es tan fácil cuando se deben predecir los beneficios de un programa, porque
la extensión en el tiempo tiende a ser mayor. Otro elemento que dificulta prever los beneficios de
un programa constituye su propia estructura, ya que se compone de numerosos proyectos. Por ende,
la medición de los beneficios también será más compleja o, al menos, se demorará más. Sobre esta
cuestión, el autor Clay comenta:

… como ejemplo, podemos citar el PAC (Programa de Aceleración del

Crecimiento) del Gobierno Federal. El Programa tiene como objetivo
construir infraestructura logística y energética para sostener el crecimiento
de Brasil. El objetivo de un Programa siempre tendrá la característica de
ser abstracto, ya que en la concepción de la idea solo está la expectativa del
beneficio y no del objeto a ser entregado. No sabemos exactamente lo que
se tendrá que hacer para que se obtenga el beneficio ni tampoco cómo. El
Gobierno Federal dividió el PAC en seis Subprogramas y dos Frentes de
Trabajo. Los Subprogramas del PAC son: PAC Energía, PAC Vivienda,
PAC Ciudad Mejor, PAC Comunidad Ciudadana, PAC Agua y Luz para
Todos y PAC Transportes... 3

Cartera de proyectos
En el ámbito de la gestión de proyectos hay un concepto que no es menos importante que
los mencionados anteriormente, denominado cartera. Aquí, hay una conexión concreta con la
estrategia de la empresa, ya que la cartera corresponde al conjunto de programas, proyectos y
subproyectos de una entidad, vistos de manera agrupada, es decir, como si estuvieran juntos dentro

2
AQUINO JUNIOR, Clay Susini. Diferenciando programas de projetos. Disponible en: http://www.pmisp.org.br/enews/
edicao1112/artigo_01.asp Acceso: enero 2019
3
AQUINO JUNIOR, Clay Susini. Diferenciando programas de projetos. Disponible en: http://www.pmisp.org.br/enews/
edicao1112/artigo_01.asp Acceso: enero 2019

22
de propiamente una cartera. En inglés, esta gestión de cartera de proyectos de una empresa se llama
PPM (Project Portfolio Management). Veamos lo que nos dice TORRES (2014) al respecto:

… La gestión de cartera busca maximizar todos los recursos organizativos

y alinearlos a las necesidades de mediano y largo plazo de la empresa. La
Gestión de Proyectos de Cartera o Gestión de Cartera es un modelo de
gestión de proyectos más amplio y completo. En esta forma, ningún
proyecto es concebido, seleccionado, ejecutado y negociado sin pasar por
los criterios de la Gestión de Cartera. Los directores y los equipos de
gestión del directorio son los que normalmente asumen la responsabilidad
de gestionar las carteras para una organización (p. 61)...

De un modo complementario, el gerente de cartera asume grandes responsabilidades, como

el monitoreo de métricas más estratégicas, el análisis del desempeño financiero de los proyectos, el
control de riesgos, el cálculo del retorno sobre la inversión, el mantenimiento de la alineación de
los proyectos en curso con la realidad externa de la empresa, el cálculo de tendencias del negocio,
entre otras.
Las figuras siguientes ilustran conceptualmente la relación entre una cartera y los
subproyectos, proyectos y programas, descritos anteriormente:

Figura 5 – Estrategia y proyectos

23
 Figura 6 – Cartera, programa, proyecto y subproyecto comparados

Figura 7 – Estructura de cartera, programa, proyecto y subproyecto

24
 Figura 8 – Cartera corporativa

Fuente: https://escritoriodeprojetos.com.br/portfolio-de-projetos

25
26
MÓDULO II – PROCESOS DE GESTIÓN DE
PROYECTOS Y CICLO DE VIDA

En este módulo veremos cómo la gestión de proyectos se basa en procesos, o sea, grupos de
acciones y actividades interrelacionadas y superpuestas. Examinaremos los 49 procesos de gestión
de proyectos y el concepto de ciclo de vida de un proyecto genérico. Asimismo, presentaremos las
diez áreas de conocimiento y su relación con la línea base, así como otros factores clave para el éxito
de un proyecto.

Alineamiento empresarial para la gestión de proyectos

Planificación estratégica y proyectos
La planificación estratégica tiene lugar en los más altos niveles de las organizaciones, que
normalmente incluyen la asamblea de accionistas, el presidente y los altos directivos, grupo clave
responsable de la revisión de la estrategia predefinida de la compañía con la debida frecuencia. Se
observa que los ciclos de revisión de la estrategia son cada vez más cortos en las empresas, mucho
más si consideramos los rubros de actividad más competitivos y cambiantes, como el de la
tecnología de la información o las telecomunicaciones.
La planificación estratégica presupone la realización de análisis que trascienden las fronteras
organizacionales y, para ello, es fundamental comprender la “foto” del ambiente antes de la toma
de decisiones o antes de (re)diseñar o repensar la estrategia actual. Además del ambiente externo,
fuera de los límites empresariales, está el ambiente interno u organizacional, que también merece
una detenida evaluación por parte de la empresa. Para realizar una exhaustiva valoración ambiental,
se cuenta con diversas herramientas, de las cuales las dos más famosas son el modelo de las cinco
fuerzas, de Michael Porter, y el análisis FODA, SWOT en inglés. Por ser una herramienta clásica
de la administración, optaremos por la segunda.
 El análisis FODA busca identificar las fortalezas y las debilidades, las oportunidades y las
amenazas presentes en la empresa en estudio. El acrónimo SWOT deriva de los términos en inglés
strengths, weaknesses, opportunities y threats. Los dos primeros elementos –las fortalezas y
debilidades– serán el resultado del análisis del ambiente endógeno de la entidad. Este diagnóstico
constituirá un verdadero autoanálisis o una radiografía de la realidad interna, ya que determina las
potencialidades y vulnerabilidades.
Por su parte, las amenazas y oportunidades surgirán del análisis del ambiente externo o
circundante de la empresa. Este ambiente exógeno está formado por elementos muy dinámicos, de
poco o ningún control por parte de las empresas. Aquí inciden los parámetros demográficos,
políticos, socioeconómicos, legales, culturales, naturales, tecnológicos, entre otros. Cuando sean
positivos, estos factores actuarán como oportunidades, porque la organización podrá beneficiarse
de tal escenario e, incluso, cosechar ganancias. Cuando los factores externos tengan aspectos
negativos, que impongan escenarios perjudiciales para la empresa o incluso comprometan el futuro,
se denominarán acertadamente amenazas.
Por lo general, un análisis FODA se construye de la siguiente forma:

Figura 9 – Análisis FODA

Fuente: SHUTTERSTOCK

28
 A modo de ejemplo, los siguientes elementos podrían surgir de un análisis de los factores
internos de una empresa cualquiera:
a) Fortalezas
 buena localización geográfica de los puntos de venta;
 buena calidad de atención percibida por los clientes;
 know-how de mercado;
 reputación ante los clientes;
 innovación tecnológica;
 receptividad de la fuerza de trabajo;
 ventajas de costos;
 patentes por más de tres años;
 flexibilidad en las negociaciones con los clientes;
 líderes de los sectores implicados;
 buenos equipamientos;
 economías de escala en la producción;
 alta liquidez financiera;
 índices de rentabilidad positiva, etc.

b) Debilidades
 recursos humanos desmotivados con la política salarial;
 publicidad ineficaz;
 falta de sistema financiero automatizado;
 sector de compras burocratizado;
 distribución de productos limitada;
 escasa fuerza de marca;
 bajo concepto en el mercado;
 costos fijos elevados;
 localización no favorable;
 falta de acceso a fuentes de materias primas;
 escaso control de la red de distribución;
 costo final elevado;
 fragilidad de la atención;
 elevado grado de insatisfacción en un producto o servicio determinado;
 alto índice de devolución de mercaderías o mercaderías dañadas, etc.

29
 Los siguientes elementos podrían surgir de un análisis externo de esta misma empresa:
c) Oportunidades
 salida de rival fuerte;
 incentivos fiscales;
 potencial alianza estratégica con otro minorista;
 ingreso en un nuevo país (mercado internacional);
 eliminación de barreras internacionales en nuevos mercados;
 relajación de las exigencias regulatorias;
 necesidades insatisfechas del consumidor;
 aumento del poder de compra del mercado;
 mayor disponibilidad de líneas de crédito;
 economía en auge;
 cambios en la legislación (tributaria, laboral, ambiental, etc.) favorables a la actividad
de la empresa;
 alianzas estratégicas, etc.

d) Amenazas
 declinación demográfica del mercado;
 proveedor clave con problemas de liquidez;
 poca innovación en las tecnologías de fabricación de los proveedores;
 guerra de precios en la industria;
 cambios en los patrones de consumo;
 productos similares con valor final más bajo;
 lanzamiento de productos sustitutivos en el mercado;
 entrada de nuevos rivales al país;
 reducción del poder de compra de los consumidores;
 inestabilidad del mercado financiero, etc.

El análisis FODA debidamente concluido es un dato frío si no se lo emplea para facilitar y

servir como base para la planificación estratégica de las organizaciones. Esta herramienta, bien
utilizada, reporta orientación y seguridad en las decisiones futuras, a tal punto que, al cabo de
estudios macroambientales como el realizado por el FODA, los altos ejecutivos alinean la estrategia
de sus compañías en el momento de seleccionar los proyectos que se han de implementar. Es obvio
que los encargados de tomar decisiones de nivel estratégico reciben un sinnúmero de propuestas de
proyectos, de los más variados contenidos y envergaduras, oriundos de diferentes sectores de la
empresa, y hasta algunas propuestas de proyectos multisectoriales o multidisciplinarios.

30
 Entre las alternativas o propuestas recibidas hay ciertamente buenas opciones de inversión y
otras que no se adecuan a la senda estratégica adoptada por la empresa. En consecuencia, en el
momento de la decisión, conocido como “embudo de oportunidades” o selección de proyectos, se
aprobarán algunas propuestas, mientras que otras no se llevarán adelante.
Tanto la estrategia empresarial como la política de priorización de los proyectos se deberán
conciliar en los casos de ideas aprobadas. Difícilmente una propuesta de proyecto que no esté alineada
con la estrategia de la empresa será aprobada por el órgano de gobierno o el presidente de la empresa
para que se convierta en una tarea efectiva. Claro que existen algunas excepciones, como los proyectos
motivados por imposición legal, según veremos en la siguiente sección del curso “Factores
motivadores de proyectos”. En estas circunstancias, la empresa no tiene la opción de ignorar la
preeminencia del proyecto, ya que se trata de una necesidad obligatoria y requiere ser encarada por
medio de un proyecto de adecuación. De este modo, tales proyectos de respuesta a cambios legislativos
se vuelven obligatorios y tienen prioridad de ingreso en el embudo de oportunidades
Según Vargas, en el proceso decisorio se consideran numerosos factores a favor o en contra
de una idea o propuesta de proyecto. Además del alineamiento estratégico ya citado, se pueden
agregar otros elementos, como la capacidad de ejecución del proyecto, el retorno de la inversión
que aquel promete, su complejidad, el nivel de riesgo previsto, la flexibilidad que se obtendrá y los
recursos disponibles actualmente en la entidad. Algunos emprendimientos se aprueban porque
mejorarán la reputación de la empresa o porque prometen traer consigo el intercambio y la
optimización de recursos.
Se pueden plantear otros interrogantes durante el análisis o embudo de oportunidades, por
ejemplo, si el proyecto propuesto obligará a la empresa a diversificar su mercado o si la naturaleza
de la tarea es familiar o muy distante de la que domina la organización. Todo este proceso arriba
explicado, con los criterios de evaluación de los proyectos propuestos y la decisión de aprobación
(realización), se resume en la siguiente ilustración:

31
 Figura 10 – Estrategia empresarial y selección de proyectos

Fuente: TORRES, 2014, p. 62

Evidentemente, hay más propuestas de proyectos en la entrada del embudo que en su salida.
Muchas propuestas resultan rechazadas y no se convierten en proyectos efectivamente, mientras que
otras resultan seleccionadas por reunir los criterios preestablecidos por los evaluadores. Tales
propuestas reciben el aval para su implementación. La mayoría de los proyectos seleccionados y
llevados a cabo en las organizaciones atienden las necesidades más adecuadamente que otros, o así
lo percibieron los encargados de la toma de decisiones. En general, el proceso de selección de
proyectos podría visualizarse de la siguiente manera:

32
 Figura 11 – Selección de proyectos

Factores motivadores de proyectos

Es necesario analizar la razón de ser de los proyectos en las organizaciones, o sea, definir por
qué las empresas invierten en estas iniciativas. Normalmente, los mayores incentivadores de los
proyectos en las empresas son exógenos, como la competencia, las normas de calidad, los cambios
económicos y los factores políticos.
Otros factores motivadores de proyectos dentro de las empresas son los de cuño legal,
conforme se vio anteriormente. Estos incentivadores exigen plena atención de las empresas. En las
diferentes legislaciones, los cambios son bastante comunes y demandan rápida adecuación. Cuando
se modifica la legislación ambiental en un país, por ejemplo, las empresas radicadas en él necesitan
adecuarse a las nuevas designaciones, lo que, por lo general, se hace mediante proyectos.
Cuando se aprueban leyes de alcance nacional (o incluso internacional), con criterios más
exigentes en materia de la huella de carbono, las empresas contaminantes de aquel país o las
alcanzadas por la decisión también necesitarán esbozar una rápida respuesta y adecuación a las
nuevas exigencias. Muchas veces, las nuevas legislaciones fijan metas agresivas y las compañías
afectadas necesitan implementar proyectos para responder a la nueva configuración impuesta, so
pena de represalias o multas o incluso de comprometer sus operaciones en el futuro.

33
 Un ejemplo práctico de cómo los cambios legales generan la necesidad de proyectos se
encuentra en el año 2014, cuando una ley brasileña obligó a todas las fábricas de automóviles a
montar sus unidades con airbags. Como es lógico, esta nueva definición provocó un enorme
quiebre de paradigma en la industria automotriz nacional, pero no quedó otra opción que
adaptarse a la resolución.
Rápidamente, las plantas brasileñas pusieron manos a la obra y se adaptaron a la nueva
legislación mediante la implementación de proyectos internos de readecuación. Con la
obligatoriedad de instalar airbags en todos los automóviles fabricados, estas empresas tuvieron que
rediseñar muchos de sus modelos para garantizar la conformidad de los futuros lanzamientos. La
inclusión de este atributo adicional de seguridad también afectó sus sistemas de costos y exigió que
se los reestructurara.
Otro tipo de cambio exógeno que afecta el día a día de cualquier organización es el
tecnológico. En verdad, este es uno de los factores que más requiere actualización por parte de las
empresas y se logra mucho más éxito cuando se lo encara a través de proyectos. Las tecnologías de
hardware y de software evolucionan de manera mucho más veloz en la actualidad, por eso a las
empresas solo les es posible mantenerse razonablemente actualizadas en materia tecnológica si
adoptan una perspectiva de proyectos. En consecuencia, algunas fijan para sí plazos de
readecuación, al igual que hacen algunos organismos públicos brasileños. Por ejemplo, algunos
mantienen un parque de un determinado número de notebooks para sus servidores durante un plazo
límite de tres años y se comprometen a encarar un proceso de renovación de la totalidad de este
equipamiento al final del período.
Tales proyectos de actualización se repiten, además, en ciclos cada vez más cortos, a
consecuencia de que el área de tecnología de la información (TI) sufre cambios reales en menor
tiempo. No sorprende que haya una gran presencia del cargo de gestor de proyecto en esta industria
desde hace mucho más tiempo que en otras, como confirma el autor Ricardo Vargas (2016): “los
cambios tecnológicos, que antes tardaban décadas en implementarse por completo, hoy demandan
apenas unas horas, con un altísimo nivel de complejidad”.
Otro factor exógeno estimulador de proyectos en las organizaciones es el requerimiento de
sus clientes. Es natural que este sea uno de los que más originen proyectos en el seno de las empresas,
ya que las organizaciones, en general, generan ingresos a través de las ventas de productos o servicios
a su clientela. Cuando una entidad satisface e incluso supera las expectativas de sus clientes, consigue
mejores resultados financieros, distribuye mejores dividendos, recompensa a sus colaboradores,
mejora su imagen, entre otras ventajas, en un gran círculo virtuoso generado por sus proyectos de
marketing. En este caso entran, obviamente, los proyectos mercadotécnicos, como los lanzamientos
de productos, los servicios o una nueva campaña de identidad visual, una nueva promoción

34
publicitaria, investigaciones de tendencias de comportamiento, así como iniciativas de retiro de
productos, relanzamientos, expansiones geográficas, etc.
Si una empresa multinacional decide ingresar a un país o si una pequeña empresa de
carpintería incluye en su cartera de productos un nuevo modelo de mueble, ambas estarán
implementando, respectivamente, proyectos con foco total en sus clientes, tanto futuros como
actuales. Estos proyectos nacen para satisfacer mejor la demanda de su público objetivo y, por ello,
se consideran verdaderamente estratégicos. Un fracaso puede ser incluso una cuestión de
supervivencia, aunque el sector de actuación sea altamente competente.
La acción de los competidores de la empresa ejecutora de los proyectos es también un feroz
estímulo. De hecho, si un agente externo, rival de nuestra firma, lanza un nuevo producto con éxito
de ventas, será evidentemente necesaria una inmediata reacción de nuestra parte. Ello se dará con
la concepción de un proyecto que comprenda, como mínimo, al equipo de marketing y de
producción para que, juntos y sin demora, conciban una respuesta al lanzamiento promovido por
el competidor. Cabe resaltar que aunque tengamos éxito en este proyecto de contraataque, el hecho
de que hayamos efectuado el lanzamiento en respuesta al rival, o sea, con posterioridad al
movimiento del competidor, puede ser interpretado de manera negativa por nuestro consumidor.
Un ejemplo real de un proyecto potenciado por el factor de competencia se dio con la NASA.
En pleno transcurso de la Guerra Fría, los rusos lanzaron con éxito su primer satélite espacial antes
que cualquier otro país, lo que puso a los soviéticos a la cabeza de la incipiente carrera espacial. Ello
obligó a los estadounidenses a una inmediata respuesta, a través de la creación de una agencia no
militar de conquista del espacio. En este contexto, la NASA fue concebida mediante decreto del
presidente Eisenhower en 1958.
Otro factor incentivador de proyectos, también externo a la empresa, es una demanda de la
sociedad o de la comunidad. Antes, las empresas públicas tenían más actuación y foco en este tipo
de proyectos. Sin embargo, desde hace por lo menos tres décadas, la iniciativa privada también ha
hecho suyos estos tipos de proyectos, de mayores implicancias y que procuran un alcance que vaya
mucho más allá de los habituales consumidores objetivo de la empresa. Los proyectos con mayor
foco en una motivación social suelen tener un atractivo social, cultural o ecológico diferente de las
actividades principales de las empresas. Así, una empresa de producción, refinación y distribución
de petróleo puede verse invirtiendo en proyectos tales como obras de teatro, limpieza de ríos o
mares, circundantes a sus actividades.
En esa misma línea de proyectos sociales, algunas organizaciones invierten en iniciativas de
cuño social en poblaciones pequeñas carenciadas, participando en la renovación de la escuela
municipal o una campaña de incorporación de menores como aprendices. Otras empresas se
destacan por proyectos con más énfasis ecológico, o sello verde, cuando promueven, por ejemplo,

35
un proyecto de reciclado de desechos de la asociación vecinal o cuando se asocian con la
municipalidad para mejorar la red cloacal.
En esa línea, el Instituto Coca-Cola implementó la Alianza Agua + Acceso en la zona rural
brasileña con campañas de concientización sobre el uso racional del agua. “El programa comenzó
actuando con nueve organizaciones en tres estados. Hoy ya son 15 los proyectos desplegados en
ocho estados. La perspectiva es de crecimiento y el impacto debe llegar a 70 mil personas en más
de 200 comunidades en 2019.”4
En el pasado, había más críticas contra estos proyectos de carácter social llevados a cabo por
las corporaciones, con el argumento de que se trataba de maniobras falsas u oportunistas. Hoy en
día, los críticos están repensando su posición, ya que son muchas las empresas que invierten en
proyectos con un factor motivador distinto de su actividad principal y la tendencia es creciente, ya
que está probado que la sociedad espera, y hasta exige, proyectos de esta naturaleza por parte del
sector privado.
Desde luego, los proyectos pueden tener justificación interna, o sea, pueden emprenderse por
la necesidad de la propia empresa, como un recorte de gastos o la optimización de procesos. Cuando
una empresa fabril desarrolla un proyecto de reingeniería de su planta de producción porque
necesita optimizar su output, la gran motivación del proyecto también es interna. O incluso cuando
un sector como el de recursos humanos de un banco decide invertir en un proyecto de capacitación
de cajeros, por cierto, la motivación es principalmente intrínseca, o sea, mejorar la calidad de ese
equipo de modo de optimizar los servicios que ellos prestan. Además, como resultado también de
este círculo virtuoso, los clientes del mismo banco percibirán mayor valor en su atención.
Otras áreas, al igual que la de recursos humanos, emprenden sus proyectos con el propósito
de mejorar las calificaciones de los empleados, por ejemplo, al implementar un nuevo plan de
carrera y remuneraciones. El sector de la informática también es muy conocido por tener siempre
muchas implementaciones de proyectos, gran parte de ellos motivados por el mejoramiento interno
del parque de máquinas, por ejemplo, una mega instalación de nuevo software de gestión.

4
Fernandes, Yuri. Gestão comunitária da água muda realidade de milhares de famílias nas zonas rurais da Bahia.
Disponible en: https://www.cocacolabrasil.com.br/historias/central-gestao-comunitaria-da-agua-muda-realidade-de-
milhares-de-familias-na-bahia?gclid=Cj0KCQiAvqDiBRDAARIsADWh5TfNSLV0OIX7R4N9a4K5mQ3APmxO2xWshMdVnp
_PSAyFpYYJNj0MvsUaAvTUE ALw_wcB. Acceso en: enero 2019.

36
Stakeholders
Una de las acepciones de la palabra inglesa stake es “interés”, por lo que una persona que tiene
interés en un proyecto es un stakeholder, o un actor del proyecto, persona involucrada, entidad
(persona física o jurídica), interesado o componente. El PMBOK 2017 agrega:

… los interesados en el proyecto son personas y organizaciones con

participación activa en el proyecto o cuyos intereses puedan verse afectados
como consecuencia de la ejecución o fin del proyecto. También pueden
influir en los objetivos y resultados del proyecto…

Difícilmente un proyecto tenga éxito sin las debidas gestiones de estos actores, que pueden
intervenir de manera negativa en el emprendimiento si no perciben valor en el mismo. Debido a
que los proyectos traen aparejados cambios, conforme dijimos en el módulo 1 del curso, habrá
resistencias naturales de algunos stakeholders a su ejecución. De hecho, hay proyectos de diversa
índole que fracasan por la intervención negativa de uno o más stakeholders. Cuanto más poderoso
sea un stakeholder, mayor es el riesgo si ese actor tiene una relación negativa con el proyecto.
Un ejemplo de esta resistencia puede ser el de un proyecto interno generado por el
Departamento de Contabilidad, percibido negativamente por el de Informática. Si este último tiene
mucho poder para bloquear el proyecto, el riesgo aumenta. Consciente de ello, el gestor del proyecto
del área contable debe actuar con rapidez para revertir esta percepción negativa de su stakeholder.
Los proyectos reconocidamente contaminantes, como los que llevan a cabo las empresas
mineras, se ven obstaculizados una y otra vez por la acción feroz de interesados como las ONG
ambientales, las fundaciones indígenas y las comunidades locales. Como estas organizaciones
resultan afectadas de manera directa por estos proyectos, al ver sus intereses perjudicados,
reaccionan contra las empresas ejecutoras y se valen de campañas populares, el accionar del
Ministerio Público y el uso de los medios.
Es importante recalcar que la presencia de stakeholders negativos es válida para todo y
cualquier proyecto, independientemente de su magnitud. Incluso los proyectos domésticos o
internos pueden involucrar actores que ven al proyecto como desfavorable para ellos.
Por cierto, los stakeholders se encuentran en el ámbito de la empresa y fuera de ella, y resulta
igualmente necesario identificarlos a todos. Como sabemos que los proyectos son singulares, habrá
distintos interesados para cada proyecto. No obstante ello, los principales stakeholders presentes en
la gran mayoría de los proyectos son los siguientes:
 Gerente de proyectos (GP): persona responsable del proyecto. Integra a todos los demás
stakeholders y planifica el uso de los recursos. Tiene la autoridad y la responsabilidad de
todo el esfuerzo y responde por su éxito o fracaso y su entrega completa. Ahondaremos
más en este stakeholder central en el tema siguiente.

37
  Cliente: quien contrata o demanda el proyecto, aquel que utilizará los productos o
servicios a generarse o quien adquiere los resultados producidos. Es el interesado a quien
se destina el proyecto. Puede ser un cliente externo o interno del proyecto. Si bien el
primero es más habitual, en las organizaciones hay innumerables proyectos cuyos
destinatarios son otros departamentos (divisiones) o personas dentro de la misma entidad.
Los clientes externos no forman parte de la empresa ejecutora del proyecto. Por ejemplo,
cuando el sector financiero solicita al de informática que desarrolle un nuevo sistema de
emisión de comprobantes fiscales electrónicos, estamos en presencia de un proyecto
interno en el que el equipo de informática será el ejecutor y atenderá una demanda del
cliente (interno), que es el área financiera.
 Organización ejecutora o anfitriona: contratada, o sea, firma en la que se ejecutará el
proyecto y cuyos empleados están directamente implicados en la ejecución del trabajo del
proyecto (CAMARGO, 2014).
 Patrocinador: persona, grupo u organización que, por lo general, tiene la idea del proyecto
y la defiende estratégicamente en los niveles máximos de la empresa. El patrocinador (o
sponsor) provee los recursos financieros e ideológicos para la ejecución del proyecto.
 Equipo: grupo de personas que responderán ante el GP y tienen actuación directa en la
entrega de los productos o servicios del proyecto. Pueden estar cedidos por otras áreas de la
empresa o provenir del mercado, pero su función es la de ejecutar el proyecto. De este modo,
Valeriano (2001) afirma que el equipo del proyecto “es multidisciplinario y tiene una vida
limitada a la duración del proyecto, es decir, que el ejecutante de un proyecto está en una
posición transitoria (...) desempeñando una determinada tarea en un equipo transitorio. (...)
El equipo del proyecto se extingue con la obtención de su resultado” (p. 24).

Además, existen otros stakeholders, que varían mucho en función de la naturaleza del proyecto
y el sector en cuestión. Algunos ejemplos de interesados identificables en los diversos proyectos
podrían ser los gerentes funcionales de la organización ejecutora del proyecto, la PMO (oficina de
gestión de proyectos), los competidores, los distintos tipos de proveedores, los agentes reguladores,
los órganos gubernamentales (de las diferentes esferas), las instituciones bancarias, los medios, las
ONG, asociaciones gremiales y profesionales, sindicatos, asociaciones vecinales, institutos de
investigación, hoteles, fundaciones, militares, universidades, centros de investigación, hospitales,
familias, accionistas, etc.

38
La figura a continuación ilustra los principales componentes en un ambiente de proyecto:

Figura 12 – Interesados de un Proyecto

Fuente: VARGAS, 2016

39
 En la figura a continuación vemos el esquema de stakeholders de la compañía SulAmérica,
empresa brasileña de seguros:

Figura 13 – Mapa de stakeholders – SulAmérica

Fuente: http://ri.sulamerica.com.br/static/ptb/perfil-missao-visao-e-valores.asp?idioma=ptb

Habilidades y competencias del gerente de proyectos

Todo equipo necesita un líder y esto no es diferente en el contexto de los proyectos, donde
tal posición está ocupada por el gerente. Son innumerables las habilidades que marcan una gran
diferencia en el Gerente de todo proyecto, a tal punto que la literatura destina muchos capítulos al
tema, que es motivo de gran número de tesis académicas. Mucho se debate acerca de cuál es la
combinación ideal de habilidades y competencias que un gerente de proyectos debe reunir para
garantizar el éxito de su tarea. No obstante las diferentes cualidades o rasgos citados por los distintos
autores, existe consenso en cuanto a que un gerente de proyectos debe poseer los tres grandes grupos
o esferas de competencias mencionados a continuación:
a) Habilidades del negocio: capacidad de conocer el rubro de actividades del proyecto, sus
tendencias y movimientos, la parte verdaderamente técnica del proyecto, el know-how del
sector, cualquiera sea este: bancario, minorista, extractivo, etc.

40
 b) Habilidades de gestión de proyectos: como gestor y responsable del emprendimiento,
le corresponde al gerente conocer las técnicas de gestión de proyectos, las herramientas
de optimización.
c) Habilidades gerenciales o de comportamiento: también se espera de un gerente un
aspecto más soft, intangible, reflejado en competencias interpersonales como la empatía,
el liderazgo efectivo, la buena negociación, la toma de decisiones de calidad, el
entusiasmo, la transparencia, entre otras.

En la práctica, estas tres esferas se superponen y pueden representarse de la siguiente manera:

Figura 14 – Esferas de competencia del gerente de proyectos

Vale formular algunas reflexiones sobre el tema a partir del siguiente texto de Luis Torres
(2014, pp. 106-109).

Gestión de proyectos: conocimientos, habilidades y actitudes

La habilidad para gestionar proyectos es muy similar a la habilidad de gestión en áreas

administrativas; las mismas competencias empleadas en áreas correlacionadas pueden
adaptarse fácilmente a la gestión de proyectos y viceversa. Se espera que el gerente de
proyectos pueda conducir el proyecto desde su concepción (inicio) hasta la entrega final
(cierre) con eximia destreza y excelencia dentro de las expectativas de los interesados, que no
se limitan al alcance, tiempo, costo, calidad, riesgo, etc. Estas expectativas son

41
 circunstancias que pueden afectar todas las áreas de conocimiento de la guía PMBOK® y
otras áreas de frontera que no se incluyen en esta guía. Cada organización se adapta y crea
su conjunto de exigencias, y define sus criterios de entrega y de éxito para la gestión de
proyectos. Para ello, son necesarias algunas referencias básicas para avanzar en el contexto,
ya que sabemos la diferencia entre gerencia y gestión y entre plan y planificación. ¿Cuáles
son las habilidades, conocimientos y actitudes que pueden llevar al éxito de un proyecto?
¿Cómo definir y caracterizar el éxito para los proyectos, programas y carteras?

Gestionar proyectos requiere de un conjunto de competencias técnicas y no técnicas que

permitan objetivar tal excelencia. En este capítulo abordaremos este conjunto de habilidades,
conocimientos y actitudes que influyen en los resultados de los proyectos, además de los
tipos de estructuras organizacionales y de qué manera cada una de ellas puede impactar en
la forma y modelo de gestión de proyectos.

Conocimientos

Para gestionar proyectos, programas y carteras es necesario un conjunto de conocimientos.

Básicamente, el gerente del proyecto necesita conocer el negocio o la estrategia de negocios
de su organización. Si la gestión del proyecto se da en un ámbito industrial, es importante
que el gerente tenga conocimiento del sector, así como de sus características, estacionalidad
y ambiente interno y externo.

Conocer el negocio es importante, ya que hay proyectos que buscan el aumento de los
ingresos, la reducción de costos o la ampliación y hasta la maximización de recursos. Si el
gerente de proyectos no está familiarizado con el sector o segmento, o no tiene
conocimientos correlacionados sobre las características específicas del segmento donde
opera, no puede satisfacer las expectativas de los involucrados de manera plena y absoluta.

Por el contrario, si el gerente de proyectos posee sólidos conocimientos de las metodologías

de gestión de proyectos, al igual que de sus herramientas y técnicas, puede influir de manera
positiva en el resultado del proyecto, incluso en circunstancias en las que aquel no tenga
conocimientos sólidos y fundados del segmento en el que actúa. En este caso, el gerente del
proyecto será un facilitador de las metodologías, un integrador de los conceptos y, por medio
de las herramientas y técnicas, podrá controlar los resultados y las expectativas de los
proyectos. Lo mismo rige si el proyecto tiene lugar en un segmento de servicios, donde la
velocidad de respuesta a una demanda del mercado es fundamental. Como ejemplo de estos
casos están las empresas que desarrollan aplicaciones o servicios estacionales, en las que el
dinamismo para atender estas necesidades del mercado es esencial para satisfacer una
necesidad puntual o responder a una oportunidad de negocio.

El conocimiento del negocio no se restringe al ambiente del proyecto. Tomemos como

referencia un proyecto en un banco. ¿Cuál es el principal negocio del banco? Muchos van a

42
decir que son las tarjetas de crédito, la seguridad social, los seguros y muchos otros servicios.
En cierta forma, todos tienen razón, ya que se trata de productos que generan resultados
financieros y excelentes resultados en muchos de ellos. Sin embargo, al preguntárselo a un
director de operaciones o ejecutivo de negocios de un banco, lo más probable es que este
diga que la principal actividad son las cuentas corrientes, ya que el banco entiende que por
medio de este servicio, además de buenos resultados, incentiva otros servicios y productos.
Es común verificar en los noticieros, periódicos o revistas que los ingresos provenientes de
los servicios a cuentas corrientes pagan todos los costos operativos del banco (nómina de
pagos, costos directos, costos asociados a los empleados, etc.). De esta forma queda de
manifiesto la importancia del servicio así como la responsabilidad de proveer el servicio por
parte del banco. Dicho esto, si el gerente de proyectos trabaja en un proyecto que impacte en
las cuentas corrientes, ¿cómo debe gestionarlo? ¿Como un proyecto más o como un proyecto
estratégico? Si se percibe que el proyecto gestionado es un proyecto de cartera, un proyecto
estratégico, el principal objetivo no será tan solo alcanzar el resultado en función de los
aspectos operativos sino, por sobre todo, maximizar recursos, operativizar ingresos y generar
valor agregado para el banco, dado que se trata de un proyecto bancario estratégico.

De esta forma, el diferencial estará dado por el conocimiento no solo del mejor abordaje
(iterativo, incremental o lineal) sino también de las disciplinas correlacionadas como
matemática financiera, estadística, normas y estándares de calidad, administración de
contratos, relaciones con los proveedores y técnicas y herramientas que visibilicen la
ejecución del proyecto. No se espera que el gerente de proyectos sea un superhombre de los
negocios. Lo que se busca es desarrollar un profesional que genere resultados y valor
agregado en los negocios en los que participe de tal modo que, aparte de incrementar
resultados financieros, logre incluso más. Es recomendable que, además de las habilidades
interpersonales, el gerente de proyectos sepa difundir sus habilidades a través del coaching,
la gestión de personas, tenga conocimiento de las disciplinas de gestión de proyectos y,
asimismo, fomente el desarrollo de quienes lo rodean; es por eso que también son
importantes las habilidades gerenciales o de comportamiento.

Habilidades

El PMBOK contiene un conjunto de habilidades interpersonales que considera pertinentes

para el éxito de la interacción durante el ciclo de vida del proyecto; pero estas habilidades
que la guía recomienda son importantes no solo para el gerente sino para todos los
ejecutivos de proyectos que pretenden entender el ambiente organizacional a fin de obtener
una buena interacción y resultados. La guía apunta a las siguientes habilidades
interpersonales: liderazgo, formación de equipos, motivación, comunicación, influencia, toma
de decisiones, conciencia política y cultural, negociación, confianza, administración de
conflictos y coaching.
TORRES, Luis. Gerenciamento de projetos: conhecimentos, habilidades e atitudes. En: Fundamentos do gerenciamento
de projetos. Rio de Janeiro, Elsevier, 2014.

43
 De manera muy similar, aunque sintética, Valeriano (2001, p. 139) presenta el siguiente
cuadro con los “atributos deseables de un gestor de proyectos”:

Cuadro 2 – Atributos del gestor de proyectos

Conocimiento del sistema administrativo-

financiero de la organización

Conocimiento del sistema de administración de

los recursos humanos de la organización

Conocimiento Conocimiento de la organización, sus prácticas,

organizacional políticas y valores

Percepción de costos y de las implicaciones

administrativas de las decisiones técnicas

Conocimiento de los productos, las misiones o

los clientes de la organización
Conocimientos
Conocimiento de áreas relacionadas con la
especialización

Competencia técnica en el área de

especialización

Dominio de métodos de investigación

Conocimiento técnico Capacidad de planificación, organización y
control

Capacidad de liderazgo

Capacidad de autoanálisis

Capacidad de asignación de recursos

Capacidad de generar confianza en el superior

Habilidades Habilidades de mando Elección del estilo de liderazgo adecuado

Habilidades de toma de decisiones

44
 Capacidad de trabajar en equipo

Creatividad

Otras habilidades Habilidad de relacionamiento personal

Capacidad de redactar de manera clara, precisa

y concisa

Interés en cuestiones administrativas

Posicionamiento en
relación con aspectos
internos y externos
Actitudes
Disciplina de trabajo
Integración con el personal externo a la
organización
Ambición profesional

Hábito de abordar el problema mediante la

revisión de la literatura
Estrategia de acción

Hábito de lectura sistemática de textos técnicos

Fuente: VALERIANO (2001, p. 139).

Por último, pero no menos importante, tenemos el texto del reconocido autor André Barcaui
(2006) sobre el tema.

El equilibrio necesario para convertirse en un excelente gerente de proyectos

Mucho se habla hoy en día sobre la gestión de proyectos, tanto en medios académicos como
profesionales. Pero, ¿hasta qué punto la actividad de gestionar un equipo en pos de un
objetivo específico con un plazo determinado puede considerarse una disciplina? Y si no lo
es, ¿cómo procurar enseñarla por medio de cursos de perfeccionamiento para gerentes o
certificaciones? ¿Qué variable termina siendo más importante en la conducción de un
proyecto: el conocimiento técnico y metodológico o las llamadas habilidades interpersonales
de quien lo conduce? En otras palabras, ¿es preferible un gerente con profundos
conocimientos técnicos pero con poca experiencia y escasas vivencias en la gestión de
personas? ¿O sería mejor considerar un gerente con poco o incluso ningún conocimiento
técnico pero que domine como nadie los aspectos interpersonales y de relacionamiento de
equipos? Tal vez debiese existir un término medio, o sea, un gerente que actúe en todas las
dimensiones. Pero si así fuese, ¿cuál es la composición ideal de cada competencia? ¿Debería
esta composición variar según el tipo de proyecto que se esté gestionando?

45
 Proyectos versus personas

Independientemente del sector industrial o rubro de actividad, la gestión de proyectos viene

creciendo de manera exponencial en el mercado de trabajo. El interés por esta actividad ha
cobrado proporciones significativas en el mundo corporativo, principalmente para que las
empresas puedan atender mejor la necesidad de producir mejor, más rápido, más barato, con
menos recursos y con la debida calidad. Este interés se confirma por la gran demanda de la
carrera de gerencia de proyectos y por la cantidad de inversión en capacitación, asesoramiento
y herramientas que existen en la actualidad. En el libro Gerente também é Gente: Um Romance
sobre Gerência de Projetos [El gerente también es un ser humano. Una novela sobre la
gerencia de proyectos], el protagonista de la historia –recién promovido a gerente– tiene que
hacer frente a tres proyectos diferentes con distintos niveles de complejidad a lo largo de la
saga. Para ello, cuenta con la ayuda de un gerente más experimentado que termina
enseñándole que gestionar proyectos implica mucho más que el mero uso de técnicas y
herramientas. Para lograr el éxito es preciso ser un buen conocedor de las personas, lo que el
protagonista termina aprendiendo al tiempo que tiene que administrar su vida profesional y
personal. A partir de esta situación, el libro procura presentar una perspectiva que no se limite
tan solo a los métodos y procesos sino que sea más abarcadora y tenga además en cuenta el
costado humano del gerente de proyectos, ya que aborda aspectos tales como conflictos
personales, inseguridades y temores inherentes al cargo.

En la vida real, el gerente, líder o coordinador de proyectos termina por desempeñar un

papel de fundamental importancia para el éxito de los proyectos de una organización. Si
consideramos que estos proyectos representan el medio para la concreción de la estrategia
de negocios de la empresa, tener un buen gerente de proyectos al mando es un factor crítico
para tal éxito. Sin embargo, las características que determinan un gerente de proyectos
exitoso no siempre son tan fáciles de identificar. Históricamente, el conocimiento técnico del
negocio y la propia formación académica eran vistos como aspectos fundamentales para la
selección acertada de un gerente.

Más recientemente, pasaron a considerarse y valorarse otras características. Otras

habilidades que antes se tenían por deseables cobraron otro grado de importancia. Ellas son:
buenas relaciones interpersonales, gestión de conflictos, inteligencia emocional, negociación,
coaching, etc. Todas estas características sumadas representan un peso importante en el
perfil de un gerente exitoso. Pero no se sabe con certeza la ponderación que tiene este
conjunto de habilidades de gestión en la composición de este perfil, en especial en relación
con otras competencias consideradas clásicas y más ligadas al sector, como el uso de la
metodología, las reglas y el conocimiento técnico.

El propio PMI (Project Management Institute), en la versión más reciente del PMBOK (Project
Management Body of Knowledge), pasó a valorar de manera más evidente algunas
características ligadas a la dirección del equipo y la gestión de los stakeholders. Algunas de las
modificaciones introducidas en sus áreas de conocimiento sugieren una mayor

46
 "humanización" de la gestión de proyectos y no meramente las competencias técnicas del
gerente del proyecto en tanto planificador, supervisor, ejecutor y responsable general del
proyecto. Este movimiento, si bien legítimo, termina por provocar interesantes discusiones
acerca de hasta qué punto las habilidades de gestión –considerada por muchos autores
como el "arte de gestionar"– pueden ser incluso más fundamentales que el propio
conocimiento técnico en sí, aliado a la utilización de una fuerte metodología de gestión.
BARCAUI, André. O equilíbrio necessário para se tornar um excelente gerente de projetos. Revista MundoPM, 2006. Disponible
en: <http://www.eduwork.com.br/artigos/ver/gerencia-de-projetos-arte-ou-disciplina>. Acceso en: enero 2019.

Es obvio que la garantía de éxito del proyecto no dependerá solo de estas calificaciones del
gerente, pero vimos que repetidamente se afirma que varios de estos rasgos son sin duda deseables
en este profesional. Además de la natural necesidad de conocimiento técnico y de experiencia con
guías como el PMBOK o de otras metodologías, concluimos que el gerente de proyectos que se
destaca necesita también habilidades de comportamiento. Las visiones presentadas arriba abonan la
conclusión de que el papel de este stakeholder es realmente definitivo en el ambiente de proyectos.

Project Management Office (PMO)

La PMO (Project Management Office) es una unidad o un departamento de la empresa
responsable de los proyectos de una organización. Este órgano puede recibir otros nombres como
Oficina de Proyectos, Oficina de Gestión de Proyectos, Comité Director de Proyectos, Coordinación
de Proyectos, Oficina de Apoyo a Proyectos o, simplemente, Project Office. La PMO puede tener
diversas funciones y alcances, que necesariamente dependen de la etapa en la que se halle su
implementación y de las carencias de la empresa, más allá del grado de complejidad de los proyectos.
Por lo general, la PMO inicia sus actividades con responsabilidades básicas y claras, por
ejemplo, la capacitación de los gerentes de proyectos de la compañía, la creación y unificación de
nuevos modelos (templates) de documentación usados en los diversos proyectos, y una mejor
integración de los gestores de proyectos y los gerentes funcionales. Es habitual que la PMO
perfeccione las normas de gestión asumiendo una metodología o haciendo una combinación de
varias. Otro rol habitual que se le asigna a esta unidad es la capacitación para la utilización de
software para la gestión de proyectos (como Ms Project, WBS Chart Pro, Primavera, etc.).
A medida que evolucionan, estas oficinas de proyectos también pueden enviar informes
consolidados y periódicos a la alta gerencia, o incluso al presidente (CEO) de la empresa, con datos
de los múltiples proyectos en curso, sus respectivos avances, puntos de atención, beneficios
obtenidos, revisiones críticas, riesgos, etc.

47
 En un nivel aún más sofisticado, las PMO pueden asumir también la función de monitores
centrales de todos los plazos y presupuestos de los proyectos actuales de las organizaciones, además

… del análisis y de la aprobación de propuestas de proyectos según los

objetivos estratégicos de la organización y criterios complementarios, la
distribución de recursos según prioridades establecidas, la identificación de
conflictos y recomendaciones para su solución, la revisión crítica y
evaluación de proyectos, la actuación externa con foco en los clientes y
patrocinadores… (VALERIANO, 2001, p. 109).

Una recomendación general para el éxito de esta unidad es que tenga las merecidas y
necesarias autoridad y autonomía. En la literatura, hay diferentes casos de PMO que fallaron en su
propósito porque no recibieron el aval o apoyo de sus directores o presidentes. Otros casos de fracaso
incluyen hasta situaciones de sabotaje contra las actividades de esta oficina.
Dado que se trata de un órgano que exigirá resultados a otros sectores y expondrá números y
desempeños, es imprescindible que la creación de una PMO se combine con una campaña interna
para concientizar a todos con respecto a la función de este departamento, de modo de evitar las
naturales resistencias. El apoyo de toda la organización a esta oficina será, sin duda, una pieza clave
para lograr las ventajas que genera habitualmente su buen funcionamiento.
En este sentido, Barcaui explica que

… una característica interesante es que la mayoría de las PMO se

establecen cuando las empresas no soportan perder más dinero con sus
proyectos. En otras palabras, hasta el momento la mayoría de las oficinas
de proyectos se crearon de manera reactiva. La expectativa del stakeholder
es que la PMO sea una especie de “mesías o salvador de proyectos” y
organice la incomodidad existente en la empresa a raíz de la gestión de
proyectos… (BARCAUI, 2006, p. 11)

Además de ello, con la creciente valoración de la gestión del conocimiento, diversas oficinas
de proyectos están creando y manteniendo un repositorio de Lecciones Aprendidas (Lessons
Learned) a partir de los distintos proyectos. Por lo general, este documento es elaborado por los
gerentes de proyectos, contiene las experiencias positivas y negativas durante la vida del proyecto y
se emite cuando este concluye. En el caso de empresas que cuenten con PMO, este documento
sigue un flujo y es entregado por el gerente del proyecto al responsable de la PMO.

48
 Con el tiempo, esta valiosa información incluida en los documentos que integran las
Lecciones Aprendidas podrá ser usada por el propio órgano para cruzar datos, crear estadísticas y
medir su desempeño por medio de los datos históricos de los proyectos documentados.
Últimamente, estos documentos han sido informatizados y se están colocando en repositorios on-
line, en carpetas compartidas o en la intranet de organizaciones.
Esa documentación brinda soporte a futuros gestores de proyectos para la toma de decisiones,
ya que estos profesionales, al estar al tanto del contenido de los documentos, podrán evitar la
repetición de los errores cometidos por sus colegas y, sin duda, podrán seguir posibles consejos que
estos hayan incluido en las Lecciones Aprendidas.
La propagación de las PMO en las organizaciones ha sido bastante razonable e incluye a las
prestadoras de servicios. Por ejemplo, el Hospital Israelita Albert Einstein de San Pablo concluyó el
proyecto de creación de su oficina de proyectos en 2010 y, cada año, su dirección promueve una
investigación en los diversos sectores para reconsiderar la utilidad de esta unidad. Esta PMO es
considerada clave en este hospital, por lo que tiene una ubicación de gran visibilidad en el
organigrama de la empresa, tal como vemos a continuación:

Figura 15 – La PMO en la estructura del Hospital Albert Einstein

Fuente: http://www5.each.usp.br/wp-content/uploads/2016/07/EAIP-O-Caso-do-Hospital-Albert-Einstein.pdf

49
 Para concluir el tema, según el autor Luis Torres:

… Una oficina de proyectos (OP) puede tener autoridad para gestionar,

controlar, delegar y marcar el inicio de un proyecto, y tomar medidas de
control según sea necesario para mantener la congruencia de los objetivos
de negocios. Además, la OP puede participar en la selección, la gestión y
la movilización de recursos de proyectos compartidos o dedicados…
(TORRES, 2014, p. 99).

La figura a continuación ilustra claramente las funciones más usuales de la PMO:

Figura 16 – Funciones de la PMO

Fuente: TORRES, 2014, p. 102.

En suma, cabe pasar en limpio los innumerables beneficios obtenidos con la adopción de las
oficinas de proyectos. En particular:
 distribución más inteligente de recursos (humanos y materiales);
 seriedad y profesionalismo en la gestión;

50
  uniformidad en la documentación de proyectos;
 creación y mantenimiento de una cultura de proyectos;
 integración de sistemas de información empresarial;
 mantenimiento del acervo de las lecciones aprendidas y
 mayor productividad de los equipos ejecutores de proyectos.

Estructuras organizacionales
La manera en que se compone el equipo de un proyecto, así como la autonomía en la gestión
de los gerentes de proyectos, la existencia de una oficina de proyectos o la agilidad con la que fluyen
las comunicaciones son apenas algunos puntos concretos que dependen directamente del modelo
de estructura adoptado por las organizaciones. Es evidente que el tipo de estructura jerárquica
vigente en una determinada empresa podrá implicar la mayor o menor importancia dada a la gestión
de proyectos, lo que facilitará o impedirá su avance.
Algunos modelos son más propicios para el avance de la gestión de proyectos y de la propia
carrera del gerente de proyectos, mientras que otras estructuras no lo son tanto. Existen
principalmente tres grandes formatos de estructura para gestionar el trabajo y las personas en las
organizaciones.

Organización funcional
Desde la formación de los primeros ejércitos existe esta estructura, que hasta el día de hoy
está directamente asociada a las instituciones militares. Esta estructura fue luego adoptada por la
iglesia católica para asegurar un mayor control de su funcionamiento. Este modelo funcional,
también conocido como jerárquico o piramidal, existe aún en la actualidad y se usa en diversas
organizaciones de cualquier esfera y porte. Veamos de qué manera esta estructura se relaciona con
el contexto de los proyectos.
En una estructura funcional contemporánea, el equipo de un proyecto está compuesto por
personas del mismo departamento. Todos los recursos necesarios para dicho equipo provienen de la
organización funcional. En la práctica, son los gerentes de los sectores (funcionales) los que van a
ejecutar los proyectos. Por ejemplo, si el proyecto está relacionado con la función de finanzas, los
recursos del proyecto provendrán del departamento financiero. Si se necesitan recursos contables,
financieros o jurídicos, todos estarán disponibles en el departamento financiero, y así sucesivamente.
Una segunda manera de obtener los recursos para un proyecto dentro de una organización
funcional es ejecutar el proyecto en partes y cada parte se ejecutará en su respectivo departamento.
De este modo, si un proyecto de gran porte contemplase el uso de recursos de finanzas, compras,
informática y producción, tal proyecto se dividiría por departamento en una organización

51
funcional, vale decir que cada cual haría su parte del todo, cada una de las áreas aportaría su propio
expertise en relación con las actividades del proyecto y con relativa independencia. Al final, todas las
diferentes partes se integrarían en una solución final.
Una de las grandes ventajas de los proyectos ejecutados en las organizaciones basadas en la
funcionalidad es que, por lo general, hay una autoridad clara, ya que los gerentes de proyectos
también tienden a ser los gerentes funcionales. Estos no necesitan negociar los recursos con otras
organizaciones, porque todos los recursos necesarios se reportan a la misma organización funcional.
Esta unidad de jefatura también es beneficiosa para los miembros del equipo del proyecto, pues
responderán únicamente a un gestor, que es definido y designado bajo esta estructura.
Otra ventaja de esta organización es que los miembros del equipo tienden a estar
familiarizados entre sí, ya que todos, en teoría, trabajan en la misma área y también aportan
conocimientos de negocios aplicables al proyecto. La especialización es además un factor favorable
al modelo porque unifica a los profesionales por conocimiento dentro de las respectivas
especialidades verticales (finanzas, informática, recursos humanos, producción, etc.).
Por otro lado, una de las principales desventajas de la organización funcional es que tal vez
las áreas funcionales no cuentan con todos los especialistas necesarios para trabajar en un proyecto.
Por ejemplo, un proyecto del departamento financiero, con un componente de tecnología, puede
tener dificultades para adquirir recursos especializados, como administradores de bases de datos,
porque posiblemente las únicas personas idóneas para este tipo de tarea estén trabajando en su
propio departamento funcional. Esto dificulta y, a veces, torna inviables los proyectos
multisectoriales o multidisciplinarios. A este respecto, Valeriano (2001) afirma que:

… cualquier tipo de trabajo atribuible a más de un departamento, que

comprenda más de uno de estos, o esté fuera de este marco, es considerado
una anomalía o una anormalidad: la organización funcional no fue hecha
para responder a solicitudes extemporáneas y, en consecuencia, no está
preparada para ejecutar otro trabajo interdepartamental que no
corresponda al proceso productivo [...] y no es capaz de dar pronta
respuesta a problemas que exijan la cooperación de varios
departamentos… (p. 17)

Otra desventaja de esta estructura es que es probable que los miembros del equipo tengan
otras responsabilidades ajenas al proyecto. Ellos pueden trabajar en otros proyectos, pero tienen,
habitualmente, la responsabilidad de brindar apoyo a sus propios departamentos, lo que impactaría
en su capacidad de cumplir los plazos del proyecto, dada la menor disponibilidad de tiempo.

52
 Una estructura funcional puede representarse como se muestra a continuación, suponiendo
que el proyecto se dé en el seno del departamento de productos:

Figura 17 – Estructura organizacional funcional

Fuente: TORRES (2014, p. 123).

Otro ejemplo de esta configuración funcional sería:

Figura 18 – Ejemplo de estructura funcional

Fuente: VALERIANO (2001, p. 16).

53
Organización matricial
Las organizaciones matriciales permiten que los departamentos funcionales pongan el foco
en las competencias específicas empresariales y que, al mismo tiempo, los proyectos estén integrados
por especialistas de toda la organización. De este modo, es el modelo intermedio entre el funcional
y los proyectos (que veremos a continuación).
En este modelo, por ejemplo, los administradores de bases de datos pueden responder a un
departamento funcional, pero a la vez ser asignados a varios proyectos en otros sectores que lo
requieran. Del mismo modo, un especialista del derecho podrá depender del área legal y también
ser designado para un proyecto de otro departamento que demande este tipo de conocimiento.
La ventaja principal de la organización matricial es la asignación eficiente de todos los
recursos, en particular, los de calificaciones infrecuentes, que no son necesarias a tiempo completo
en el proyecto. Por ejemplo, si bien quizá no utilice a los especialistas en modelado de datos a
tiempo completo en un único proyecto, se los aprovechará enteramente al asignarlos a otros
proyectos en los que resulten de utilidad.
La organización matricial también es más flexible ante los cambios de las necesidades y las
prioridades del negocio, dado que posibilita la transversalidad entre los sectores.
La desventaja principal de la organización de tipo matricial es que las relaciones de
subordinación son complejas. Puede ocurrir que algunas personas dependan jerárquicamente del
gerente funcional para quien ejecutan poco trabajo, al tiempo que trabajan para uno o más gerentes
de proyectos. Por ello, es cada vez más importante que los empleados desarrollen rápidamente
habilidades de gestión del tiempo, de manera de garantizar que se atiendan las expectativas de
trabajo de múltiples gerentes.
Esta organización también requiere de una buena comunicación y cooperación entre los
diversos gerentes funcionales y los gerentes de proyectos, pues necesitarán utilizar los mismos
profesionales. Este es uno de los mayores problemas de la estructura matricial, que deriva en la
acumulación de funciones. Según Valeriano (2001),

… en algunos momentos, un profesional responde a su jefe de

departamento y, en otros, al gerente de proyectos (...) De este modo, los
jefes se sentían muy disminuidos y desprestigiados por “interferencias” en
sus reductos y en la prestación de servicios a “extraños” por parte de sus
subordinados. A su vez, sin una clara distribución de autoridad y
responsabilidades, los profesionales estaban confundidos acerca de a quién
rendir cuentas y cuáles, de entre sus jefes, serían los que realmente
evaluarían su desempeño para el otorgamiento de recompensas,
promociones, etc… (p. 19-20)

54
 Sin duda, esta problemática de la doble jefatura, común en la estructura matricial, trae aparejada
una acumulación de funciones: desde el punto de vista del empleado que es asignado a más de un
proyecto, debe responder a más de un gerente y, aun así, completar las tareas funcionales cotidianas.
En general, una empresa con modelo matricial podría presentar la siguiente configuración,
en la cual resulta evidente la mayor facilidad de los proyectos transversales y multisectoriales.

Figura 19 – Ejemplo de estructura matricial

Fuente: VALERIANO (2001, p. 19).

Además, cabe resaltar que el modelo matricial puede presentar tres subdivisiones posibles: la
estructura matricial débil, la matricial balanceada y la matricial fuerte, que se describen en el texto
de Torres (2014, p. 127-131).

55
 Figura 20 – Estructura matricial débil

La estructura matricial débil es predominantemente funcional. Como puede observarse, los

equipos están separados por especificidades y la gestión es jerárquica. No obstante ello, surge la
figura del coordinador de proyectos (o líder de proyectos). Esto significa que uno de los recursos de
la estructura, por lo general el de mayor nivel jerárquico o con más experiencia organizacional, será
responsable de la administración y la coordinación del proyecto. En esta estructura, el coordinador
del proyecto no tiene las mismas atribuciones y responsabilidades que el gerente del proyecto. Como
puede verse, el coordinador del proyecto está dentro de una estructura organizacional funcional y
las actividades diarias de rutina deben ser ejecutadas por él. Vale decir que en esta estructura el
coordinador del proyecto dedica parte de su jornada a la gestión del proyecto y la mayor parte de
su tiempo, a las actividades diarias.
A continuación veamos las ventajas y desventajas de la estructura matricial débil:
 Ventajas: para el coordinador de proyectos es favorable tener contacto con las herramientas
y técnicas de la gestión de proyectos, y evaluar sus competencias y habilidades. Además,
así como los recursos pueden trabajar en actividades diarias y en proyectos determinados
de manera simultánea, los equipos comienzan a tener contacto con las metodologías de
gestión de proyectos y, si bien de manera incipiente, empiezan su aprendizaje.
 Desventajas: doble subordinación, de modo que los recursos comienzan a percibir que
existe una subordinación directa a la jerárquica, a la vez que hay reclamos por los resultados
de los proyectos. Dadas las prioridades de ambos tipos de gerentes, se generan tensiones y
conflictos en relación con las actividades a ejecutar. Aunque la prioridad de los proyectos
sea baja, se producen reclamos por los resultados de los proyectos y eso termina generando
expectativas no atendidas y frustraciones.

56
 Adjudicando mayor fuerza al rol del coordinador de proyectos, la estructura organizacional
balanceada puede explicitarse de la siguiente manera:

Figura 21 – Estructura matricial balanceada

En esta estructura, el coordinador de proyectos pasa a tener el rol de gerente del proyecto y
ya no ejecuta actividades diarias o rutinas operativas. Aun estando presente en una estructura con
fuertes características funcionales, en este modelo, el elemento del equipo (por lo general, el de más
alto rango) pasa a ejercer la función de gerente de proyectos a tiempo completo. Mientras dure el
proyecto, este actuará como director del proyecto.
Si el proyecto termina o se cancela, este profesional regresa a sus responsabilidades, actividades
y operaciones diarias. En el caso de proyectos recurrentes, este podrá ocupar la posición por un
tiempo mayor. Sin embargo, es pertinente recordar que, en la estructura matricial balanceada, el
profesional no es gerente de proyectos sino que se desempeña como gerente de proyectos mientras
estos duren.
Veamos a continuación las ventajas y desventajas de esta estructura:
 Ventajas: como estamos hablando de estructuras matriciales, las ventajas son bastante
similares entre las estructuras débil, balanceada y fuerte. No obstante ello, podemos
destacar que, en esta estructura, el gerente de proyectos puede aplicar los métodos, las
herramientas y las técnicas de gestión de proyectos. Su dedicación a la gestión y al control
del proyecto es exclusiva, lo que permite una mayor y mejor interacción con los procesos
y dinámicas de gestión. Asimismo, el ejercicio de la función gerencial es una forma de
madurar profesionalmente tanto en lo que respecta a las prácticas de gestión de personas
y recursos como a la preparación para funciones futuras de gerente de proyectos o en otras
áreas de gestión.

57
  Desventajas: la principal se refiere a desempeñarse como gerente de proyectos. Como
podemos percibir, si el proyecto se termina, el recurso que tenía roles y responsabilidades
de gestor regresa al llano del equipo y vuelve a ejecutar sus actividades y rutina de la
función. Muchas veces, esto provoca tensión o conflicto entre los miembros del equipo,
que dejan de percibirlo como un par, ya que por un tiempo prolongado ejerció la función
de dirección y control. En el profesional que hasta entonces era gerente puede generar
frustración en relación con el entorno.

Es altamente recomendable que, al ocupar la responsabilidad de gerente dentro de una

estructura matricial balanceada, el profesional revea su posición dentro de la organización del
proyecto y reevalúe sus relaciones y comprenda que el mismo tiene un rol transitorio y debe usar
ese tiempo para aprender y familiarizarse con las tendencias, situaciones y características de la
gestión. Cuando no se lo promueve o no conserva su rol de gerente, es aconsejable que, al retomar
sus rutinas anteriores, regrese con más madurez y habilidad para relacionarse con las personas
jerárquicamente, así como hacer frente a sus limitaciones y características, de modo de evitar
frustraciones y administrar mejor las relaciones futuras.
Por último, pasemos a la estructura matricial fuerte, la más habitual en las organizaciones
y con un volumen acentuado de proyectos.

Figura 22 – Estructura matricial fuerte

Como podemos ver, en esta estructura surge una gerencia o dirección para la gestión de
proyectos. Los gerentes de proyectos se agrupan bajo esta dirección y utilizan los recursos
organizacionales para la consecución de los proyectos.

58
 Para la gestión de proyectos, esta estructura permite la difusión de los conocimientos, las
herramientas y técnicas de gestión de proyectos y facilita un control más eficiente de los recursos
humanos, financieros y estratégicos de la empresa, no con máxima eficiencia, sino con mejor
administración.
Los gerentes de proyectos asignan los recursos de la organización a medida que los proyectos
los requieran y los recursos también actúan en actividades diarias. Dado que el gerente de proyectos
sénior tiene el mismo nivel jerárquico que los demás gerentes funcionales, la estructura es más
estable en lo que respecta a la administración, la gestión y el control de los proyectos.
Veamos a continuación las ventajas y desventajas de esta estructura:
 Ventajas: esta estructura permite una mejor asignación de los recursos y los optimiza para
el control de los proyectos. Los miembros del equipo pueden trabajar en procesos y rutinas
internas y en las actividades del proyecto. En esta estructura existe un mejor control de la
gestión de los equipos, la coordinación de las actividades de los proyectos es más eficiente
y eficaz, la información sobre los aspectos de gestión de los proyectos se vuelve más fluida
y constante y el soporte de las áreas funcionales es más efectivo, dado que la comunicación
tanto horizontal como vertical sobre los proyectos transcurre con mayor agilidad.
 Desventajas: doble subordinación, de modo que el equipo del proyecto actúa en
actividades diarias para los proyectos y pasa a tener dos gerentes, los funcionales y los de
proyectos, lo que genera una red de tensiones y disputas por los recursos más eficientes y
estratégicos. Los proyectos rivales pugnan por los recursos y así aumenta la complejidad
para monitorear y controlar el proyecto, las rutinas y los procesos.

Organización por proyectos

Como el propio nombre lo indica, en este modelo, el gerente de proyectos cuenta con más
margen para ejercer su cargo y posee más autoridad sobre los recursos disponibles del proyecto. En
el modelo por proyectos, el equipo ejecutor del proyecto se asigna y consolida de manera
temporaria, es decir, por el tiempo que dure la tarea; ese equipo estará dedicado hasta la conclusión
del proyecto o hasta tanto se lo necesite. Lo mismo vale para la asignación del gerente del proyecto,
al que se le ha encargado la tarea con dedicación exclusiva. Por consiguiente, la asignación del
equipo al proyecto es prácticamente integral o exclusiva, y no hay competencia por el tiempo del
equipo entre el proyecto y el departamento (como vimos en la estructura matricial).
En el caso de un proyecto de mayor tamaño, es posible crear departamentos funcionales en
torno al equipo del proyecto. Esto resulta particularmente práctico cuando un programa grande
tiene docenas o cientos de personas designadas por un plazo prolongado. Las ventajas de este
modelo por proyectos incluyen una autoridad clara, porque el gerente del proyecto es también el

59
gerente funcional, y un foco claro, porque todos los integrantes del equipo únicamente tienen el
proyecto como responsabilidad principal.
Las desventajas de esta organización incluyen la duplicación de recursos, dado que los recursos
escasos deben multiplicarse para los distintos proyectos. Por ejemplo, un proyecto de mayor
envergadura puede exigir la totalidad del área de recursos humanos. Otro posible punto
desfavorable es el riesgo de ociosidad de algún recurso del equipo, dada su asignación integral al
proyecto. Si un profesional no está siendo empleado en un 100% en el proyecto X y no hay otro
proyecto al cual asignarlo, se verificará esta ociosidad de hecho.
Por otra parte, en este modelo, puede surgir alguna preocupación sobre cómo reasignar o
desmovilizar a las personas y los recursos al cierre de los proyectos. En una organización funcional,
las personas aún tienen trabajo dentro del departamento funcional y regresan al mismo al final del
proyecto. Sin embargo, en una organización por proyectos, no está tan claro dónde deberá ser
asignado cada recurso una vez concluido el trabajo. Ello podría generar algún tipo de malestar o
temor en los recursos.
La estructura por proyectos podría presentar esta configuración:

Figura 23 – Estructura organizacional por proyectos

Fuente: TORRES (2014, p. 124).

60
 La figura a continuación esboza importantes características relacionadas con los proyectos y
su cruzamiento según los tipos de estructuras organizacionales que vimos.

Cuadro 3 – Comparación de modelos de estructura organizacional

Estructura de Matricial
organización
Por
Funcional
Débil Balanceada Fuerte proyectos
Característica
del proyecto

Autoridad del gerente de Poca o Baja a Moderada a Alta a casi

Limitada
proyectos ninguna moderada alta total

Poca o Baja a Moderada a Alta a casi

Disponibilidad de recursos Limitada
ninguna moderada alta total

Quién controla el Gerente Gerente Gerente de Gerente de

Mixto
presupuesto del proyecto funcional funcional proyectos proyectos

Función del gerente de Tiempo Tiempo Tiempo Tiempo Tiempo

proyectos parcial parcial completo completo completo

Equipo administrativo de Tiempo Tiempo Tiempo Tiempo

Tiempo parcial
gestión de proyectos parcial parcial completo completo

En este cuadro comparativo, resulta bastante evidente que hay más chances de desarrollar una
carrera en gestión de proyectos en los formatos matricial y por proyectos. Se concluye que, en una
firma de tipo funcional es más infrecuente la existencia del cargo de gerente de proyectos y del
desarrollo profesional en el área.
En lo que atañe específicamente a la posición de gerente de proyectos en estas tres grandes
estructuras, en comparación con el funcional, hay más autoridad del primero en relación con el
segundo a medida que avanzamos de izquierda a derecha. Es decir que en las estructuras matriciales
y por proyectos, el cargo de gerente de proyectos asume más autoridad y relevancia. Contrariamente,
en la dirección inversa, siguiendo los modelos más a la izquierda del cuadro, tendremos un gerente de
proyectos con poca o ninguna autoridad en comparación con los gerentes funcionales.

61
 Figura 24 – Estructuras organizacionales y autoridad

Procesos de gestión de proyectos

Grupos de procesos
La enseñanza y la aplicación de los conceptos propios de los proyectos suelen fundamentarse
en procesos. Esto tiene sentido si entendemos que los proyectos se realizan por medio de la
integración de múltiples procesos de gestión y perfeccionamiento. Así, la guía del PMBOK presenta
cinco grupos o categorías de procesos de gestión de proyectos, que son los siguientes:
 procesos de iniciación: responsables de definir y autorizar el proyecto o el inicio de una de
sus etapas;
 procesos de planificación: responsables de definir y refinar los objetivos, así como de
planificar la acción necesaria para alcanzar los objetivos y el alcance para los cuales se
realizó el proyecto;
 procesos de ejecución: se ocupan de la integración de las personas y otros recursos para la
concreta implementación del plan de gestión del proyecto;
 procesos de monitoreo y control: su función es la de medir y evaluar, en forma regular, el
progreso del proyecto identificando variaciones con relación a lo planificado, de modo
que se puedan realizar acciones correctivas, cuando sea necesario, con el fin de atender a
los objetivos del proyecto;
 procesos de cierre: su misión es formalizar la aceptación del producto, servicio o resultado
(también conocida como homologación) con el objetivo de conducir el proyecto (o una
de sus etapas) hacia un final ordenado.

62
 Un proyecto debe implementar estos 5 grupos de procesos considerando que los procesos son
conglomerados de acciones y actividades interrelacionados y superpuestos. Los procesos
pertenecerán siempre a uno de los cinco grupos o naturalezas, sin embargo, en la práctica se los
llevará a cabo de forma iterativa. Las dos figuras siguientes lo explican de modo esquemático:

Figura 25 – Procesos en gestión de proyectos

63
 Figura 26 – Interacción de procesos en gestión de proyectos

Adicionalmente, en la 6ª edición de la guía del PMBOK los cinco grupos de procesos de

gestión se presentan divididos en un total de 49 procesos, clasificados según su área de conocimiento,
que se implementarán a medida que avance el proyecto. La siguiente ilustración muestra cómo
interactúan estos procesos durante el desarrollo de un proyecto, es decir, la salida de uno de los procesos
probablemente será la entrada de otro. Como ya se mencionó, el alto grado de superposición de estos
procesos de gestión se manifiesta de modo evidente. En realidad, no es necesario concluir un proceso
para iniciar el otro, ya que los dos se pueden realizar en forma paralela.

Figura 27 – Interacción entre procesos de gestión de proyectos

64
Ciclo de vida de un proyecto
De la misma forma en que se aplica el concepto de ciclo de vida a los seres humanos, el mismo
razonamiento existe en el ámbito de los proyectos, lo cual no podría ser de otra manera. Los
proyectos son entidades vivas, orgánicas y finitas, y es natural que también tengan su propio ciclo
de vida. Ello refuerza, una vez más, la característica de temporalidad propia de los proyectos, en
concordancia con lo que se describió en el primer módulo.
Cabe destacar que es común confundir el concepto de ciclo de vida y el de proceso de gestión
de proyectos. De acuerdo con lo visto anteriormente, los procesos de gestión de proyectos se
distribuyen a lo largo de la vida útil del proyecto. En otros términos, estos procesos de gestión se
suceden dentro del ciclo de vida de un proyecto.
A continuación, la figura representa este esquema, donde el ciclo de vida del emprendimiento
aparece con la línea más gruesa y los procesos, dentro de dicho límite.

Figura 28 – Ciclo de vida

En forma complementaria, es importante destacar que, normalmente, los grupos de procesos

son fijos para todos los tipos de proyecto, es decir, todos los proyectos pasarán por los cinco grupos
de gestión. Sin embargo, cuando estos procesos requieran de mayor detalle o se los deba dividir, se
podrán apreciar las etapas del proyecto. Estas divisiones o etapas servirán para conectar el esfuerzo
desde el inicio hasta el fin. El ciclo de vida de un proyecto se obtiene, por consiguiente, por medio
de la suma de sus etapas. La siguiente figura muestra una secuencia típica de etapas en el ciclo de
vida de un proyecto genérico:

65
 Figura 29 – Etapas del ciclo de vida del Proyecto

Es necesario observar que las etapas de un proyecto son bastante específicas en cada rubro de
actividades. Según cuál sea la actividad a la que pertenece la empresa ejecutora del proyecto, variarán
las denominaciones de sus distintas etapas. De la misma manera, dependiendo de cuál sea el sector
responsable del emprendimiento, se darán nombres diferentes a las etapas de dichos proyectos. En
síntesis, los nombres de las etapas de cada proyecto necesariamente serán distintos y variables, lo
cual confirma la característica de exclusividad presentada en el primer módulo.
Por ejemplo, un proyecto realizado por la división de Investigación y Desarrollo no tendrá
las mismas etapas que un proyecto de la división de control cambiario de un banco. Aunque haya
otros proyectos en desarrollo en los mismos sectores, las etapas tendrán denominaciones específicas
y, posiblemente, distintas. Es importante destacar un punto en común entre ellos: todos aplicarán
los cinco grupos de procesos de gestión de proyectos, aunque las etapas sean diferentes,
respectivamente. Esto se puede apreciar en la siguiente ilustración:

Figura 30 – Procesos y actividades

Fuente: VARGAS (2016)

66
 Sin dudas, la división del ciclo de vida en etapas facilita el control del proyecto al gerente, al
lograr que su foco esté más segmentado, sin perder la noción total del esfuerzo. Por ejemplo, el
proyecto de desarrollo de un sistema tendría las siguientes etapas que componen su ciclo de vida
(VALERIANO, 2001, pp. 134-136):
 etapa A: diseño conceptual;
 etapa B: diseño detallado;
 etapa C: investigación y desarrollo del producto y los servicios asociados;
 etapa D: producción, construcción, instalación;
 etapa E: operación, utilización y servicios asociados, y
 etapa F: fin del servicio y descarte.

Figura 31 – Etapas de un proyecto específico

Fuente: VALERIANO (2001)

67
 Cabe destacar que la transición entre una etapa y la siguiente presupone un producto, una
transferencia de saber o una entrega o entregable. Se puede estar hablando de un documento, una
reunión solemne o un resultado tangible y verificable, como lo serían el plan de gestión del proyecto
al ser entregado, o bien un prototipo del producto del proyecto, un informe de desempeño
bimestral, la construcción de los cimientos de una obra o de un módulo de un curso. Los siguientes
son ejemplos de posibles puntos de transición:

Figura 32 – Puntos de transición

Fuente: PMBOK (2017)

Normalmente, la entrega que se hace entre una etapa y otra del proyecto deberá ser aprobada
por el cliente del proyecto. Si se cumple con los requisitos, esta aprobación por parte del cliente
definirá la autorización para pasar a la siguiente etapa. De forma suplementaria, estas transiciones
de una etapa a otra deben encararse como un punto de control de calidad del proyecto. El gerente
debe apoyarse en el equipo para evaluar el progreso del esfuerzo realizado durante estas transiciones
entre las etapas. Si corresponde, debe implementar ajustes.
Según Valeriano (2001, pp. 126-127), las diferentes etapas del ciclo de vida podrían
caracterizarse individualmente de la siguiente manera:
a) Etapa de iniciación
Esta etapa da inicio al proyecto y constituye un conjunto de percepciones, voluntades e
intereses, en general estimulado por una demanda o necesidad externa, o bien por una oferta u
oportunidad de la organización o del grupo que emprenderá el proyecto. Así se identifica la
necesidad o la oportunidad y la manera de suplirla, es decir, se detecta el problema y se concibe una
vía de solución. Esta etapa se caracteriza por el compromiso de la organización en continuar a la
etapa siguiente. Aquí, es común hacer una estimación de los esfuerzos a realizar, especialmente en
términos de costos y plazos, para dar una base a la iniciación.

68
 b) Etapa de planificación
Con la información relevada en la etapa de iniciación, se procede a la planificación
estableciendo el alcance del proyecto progresivamente. Por lo general, se suele desdoblar la
planificación en dos subetapas: planificación preliminar y planificación detallada.
La planificación preliminar contiene información global del emprendimiento que se iniciará,
con la definición del producto del proyecto, la manera de obtenerlo, los costos, los plazos, los demás
recursos y los compromisos necesarios, los riesgos involucrados, etc. Esta subetapa es útil para las
negociaciones con las partes interesadas, a fin de conciliar los objetivos, aunar esfuerzos, comenzar
la definición de responsabilidades, etc.
A continuación, se realiza una planificación detallada del proyecto para permitir su ejecución y
control. Mientras que la planificación preliminar busca comprender el problema o la necesidad y su
forma de realización, la planificación detallada precisa definir todas las actividades que involucran la
utilización de los recursos, con la explicitación de los productos de cada “paquete de trabajo”, sus
requisitos y destinos. Se preestablecen las interfaces, los diversos procesos técnicos y administrativos,
así como los compromisos internos. A medida que se va estableciendo la definición de las condiciones
de ejecución, se instituye todo un esquema de control. Este control se ejercerá sobre el producto
(procesos, materiales y calidad), sobre los procesos gerenciales y administrativos, sobre los recursos
(costos) y sobre los plazos escogidos. El equipo del proyecto se define, selecciona y arma por medio
de negociaciones, en general, con la administración de la organización ejecutante del proyecto.

c) Etapa de ejecución
Consiste en poner en acción todas las tareas planificadas, en las condiciones de calidad, costos
y plazos, de manera de alcanzar los objetivos de las partes interesadas. Esta etapa se caracteriza por
un intenso trabajo en equipo, bajo la coordinación general del gerente del proyecto, con muchas
acciones gerenciales descentralizadas a cargo de diferentes gestores, por ejemplo. De este modo, el
gerente podrá delegar en uno de los ejecutantes la gestión de la calidad, la gestión del suministro en
otro, etc. Los resultados de la ejecución deben documentarse y constituyen una parte fundamental
de la gestión de las comunicaciones.

d) Etapa de control
La etapa de control del proyecto sigue pari passu a la de ejecución, pudiendo dar origen a
diversas observaciones y ajustes en la planificación inicial manteniendo, no obstante, el alcance del
proyecto. Cada gestión tiene su control particular, pero los controles de todas las gestiones son
coordinados y armonizados por el control general de cambios, que constituye un importante
proceso de la gestión de la integración.

69
 e) Etapa de cierre
Una vez alcanzado el objetivo, se debe dar cierre al proyecto, con algunas disposiciones finales a
partir de la aceptación del producto. Deberán tomarse medidas respecto de los contratos, el cierre
administrativo, la devolución de materiales, los espacios, entre otros. Antes de la liberación y disolución
del equipo, se debe proceder a una evaluación general y al relevamiento de las “lecciones aprendidas”.
Concluimos el estudio del concepto de ciclo de vida y de los eventos más comunes de cada
una de sus etapas. En este momento, es conveniente investigar el comportamiento de algunos
parámetros en referencia a la historia de un emprendimiento. En otras palabras, haremos un
interesante ejercicio de reflexión acerca de cómo se comportan algunos factores durante el ciclo de
vida de un proyecto genérico. Veamos:
 Costos de personal: es común que estos costos sean ascendentes en la historia de un
proyecto, es decir, son menores en las primeras etapas, luego tienden a crecer y, con
frecuencia, alcanzan su pico máximo en la etapa de ejecución del proyecto, precisamente
porque hay más entregas. Posteriormente, sufren una caída ya que tiene lugar la
desmovilización de muchos recursos, en especial, al final de la etapa de ejecución. Este
comportamiento se muestra en el siguiente gráfico:

Figura 33 – Costos de personal en el Proyecto

 Costos de cambio: los costos para rehacer o repetir trabajos en cualquier proyecto tienden
a ser crecientes a lo largo del ciclo de vida. Los cambios son más fácilmente tolerados en
las etapas iniciales de la obra. A medida que nos acercamos a la ejecución, por otro lado,
se vuelve mucho más costoso hacer correcciones en el proyecto, según lo demuestra el
gráfico a continuación:

70
 Figura 34 - Costos de cambio en el Proyecto

 Influencia de los stakeholders: el poder de las partes interesadas o su capacidad de influir

con más fuerza en los rumbos del proyecto, en lo que atañe a las características finales del
producto del proyecto inclusive, tienden a ser más altos al inicio o en las primeras etapas.
Con posterioridad, esta influencia tiende a decaer, a medida que el proyecto progresa. El
gráfico siguiente muestra este comportamiento:

Figura 35 – Influencia de los stakeholders

71
  Grado de riesgo: usualmente, el comportamiento de esta variable en un proyecto sigue
un movimiento decreciente. A medida que se va entregando el proyecto, el grado de riesgo
deberá disminuir. Otra forma de evaluar este aspecto es según el grado de incertidumbres,
que repite la tendencia decreciente. El proyecto avanza y la incertidumbre relativa a la obra
desciende, según se ilustra a continuación:

Figura 36 – Grado de riesgo del Proyecto

 Cantidad de personas (personal): en general, la cantidad de personas en un proyecto al

principio es escasa, pero después va aumentando de acuerdo con las mayores necesidades
que suele requerir la etapa de ejecución. Es común que el pico en materia de personal
aparezca en el punto central de la etapa de ejecución del proyecto, debido a la mayor
cantidad de tareas y entregas a completar. Sin embargo, en esta etapa de ejecución ya se
empieza a prescindir de algunos recursos humanos que dejan de ser necesarios. El gráfico
que representa esta variable en un proyecto genérico seguiría una curva normal:

72
 Figura 37 – Cantidad de personas en el Proyecto

Cabe hacer la salvedad de que los comportamientos de las variables anteriores se obtuvieron
de lo que se considera la media en materia de proyectos; por lo tanto, para un proyecto específico
puede haber una tendencia diferente o hasta contrastante con las mencionadas.
Otro punto importante es que algunos proyectos no atraviesan necesariamente todo su ciclo de
vida original y pueden sufrir interrupciones o, incluso, extinguirse. Un ejemplo sería el de un proyecto
concebido bajo condiciones apropiadas tanto económicas como de política cambiaria que, ante una
crisis repentina en Asia, compromete la estabilidad local por el alza del dólar. Estas nuevas condiciones
externas y desfavorables pueden provocar que el proyecto deje de valer la pena, incluso financieramente.
Estos cambios de escenario ocurren con cierta frecuencia cuando se modifica el
comportamiento de nuestro cliente final. Nuestro proyecto puede haber nacido con un objetivo,
pero una modificación en el gusto del consumidor quizás inviabilice, definitivamente, la
continuación de nuestro emprendimiento. Como resultado, puede suceder que el proyecto sea
suspendidos o incluso abortado (con un cierre anticipado), después del análisis y la anuencia del
gerente de proyecto, el cliente, el patrocinador y otros stakeholders clave.
Otro problema es que a veces un proyecto tarda mucho en aplicarse efectivamente en las
empresas, debido incluso a la excesiva burocracia para su aprobación. Cuando por último se los
autoriza y se le da inicio, las circunstancias que los justificaron pueden ser otras, incluso peores. La
empresa puede haber perdido la oportunidad de acceder al consumidor originalmente considerado.
A la luz de estos riesgos, y con nuestro mercado cada vez más cambiante, los proyectos deben ser
evaluados sin demoras y, si son viables, implementados prontamente, bajo pena de perder el escenario
favorable y, posiblemente, su viabilidad. Al igual que en el caso anterior, este ciclo de vida tampoco
será completado si el sector ejecutor decide su suspensión o, incluso, la cancelación del proyecto.

73
 Cuando ciertas situaciones desfavorables como las mencionadas perjudican un proyecto, es
necesario evaluarlas debidamente cuando este desaparece, es decir, se debe hacer un relevamiento
de las causas de la finalización prematura de cada emprendimiento y registrarlas en el documento
de las lecciones aprendidas, en conformidad con lo que ya expuesto. En este documento se
colocarían los motivos del cierre precipitado, de modo de evitar errores en futuras iniciativas. Dicho
documento podrá, asimismo, servir de alerta y enseñanza para los demás gestores de la empresa. Un
proyecto que no haya atravesado todo su ciclo de vida tendría entonces la siguiente apariencia:

Figura 38 – Proyecto con un ciclo de vida incompleto

Diez áreas de conocimiento de la gestión de proyectos, según la 6ª edición

del PMBOK
La 6ª edición del PMBOK, de 2017, presenta diez áreas de conocimiento, a saber:
 gestión de la integración del proyecto;
 gestión del alcance del proyecto;
 gestión del cronograma del proyecto;
 gestión de los costos del proyecto;
 gestión de la calidad del proyecto;
 gestión de los recursos del proyecto;
 gestión de la comunicación del proyecto;
 gestión de los riesgos del proyecto;
 gestión de las adquisiciones del proyecto, y
 gestión de los interesados (stakeholders) del proyecto.

74
En líneas generales, las áreas presentan los siguientes focos:
 Alcance: área que define el “qué” del proyecto, es decir, el trabajo que debe ser
necesariamente realizado para la generación exitosa del producto o servicio contratado por
el cliente y de la buena gestión del esfuerzo general.
 Cronograma: área que calcula el tiempo en el que se concluirá la obra, respetando la
temporalidad, característica fundamental de cualquier proyecto, como vimos en el
primer módulo.
 Costos: área responsable del cumplimiento de los costos dentro del presupuesto aprobado.
Cuanto más respetemos el límite de costos, mayor será el margen de ganancias de la
empresa ejecutora.
 Calidad: área de la satisfacción de los requisitos mínimos de calidad o las necesidades,
incluso de acuerdo con la expectativa de los stakeholders. Anteriormente, las empresas se
enfocaban en la corrección de problemas, lo que llevaba a un aumento de costos
(retrabajo). Hoy en día, el foco está puesto en mayor medida en la planificación de la
prevención de errores.
 Recursos: área que define los insumos materiales y los recursos humanos del proyecto,
se ocupa de la distinción de roles y responsabilidades de cada miembro del equipo, así
como de sus habilidades.
 Stakeholders: área que determina la importancia de los involucrados en el proyecto, por
medio de la identificación y el mapeo de su grado de importancia, intereses y poder frente
al proyecto. El gerente del proyecto debe gestionar expectativas y mantener el nivel de
involucramiento de estos interesados.
 Comunicación: área que delimita los destinatarios de la comunicación durante todo el
proyecto, así como los medios que se utilizarán, las frecuencias y las reglas de
almacenamiento de dicha documentación.
 Riesgos: área que identifica todo aquello que puede salir bien o mal en el proyecto, así
como sus impactos y las posibles respuestas a cada uno de dichos eventos.
 Adquisiciones: área que define qué producto o servicio se debe comprar adquiriéndolo de
forma externa, es decir, fuera de las fronteras de la empresa ejecutora. Es en esta área donde
se desarrollan las relaciones con los proveedores.
 Integración: área de conocimiento, que coordina y conecta los diversos elementos
constitutivos del proyecto. Debe aspirar a la armonización de las demás áreas de
conocimiento.

75
 Cabe señalar que no todos los proyectos necesitan usar o implementar las diez áreas. Al
contrario, en cada proyecto se debe evaluar cuáles son las áreas que deberán ser efectivamente
iniciadas o utilizadas. Por otro lado, el gerente de proyecto que así lo haga debe ser consciente de
que, cada vez que deje de planificar algún aspecto de un área de conocimiento, podrá perder el
control sobre la misma.
A continuación, la ilustración de Vargas (2016) muestra cómo se deben encarar las áreas, es
decir, de manera integrada:

Figura 39 – Diez áreas del conocimiento

Como se adelantó en el apartado 2.1, la 6ª edición del PMBOK presenta 49 procesos de

gestión distribuidos a lo largo de las 10 áreas de conocimiento. A continuación, haremos un listado
de estos procesos por área de conocimiento. Las numeraciones presentadas de cada área
corresponden a su capítulo en el PMBOK.

4. Gestión de la integración del proyecto

4.1 Desarrollo del acta de constitución del proyecto
4.2 Desarrollo del plan de gestión del proyecto
4.3 Orientación y gestión del trabajo del proyecto

76
4.4 Monitoreo y control del trabajo del proyecto
4.5 Gestión del conocimiento del proyecto
4.6 Realización del control integrado de cambios
4.7 Cierre del proyecto o etapa

5. Gestión del alcance del proyecto

5.1 Planificación de la gestión del alcance
5.2 Recolección de los requisitos
5.3 Definición del alcance
5.4 Creación de la EAP
5.5 Validación del alcance
5.6 Control del alcance

6. Gestión del cronograma del proyecto

6.1 Planificación de la gestión del cronograma
6.2 Definición de las actividades
6.3 Secuenciación de las actividades
6.4 Estimación de la duración de las actividades
6.5 Desarrollo del cronograma
6.6 Control del cronograma

7. Gestión de los costos del proyecto

7.1 Planificación de la gestión de los costos
7.2 Estimación de los costos
7.3 Determinación del presupuesto
7.4 Control de los costos

8. Gestión de la calidad del proyecto

8.1 Planificación de la gestión de la calidad
8.2 Gestión de la calidad
8.3 Control de la calidad

9. Gestión de los recursos del proyecto

9.1 Planificación de la gestión de los recursos
9.2 Estimación de los recursos de las actividades
9.3 Adquisición de recursos

77
 9.4 Desarrollo del equipo
9.5 Gestión del equipo
9.6 Control de los recursos

10. Gestión de la comunicación del proyecto

10.1 Planificación de la gestión de la comunicación
10.2 Gestión de la comunicación
10.3 Monitoreo de la comunicación

11. Gestión de los riesgos del proyecto

11.1 Planificación de la gestión de los riesgos
11.2 Identificación de los riesgos
11.3 Realización del análisis cualitativo de los riesgos
11.4 Realización del análisis cuantitativo de los riesgos
11.5 Planificación de las respuestas a los riesgos
11.6 Implementación de las respuestas a los riesgos
11.7 Monitoreo de los riesgos

12. Gestión de las adquisiciones del proyecto

12.1 Planificación de la gestión de las adquisiciones
12.2 Conducción de las adquisiciones
12.3 Control de las adquisiciones

13. Gestión de los interesados (stakeholders) del proyecto

13.1 Identificación de los interesados
13.2 Planificación del involucramiento de los interesados
13.3 Gestión del involucramiento de los interesados
13.4 Monitoreo del involucramiento de los interesados

Las diez áreas de conocimiento y sus respectivos procesos de gestión se pueden visualizar en
la forma anterior, en una lista, o en una tabla como se muestra a continuación. En la columna de
la izquierda se consignan las áreas de conocimiento y en la de la derecha, los cinco grupos de
procesos hasta alcanzar un total de 49 procesos. Veamos:

78
 Área de Monitoreo y
Inicio Planificación Ejecución Cierre
conocimiento control

4. Integración 4.1 Desarrollo 4.2 Desarrollo del 4.3 Orientación y 4.5 Monitoreo y 4.7 Cierre del
del acta de plan de gestión del gestión del control del trabajo proyecto o etapa
constitución proyecto trabajo del del proyecto
del proyecto proyecto
4.6 Realización del
4.4 Gestión del control integrado
conocimiento de cambios
del proyecto

5. Alcance 5.1 Planificación de la 5.5 Validación del

gestión del alcance alcance

5.2 Recolección de 5.6 Control del

los requisitos alcance

5.3 Definición del

alcance

5.4 Creación de la
EAP

6. Cronograma 6.1 Planificación de la 6.6 Control del

gestión del cronograma
cronograma

6.2 Definición de las

actividades

6.3 Secuenciación de
las actividades

6.4 Estimación de la
duración de las
actividades

6.5 Desarrollo del

cronograma

7. Costos 7.1 Planificación de la 7.4 Control de los

gestión de los costos costos

7.2 Estimación de los

costos

7.3 Determinación
del presupuesto

8. Calidad 8.1 Planificación de la 8.2 Gestión de la 8.3 Control de la

gestión de la calidad calidad calidad

79
 Área de Monitoreo y
Inicio Planificación Ejecución Cierre
conocimiento control

9. Recursos 9.1 Planificación de la 9.3 Adquisición 9.6 Control de los

gestión de los de recursos recursos
recursos
9.4 Desarrollo
9.2 Estimación de los del equipo
recursos de las
9.5 Gestión del
actividades
equipo

10. 10.1 Planificación de 10.2 Gestión de 10.3 Monitoreo de

Comunicación la gestión de la la comunicación la comunicación
comunicación

11. Riesgos 11.1 Planificación de 11.6 11.7 Monitoreo de

la gestión de los Implementación los riesgos
riesgos de las
respuestas a los
11.2 Identificación de
riesgos
los riesgos

11.3 Realización del

análisis cualitativo de
los riesgos

11.4 Realización del

análisis cuantitativo
de los riesgos

11.5 Planificación de
las respuestas a los
riesgos

12. 12.1 Planificación de 12.2 Conducción 12.3 Control de las

Adquisiciones la gestión de las de las adquisiciones
adquisiciones adquisiciones

13. 13.1 13.2 Planificación del 13.3 Gestión del 13.4 Monitoreo
Stakeholders Identificación involucramiento de involucramiento del
de los los interesados de los involucramiento
interesados interesados de los interesados

Fuente: https://escritoriodeprojetos.com.br/procesos-de-guia-pmbok-sexta-edicao

80
Documentos clave: Acta de constitución del proyecto y plan de gestión del
proyecto

Acta de constitución del proyecto (ACP)

Tan pronto como se confirme la necesidad de un proyecto, se redactará el acta de constitución
del proyecto (ACP) o Project Charter. El objetivo de este documento es el de oficializar o autorizar
la constitución del proyecto dentro de la empresa ejecutora. Por lo tanto, el ACP se genera en la
etapa preliminar o de iniciación del emprendimiento.
He aquí algunas recomendaciones sobre su contenido. Normalmente, se hace una
introducción a efectos de contextualizar el proyecto, con algunas líneas que lo justifican, o bien
expresan para qué necesidades se lo está creando, sus motivos. Además, se deben agregar algunas
líneas con los requisitos del proyecto, así como sus objetivos generales y específicos. Sobre el tema
de definición de los objetivos de un proyecto, el autor Ricardo Vargas (2016) sugiere utilizar los
criterios SMART, según se presenta a continuación:

Figura 40 – Criterios SMART

81
 En el documento del ACP, también es común encontrar los siguientes elementos:
 productos esperados de la obra;
 definición de sus principales stakeholders;
 premisas: todo lo que se presume o presupone como cierto en el proyecto y además es
validado y acordado, se convierte en una premisa 5;
 restricciones: todo factor restrictivo del proyecto que afecte, en mayor o menor grado, su
ejecución o mantenimiento dentro del curso ideal 6;
 nombramiento o designación del gerente del proyecto y sus responsabilidades;
 presupuesto preliminar;
 cronograma macro o resumido, y
 riesgos identificados inicialmente.

Una vez concebido y preparado el documento, es altamente recomendable que el

patrocinador del proyecto firme el ACP con el fin de volverlo debidamente reconocido. Después
de la firma de este certificado de nacimiento, el proyecto estará oficializado o autorizado. Gracias a
la importancia de este acto y también como forma de valorizar la asunción de responsabilidades por
parte del gerente del proyecto, el documento firmado debe ser distribuido internamente en la
empresa ejecutora o, al menos, el hecho debe ser anunciado ante los stakeholders más vinculados al
proyecto. Esta comunicación se puede hacer a través de diversos medios, pero ha sido común
compartir el archivo ACP por correo electrónico o por medio de anuncios hechos en reuniones,
presenciales o virtuales, gracias a herramientas cada vez más comunes en las empresas, como Skype,
Google HandOuts, WebEx, Citrix, GoToMeeting, Adobe Connect, Microsoft Office Live
Meeting, entre otras.
Con el ACP firmada y ampliamente difundida, el proyecto se encuentra listo para dejar atrás
la etapa de concepción. Como hemos visto en un apartado anterior sobre el ciclo de vida, se trata
de la etapa siguiente de planificación, que será conducida personalmente por el gerente del proyecto.
Como ya sabemos, en el período de planificación se presta atención a los detalles de las estimaciones
y pormenores más concretos, así como las definiciones más fundamentales de la obra. En esta etapa
siguiente de la planificación, la gran meta del gerente del proyecto pasará a ser la confección del
plan de gestión del proyecto.

5
Ejemplo 1: Formarán parte del equipo ejecutor del proyecto los recursos Mario, Moisés y Daniel, cedidos anticipadamente
por su gerente funcional. Ejemplo 2: El dólar quedará anclado en R$ 4,00 a lo largo del ciclo de vida del proyecto. Ejemplo 3:
El horario de trabajo del proyecto será en el turno de la mañana, de 8:30 a 12:30, hora de Brasilia.
6
Ejemplo 1: La fecha final de este proyecto será el 01/12/2021, sin autorización para postergaciones. Ejemplo 2: El techo
presupuestario de este proyecto es de USD 290.000,00. Ejemplo 3: Solo los miembros del sector de contabilidad tendrán
acceso a la sala de ejecución del proyecto.

82
Plan de gestión del proyecto
El plan de gestión del proyecto, el plan general del proyecto o, simplemente, el plan del
proyecto tiene por fin ser un plan ejecutable y aportar las directrices para la ejecución del esfuerzo.
Debe haber coordinación en la elaboración e integración de la planificación, durante las cuales se
integrarán adecuadamente las áreas de conocimiento, tratadas en el apartado 2.3. Debido a este
enfoque, el plan de gestión del proyecto es el documento clave del área de integración de un proyecto.
Valeriano (2001, p. 13) agrega que este plan es “el documento que consustancia las
decisiones, tomadas en un determinado momento, en cada uno de los niveles, y que persigue la
consecución de objetivos finales a ser alcanzados en determinado período”.
Para el autor Vargas (2016), “el proceso de desarrollar el plan de gestión del proyecto incluye
las acciones necesarias para definir, coordinar e integrar todos los planes auxiliares en un plan de
gestión del proyecto”. De hecho, el plan del proyecto contendrá los nueve subplanes o planes
auxiliares de las demás (nueve) áreas de conocimiento:
 plan de gestión del alcance;
 plan de gestión de los costos;
 plan de gestión del cronograma;
 plan de gestión de los recursos;
 plan de gestión de la comunicación;
 plan de gestión de los riesgos;
 plan de gestión de los stakeholders;
 plan de gestión de la calidad, y
 plan de gestión de las adquisiciones.

83
 Una vez que el gerente de proyectos elabore estos subplanes, se habrán alcanzado las líneas
base de cada una de las áreas de conocimiento (tema del próximo apartado). El plan del proyecto
es fruto de la combinación de estos planes en un solo documento. Una vez finalizado, el plan de
gestión del proyecto define las líneas de referencia a seguir durante todo el ciclo de vida que queda
por delante. El mismo podrá contener los siguientes documentos, por área de conocimiento:

Documentos de tiempos y actividades

Atributos de actividades

Estimación de costos de actividades

Lista de actividades

Requerimientos de recursos de actividades

Cronograma del proyecto

Diagramas de la red de actividades del proyecto

Datos del cronograma

Calendarios del proyecto

Lista de hitos del proyecto

Documentos de adquisiciones

Paquete de documentos de adquisiciones

Declaraciones de trabajo

Propuestas de proveedores

Criterio de selección de proveedores

84
 Documentos de stakeholders

Registro de stakeholders

Matriz de involucramiento de stakeholders

Documentos de alcance

Registro de cambios

Solicitudes de cambios

Documentación de requerimientos

Matriz de trazabilidad de requerimientos

Documentos de costos

Documentos de requerimientos de fondos

Presupuesto del proyecto

Documentos de recursos

Organigrama

Descripción de cargos

Evaluación de desempeño del equipo

Documentos de comunicación

Datos de desempeño del trabajo

Información de desempeño del trabajo

Informes de desempeño del trabajo

85
 Documentos de calidad

Listas de verificación

Planillas de mediciones de control

Métricas de la calidad

Documentos de riesgos

Registro de riesgos

Estructura analítica de riesgos

La línea base y la triple restricción

La línea base (o baseline) es un concepto muy presente en la jerga de la gestión de proyectos,
ya que significa la medida de desempeño de la obra. Se la puede utilizar en el proyecto en forma
cotidiana para comparar lo que se planificó y lo que concretamente se entregó, y también se la usa
como herramienta de evaluación de desempeño del proyecto. En síntesis, sin una línea base, no se
puede controlar ningún proyecto, ya que no habría una referencia o una orientación para evaluar
el éxito del emprendimiento.
En general, las tres líneas base más comunes son:
 Línea base del alcance: se obtiene por medio de la elaboración de la herramienta EAP (que
será descrita en el módulo final). Las entregas que no estén contenidas en la línea base del
alcance no formarán parte del proyecto.
 Línea base del cronograma: se obtiene por medio de la elaboración de la herramienta
Cronograma, que será detallada en el módulo final. De la misma forma, no se deberá
realizar ninguna actividad que esté ausente en el cronograma, ya que no cuadra con la
línea base.
 Línea base de costos: se evidencia en el presupuesto final del proyecto (una vez retiradas
las reservas gerenciales para costos desconocidos). Contiene los costos de las tareas del
proyecto y la reserva para contingencias del proyecto (protección contra riesgos).

El programa aeroespacial de la NASA, comentado por diversas razones en apartados

anteriores, utiliza el concepto de línea base desde 1967. En las misiones espaciales de la serie Apollo,
se creó un manual de gestión de programa, que contiene las etapas existentes en cada uno de los
proyectos, las respectivas EAP y la línea base del programa (CAMARGO, 2014).

86
 Otro aspecto relacionado con la gestión de proyectos, derivado incluso del concepto de línea
base, es la restricción triple de los proyectos. Esta restricción está formada por los vértices de las
áreas de conocimiento de alcance, tiempo y costos. A esta altura de nuestros estudios, resulta claro
que es difícil mantener un equilibrio de las demandas conflictivas entre estos tres parámetros. A
pesar de que están preestablecidos en el plan de gestión del proyecto (según lo tratado en el
apartado 2.4.2), es común que durante la ejecución del proyecto surjan demandas que modifiquen
dichas especificaciones y que exijan una replanificación por parte del gerente del proyecto.
También existe la posibilidad de percibir errores u omisiones en el plan original o la necesidad
de adaptaciones a la línea base original. Si se trata de una inclusión necesaria en el área de tiempo,
es probable que esta modificación afecte el vértice de los costos. Si se trata de un cambio en el vértice
de los costos, podremos percibir un impacto en el tiempo o en el alcance del proyecto, y así
sucesivamente. Por ejemplo, un aumento de alcance sería la inclusión de una nueva habitación en
el proyecto original de la construcción de la casa de una familia. Sin duda, este elemento adicional
generaría un aumento en los costos y en los tiempos originales del proyecto, de modo que la
habitación adicional implicaría rehacer el alcance del proyecto, incluyendo el nuevo elemento.
Además, la nueva construcción aumentaría el costo total original del proyecto, ya que sería muy
probable que se hiciera necesario aplicar más recursos financieros y, tal vez, humanos para la
consecución de esta obra complementaria. A la luz del mismo caso hipotético, quizá tendríamos
que enfrentar el posible impacto de un atraso en el cronograma del proyecto, debido a la adición
de la habitación. Si la fecha original para la conclusión del proyecto fuera la primera quincena de
enero de 2010, con esta adición de alcance, la fecha recalculada tal vez pasaría a ser el inicio de
febrero de 2010.
La restricción triple se puede ilustrar de la siguiente manera:

Figura 41 – Restricción triple

87
Control general de cambios
Por excelente que sea la planificación hecha por el gerente del proyecto, es probable que
surjan necesidades de cambios en la línea base, como vimos en los ejemplos al final del apartado
anterior. Vargas (2016) explica que este proceso:

… se realiza desde el inicio del proyecto hasta su finalización. El control

de cambios es necesario porque raramente la ejecución de los proyectos
sigue con exactitud el plan de gestión del proyecto. El plan de gestión del
proyecto, la declaración de alcance del proyecto y otras entregas deben
mantenerse por medio de la gestión continua y cuidadosa de los cambios…

Valeriano (2001) también señala:

… Todos los parámetros del proyecto (tiempo, costos, requisitos de

calidad y de desempeño, en general) deben estar bajo control para detectar
los desvíos con relación a lo previsto en cada uno de ellos. Esto se hace por
medio de medidas de desempeño adecuadas para cada caso particular,
removiendo las causas de los desvíos o discrepancias y, si fuera el caso,
aplicando medidas correctivas sobre el resultado. Algunos de los desvíos
observados pueden exigir planificaciones adicionales o una replanificación
para ajustar la realidad a lo esperado. Esto puede significar introducir
cambios de gestión, personal, plazos, materiales, procesos. Los cambios del
alcance y los respectivos reflejos y consecuencias deben ser claramente
documentados, los documentos modificados deben ser aprobados y se
debe dar conocimiento de los mismos a las partes interesadas. Los cambios
en el alcance que afecten al cliente o al patrocinador o contratante del
proyecto deben ser aprobados por aquellos, mediante negociación del
gerente del proyecto y demás partes interesadas. Siempre que sea el caso,
se deben tomar las debidas acciones preventivas o correctivas, manteniendo
siempre los resultados de acuerdo con lo planificado. Como en todas las
gestiones, se deben reconocer las lecciones aprendidas y se las debe
organizar para su utilización posterior… (pp. 200-201)

88
 Aquí es necesario destacar la función clave del gerente de proyecto en la evaluación de los
impactos de cada uno de los cambios solicitados, ya que deberá considerar qué áreas de conocimiento
se verían posiblemente afectadas si se contara con la efectiva aceptación de la propuesta.
En el pedido de cambio iniciado por los diversos stakeholders, el proponente de la
modificación describirá su demanda junto con una justificación, pero el gerente podrá demarcar
los límites de aprobación, es decir, quién deberá participar en el análisis de dichas solicitudes de
cambio. Se ha vuelto común la composición de grupos o comités de control de cambio en las
empresas ejecutoras de los proyectos.
Según Valeriano (2001, p. 177), “la evaluación y la aprobación de cambios son realizadas por
un colegio multidisciplinario (Comisión de Control de Cambios) con representantes de las áreas
administrativas y gerenciales y de las áreas de conocimiento involucradas”. Estos comités de cambio
analizarán las solicitudes oficialmente presentadas, y el proceso será realizado muchas veces, en línea,
por medio de sistemas de control. A continuación, el pedido será evaluado, y podrá ser rechazado
(archivado) o aprobado (implementación del cambio solicitado).
En resumen, el control general de cambios de los proyectos debe ser formal y procesal, además
de ser ampliamente difundido entre los stakeholders. Todo este tratamiento de solicitud de cambios
está representado en el siguiente diagrama de flujo:

89
 Figura 42 - Control de cambios

Fuente: VARGAS (2016)

90
Criterios de un proyecto exitoso
La definición de proyecto exitoso depende mucho de cuál sea el stakeholder que responda,
pero debemos pensar, prioritariamente, en la respuesta obtenida por el propio gerente de proyectos,
por su patrocinador, por su cliente y por el equipo. Evidentemente, al término del proyecto el
gerente medirá si el mismo fue o no exitoso, por medio de criterios preestablecidos.
Lo ideal sería que estos criterios de medida del éxito hayan sido previamente acordados con
los stakeholders clave, como los mencionados anteriormente. Ello evitaría dudas o percepciones
subjetivas que comprometerían la evaluación final del proyecto.
Según lo indicado en los apartados anteriores, se deberá añadir la utilización de las áreas de
conocimiento y sus respectivas líneas base para hacer la comparación entre lo planificado y lo
realizado, de modo de facilitar la conclusión sobre el desempeño del proyecto.
Las siguientes preguntas pueden ser utilizadas por el gerente de proyectos para cuestionar a
sus involucrados y obtener una posición definitiva, real y final sobre el éxito de la obra:
 ¿El proyecto concluyó dentro del plazo definido en el cronograma?
 ¿El proyecto respetó el presupuesto original?
 ¿El proyecto entregó todo el alcance previsto y alineado con el cliente?
 ¿El proyecto utilizó, efectivamente, los recursos físicos de la empresa?
 ¿El proyecto acató los estándares de calidad preacordados?
 ¿El proyecto cumplió con los requisitos de seguridad del trabajo exigidos por la legislación?
 ¿El proyecto trató a los stakeholders de manera adecuada?
 ¿El proyecto cumplió con las promesas de comunicación (reuniones, llamados telefónicos,
e-mails, teleconferencias, informes de estado, etc.) y lo hizo con la debida frecuencia?
 ¿El proyecto estimuló correctamente a su equipo para entregar de forma optimizada el
alcance del proyecto?
 ¿El proyecto recibió de sus proveedores las materias primas y demás insumos en la forma
y calidad técnicas solicitadas en el contrato?
 ¿El proyecto respetó la cultura de la empresa?

Torres (2014, p. 116) indica cinco factores críticos de éxito en los proyectos:
 capacitación conductual: habilidades de relación haciendo la diferencia en el trabajo en
equipo;
 metodología consistente de gestión: articulación entre las buenas prácticas y la expertise de
la empresa;
 gobernanza de proyectos: definición de reglas de soporte institucional a los proyectos;
 sistema de informaciones de gestión de proyectos: procesos consistentes apoyados por
herramientas eficaces, y
 capacitación técnica: habilitación progresiva con autonomía y en diversos formatos.

91
MÓDULO III – ADQUISICIONES EN
PROYECTOS

En este módulo pondremos el foco en la gestión de las adquisiciones en el entorno de un

proyecto y utilizaremos su ciclo de vida como hilo conductor. Luego nos ocuparemos de la
identificación de las necesidades, la planificación del trabajo, la búsqueda de los recursos y la
administración de los contratos de suministro.

Introducción
El principio de escasez, fundamental en la economía, reconoce que todos los recursos
disponibles para uso humano son finitos (aunque en un examen superficial sus existencias puedan
parecer inagotables) y define la medida de la escasez de un recurso como el costo (ambiental, social,
técnico y económico) de su obtención. Una de las consecuencias de este principio es que resulta
inviable que una persona, un grupo o una organización tengan o controlen todos los recursos que
necesitan para ejecutar y alcanzar sus objetivos, lo que los obliga a interactuar entre sí para conseguir
lo que les falta.
Esta realidad determina el origen del comercio y, por extensión, de todo el corpus de
conocimiento desarrollado a lo largo del tiempo a fin de asegurar que la persona, el grupo o la
organización tenga acceso a los recursos faltantes, dentro de una razonable relación de costo-
beneficio y de acuerdo con reglas mínimamente seguras y aceptables para las partes intervinientes.
En la actualidad, las organizaciones tratan este corpus de conocimiento como un
macroproceso de trabajo indispensable, con gran impacto en los resultados de la actividad, que
recibe diversos nombres: suministros, compras, adquisiciones, entre otros. Si bien cada organización
configura este proceso de acuerdo con las peculiaridades de su actividad, existe un conjunto de
principios, técnicas y buenas prácticas que sirve de base de conocimientos aplicable por igual a la
mayoría de las organizaciones y de las situaciones en las que han de obtenerse recursos.
 Las diferencias entre operaciones y proyectos, particularmente la temporalidad, hacen que las
metodologías de adquisición utilizadas en los proyectos tengan algunas características específicas,
sin alterar, empero, esa base común de conocimientos.
Nos ocuparemos aquí de la gestión de adquisiciones en el entorno de los proyectos y
mantendremos el análisis en el nivel de las directrices aplicables a la mayoría de las organizaciones.
De ser necesario, se señalarán las diferencias entre su aplicación en organizaciones privadas y públicas.
Tomaremos como hilo conductor el ciclo de vida del proyecto y nos detendremos en la
identificación de las necesidades, la planificación del trabajo, la búsqueda de los recursos y la
administración de los contratos de suministro. Abordaremos el tema desde la perspectiva gerencial,
por lo que los aspectos jurídicos y procesales se mencionarán solo cuando sea necesario para
entender el contexto. Si bien la vastedad del tema y los límites de este módulo nos impiden tratar
los tópicos en la profundidad ideal, esperamos ofrecer una visión de conjunto que permita
comprender el proceso y remita a estudios más específicos cuando corresponda.

Adquisiciones en proyectos
Si visualizamos un proyecto como un grupo de personas encargado de elaborar una solución
para una necesidad específica, es fácil percibir que este equipo se encontrará desde el primer día ante
un viejo problema: no contar con los recursos necesarios para realizar su trabajo, entendiendo por
recurso cualquier elemento (energía, materiales, medios de producción, conocimiento, trabajo, etc.)
requerido para lograr el resultado deseado. De este modo, el equipo se ve ante la necesidad de
formular algunas preguntas y buscar respuestas:
 ¿QUÉ necesitamos para realizar el proyecto?
 ¿DÓNDE conseguiremos lo que necesitamos?
 ¿CÓMO obtendremos lo que necesitamos?
 ¿CUÁNDO tendremos lo que necesitamos?
 ¿CUÁNTO nos costará lo que necesitamos?
 ¿QUÉ riesgos corremos al adquirir lo que necesitamos?

Una vez conocidas las respuestas, es preciso encarar un trabajo sistemático para lograr
abastecer el proyecto de los recursos necesarios respetando los requisitos y restricciones de calidad,
plazo y costo establecidos. De la calidad de las respuestas y del trabajo efectuado a partir de ellas
dependerá no solo el éxito sino también la propia existencia del proyecto.

94
 Para obtener este resultado, la organización y, por extensión, el equipo del proyecto deben
comprender la esencia del proceso de gestión de adquisiciones aplicada a proyectos y también su
dinámica para, así, desarrollar una metodología adecuada a sus especificidades. Dos elementos son
definitorios de este proceso: el principio del riesgo y el principio de la calidad.
El principio del riesgo se aplica al proyecto como un todo, aunque cobra especial importancia
en las adquisiciones por el hecho de que los recursos son técnicamente complejos, tienen un alto
impacto en el presupuesto o requieren de considerable tiempo hasta que están disponibles (o sea,
tienen potencial para causar serios daños al proyecto). Ello exige que la gestión de las adquisiciones
nunca se aparte de la gestión de riesgos y define el criterio básico para la toma de decisiones en las
adquisiciones: el menor riesgo para el proyecto. La amenaza al proyecto impone también uno de los
principios centrales en las contrataciones: la transferencia del riesgo entre cliente y proveedor. Elegir
la mejor alternativa en cada caso incide de manera significativa en la probabilidad de éxito de las
adquisiciones y, por ende, del propio proyecto.
Otro aspecto característico de las adquisiciones en los proyectos es que, por ser los plazos
generalmente cortos, es habitual que los recursos estén disponibles poco tiempo antes de ser
utilizados. Algunos (por lo general, los principales) tienen plazos de obtención largos y deben
adquirirse con mucha antelación, en una etapa del proyecto donde la incertidumbre de la
información es aún elevada. De nuevo, el riesgo de errar es alto, como también lo es la posibilidad
de que se detecten los errores recién después de recibido el recurso. Los daños pueden ser
considerables y quizás irreparables.
Eso nos lleva al segundo elemento definitorio: el principio de la calidad. Organizar el trabajo
de las adquisiciones según los principios de esta área de conocimiento, asociándolos a una gestión
sistemática de riesgos, es la mejor manera de asegurar un buen resultado para el proyecto. De este
modo, la buena práctica reconocida en la gestión de adquisiciones es poner el énfasis en la
planificación y la aplicación de procedimientos que:
 busquen minimizar el riesgo de no conformidades, y
 organicen el trabajo de modo que no se cometan errores la primera vez.

Debido a esta necesidad, no es de sorprender que los procesos de gestión de adquisiciones se

modelen según el ciclo planificar-hacer-verificar-actuar, PDCA en inglés, desarrollado por Deming.
En particular, el PMI (2017) define que el trabajo del área de gestión de adquisiciones en proyectos
se distribuye en tres procesos: planificar las adquisiciones (plan procurement), ejecutar las
adquisiciones (conduct procurement) y controlar las adquisiciones (control procurement); partiendo
del supuesto de que el control implica retroalimentación para corregir los desvíos y mejorar el
resultado de manera continua, tenemos ahí el PDCA clásico. Cabe apuntar que el abordaje
preconizado por el PMI reproduce la base común de conocimiento antes mencionada y constituye

95
un conjunto de directrices que cualquier organización puede utilizar para desarrollar su propia
metodología de gestión de adquisiciones en proyectos. Utilizaremos este modelo para completar el
análisis inicial del proceso.
El proceso de planificación se inicia junto con las planificaciones de las demás áreas (alcance,
costos, riesgos, etc.) y sus resultados se integran al documento maestro de planificación del proyecto:
el plan del proyecto (más información en el apartado 3). Este proceso tiene su mayor nivel de
actividad durante las etapas de iniciación y de planificación del proyecto y prosigue en la etapa de
ejecución, para efectuar las actualizaciones periódicas que sean necesarias. En el cuadro 5 se exhiben
sus entradas, salidas, técnicas y herramientas, según el PMI (2017).
El proceso de ejecución de las adquisiciones transcurre, naturalmente, durante la etapa de
ejecución del proyecto, con dos peculiaridades: (a) se inicia una vez aprobada la planificación del
proyecto, ya que varios recursos son de largo plazo e impactan de manera directa en el camino
crítico, y b) excede la etapa de ejecución y finaliza recién en la etapa de cierre del proyecto, ya que
algunos contratos solo se pueden concluir una vez entregado el producto del proyecto. El cuadro 6
muestra su modelado, según el PMI (2017). El proceso de control, a su vez, acompaña el de
ejecución a lo largo de todo su período de actividad. El modelado del PMI (2017) para este proceso
se muestra en el cuadro 7.
En un plano más operacional, podemos subdividir el proceso de ejecución en tres
subprocesos, que se superponen en parte a lo largo del tiempo: la búsqueda, la contratación y la
administración. Partiendo de la necesidad específica de un recurso, el primero engloba todo el
trabajo necesario para obtener opciones de suministro del mercado y seleccionar la más adecuada; el
segundo comprende el trabajo de transformar la opción de suministro elegida en un contrato
(acuerdo formal entre el cliente y el proveedor) y el tercero incluye el trabajo de gestionar los
contratos firmados de modo de asegurar la disponibilidad de los recursos para el proyecto y el
correcto cumplimiento de las condiciones acordadas entre las partes. El apartado Procesos
Licitatorios presenta en mayor detalle la búsqueda de las mejores opciones. El apartado Modelos de
Contrataciones se ocupa de la contratación y los apartados Administración de Contratos y
Terminación de Contratos, de la administración.

96
 Cuadro 5 – Elementos del proceso de planificación de adquisiciones

Entradas Técnicas y Herramientas Salidas

Acta de constitución del Conocimiento Plan de gestión de las

proyecto especializado adquisiciones

Caso de negocio Bases de datos Estrategia de adquisiciones

Plan del proyecto Interpretación de datos Procedimientos licitatorios

Métodos de selección de Enunciado del trabajo de

Documentación del proyecto
alternativas adquisiciones

Factores ambientales de la
Reuniones Criterios de selección de fuentes
organización anfitriona

Activos organizacionales de la Decisiones de hacer o comprar

organización anfitriona (make-or-buy)

Estimaciones de costos

Solicitud de cambios

Documentación del proyecto

actualizada

Activos organizacionales
actualizados

Fuente: adaptado de PMI

Cuadro 6 – Elementos del proceso de ejecución de las adquisiciones

Entradas Técnicas y Herramientas Salidas

Plan del proyecto Conocimiento especializado Proveedores seleccionados

Documentación del proyecto Publicidad Acuerdos

Documentación de
Encuentros con licitantes Solicitudes de cambios
adquisiciones

97
 Entradas Técnicas y Herramientas Salidas

Propuestas de proveedores Análisis de datos Plan del proyecto actualizado

Factores ambientales de la Competencias interpersonales Documentación del proyecto

organización anfitriona y de trabajo en equipo actualizada

Activos organizacionales de la Activos organizacionales

organización anfitriona actualizados

Fuente: adaptado de PMI

Cuadro 7 – Elementos del proceso de control de las adquisiciones

Entradas Técnicas y Herramientas Salidas

Plan del proyecto Conocimiento especializado Documentación concluida

Información sobre el
Documentación del proyecto Gestión de conflictos
desempeño del trabajo

Documentación de
Acuerdos Análisis de datos
adquisiciones actualizada

Documentación de
Inspecciones Solicitudes de cambios
adquisiciones

Documentación de cambios
Auditorías Plan del proyecto actualizado
aprobados

Información sobre el Documentación del proyecto

desempeño del trabajo actualizada

Factores ambientales de la Activos organizacionales

organización anfitriona actualizados

Activos organizacionales de la
organización anfitriona

Fuente: adaptado de PMI

98
 Otro elemento importante es el paralelismo entre el proceso de adquisiciones realizado por la
organización anfitriona de manera continua para sostener su funcionamiento y el proceso
temporario establecido para el proyecto. Como ya se comentó, los procesos son semejantes pero no
idénticos y, dependiendo del posicionamiento del proyecto en la organización, es factible que surjan
dificultades. En una organización de tipo funcional, estructurada exclusivamente para atender las
necesidades de su funcionamiento, las adquisiciones del proyecto están a cargo del sector
especializado (gerencia de compras, departamento de suministros o similares), de acuerdo con sus
procedimientos y criterios. El riesgo de conflictos a causa de, por ejemplo, prioridades o criterios
de decisión es alto y solo podrá resolverse con la acción de los patrocinadores y la intervención del
sector de compras en el proyecto.
Pero otras organizaciones, estructuradas para llevar a cabo una operación, poseen sectores y
equipos permanentes dedicados a proyectos: son las llamadas organizaciones matriciales. En ellas,
el equipo del proyecto tiene por lo general autoridad para adquirir parte de los recursos según
criterios de valor o de naturaleza del recurso. De este modo, la buena práctica para el éxito es la
existencia de una buena matriz de responsabilidades entre el proyecto y el sector de compras. En
este entorno, el equipo del proyecto necesita contar con profesionales competentes en adquisiciones
y usar los procedimientos y las herramientas del sector de compras.
Por último, están las organizaciones cuya actividad principal es la realización de proyectos y
que, por ende, se estructuran para ello. En estas organizaciones por proyectos, el equipo del proyecto
suele ser el responsable de adquirir todos los recursos necesarios, pero respetando las directrices y
procedimientos corporativos. Aquí el punto clave es el establecimiento, dentro del equipo del
proyecto, de un grupo de adquisiciones con todas las competencias y capacidades necesarias para
realizar el trabajo. En cualquier caso, el responsable del proyecto debe identificar desde el primer
día el entorno de adquisiciones en el que se encuentra y prepararse para trabajar de acuerdo con él.
Tratar de ignorar la autoridad funcional del departamento de compras o insistir en delegar en él
adquisiciones que el proyecto no quiere (pero debería) hacer son actitudes contraproducentes que
solo pueden perjudicar el resultado final.
Utilizando los conceptos básicos presentados arriba, podemos seguir el recorrido de las
adquisiciones de un proyecto, y para ello comenzaremos por responder las preguntas formuladas al
principio de esta unidad.

99
Planificación de adquisiciones en proyectos
¿QUÉ necesitamos?
Antes de nada, debemos entregar el alcance del proyecto. Este alcance está explicitado en la
EAP (estructura analítica del proyecto), que es el documento que sirve como primera fuente de
identificación de los recursos. Si una EAP identifica como entregas parciales del proyecto un estudio
de ingeniería o un equipamiento, estos elementos se convierten automáticamente en recursos
necesarios para que el alcance del proyecto pueda completarse. De esta manera, el último nivel de
una EAP representa el conjunto de recursos que se han de obtener para un proyecto. Naturalmente,
cuanto más detallada sea la EAP, mejor definidas estarán las necesidades en materia de recursos.
Así, el primer paso para planificar las adquisiciones de un proyecto es la elaboración de la lista de
necesidades a partir del último nivel de la EAP. Evidentemente, como la EAP es dinámica, también
lo será la lista.

¿DÓNDE conseguiremos lo que necesitamos?

Hay tres fuentes de recursos para un proyecto: la organización anfitriona, su cliente, (si es
externo a esa organización) y el universo externo a estas dos entidades, el mercado. De este modo,
se impone como segundo paso la clasificación de la lista de necesidades en dos grupos de recursos:
los internos y los que deben adquirirse en el mercado. Este ejercicio no es tan simple como puede
parecer, ya que implica no solo el conocimiento de las posibilidades del mercado y de las casas
centrales sino también tomar decisiones estratégicas sobre el uso de recursos propios que tal vez sean
objeto de disputa con otras aplicaciones, políticas de tratamiento del riesgo (aversión o tolerancia),
sigilo, propiedad intelectual, disponibilidad financiera, etc. Este análisis se conoce como make-or-
buy, literalmente, hacer o comprar. Es común que los documentos iniciales del proyecto, como el
acta de constitución del proyecto o el enunciado del alcance del proyecto, incluyan directrices y
restricciones al respecto, como una exigencia de contenido local mínimo o una regla sobre
tercerización de servicios. Las políticas y los reglamentos de la organización y del cliente también son
fuentes de orientación. Por lo general, el equipo del proyecto no tiene información ni autonomía
suficientes para tomar todas las decisiones necesarias sobre el origen de los recursos, por lo que debe
recurrir a la jerarquía o a los patrocinadores del proyecto para concluir el análisis. Pero muchas veces
estas instancias no responden de inmediato y se depende de información adicional (a menudo
generada por el propio proyecto) para decidir. Ello puede ocasionar que la obtención de recursos
importantes se vea comprometida y corresponda al equipo del proyecto informar y concientizar a
los responsables sobre el límite de sus competencias, para asegurar que estas decisiones iniciales
orientadoras de todo el trabajo se tomen de manera oportuna y con calidad.

100
 El análisis make-or-buy produce la lista de adquisiciones, que es un subconjunto de la lista de
necesidades, que relaciona los recursos que se deberán adquirir en el mercado. Con ella es posible
responder la tercera pregunta.

¿CÓMO obtendremos lo que necesitamos?

Ahora se debe explorar el mercado con el fin de evaluar las condiciones generales en las que
se podrá obtener cada recurso buscando información, como la cantidad de proveedores existentes, su
distribución geográfica, el modus operandi de estos proveedores (por ejemplo, sus formas de
negociación y ventas) y, en particular, los riesgos implícitos. Por ejemplo, identificar que no hay
proveedores de un determinado equipamiento en el país apunta a la necesidad de recurrir a una
licitación internacional, lo que implica un proceso de adquisición más complejo; cuanto antes se
conozca esta circunstancia, más tiempo tendrá el equipo del proyecto para prepararse y, de este
modo, mitigar los riesgos. Otro resultado de esta exploración es la posibilidad de racionalizar las
adquisiciones aprovechando las opciones disponibles en el mercado, por ejemplo, la adquisición de
“paquetes” de servicios a un solo proveedor en lugar de varias contrataciones separadas, o la
combinación de varios equipamientos complementarios en un solo abastecimiento integrado (un
sistema de generación y distribución de energía en lugar de generadores, paneles de distribución,
cableado, etc. acompañados de servicios de instalación aparte).
Es probable, y con frecuencia es seguro, que este ejercicio se traduzca en ajustes en la EAP,
ya que es de interés para la planificación y sobre todo para el control del proyecto que las entregas
del último nivel coincidan, tanto como sea posible, con la lista de adquisiciones.

¿CUÁNDO tendremos lo que necesitamos?

Los plazos de obtención de los recursos son decisivos para la realización del proyecto. Varios
de ellos serán parte del camino crítico, lo que significa que cualquier atraso en el proceso de
adquisición provoca el atraso del proyecto entero. Es más, los recursos que no estén comprendidos
en este caso pueden llegar a provocar problemas en cascada si no están disponibles en el momento
preciso. Por eso, la calidad con la que se estimen los plazos de las adquisiciones impacta fuertemente
en la calidad de la planificación del proyecto como un todo y debe recibir atención proporcional a
ese potencial de ocasionar daños.
Cada elemento de la lista de adquisiciones debe evaluar su plazo de obtención, desde el inicio
de la preparación de la licitación hasta cuando se pone el recurso a disposición del usuario. Y cada
estimación debe estar asociada a un margen de error proporcional a la calidad de la información
utilizada (como referencia para la determinación de errores de estimación, recomendamos las normas
de la AACE, Asociación Estadounidense de Ingeniería de Costos). Si bien es normal que la

101
planificación comience con estimaciones menos confiables, por otro lado, es imperativo mejorar esas
estimaciones en el plazo más corto posible hasta un nivel de error considerado aceptable para la
toma de decisiones y el control del proyecto.
Las estimaciones de los plazos de obtención deben trasladarse al cronograma del proyecto, de
modo que formen parte del tiempo total de ejecución de la entrega a la cual sirve este recurso. A medida
que se mejore la planificación, las estimaciones globales deben reemplazarse por secuencias de
actividades, con estimaciones de plazos y márgenes de error específicos. Este traslado debe hacerse
tomando como base la fecha más temprana en la que se necesite el objeto en el proyecto (por
ejemplo, el montaje de una máquina o el inicio de un determinado servicio) y desdoblando el
proceso de adquisición aguas arriba a partir de ahí. La fecha más temprana de cierre del proceso de
obtención coincide con la fecha más temprana de necesidad del recurso.

¿CUÁNTO nos costará lo que necesitamos?

Se debe elaborar una estimación del costo de obtención para cada elemento de la lista de
adquisiciones siguiendo los mismos principios de la estimación de plazos (el costo estimado es el
del proceso de obtención, el precio del recurso es una parte de este costo). Los costos de las
adquisiciones tienen un impacto tan significativo en el proyecto como los plazos porque pueden
representar la mayor parte del presupuesto. Creemos que no está de más recalcar la importancia de
calcularlos con calidad. Las estimaciones de costos deben trasladarse al plan de cuentas del proyecto,
con lo cual pasan a formar parte del presupuesto del mismo.
Cabe notar, tanto para los costos como para los plazos, que las estimaciones elaboradas por
el grupo de adquisiciones tal vez no coincidan, en esta fase, con estimaciones anteriores preparadas
durante los estudios de factibilidad del proyecto. En este caso, es preciso identificar los puntos de
discrepancia y comparar las fuentes de información a fin de mantener en la planificación la
estimación de mayor calidad. Este ejercicio debe realizarse con la mayor celeridad posible, dado que
es factible que se reconsidere la propia continuidad del proyecto si el grupo de adquisiciones analiza
justificadamente plazos y valores mayores que los previstos inicialmente.

¿QUÉ riesgos corremos al adquirir lo que necesitamos?

A partir de la información anterior es posible iniciar la identificación y la evaluación de los
riesgos presentes en cada proceso de adquisición. Algunos factores como los plazos extensos, los
costos elevados, la complejidad técnica, la innovación, la propiedad intelectual, la necesidad de
sigilo, la cantidad y ubicación de proveedores, entre otros, deben tenerse en cuenta y, si corresponde,
relacionarse como amenazas u oportunidades para la obtención de cada recurso. En este ejercicio
conviene utilizar los criterios definidos para la gestión de los riesgos del proyecto. Si tales criterios
no están disponibles o resultan demasiado complejos para la finalidad deseada, es dable efectuar un

102
análisis cualitativo de los riesgos con aplicación de escalas de probabilidad e impacto predefinidas. Se
recomienda contar con el apoyo de especialistas en esta etapa del trabajo.
Los riesgos son dinámicos y su evaluación debe revisarse periódicamente a medida que avance
el trabajo. Los resultados deben volcarse al mapa de riesgos generales del proyecto. Las acciones de
mitigación a definirse deben ser seguidas sistemáticamente por la gerencia del proyecto.
La totalidad de la información vista constituye un documento clave para planificar y controlar
el proyecto denominado “cuadro de adquisiciones”. Es necesaria la integración entre este
documento, la EAP, el cronograma y el presupuesto para una gestión eficiente del proyecto. No
está de más recordar que la mayoría de los resultados del proyecto está creada por medio –y dentro–
de los contratos de suministro de bienes y servicios; los atrasos y los costos extras no se estipulan en
el cronograma o en el presupuesto sino que derivan de la ejecución de esos contratos. Integrar los
contratos con los elementos clave de control del proyecto es altamente beneficioso, y hasta
indispensable, para asegurar la calidad del control y maximizar las chances de éxito.
El cuadro de adquisiciones es el elemento principal para complementar la planificación de las
adquisiciones. Partiendo del contenido del cuadro, que representa el alcance del trabajo del grupo
de adquisiciones (sea este del proyecto o del departamento de compras), es preciso evaluar los
siguientes aspectos:
 Equipo: ¿cuántas personas, con qué perfiles de competencia, serán necesarias para realizar el
trabajo delineado en el cuadro de adquisiciones? ¿Por cuánto tiempo deberá movilizarse a
estas personas? ¿Qué capacitación se les deberá impartir? ¿Estas personas serán asignadas al
proyecto o pertenecerán al sector especializado de la organización anfitriona?
 Procedimientos: ¿qué procedimientos de trabajo utilizará el grupo? ¿Cuáles ya existen y
cuáles será necesario elaborar?
 Desempeño: ¿qué indicadores se usarán para medir el desempeño de la gestión de las
adquisiciones? ¿Cómo se efectuarán las evaluaciones externas?
 Comunicación: ¿qué informes deberán emitirse? ¿Cuál es el contenido, la periodicidad,
el vehículo y los destinatarios de cada uno? ¿Cómo se administrará la seguridad de la
información? ¿Cómo se archivará el acervo al final del proyecto?
 Recursos: ¿qué infraestructura se requerirá para el trabajo del grupo? ¿Está disponible esta
infraestructura o se la deberá adquirir?

Esta información, como la volcada en el cuadro de adquisiciones, también debe trasladarse a

las áreas de gestión respectivas (como el plan de comunicación del proyecto). Tal interacción, llevada
a cabo en conjunto con las demás áreas de gestión, es indispensable para que el proyecto llegue a tener
una planificación congruente que sirva de base para una ejecución y control eficaces. Concluida esta
etapa, con la salvedad de que toda planificación es dinámica y debe mantenerse permanentemente
actualizada, puede comenzar el trabajo de campo. Se inicia la gran tarea de búsqueda.

103
Procesos licitatorios
En el contexto de las adquisiciones, buscar significa obtener respuestas del mercado, analizarlas
y tomar una decisión de compra. Partiendo del cuadro de adquisiciones, esta actividad se desdobla
en un proceso licitatorio para cada elemento de la lista. Existen diversas maneras de llevar a cabo
estos procesos, de acuerdo con la naturaleza y el valor de cada adquisición y dentro del marco
normativo de la organización anfitriona. Normalmente, una adquisición de bienes o servicios sigue
una hoja de ruta de cuatro pasos: preselección de proveedores, elaboración de los términos de
referencia, obtención de propuestas y análisis de propuestas. Eventualmente, se puede obviar el
primer paso si la organización ya tiene un registro de proveedores homologados para participar en
sus licitaciones o si las normas internas de la organización determinan que eso no se lleve a cabo
(caso típico de las empresas públicas). Repasemos sucintamente cada uno de ellos.

Preselección de proveedores
En este paso, el grupo de adquisiciones debe identificar quién puede, quién quiere y quién está
apto para proveer el objeto licitado. Quien puede son los proveedores que ofrecen el objeto en el
mercado; quien quiere son los que, además de ofrecer el objeto, están interesados en proveerlo; aptos
están los que, pudiendo y queriendo, reúnen las condiciones mínimas definidas en la convocatoria
y en las normas y reglamentaciones aplicables.
El conocimiento del mercado, indispensable en cualquier equipo de adquisiciones, permite
identificar a los proveedores potenciales de un objeto determinado. Según la estrategia de
adquisiciones definida en la planificación, será (o no será) posible restringir la búsqueda de estos
proveedores al mercado nacional o solo al internacional o incluso a empresas con determinadas
características, etc. Cuantos más proveedores haya, mayores serán las chances de lograr un buen
resultado en la contratación; por eso es importante no limitarse solo a los proveedores conocidos y
buscar siempre nuevas opciones.
Al menos para las adquisiciones de mayor riesgo, es prudente ponerse en contacto lo antes
posible con los proveedores identificados para confirmar si tienen en efecto la capacidad esperada y
el interés de, eventualmente, proveer lo que deseamos. Para eso se usa una solicitud de información,
o RFI (request for information), que abre un canal de comunicación con el proveedor, a través del
cual se le dan a conocer las condiciones generales de la futura adquisición (en especial, cantidades y
plazos, si bien preliminares) y se le solicita que confirme la posibilidad de atender el requerimiento
y su interés en participar en el proceso licitatorio. Las respuestas orientan este proceso y funcionan
como un primer filtro de preselección. Esta consulta debe cursarse también a proveedores ya
registrados u homologados, dado que las condiciones de suministro previstas tal vez no sean
compatibles con las posibilidades del proveedor en ese momento, lo que lo obligará a abstenerse de

104
competir. Desde el punto de vista del riesgo, cuanto antes se conozca este tipo de situación mejor
se administrará el proceso de adquisición de ese objeto.
El resultado de este primer esfuerzo es una lista provisoria de proveedores, clasificados en dos
categorías: los ya conocidos, registrados u homologados, y los desconocidos. Al menos en las
adquisiciones de mayor riesgo, no es aceptable incorporar proveedores poco conocidos en el
proceso. En este contexto surge la necesidad de adquirir conocimiento y un grado mínimo de
confianza en estos proveedores antes de aceptar la posibilidad de su futura contratación. La mayoría
de las organizaciones que llevan a cabo contrataciones frecuentes resuelve esta cuestión
homologando a los proveedores según un procedimiento prácticamente estandarizado: una visita
técnica realizada por especialistas para evaluar la capacidad de ejecución del proveedor y una visita
comercial a cargo de gestores para evaluar la calidad de la organización y la capacidad del proveedor
de cumplir compromisos contractuales. De ser satisfactorios los resultados, el proveedor es aceptado
como homologado o registrado.
Las organizaciones que registran u homologan proveedores de manera sistemática
normalmente establecen como restricción del proyecto que los procesos licitatorios se realicen
exclusivamente con proveedores de este registro (las excepciones se tratan caso por caso). La
legislación brasileña más reciente (BRASIL, 2016, artículo 36) 7 autoriza a empresas públicas y de
economía mixta a efectuar la precalificación de proveedores, sujeto a determinadas condiciones.

Términos de referencia
El grupo de adquisiciones debe elaborar la documentación a ser enviada a los futuros licitantes
para que estos puedan preparar sus propuestas. Esta documentación varía según el objeto y puede ser
tan simple como un correo electrónico que contenga algunos pocos requisitos o tan compleja como
un directorio de muchos megabytes con archivos repletos de sofisticada información. Genéricamente,
la información se organiza en dos categorías: la descriptiva del objeto a ser adquirido y la descriptiva
de las condiciones de adquisición del objeto. Esta información en su conjunto puede recibir muchas
denominaciones (convocatoria, invitación, solicitud de propuesta, request for propasal, solicitud de
cotización, etc.). De manera genérica la denominaremos términos de referencia.

7
Ley nº 13.303/16 – Disponible en http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2016/lei/l13303.htm Acceso en: 9
jun. 2019

105
 La información que describe el objeto se reúne en un documento (o colección de
documentos) llamado pliego de condiciones, que contiene la información necesaria para que los
licitantes comprendan correctamente el objeto. Puede incluir cualquier tipo de documento necesario,
siempre que respete algunos criterios:
 Objetividad: solo es requisito lo que es factible de medir y verificar, por lo que en un pliego
no hay espacio para la subjetividad. Si no es posible definir adecuadamente un requisito,
es mejor no incluirlo.
 Neutralidad: en la medida de lo posible, el pliego debe definir lo que se desea sin dirigir
la respuesta. Hay casos en que un producto específico debe formar parte del objeto y,
entonces, se lo debe citar, pero estos casos deben limitarse al mínimo indispensable.
 Viabilidad: un pliego debe ser completamente comprensible y viable para los licitantes
(por ejemplo, exigir la observancia de una norma a la cual los proveedores no tienen acceso
niega viabilidad a la licitación).

Si bien el pliego de condiciones está redactado por especialistas, el grupo de adquisiciones

debe efectuar un análisis crítico del documento para asegurar su conformidad con el resto de la
documentación y con el propio proyecto antes de ponerla a disposición de los licitantes.
La información descriptiva de las condiciones de adquisición se organiza, a su vez, en
condiciones de habilitación, condiciones de participación y condiciones de contratación. Las
condiciones de habilitación corresponden a los requisitos que el proveedor debe reunir para calificar
y participar en el proceso licitatorio. Son condiciones de habilitación típicas:
 registro u homologación previos;
 presentación de garantías (seguros, cartas de crédito, garantías de fiel cumplimiento);
 presentación de constancias de cumplimiento fiscal (certificados, declaraciones);
 presentación de constancias de cumplimiento de requisitos comerciales (balances,
certificaciones) y
 presentación de pruebas de idoneidad (equipamiento especial, calificación de los recursos
humanos, acceso a tecnologías, consorcios).

Las condiciones de participación definen las reglas de la licitación. Normalmente abordan los
siguientes aspectos:
 agenda del proceso;
 documentación a ser presentada por los oferentes;
 modelos de documentos a ser utilizados;
 procedimientos de comunicación;
 criterios de evaluación de propuestas;
 condiciones de rechazo de ofertas;
 presentación de embargos, impugnaciones o recursos.

106
 Las condiciones de contratación presentan los elementos principales del futuro contrato que el
adjudicatario de la licitación ha de suscribir (minuta de contrato). Esta minuta debe abarcar todos los
elementos que el contrato debe obligatoriamente incluir y aquellos que inciden en los costos del
proveedor (por caso, un proveedor que deberá instalar un equipo para que funcione en las dependencias
del contratante necesita saber que este equipo debe adecuarse a normas de seguridad o ambientales cuyo
cumplimiento tal vez cueste dinero). Son elementos habituales de una minuta de contrato:
 obligaciones del contratante y del contratista;
 normas aplicables (no relativas al objeto);
 reglas de medición y facturación;
 tratamiento tributario;
 criterios de reajuste;
 penas y bonificaciones;
 cláusulas de rescisión;
 confidencialidad;
 propiedad intelectual;
 reglas de fiscalización del contrato;
 condiciones de aceptación del alcance y
 condiciones de terminación del contrato.

Obtención de propuestas
La obtención de las respuestas de los proveedores puede seguir distintos procedimientos,
básicamente en función de la complejidad de la adquisición. Para los objetos más simples, como los
productos básicos, es posible que sea suficiente una solicitud de cotización para luego tomar una decisión
puramente financiera. Para eso, la subasta electrónica (también denominada subasta inversa) es en
la actualidad el método más utilizado e incluso considerado de preferencia por la legislación
brasileña (BRASIL, 2016). En esta modalidad, los proveedores reciben los términos de referencia y,
luego de registrarse, participan en una subasta en un sitio de internet, en la que el ganador es el
mejor postor. Por ser una subasta cerrada, cada licitante pone su precio y el resultado se anuncia de
inmediato. Si es abierta, los oferentes pueden hacer ofertas y el ganador es quien ofreció la cotización
menor dentro del plazo de la subasta. Si bien este método se considera muy seguro, es factible
burlarlo por cartelización o direccionamiento de la consulta, por lo que el grupo de adquisiciones
debe tomar precauciones para evitar estas posibilidades. De igual modo, debe evitarse el uso de este
método para objetos complejos, en los cuales la decisión no debe tomarse exclusivamente en función
de los precios. En estos casos, la mejor alternativa es una licitación en la que se tengan en cuenta
aspectos técnicos y el precio, y se invite a los proveedores a presentar propuestas técnico-comerciales,
en respuesta a los términos de referencia, para permitir su análisis y selección posterior. Este es el

107
modelo clásico para objetos de complejidad técnica media o alta, largos plazos de entrega, costo
medio o alto en relación con el presupuesto del proyecto y riesgos de obtención medios o altos. Por
ser más complejo, lo describiremos a continuación en detalle. Ciertamente es dable que los aspectos
operativos varíen de manera significativa de una organización a otra, pero los elementos básicos son
prácticamente universales.
El grupo de adquisiciones debe comunicar a los proveedores el inicio del proceso licitatorio.
Esto marca el comienzo de un período de interacciones entre el grupo y los proveedores que
respondieron a la convocatoria, ahora elevados a la categoría de licitantes. La duración de este
período está definida en el instrumento convocatorio y la agenda debe cumplirse de manera
rigurosa. Durante este lapso, el grupo debe tener especial cuidado con tres aspectos: dar a los
licitantes un trato igualitario, para evitar situaciones de favorecimiento; brindar apoyo a los licitantes
ofreciéndoles las mejores condiciones posibles que les permitan preparar propuestas de buena
calidad; y mantener el control de la comunicación.
El riesgo de favorecimiento no solo puede arruinar todo el proceso de adquisición, con los
impactos previsibles en el proyecto, sino también destruir carreras y reputaciones, a veces,
injustamente. Este riesgo debe evitarse mediante el respeto a los procedimientos licitatorios, la
documentación y trazabilidad del proceso, y una actitud de distanciamiento cortés en relación con
los licitantes. Esta actitud debe combinarse con acciones de apoyo como:
 designación de las personas del grupo responsables de aclarar dudas de los licitantes y
centralizar la comunicación en ellas;
 organización de reuniones aclaratorias;
 suministro de información adicional cuando sea necesario;
 organización de visitas técnicas.

El control de la comunicación consiste en establecer protocolos para el intercambio de

información entre las partes y aplicarlos de manera sistemática, sin excepciones. Algunos de estos
protocolos versan sobre:
 documentación y trazabilidad de todas las comunicaciones;
 divulgación de la información a todos los licitantes;
 control de las revisiones de los documentos licitatorios.

Convencionalmente, el proceso licitatorio se materializa con la entrega de los términos de

referencia a los licitantes en un acto presencial (público o privado) y con la recepción de las
propuestas de igual forma. Hoy este método está siendo rápidamente reemplazado por entornos
virtuales que reproducen la hoja de ruta presencial, pero ofrecen diversas ventajas. Quizás la
principal sea la capacidad de llevar a cabo procesos licitatorios internacionales sin necesidad de

108
desplazar equipos y minimizando el problema de diferentes husos horarios. La celeridad del
intercambio de información y la seguridad de la trazabilidad de las comunicaciones son otro gran
beneficio. El gran obstáculo que dificultó durante mucho tiempo la adopción de esta tecnología –
el requisito de firma de los documentos– ya fue superado por la técnica de certificación digital.
Recomendamos que, en la medida de lo posible, al menos los procesos de adquisición principales se
efectúen con el apoyo de estas tecnologías.
Como ejemplo de reglas de un conjunto de criterios para procesos licitatorios, veamos a
continuación los cinco principios que una institución financiera (CAF – banco de desarrollo de
América Latina) adopta para los proyectos que lleva a cabo:
1. El prestatario deberá realizar una licitación pública internacional para la adquisición de
bienes cuyo valor sea superior o equivalente a USD 500.000,00 (quinientos mil dólares
estadounidenses), al igual que en caso de la contratación de obras y de servicios de
ingeniería por valores superiores o equivalentes a USD 2.000.000,00 (dos millones de
dólares estadounidenses). Las convocatorias a licitación deberán tener amplia divulgación
según los requisitos que establece la ley, de modo de posibilitar la eficiencia y la
transparencia y garantizar la alta competitividad del proceso licitatorio.
2. En situaciones especiales de contrataciones que tengan por objeto valores superiores a los
mencionados en el párrafo anterior, se podrá utilizar la licitación pública nacional siempre
que, por motivos de orden técnico, estén debidamente justificadas por el prestatario y
tengan la previa autorización formal de CAF.
3. Para adquisiciones de bienes cuyo valor sea inferior o equivalente a USD 500.000,00
(quinientos mil dólares estadounidenses), o en el caso de contratación de obras y
servicios por un valor inferior o equivalente a USD 2.000.000,00 (dos millones de
dólares estadounidenses), el prestatario aplicará reglas y procedimientos de licitación
pública nacional.
4. Para contrataciones de consultorías cuyos valores sean superiores o equivalentes a
USD 250.000,00 (doscientos cincuenta mil dólares estadounidenses), el prestatario
aplicará procedimientos de licitación pública internacional. Para contrataciones inferiores
o equivalentes a USD 250.000,00 (doscientos cincuenta mil dólares estadounidenses), el
prestatario aplicará reglas y procedimientos de licitación pública nacional.
5. Publicidad: en las licitaciones y concursos públicos internacionales, los prestatarios y las
agencias de ejecución publicarán las notificaciones correspondientes en no menos de
2 (dos) periódicos de circulación nacional, observando además los requisitos de las
reglamentaciones locales aplicables. Para todos los demás casos, los prestatarios y las
agencias de ejecución informarán a CAF el procedimiento antes de solicitar el concurso
o el llamado de selección.

109
Análisis de propuestas
Una vez recibidas las propuestas de los licitantes, el grupo de adquisiciones debe analizarlas y
decidir cuál de ellas sirve mejor al proyecto. Ello requiere, una vez más, un procedimiento formal y
objetivo, aunque se trate de una solicitud de cotización para un objeto sencillo. No es viable decidir
de manera subjetiva (es decir, arbitraria) un concurso que afecte los intereses del proyecto, de la
organización anfitriona, del cliente, de diversos proveedores, de órganos de control. Hay muchas
maneras de organizar esta fase del proceso, pero por lo general, todos siguen la misma hoja de ruta
básica: análisis de los requisitos excluyentes, análisis de los requisitos clasificatorios técnicos y
análisis de los requisitos comerciales.
Los requisitos excluyentes son aquellos que, de no reunirse, determinan la salida del licitante
del concurso. Las condiciones de habilitación constituyen requisitos excluyentes típicos, pero
también hay requisitos técnicos y comerciales que pueden tener esta característica. Si las condiciones
particulares definen que el material de un tubo debe ser obligatoriamente de acero inoxidable y el
proveedor ofrece cualquier otro material, ese proveedor debe quedar eliminado por insuficiencia
técnica; si se especifica que el plazo máximo de realización de un servicio es de doce meses y el
proveedor ofrece quince, estamos ante la misma situación. Sin embargo, es necesario tener cuidado
y no interpretar como excluyentes requisitos que admiten una franja de variación para ser
considerados aceptables. En el ejemplo anterior, el plazo solo sería excluyente si los doce meses
requeridos fuesen efectivamente el límite aceptable para el proyecto. De lo contrario, sería mejor
considerar los doce meses como referencia y clasificar a los proveedores según su posicionamiento
en relación con este plazo.
Es buena práctica informar en los términos de referencia qué requisitos son excluyentes y qué
método de análisis de propuestas se utilizará.
Los requisitos clasificatorios son, evidentemente, todos los que no se encuadren como
excluyentes. Se dividen en dos grandes grupos: técnicos y comerciales. Pueden analizarse por
separado o no, de acuerdo con el marco normativo de la organización o los procedimientos
adoptados por el proyecto. El criterio de análisis debe respetar el criterio de toma de decisión ya
comentado: el menor riesgo para el proyecto. Eso significa que no se trata de seleccionar de manera
automática la cotización más baja; se trata de identificar previamente una combinación de factores
técnicos y comerciales que represente la solución más adecuada para el proyecto y, a partir de allí,
comparar las propuestas usando esta combinación como referencia. En este sentido, es posible que
el del menor precio sea el mejor criterio. Sin embargo, esta decisión debe ser el resultado de las
características de la adquisición. La propuesta que más se aproxime a la referencia adoptada (o la
supere) será, en principio, la más adecuada.
Una de las maneras más adecuadas de poner en práctica este principio es usar técnicas de
análisis multicriterio, en especial la más conocida de ellas, el proceso de análisis jerárquico (AHP en

110
inglés). A modo de ejemplo, consideremos que todos los requisitos clasificatorios de una licitación
puedan reunirse en cinco grupos: precio, plazo, calidad, cantidad y servicios (ciertos elementos
como reajustes de precio y condiciones de pago quedan en el grupo precio; los elementos de
desempeño del objeto se encuadran en el grupo calidad, y así sucesivamente). En función del objeto
que se esté adquiriendo y las condiciones del mercado, se define la importancia relativa entre cada
par de los cinco grupos y se calcula la importancia relativa de cada uno según el algoritmo del
proceso AHP. 8 En situaciones simples, es posible realizar el análisis con eficiencia solo con la
ponderación de los grupos. Para objetos más complejos, podemos realizar el mismo cálculo para los
requisitos reunidos en cada grupo, 9 de modo de ponderar doblemente cada requisito y así ofrecer
una calidad de análisis superior. La correcta atribución de pesos es crucial para que el resultado del
análisis indique la propuesta efectivamente más adecuada. Los errores en este algoritmo pueden crear
riesgos innecesarios y graves para el proyecto. La aplicación del algoritmo debe hacerse, por cierto,
antes de la recepción de las propuestas y l a validación del modelo por parte de la jerarquía del
proyecto es indispensable para legitimar la futura elección del ganador de la licitación.
El análisis multicriterio es la herramienta más indicada para comparar elementos dispares
como el reajuste de un precio y el nivel de servicio especificado para la asistencia técnica. Para mayor
información sobre el AHP, recomendamos el material de lectura complementaria de esta unidad.
El segundo elemento del análisis es una escala de puntuación que permita posicionar la
respuesta de un licitante en relación con lo especificado en los términos de referencia. Se usan desde
escalas conceptuales simples (satisface, no satisface y satisface parcialmente) hasta escalas numéricas
más elaboradas. Una técnica eficiente es la escala numérica con el cero en el centro, donde la
atribución del valor cero a la respuesta del proveedor significa la satisfacción plena del requisito,
mientras que los valores positivos a la derecha representan respuestas por encima del mínimo
establecido y los valores negativos a la izquierda muestran la situación inversa. Evaluando de esta
forma todas las respuestas de una propuesta dada, es posible atribuir una nota a cada requisito
multiplicando la puntuación por el peso del mismo (obtenido por el método AHP). La media de
las notas forma el índice de conformidad de la propuesta. En particular, si una propuesta obtiene
un índice cero, la misma habrá reunido todo los requisitos clasificatorios dentro del mínimo o de
los valores de referencia especificados. Cuanto más positivo sea el índice, más alejado de este
mínimo se ubica la propuesta, mientras que los índices negativos significan satisfacción insuficiente.

8
Si aplicamos este criterio a la compra de mil bolsas de cemento común, reunir los requisitos de plazos, calidad, cantidad
y servicios no deberá ser un problema para los proveedores, de modo que es probable que el grupo precio reciba el mayor
peso y tenga la mayor importancia. En la práctica, eso significará una compra por el menor precio. Sin embargo, si estamos
contratando una consultoría altamente especializada y de cuyo trabajo dependen muchas otras cosas en el proyecto, los
mayores pesos recaerán sobre servicios y calidad. La propuesta más adecuada no será necesariamente la más barata.
9
Si, por ejemplo, tenemos quince requisitos en el grupo calidad, ¿cuál será la importancia relativa de cada uno?

111
 Si se realiza este ejercicio para cada una de las propuestas calificadas tendremos una indicación
satisfactoria sobre la medida en que cada una atiende las necesidades del proyecto (y siempre dentro
de la lógica del menor riesgo). Este método posee las calidades de objetivo, demostrable y rastreable,
pero no tiene precisión quirúrgica: siempre hay margen para alguna interpretación, por lo que se
recomienda usarlo con la debida cautela.
Si la diferencia de índices entre los licitantes es significativa, el ganador puede elegirse en
función de tan solo este resultado, mientras que si esta diferencia es pequeña, es probable que
tengamos un resultado inicial intermedio que solo permitirá identificar los mejor ubicados. En este
caso, es posible usar criterios de desempate como la puntuación obtenida en los requisitos más
importantes, una solicitud de información complementaria sobre algunos requisitos para permitir
una mejor comprensión y revisión de notas y, por último, la elevación de un resultado de empate
técnico a los decisores jerárquicos del proyecto para que tomen una decisión.
De todos modos, el uso de este método o de otros semejantes es condición básica para que el
proceso licitatorio culmine de manera satisfactoria. Cabe recordar que los licitantes tienen derecho
a impugnar los resultados y la mejor manera de evitar ese contratiempo que puede ocasionar serios
inconvenientes al proyecto es un procedimiento transparente y defendible.
Con la selección del ganador, la licitación debe cerrarse formalmente con la respectiva
información y agradecimiento a los participantes. Ahora estamos listos para ingresar en la tercera
etapa del proceso de adquisición: la contratación.

Modelos de contratos y su aplicación

Un contrato es un acuerdo entre dos partes en el cual una de ellas tiene una necesidad y está
dispuesta a obtener una solución dando algo a cambio, y la otra tiene la solución y está dispuesta a
ofrecerla mediante una contraprestación. Los contratos pueden ser explícitos o no, escritos o verbales,
sin embargo, en el ámbito de un proyecto solo se deben utilizar los contratos formales escritos.
En principio, cualquier acuerdo entre partes es válido, siempre y cuando no sea ilegal, y la
práctica ya se ha encargado de desarrollar los mejores modelos de contratos para cada tipo de
adquisición. Dada la obligatoriedad del estricto marco legal, se hace necesario que en esta etapa del
proceso el equipo de adquisiciones sea asesorado por especialistas en Derecho, de modo de
garantizar que el acuerdo sobre los requisitos técnicos y comerciales esté respaldado por elementos
jurídicos capaces de proteger a los interesados de ambas partes dentro de los marcos pertinentes. En
este punto, cabe hacer algunos breves comentarios acerca de los mencionados marcos.
En primer lugar se encuentra la legislación. En Brasil, los contratos entre particulares
(entidades de derecho privado) están regulados, en primera instancia, por el Código Civil (BRASIL,
2002). Los contratos administrativos (firmados entre el Estado y los particulares) se rigen por la

112
Ley 8666/1993 (BRASIL, 1993) 10 y por la Ley 13303/2016 (BRASIL, 2016) 11. Dentro de los
límites del presente curso, no está previsto debatir acerca de estos marcos legales, no obstante es
posible hacer algunas observaciones:
a) La entidad privada tiene derecho a organizar sus procesos licitatorios como mejor le
convenga (y hasta puede abstenerse de usar dicha técnica de adquisiciones). En cambio,
la entidad pública está obligada a presentarse a licitación y debe atenerse a las reglas
estipuladas en la legislación.
b) En la contratación, ambas entidades deben respetar los respectivos marcos legales, aunque
hay que destacar que el marco público es mucho más específico que el privado.
c) A pesar de las diferencias procesales, los principios públicos y las buenas prácticas privadas
son muy similares. Las pautas licitatorias comentadas en el apartado Procesos Licitatorios,
por ejemplo, son típicas de los servicios públicos y muchas organizaciones privadas las
adoptan libremente a causa de su reconocida eficiencia. Otros principios, como la adhesión
a lo consignado en el edicto (solo se puede adquirir lo que se especifica en el documento de
consulta), la isonomía (ningún proveedor puede ser favorecido en relación con los demás),
la impersonalidad (el grupo de adquisiciones es el agente de la transacción, no el propietario
del objeto adquirido) y otros, que son obligatorios para los organismos públicos, también
son reconocidos como importantes en el ámbito privado y aparecen en muchas regulaciones
internas de compra y de compliance de grandes empresas.

La legislación también se ocupa de definir categorías de contratos y de establecer reglas

específicas para cada una, creando una estructura mínima para proveer a los contratos de un marco
de uniformidad jurídica. De esta manera, podemos distinguir entre contratos de compraventa
(utilizados cuando la propiedad de un bien se transfiere del vendedor al comprador mediante una
contraprestación), contratos de locación (cesión del derecho de uso mediante una
contraprestación), contratos de locación de obra (el objeto contratado comienza a existir en función
del contrato) y así sucesivamente. Sobre esta base legal, el mercado, basado en la experiencia
acumulada, desarrolla modelos de contrato específicos para ciertos tipos de productos, segmentos
de negocios, etc. 12

10
Disponible en: http://www.planalto.gov.br/ccivil_03/leis/l8666cons.htm Acceso en: 9 jun. 2019
11
Disponible en: http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2016/lei/l13303.htm Acceso en: 9 jun. 2019
12
Un contrato de servicios de TI tiene una estructura característica que difiere, por ejemplo, de la de un contrato de servicios
de mantenimiento industrial, aunque ambos sean contratos de locación de obra.

113
 El tipo de contrato que se utilizará se define, generalmente, en los términos de referencia.
Para ello, en un primer momento el grupo de adquisiciones debe evaluar diversos factores. Algunos
son estratégicos, como la disponibilidad de capital, la capacidad gerencial, las políticas de
confidencialidad y similares; y otros son específicos, como el grado de definición del objeto, la
situación del mercado y las particularidades de cada segmento del mercado. Mediante este conjunto
de factores se arriba a la selección del modelo más indicado, considerando las categorías jurídicas y
los aspectos gerenciales. Entre ellos, el más importante es el criterio de la transferencia de riesgo,
según el cual cada parte siempre intentará transferir la mayor parte posible de los riesgos del contrato
a la otra. En tal sentido, el buen contrato es aquel que logra un equilibrio entre las posibilidades y
los intereses de ambas partes. Los contratos desequilibrados o mal seleccionados distribuyen
obligaciones y responsabilidades de forma desproporcionada, lo cual aumenta mucho la
probabilidad de fallas (que en algunas ocasiones terminan siendo inevitables). Este criterio funciona
con la noción de que el riesgo se puede incorporar en el contrato de dos maneras: estructuración y
formación de precios.
El precio de un bien o servicio, según esta noción, siempre debe incluir una parte de
contingencia que corresponda a la percepción de riesgo del proveedor. Esta parte será tanto mayor
cuanto mayor sea el riesgo que asumió y viceversa, lo cual varía entre límites que dependen del tipo
de objeto y de las condiciones del suministro. Por una parte, un proveedor puede rehusarse a
presentar una propuesta o a firmar el contrato en caso de que considere que el riesgo que se le
transfiere es excesivo y, por otra, uno de los elementos centrales de la negociación del precio de un
contrato es el valor de la contingencia. En este tipo de negociaciones, la cuestión es la transferencia
de riesgo entre el contratado y el contratante, mientras que el valor de la contingencia es una
consecuencia de ello.
Se puede sintetizar la estructuración del precio en una clasificación simple (que de hecho es
la que adopta el PMI) según la cual cada contrato se divide en tres tipos básicos (susceptibles de
combinaciones): contratos de precio fijo, contratos de precio unitario y contratos de precios
administrados. La relación entre estos tres tipos y la transferencia de riesgos entre las partes se
presenta en la siguiente figura.

114
 Figura 43 – Transferencia de riesgos entre contratante y contratado

Un contrato de precio fijo es aquel en el que el precio del objeto está definido desde el
momento en el que empieza a regir (el precio fijo no debe confundirse con el precio al contado ni
con el precio que no se puede ajustar). Este tipo de contratos requiere que el objeto y las condiciones
de suministro estén bien definidos y, generalmente, son los preferidos por el comprador (y, por lo
tanto, a menudo se los adopta erróneamente). El riesgo asumido por el proveedor al fijar el precio
de un objeto que quizás aún no existe (un equipo fabricado por encargo o una obra, por ejemplo)
se compensa con la buena definición contractual y el precio más elevado (contingencia).
Si el objeto y las condiciones de suministro son indefinidos o están sujetos a cambios, es
probable que un contrato de precio fijo presente más dificultades que beneficios y que el precio sea
más alto de lo razonable. En este caso entra en juego el contrato de precio unitario, también
conocido como contrato por tiempo y materiales: en lugar de fijar un precio global para el objeto,
este contrato define tarifas, es decir, precios parciales para partes o etapas definidas del alcance
contratado (precio por metro cuadrado de piso colocado o precio por hora trabajada de un
profesional.).
El monto adeudado por el contratante es el producto de la tarifa por el resultado medido
durante determinado período. Esta solución le evita al proveedor un riesgo que sería excesivo si
tuviera que asumir un precio fijo y lo ayuda a mantener el costo total más bajo con el control de la
contingencia. El precio unitario no significa que el contrato no tenga un valor, sino que este valor
es apenas referencial y no obligatorio. El valor final de este tipo de contratos solo se conoce a su

115
término, pero el contrato puede concluirse antes de completar su alcance, en caso de que los costos
medidos alcancen o superen cierto límite del valor de referencia.
Si la incertidumbre sobre el objeto y las condiciones de suministro es muy alta y, aun así,
debe realizarse la adquisición, puede ser necesario hacer uso de un contrato de precios administrados
o de costos reembolsables. Dado el grado de indefinición, el contrato no tiene un precio, sino una
referencia presupuestaria. Los costos del proveedor son medidos, comprobados y reembolsados por
el contratante con el agregado de una tasa de administración definida en el contrato. El riesgo para
el contratante es el máximo y para el proveedor, el mínimo, por lo cual el valor del contrato es
inferior al de los demás tipos para un mismo alcance.
Otro punto a tener en cuenta es el esfuerzo gerencial asociado con cada tipo de contrato.
Como regla general, cuanto menor sea la definición, mayor será el esfuerzo. De hecho, el precio
más bajo obtenido en contratos de precios unitarios o administrados se compensa, al menos en
parte, con el costo interno del contratante. El grupo de adquisiciones debe incluir esta información
en su planificación, particularmente en el diseño de los equipos de gestión de los contratos.
Como estrategia de realización, en los proyectos complejos se puede decidir agrupar una gran
parte o incluso todo el alcance en grandes contratos especiales. Por lo general, estos contratos
presentan combinaciones de los tres tipos básicos descritos anteriormente y se enmarcan dentro del
concepto de locación de obra. Entre la variedad de tipos existentes, podemos mencionar los cuatro
más significativos:
a) Llave en mano: es el contrato que absorbe todo el alcance de un proyecto, es decir, la
gestión del proyecto se convierte, en definitiva, en la administración de un megacontrato.
El riesgo para el contratado es, obviamente, el máximo posible, y el precio también será
más alto que el de otras modalidades de contratación. El contratante, por su parte, corre
el riesgo de perder el control sobre el proyecto al transferir todo el alcance a terceros. Sin
embargo, en ciertas situaciones, esta opción puede justificarse y generar buenos
resultados.
b) EPC (Ingeniería, Compra y Construcción): en grandes proyectos que involucran la
implementación de activos físicos complejos (unidades industriales, por ejemplo), es
habitual que una parte considerable del alcance, que incluye el proyecto de ingeniería, el
suministro de todos (o casi todos) los materiales necesarios para la creación del activo, su
construcción y montaje, así como su puesta en marcha, se delegue a un único proveedor.
No obstante el contrato EPC también represente un riesgo elevado para el proveedor,
puede ocurrir que el contratante deba subordinársele gerencialmente y, al mismo tiempo,
siga siendo el responsable de algunas partes del alcance de menor peso que las del
proveedor. La administración de un contrato EPC es compleja y requiere un alto grado
de planificación y capacidad de gestión de ambas partes.

116
 c) EPCM (Ingeniería, Compra, Construcción y Gestión): es una variación del contrato EPC,
en la que el proveedor pasa a ser el responsable de la gestión de las funciones de EPC. El
cliente contrata estas funciones a otras empresas y las pone bajo la responsabilidad del
proveedor de EPCM. El riesgo para este proveedor es menor que en el EPC común y el
riesgo del contratante es proporcionalmente mayor. Sin embargo, transferir el esfuerzo de
gestión de EPC a un proveedor puede ser de interés para el contratante.
d) Contrato de alianza: es posible romper el paradigma de la transferencia de riesgos
mediante la adopción de modelos de contratos asociativos, en los cuales el riesgo es
compartido por las partes. Este es el caso del contrato de alianza, también conocido como
Open Book, por requerir la presentación de toda la información de ambas partes para que
pueda completarse el contrato. Se diferencia de un consorcio o joint venture por el hecho
de que la relación cliente-proveedor se preserva dentro de las condiciones de una
colaboración. Reemplaza a los modelos EPC, EPCM y llave en mano, y tiene un buen
historial de casos de éxito.

Prácticas de administración de contratos

Con el contrato firmado se da inicio a su administración. El objetivo de esta actividad es
garantizar que el objeto adquirido se ponga a disposición de quienes lo necesiten, en las condiciones
especificadas, y que el acuerdo firmado con el proveedor se cumpla en su totalidad. Para ello, la
administración del contrato implica dos funciones y cuatro ejes de acción:

Funciones
 relaciones contractuales: comprenden todo el trabajo necesario para garantizar el éxito del
contrato y cubrir los cuatro ejes de acción, y
 diligenciamiento: busca asegurar la conformidad técnica del objeto a la especificación
contractual.

En contratos pequeños, una sola persona puede asumir ambas funciones, sin embargo, a
medida que aumentan el tamaño y la complejidad del contrato, se hace necesario dividirlas entre
un Gerente de Contratos y un Inspector a cargo de la fiscalización. El primero tiene un perfil de
competencia gerencial, y el segundo debe ser un especialista en el objeto del contrato. Es posible
que estos profesionales necesiten ayuda, motivo por el cual puede haber equipos de administración
contractual compuestos por decenas de personas. Como ya se mencionó, el grupo de adquisiciones
debe considerar este factor en la planificación del trabajo.

117
 El equipo de administración del contrato debe tener una actitud adecuada en las siguientes
tres áreas:
 Con respecto al contrato: este documento, sus anexos y documentos complementarios son
las únicas referencias aceptables (además de la legislación) para organizar y controlar el
trabajo, así como para responder cualquier duda.
 Con respecto a los hechos: el entorno del contrato es fáctico y objetivo, y no debe estar
contaminado por opiniones y subjetividades. Si algo está respaldado por la evidencia, es
inútil contrarrestarlo mediante la voluntad y la intuición.
 Con respecto a las personas: el contrato es impersonal y los equipos son agentes de sus
organizaciones. Los problemas deben tratarse con rigor técnico y firmeza gerencial, pero
dentro de un ambiente de civilidad en el que un trato respetuoso contribuya a la búsqueda
de soluciones equilibradas.

Tal actitud constituye la base para una administración exitosa y debe ser adoptada por los
equipos de ambas partes.

Eje de la adhesión
La adhesión al contrato es una responsabilidad de ambas partes y consiste en asegurar que el
trabajo se realice con arreglo a las disposiciones contractuales. En el entorno contractual no hay
espacio para improvisaciones o informalidades; simplemente, las personas responsables de ejecutar
un contrato deben seguirlo y los hechos nuevos o imprevistos deben encararse con los
procedimientos pertinentes. Desde ya, es posible interpretar la letra de cualquier contrato, pero este
recurso debe ser utilizado con discernimiento por sus gerentes para respetar el espíritu con el que se
negoció y firmó el contrato. El criterio de análisis y decisión debe preservar el interés del proyecto
como prioridad con el fin de evitar la creación de riesgos innecesarios.
Algunas de las principales rutinas para asegurar la adhesión son:
 Seguimiento y facturación: prácticamente ningún contrato de un proyecto se paga al
contado; por lo tanto, la forma de pago es una de las cláusulas más importantes. Por lo
general, su aplicación requiere un procedimiento complementario que detalle los pasos
administrativos, y la secuencia habitual es la presentación de un registro de seguimiento
que, si se aprueba, autoriza al proveedor a emitir un comprobante de cobro. El registro (o
documento equivalente) describe las entregas que se están controlando y el monto a pagar,
y se instrumenta con todas las pruebas necesarias para justificar el cobro. El gerente de
contratos, por otro lado, se basa en la información suministrada por los especialistas para
evaluar el seguimiento, que la podrá aceptar en todo o en parte. Este procedimiento debe
recibir un tratamiento prioritario dentro de las rutinas administrativas, ya que la demora

118
 en los pagos, además de una irregularidad contractual pasible de penalidades y litigios,
puede ocasionarle serias dificultades al proveedor y, por consiguiente, al propio objeto.
 Gestión de cuestiones pendientes de resolución: la ejecución de un contrato genera desvíos
que se deben corregir para que el alcance se lleve a cabo de manera adecuada. Cuando algo
que debería haberse hecho no lo ha sido o presenta una no conformidad, existe una
cuestión pendiente de resolución que debe ser subsanada. Las cuestiones pendientes de
resolución, por definición, afectan algún otro aspecto del trabajo (aunque más no sea la
aceptación final del alcance) y tienen un plazo de resolución y un responsable definido. El
gerente de contratos debe llevar un registro de todas las cuestiones pendientes de
resolución en el contrato y tomar las medidas necesarias para garantizar que no se
conviertan en una fuente de problemas en cadena, ampliando negativamente las
situaciones que podrían resolverse fácilmente.
 Acción de presencia: ninguna administración contractual es verdaderamente eficaz si el
equipo del contratante no se presenta ante el proveedor. Ya sea por medio de reuniones
regulares, visitas, diligencias o, incluso, de la permanencia en el lugar de ejecución del
contrato, dicha presencia debe estar planificada y prevista en el contrato. La presencia del
contratante, por regla general, hace que la ejecución del contrato sea más ágil y segura, lo cual
evita o resuelve rápidamente problemas que, de otra manera, tomarían una forma no deseada
e innecesaria.
 Negociación: la ejecución diaria de un contrato implica el ejercicio constante de la
interpretación de las cuestiones dudosas, la toma de decisiones sobre dificultades
imprevistas, los ajustes de programación para absorber contingencias, etc. Ello conlleva la
negociación entre las partes pues, de lo contrario, la administración del proyecto se
convertiría prácticamente en inviable. El gerente de contratos debe entender esta realidad
y adoptar una postura adecuada, preparándose para actuar de esta manera, por ejemplo,
armando una agenda de encuentros con el proveedor para hacer un seguimiento de los
asuntos cotidianos y revisar el progreso del contrato (incluso si no hay ninguna cuestión
grave a tratar).

Eje de la comunicación
La comunicación contractual, esencial para el éxito, busca asegurar que las partes tengan pleno
conocimiento de la situación laboral y, así, puedan actuar de manera eficiente en su administración.
Además, las partes interesadas del proyecto pueden requerir información regular del contrato con
fines legales o de contralor. Ello implica definir claramente qué protocolos de comunicación se deben
usar (informes, eventos de seguimiento, redes de comunicación digital, etc.) y garantizar que estos se
utilicen de manera adecuada. La comunicación también debe lidiar con el dilema de preservar la

119
seguridad de la información, a menudo confidencial, mientras se mantiene la transparencia de una
actividad particularmente sujeta a cuestionamientos y dudas sobre la uniformidad de los
procedimientos. Los informes de situación, registros de eventos y demás documentos de
comunicación se deben calibrar con el fin de atender a estas necesidades de manera equilibrada.

Eje de la modificación
Todos los contratos están sujetos a modificaciones debidas al surgimiento de nuevos hechos
o de no conformidades que se produzcan en la ejecución del contrato y que no se puedan corregir.
Los procesos de adquisición bien manejados producen contratos de buena calidad que, si se
gestionan bien, probablemente sufran pocas modificaciones. En el caso contrario, se pueden generar
contratos con tal sucesión de modificaciones que se vuelvan inmanejables.
La modificación contractual no es negativa en sí misma y debe tratarse como un evento
normal. Para ello, el contrato debe incorporar un procedimiento para registrar y enviar las
modificaciones propuestas por las partes, así como para someterlas a su aprobación. Este
procedimiento sigue un itinerario simple: la propuesta de modificación debe ser formal y estar
fundamentada con sus justificaciones y la evaluación de los impactos que causará el proyecto. La
propuesta se evalúa según su viabilidad y aplicabilidad y puede ser aprobada o no. Solo se pueden
implementar las modificaciones aprobadas, cuya incorporación al contrato se realiza por medio de
adendas contractuales. Las modificaciones contractuales que se realizan y se pagan sin la
correspondiente adenda caracterizan irregularidades serias en la administración contractual.

Eje del conflicto

El entorno de ejecución de un contrato es conflictivo, lo cual no significa que sea
necesariamente agresivo. El conflicto es inevitable, ya que incluso los mejores contratos no están a
salvo de desvíos en la realización, de divergencias de interpretación y también de comportamientos
inadecuados de las partes. El gerente de contratos debe estar preparado para identificar el conflicto
y actuar lo más rápidamente posible de modo de impedir su agravamiento, preservando el contrato
y el proyecto de turbulencias que puedan tener consecuencias graves. Dejando de lado los conflictos
de comportamiento (que también deben ser tratados con atención), los conflictos que surgen de
cuestiones objetivas sobre la realización del contrato son tratados bajo la forma de reclamaciones,
también conocidos como claims.
Una reclamación no debe ser confundida con una modificación: esta constituye un episodio
normal en la vida del contrato, aquel corresponde a una anormalidad. Las reclamaciones
constituyen reivindicaciones de una de las partes, que se considera perjudicada en sus derechos,
tendientes a obtener compensaciones para el perjuicio que considera haber sufrido o estar sufriendo.

120
Una modificación mal gestionada, eventualmente, puede dar origen a una reclamación, pero nada
más. La reclamación consiste en una exposición de motivos, fundamentada con todas las evidencias
necesarias, y en una demanda de resarcimiento o de ajuste de conducta por la parte supuestamente
ofensora. Se dirige a la jerarquía superior a la del gerente de contratos y constituye la última instancia
de negociación antes de recurrir a un arbitraje o proceso judicial, por tal motivo, siempre debe ser
preparada con el apoyo de especialistas jurídicos. Como norma, la negociación de reclamaciones
produce acuerdos para evitar el desgaste, la demora y las incertidumbres de un litigio en la Justicia.
Las reclamaciones también deben ser incorporadas al contrato por medio de adendas.
Lecciones aprendidas: el proceso de adquisición y, en particular, la gestión del contrato
generan un aprendizaje que no debe perderse. El equipo de adquisiciones debe implementar un
procedimiento de lecciones aprendidas desde la etapa de planificación, y el gerente de contratos
debe utilizarlo, y también alentar al proveedor a que lo haga. El conocimiento adquirido es una
fuente principal de mejora continua para la organización.

Terminación de los contratos

El contrato se debe concluir de forma ordenada, lo cual puede ocurrir de diversas formas
según los marcos legales, no todas positivas para el proyecto. Las principales son:

Conclusión en tiempo y forma

Forma normal de conclusión contractual, que presupone el cumplimiento de cuatro
condiciones:
 alcance completado y aceptado;
 pagos realizados y reconocidos;
 regularidad fiscal y laboral; y
 ausencia de negociaciones abiertas o procesos judiciales pendientes.

En principio, todos los contratos del proyecto deben ser concluidos de esta forma. Cabe
señalar que la existencia de negociaciones extiende la vigencia del contrato hasta su conclusión, lo
que puede aparejar la extensión del período en el que permanecen vinculados el gerente de
contratos, el grupo de adquisiciones o incluso el gerente del proyecto. La conclusión del proyecto
también puede permanecer pendiente en estos casos. Cuando el contrato está bajo la
responsabilidad directa del proyecto, una de las soluciones habituales es transferirlo al
Departamento de Compras o al Departamento Jurídico de la organización anfitriona.

121
Rescisión
Conclusión anticipada y unilateral del contrato, por decisión de una de las partes después de
que la otra parte haya incurrido en alguna cláusula rescisoria prevista en el mismo contrato
(incumplimiento, demora excesiva, falta de idoneidad, por ejemplo). Cuando se produce una
situación de este tipo, la parte perjudicada tiene derecho a rescindir el contrato, pero dicha acción
es una opción, generalmente tomada después de negociaciones y de algunos pasos preparatorios,
como las cartas de advertencia. La rescisión no es amigable y, por lo general, tiene consecuencias
judiciales. Las partes, especialmente el gerente de contratos y el grupo de adquisiciones, deben
redoblar esfuerzos para evitar este tipo de situaciones, ya que estas representan todo lo que se debe
evitar en el proyecto.
El impacto del retiro abrupto de un proveedor puede implicar la paralización y hasta la
inviabilidad de la continuidad de un proyecto (exactamente lo que se pretendía evitar con todo el
esfuerzo de la gestión de adquisiciones). Dependiendo de las circunstancias, una rescisión en el
medio de un proyecto tal vez tenga consecuencias perjudiciales, incluso para las carteras de los
responsables involucrados. Dicho esto, hay casos en los cuales la rescisión se vuelve inevitable y debe
ser ejecutada. Valiéndose de los mecanismos de control del contrato y del proyecto, el gerente de
contratos, el grupo de adquisiciones y los responsables del proyecto deben identificar lo antes
posible la posibilidad de que ocurra una situación de rescisión y prepararse para enfrentarla,
elaborando soluciones alternativas.

Resolución
Conclusión anticipada e imprevista de un contrato por motivos de fuerza mayor. Aquí, las
partes no tienen el control sobre el acontecimiento y no pueden ser consideradas responsables del
compromiso asumido. Es el caso de una catástrofe natural o de un shock económico repentino y
de alto impacto. En muchos casos, la inviabilidad se debe demostrar antes de que se confirme la
conclusión por resolución. En general, se trata de un evento amigable, aunque siempre es negativo
para ambas partes. Cuando la causa perjudica solo a la parte contratada, el efecto práctico sobre el
proyecto es similar al de una rescisión, con el agravante de la imprevisibilidad. Las resoluciones
contractuales suelen ser sinónimo de crisis en cualquier proyecto y, en la medida de lo posible,
deben ser evaluadas en la gestión de riesgos de las adquisiciones.

Desistimiento voluntario
Extinción anticipada por acto de voluntad de una o de ambas partes. Existen varias
situaciones posibles para un escenario de desistimiento voluntario, por ejemplo, el distracto
(desinterés mutuo en la continuación del contrato), la renuncia (desistimiento de una de las partes,

122
con el abandono de sus derechos contractuales) y la denuncia (desinterés de una de las partes,
comunicado con anticipación en conformidad con una cláusula contractual). Los casos de
desistimiento voluntario pueden tener un impacto mixto en el proyecto: algunos están controlados
(la queja, cuando se inicia el proyecto) y otros no. El impacto negativo de un desistimiento
voluntario tiende a ser menor que el de una rescisión o resolución, sin embargo, aun así, se trata de
situaciones que deben ser evitadas en la medida de lo posible.
La extinción de un contrato requiere la firma de un Acta de Conclusión, dando pleno
finiquito de las obligaciones de ambas partes (no es el caso de la rescisión, por supuesto). En los
proyectos, en cada contrato, hay dos variaciones comunes que deben ser previstas por el grupo de
adquisiciones y por el gerente de contratos. Veamos lo siguiente.

Aceptación de alcance
En los contratos complejos suele suceder que el diligenciamiento considere que ya se puede
entregar el objeto (alcance total) mientras que hay cuestiones gerenciales abiertas (reclamaciones,
por ejemplo). En estos casos, podemos utilizar un acta de aceptación de alcance. Este documento
no concluye el contrato, pero libera el objeto que se incorporará al proyecto, haciendo mención de
posibles plazos o retrasos. Esta opción, aunque muy útil en algunas situaciones, debe adoptarse con
precaución y solo cuando sea realmente necesario debido a eventuales problemas de custodia,
responsabilidad técnica, transferencia de derechos y similares, que quizás se conviertan en
problemas mayores que los beneficios que se pretendían conseguir con la aceptación anticipada del
objeto. Constituye una buena práctica que el acta de aceptación de alcance sea preparada por un
asesor jurídico del proyecto, no solo por el grupo de adquisiciones.

Transferencia de custodia
Algunos contratos incluyen en su alcance elementos que se extienden más allá del ciclo de
vida del proyecto, como la garantía de un edificio (cinco años después de la correspondiente
habilitación) o la asistencia técnica a los usuarios de un equipamiento durante la primera etapa de
su operación. Sin embargo, es necesario que, de ahí en más, estos contratos continúen vigentes bajo
la responsabilidad de otro equipo después de la conclusión del proyecto. De este modo, el gerente
de contratos y el grupo de adquisiciones deben efectuar una transferencia de custodia, pasándole al
nuevo equipo todo el historial del contrato y cumpliendo con los procedimientos corporativos
pertinentes. 13 La parte contratada no tiene injerencia en este punto, pero se la debe mantener
informada y debe participar de la transición.

13
No siempre hay necesidad de documentos formales de transferencia, pero el registro del pasaje constituye siempre una
buena práctica.

123
 Una vez que se complete el alcance de las adquisiciones, la misión del grupo de adquisiciones
en el proyecto estará (casi) concluida. Si los recursos se han puesto a disposición de acuerdo con las
especificaciones y de manera oportuna, si se ha respetado el presupuesto y los contratos se han
concluido sin mayores problemas para la organización anfitriona y los proveedores, entonces el
trabajo habrá sido exitoso. Pero todavía queda algo por hacer: el proceso de gestión de las
adquisiciones en el proyecto también debe ser concluido. Para ello, tendremos que:
 archivar correctamente la documentación de los contratos;
 recopilar y difundir las lecciones aprendidas (las adquisiciones y los contratos constituyen
fuentes muy ricas de conocimiento, de manera que sería una insensatez desperdiciar la
oportunidad de aprovecharlos);
 desvincular los medios utilizados en el trabajo (oficinas, TI, etc.); y
 desvincular al equipo.

Una vez completada la enumeración anterior, podremos celebrar e iniciar entonces otro
proyecto.

124
MÓDULO IV – RECURSOS TECNOLÓGICOS
DE GESTIÓN DE PROYECTOS

En este módulo veremos algunas aplicaciones tecnológicas de gestión de proyectos, que

describiremos y emplearemos en casos reales o hipotéticos.

Demostración de las principales herramientas de gestión de

proyectos
WBS o EAP
Como sabemos, en la fase del ciclo de vida llamada iniciación, la definición del alcance del
proyecto es todavía muy rudimentaria, preliminar o resumida. Pero a medida que avanzamos en la
etapa de planificación, todas las estimaciones deberán detallarse de manera exhaustiva. Esto tendrá
lugar tanto para el alcance como para las demás áreas de conocimiento.
La EAP (estructura analítica del proyecto) –en inglés, WBS (work breakdown structure) – es
justamente la herramienta maestra del área de conocimiento del alcance, ya que describe de manera
gráfica lo que ha de contener el alcance del proyecto, identifica las entregas previstas, “los resultados
físicos o semiproductos, obtenidos a lo largo del proyecto. Sirve para medir y evaluar el desempeño
del proyecto” (VARGAS, 2016). La EAP pormenoriza los componentes más elementales al dividir
el producto del proyecto en partes lógicas e interrelacionadas jerárquicamente.
Según Valeriano (2001, p. 201), la herramienta “consiste en una forma de presentación del
proyecto, que lo explicita en sus partes físicas, software, servicios y otros tipos de trabajo, y que
organiza, define y muestra de manera gráfica tanto el producto que se ha de realizar como el trabajo
que se ha de llevar a cabo para obtenerlo. La EAP es una descomposición del producto y de los
procesos necesarios para conseguirlo, así como de las consiguientes tareas gerenciales”. La EAP se
presenta como un organigrama, también conocido como árbol de descomposición del trabajo,
como podemos verificar en el siguiente ejemplo:

Figura 44 – Árbol de descomposición del proyecto: ejemplo

Fuente: VARGAS, 2016

La EAP es un instrumento orientado eminentemente al trabajo del proyecto, o sea, desglosa

el alcance en partes más pequeñas, pero sirve también para la comunicación con los stakeholders,
por ser una herramienta altamente visual. Una vez que esté diseñada en su totalidad, la EAP ayudará
a los stakeholders a visualizar y entender mejor las entregas previstas del proyecto. Como la EAP
divide los componentes del todo, discriminando los elementos de alcance, impide que se omita
ningún trabajo.
En la práctica, el diseño de una EAP se inicia con la descomposición del macroalcance del
proyecto en bloques cada vez más pequeños y de entregas cada vez más diminutas. Esos
desmembramientos llegan a un punto ideal o al nivel de detalle deseado, que en la literatura se
denominan paquetes de trabajo.

126
 En la EAP a continuación, los paquetes de trabajo son fácilmente identificables ya que están
localizados en el tercer (y último) nivel de desglose, conforme quedó indicado:

Figura 45 – Ejemplo de EAP

Como sirve para mostrar los componentes del alcance del proyecto, la EAP orientará los
trabajos del propio equipo ejecutor y, de este modo, facilitará la asignación de “dueños” para cada
paquete de trabajo y permitirá estimaciones de costos a partir de la atribución de los recursos necesarios
a cada entrega. La herramienta también será útil para identificar los posibles riesgos del proyecto,
gracias a la visualización detallada del alcance que la herramienta posibilita. Del mismo modo, permite
al gerente de proyectos usar la EAP en la definición de tiempos de duración de cada paquete de trabajo,
al dividirlos en actividades.
En su versión final, la EAP servirá de base orientadora para la mayor parte de la planificación
del proyecto. Esta herramienta de alcance servirá de insumo para varias otras áreas de conocimiento,
como se muestra en la figura siguiente:

127
 Figura 46 – EAP como apoyo de otras áreas

En lo que respecta a la confección de las EAP, normalmente es posible generar las

estructuras mediante programas muy conocidos y de uso extendido en el mercado, incluso los
más accesibles que integran el paquete de Microsoft Office. Podemos elaborar una EAP
fácilmente con PowerPoint, Word o MS Project por medio del recurso “organigrama”, en el
menú SmartArt (CAMARGO, 2014).
Otras opciones de software para la confección de EAP son Visio y XMind, pero también hay
en el mercado recursos tecnológicos concebidos y destinados exclusivamente para la construcción
de las EAP. Uno de los más utilizados entre los gerentes de proyectos es el software WBS Chart Pro.,
desarrollado por la empresa Critical Tools.

128
Se usó esta herramienta para confeccionar la siguiente EAP:

Figura 47 – EAP creada con WBS Chart Pro

129
 Otros programas útiles para crear una EAP son WBS Tool.com y OpenProj, ambos
descargables en línea sin cargo. Para la creación de las dos EAP a continuación se usaron estos dos
programas, respectivamente:

Figura 48 – EAP creada con WBS Tool.com

Figura 49 – EAP creada con Open Proj

130
 Un aspecto adicional y positivo del programa OpenProj es que su aplicación va más allá de
la mera elaboración de la EAP, por lo que constituye una herramienta más amplia de gestión de
proyectos. OpenProj puede usarse para el control de tiempos y costos, además de permitir la
asociación de tareas a los responsables (control de recursos). Otra ventaja es que, por ser un software
libre, funciona tanto en el entorno Windows como en Linux.
El siguiente texto, del renombrado autor Carlos Magno, brinda más detalles acerca de la EAP
y explica el paso a paso de su confección.

Los diez mandamientos de la estructura analítica del proyecto

La estructura analítica del proyecto (EAP) – en inglés, work breakdown structure (WBS) – es el
corazón de toda la planificación del proyecto. A partir de ella se elaboran el cronograma y el
presupuesto.

131
I – Deseará la EAP de su prójimo

Aprender del pasado es una habilidad importante del gerente de proyectos. Antes de iniciar la
elaboración de la EAP de su proyecto, verifique cómo se estructuró el alcance de proyectos
semejantes. Consulte otros proyectos de la empresa, revise la literatura y converse con otros
profesionales de la gestión que hayan actuado en proyectos cuyo objetivo haya sido la generación
de productos y servicios similares.

II – Explicitará todos los subproductos, incluso los necesarios para la gestión del proyecto

El producto o servicio que no esté en la EAP no forma parte del alcance del proyecto. Por lo tanto,
no deje ninguno afuera. Si durante la ejecución del proyecto algún miembro trabaja en una
actividad que no aporta a ningún producto de la EAP, estará trabajando fuera del alcance del
proyecto. De ser este trabajo necesario para el proyecto, se usarán los procedimientos para su
inclusión en el alcance. Los productos y servicios necesarios para la gestión del proyecto también
se deben incorporar a la EAP.

III – No usará los nombres en vano

Para los elementos de la EAP no use nombres imprecisos que generen dudas semánticas acerca
de qué producto se está representando. Utilice sustantivos para representar los productos y
servicios. No indique el proceso de generación de los mismos, pero sí la entrega de este proceso.
Así, en lugar de “someter a prueba el equipo” (un servicio), utilice “prueba del equipo”; en vez de
“elaborar el manual del equipo”, utilice “manual del equipo”.

IV – Guardará la descripción de las entregas en el diccionario de la EAP

Las entregas deben estar claramente definidas en el diccionario de la EAP para que quede bien
explicitado el trabajo a realizar.

V – Descompondrá hasta el nivel de detalle a fin de planificar y controlar el trabajo

necesario para la entrega del producto o servicio

La planificación y el control comprenden el alcance (verificación y control de cambios), el tiempo

(definición de las actividades), los costos (planificación de recursos, estimación de costos y
presupuestos) y el riesgo (planificación del riesgo).

VI – No desglosará en exceso para que el costo/tiempo de planificación y control no genere

el beneficio correspondiente

Planificar y controlar tiene su costo/tiempo necesario. Por consiguiente, desglose según su

necesidad en el proyecto. A modo de ejemplo, no sirve de nada descomponer el alcance en
subproductos cuya generación demande una hora si el control se realizará con frecuencia
semanal. Por otro lado, en caso de que un proyecto tenga entregables con altos niveles de
incertidumbre (que impliquen altos riesgos) y costos elevados, los controles necesarios exigirán
un desglose con alto grado de detalle. A modo de ejemplo, la EAP de un proyecto de construcción
de un vehículo lanzador de satélites (que cuesta varios cientos de millones de dólares)

132
será mucho más detallada que la EAP de la construcción de una casa prefabricada de 2 ambientes (que
cuesta unos miles de reales).

VII – Honrará al padre

Cada elemento de la EAP debe ser un componente del elemento “padre” al cual está subordinado.
Verifique si los elementos hijos en la EAP son realmente componentes de los elementos padre.
Por ejemplo, el hecho de que una capacitación dependa de que esté disponible un manual del
equipamiento no quiere decir que la elaboración del manual sea parte de la capacitación.

VIII – Desglosará de modo que la suma de las entregas de los elementos componentes
(hijos) corresponda a la entrega del elemento padre (regla del 100%)

Al descomponer un subproducto, no debe obviarse ninguna parte del mismo. Recuerde que la
suma de los subproductos componentes debe ser equivalente al subproducto que se sometió a
descomposición. Por ejemplo, al descomponer un estudio de factibilidad de la fase de concepto,
no deberíamos olvidar el informe final del estudio.

IX – No descompondrá en solo un subproducto

Un elemento de la EAP no debe tener un único componente (hijo). De acuerdo con el

mandamiento anterior, si un elemento tiene solo un componente, este es igual al padre. Si lo es,
¿por qué representarlo dos veces? Si esto ocurre, verifique que no haya olvidado ningún
componente. Si no lo olvidó, la representación del elemento subordinado es innecesaria.

X – No repetirá el mismo elemento como componente de más de una entrega

No podemos tener un elemento como componente (hijo) de más de un subproducto (padre). Por
ejemplo, si para impartir dos capacitaciones usamos la misma guía de estudio, no debemos ubicar
la elaboración de la misma como subproducto de dos capacitaciones. Es importante resaltar que
podemos tener elementos con el mismo nombre que compongan dos subproductos diferentes,
pero cada uno con un significado diferente.
MAGNO, Carlos. Os dez mandamentos da estrutura analítica do projeto. Disponible en:
https://beware.com.br/academia/artigos/os-dez-mandamentos-da-estrutura-analitica-do-projeto. Acceso: enero de 2019.

Cronograma
En el apartado 2 del módulo 2, vimos que el foco del área de conocimiento del tiempo es velar
por el cumplimiento del plazo final del proyecto, de modo de respetar la temporalidad de los
proyectos. Este monitoreo y control del tiempo los realiza principalmente la herramienta cronograma.
Las técnicas o programas modernos con énfasis en el control temporal han permitido a los
gerentes de proyectos desarrollar cronogramas más sofisticados y precisos, pero se impone hacer un
poco de historia.

133
 Uno de los primeros instrumentos creados específicamente para la gestión de proyectos fue
el gráfico de Gantt. Surgido en las primeras décadas del siglo XX, su principal motivación fue la
necesidad de la marina estadounidense de controlar proyectos. El autor del diagrama, Henry Gantt,
como parte de una tarea durante la Primera Guerra Mundial, diseñó una matriz que cruzaba las
actividades o tareas del proyecto con sus respectivas duraciones e interdependencias. En el eje
vertical, a la izquierda, enumeró las actividades y, a la derecha del gráfico, introdujo el factor tiempo,
con las duraciones de las tareas del proyecto. Estas duraciones se representaron mediante barras
horizontales. En la figura a continuación tenemos un ejemplo de un diagrama de Gantt:

Figura 50 – Diagrama de Gantt

Semanas
Etapa Actividad
11 22 33 44 55 66 77 88 99

1 Definición de los objetivos

2 Operacionalización de los conceptos

3 Selección de la muestra

4 Cuestionario y prueba preliminar

5 Definición de los recursos

6 Selección y capacitación

7 Trabajo de campo

8 Análisis e interpretación

9 Elaboración del informe

10 Análisis y aprobación del proyecto

En el marco de las demandas de un programa militar llamado Polaris, también perteneciente

la marina estadounidense, en la década de 1950 fue necesario desarrollar una estimación más
cuantitativa y probabilística de la duración de las actividades, lo que marcó un hito en la historia
de las herramientas de tiempo en proyectos: la técnica de evaluación y revisión de programas (PERT
en inglés). Simultáneamente, se desarrolló en la empresa DuPont el método del camino crítico, que
introdujo el concepto de la ruta más larga o la duración máxima de un proyecto.

134
 Las actividades constitutivas de este camino crítico no tienen holgura o presentan la menor
holgura disponible en todo el proyecto. El método enseña que la duración de esta ruta crítica
determina la duración total del proyecto. Así, con la identificación de la ruta crítica y de sus actividades
constitutivas, los gerentes de proyectos pondrán más foco en estas tareas críticas para evitar posibles
atrasos en sus ejecuciones según las duraciones originales. De hecho, si alguna actividad de la ruta crítica
se atrasa, habrá un riesgo de impacto directo en el plazo final del proyecto.
Desde entonces, la disciplina de la gestión de proyectos ha aplicado el método de
dimensionamiento del camino crítico, ya sea de forma manual o usando distintos programas. Sin
embargo, gran cantidad de otros recursos (similares o no) surgieron con el mismo objetivo de
desarrollar cronogramas de proyectos. En virtud de la propia evolución tecnológica del siglo XXI
aplicada a la gestión de proyectos, el escenario ha sido favorable a la universalización del uso del
cronograma para la gestión del tiempo o los plazos de cualquier proyecto, independientemente de la
envergadura e industria en la que se lo emplee. Así, cabe detallar la fundamentación de la
elaboración progresiva de la herramienta.
Según quedó dicho anteriormente, la EAP, con el desglose de los paquetes de trabajo,
representa la entrega total del proyecto, de ahí que es una herramienta del área de alcance del
proyecto. Sin embargo, a los fines de la confección de los cronogramas, será necesario dividir los
paquetes de trabajo obtenidos en la EAP en actividades o tareas. Por actividad se entiende cualquier
componente del trabajo realizado en el trascurso del ciclo de vida del proyecto que consuma tiempo
y recursos (CAMARGO, 2014).
La figura a continuación ilustra esta descomposición de los paquetes en actividades como
primer paso en la elaboración de un cronograma:

Figura 51 – Paquetes de trabajo por actividades

Fuente: VARGAS (2016)

135
 Como paso inicial de la confección del cronograma, se deben dividir las actividades a partir
del nivel de paquetes de trabajo, tal como se ilustra en la EAP siguiente:

Figura 52 – EAP y descomposición en actividades

Las dos ilustraciones siguientes, creadas con el programa WBS Chart Pro, ejemplifican
también el procedimiento de división de los paquetes de trabajo en actividades:

Figura 53 – EAP

136
 Figura 54 – Parte de EAP con desglose de actividades

Una vez identificadas las tareas y elaborado el listado de las que se han de ejecutar en el
proyecto, se deberá efectuar la secuenciación o relacionamiento lógico entre ellas. Según Valeriano
(2001), las actividades deben:

… disponerse en una secuencia que considere la precedencia de unas con

respecto a otras. Es como separar, en la construcción de un edificio, la
actividad de construcción de los cimientos de la que sigue a la estructura
de la obra [...]. Este proceso pretende disponer las actividades de manera
que se observen las precedencias. Hay actividades que se pueden realizar
independientemente de otras, pero están las que exigen una relación de
dependencia temporal. La principal salida de este proceso de secuenciación
de actividades es el diagrama de red del proyecto, que muestra de manera
gráfica las vinculaciones lógicas y la interdependencia de las actividades del
proyecto… (p. 211)

137
 De hecho, algunas actividades tienen una relación secuencial entre sí, es decir que una es
sucesora de otra. Otras tareas se pueden realizar paralelamente con otras. Estas dos configuraciones
de interdependencia se representan en los siguientes diagramas habituales:

Figura 55 – Interdependencias entre actividades

Relación Paralelo Secuencial

Representación
gráfica

El gerente de proyectos también estima y asigna los recursos necesarios para la ejecución de
cada una de las tareas y, como tercer paso, atribuye un plazo para cada una de las actividades. Muchas
empresas no tienen fuentes seguras para esta información, lo que perjudica sus estimaciones. Por otro
lado, las empresas que invierten en la gestión de conocimiento y el almacenamiento de datos a partir
de las lecciones aprendidas, cuentan con más facilidades al momento de estimar tiempos, ya que los
registros de proyectos anteriores podrán servir como una fuente confiable. Otra opción
complementaria para definir la duración de las tareas es recurrir a profesionales o especialistas, como
los miembros del equipo ejecutante del proyecto y consultores expertos.
Del mismo modo que ocurre para la elaboración de las EAP, existe también una oferta variada
de programas de gestión y control de proyectos. Todos poseen sus respectivos recursos o visiones para
la generación de cronogramas, algunos bastante robustos. Entre la amplia oferta de sistemas
disponibles, podemos mencionar especialmente los programas MS Project, Primavera, Openproj,
NetProject y Netoffice.

138
 Las figuras a continuación fueron generadas por las herramientas MS Project, OpenProj y
NetProject, respectivamente:

Figura 56 – Cronograma

139
 Figura 57 – Cronograma

Figura 58 – Cronograma

Fuente: http://netproject.com.br/imgs/cronograma-gestao-proyectos-ampliado.jpg

140
 OpenProj, por ejemplo, ofrece innumerables posibilidades adicionales aparte del diagrama
de Gantt. El sistema también permite introducir datos relativos a los recursos necesarios del proyecto
(sean estos humanos o materiales/equipamientos), como muestra la figura a continuación. Es
importante observar que en la columna “máximo de unidades”, se indica la cantidad planificada de
personas. También está la opción de introducir los costos horarios (BRL) y consignar si estos costos
se incurrirán al inicio o al final del proyecto o, incluso, si serán prorrateados con otro departamento
de la empresa ejecutora del proyecto. Por último, OpenProj también permite que cada recurso
tenga un calendario único, por ejemplo, un profesional que solo trabaje parcialmente en el proyecto,
4 horas por día, etc. En caso de que el recurso “Bruno” de la figura no esté disponible en el
calendario estándar del proyecto, que es de 8.00 a 17.00, se puede adaptar el calendario de ese
recurso a su especificación para el “período matutino” (CAMARGO, 2014).
Todas estas opciones mencionadas acerca de OpenProj también están disponibles en Ms
Project.

Figura 59 – Cronograma con asignación de recursos

Además, OpenProj, Ms Project y casi todos los demás programas permiten que el esfuerzo
del equipo genere un histograma de los recursos. Se muestran a continuación algunos ejemplos de
esta visualización:

Figura 60 – Asignación de recursos

141
 Figura 61 – Asignación de recursos

300

275

250

225

200
Uso de los recursos

175

150

125

100

75

50

25

09 16 23 30 06 13 20 27 06 13 20 27 03 10 17 24 01 08 15 22

Enero Febrero Marzo Abril Mayo

Horas del personal en la utilización de los recursos

En función del histograma obtenido, el gerente del proyecto y otros usuarios de estos
programas tendrán la indicación de la carga de trabajo de cada recurso y el esfuerzo disponible en
el equipo. El histograma indica varios puntos en el proyecto, por ejemplo, si hay sobrecarga, si se
deben postergar actividades no críticas o si debe reemplazarse el recurso asignado por otro no
sobrecargado. Es factible que sean necesarias otras decisiones en función de lo que muestren estos
sistemas, como la opción de atrasar o no algunas fechas clave del proyecto, o crear un margen de
seguridad donde haya sobrecarga del personal, etc.
En MsProject o en OpenProj también es posible incluir la columna de porcentaje del trabajo
realizado con los datos reales de lo que se concretó diariamente del proyecto. Para ello, basta agregar
la columna “% concluido” en el nombre del campo e introducir los porcentajes a medida que se
van realizando las tareas.

142
 Para concluir el módulo, es oportuna la lectura del siguiente texto:

Cinco herramientas gratuitas para la gestión de proyectos

Establecer buenas relaciones entre los miembros del equipo es uno de los factores clave para
el éxito de un proyecto. Aquí van cinco herramientas para ayudarlo en esta tarea.

De la redacción, IDG News Service, 19/03/2018 a las 6h55

Cierta vez, el mánager de béisbol Casey Stengel dijo que “encontrar buenos jugadores es fácil;
lo difícil es hacerlos jugar juntos”. Tal vez la afirmación valga para el momento actual en lo
que atañe a los recursos tecnológicos. La colaboración es uno de los factores clave para el
éxito, independientemente del tamaño de la compañía.

Con ello en mente, resulta simple observar cuán importante es poseer la herramienta de
colaboración adecuada para que los equipos se mantengan conectados y en una misma
dirección. Computerworld apunta algunas soluciones que lo ayudarán en este sentido.

Podio – Red social corporativa a la que se le pueden agregar funciones de gestión de

proyectos. Cada usuario mantiene su propio perfil, que se puede asociar a otras
personas, como gestores, colegas que participen directamente en alguna iniciativa,
líderes de proyectos y desarrolladores. Posee aplicativo de chat, intercambio interno
de correo electrónico, contactos, calendarios y tareas. Tal vez una de las grandes
ventajas de la herramienta sea la posibilidad de personalizar recursos, además de
algunas aplicaciones interesantes del mercado.

Asana – Herramienta creada por dos ex Facebook (Dustin Moskovitz, cofundador de la

red social de Mark Zuckerberg, y Justin Rosenstein, líder de tecnología) para hacer la
gestión de proyectos y flujos de modo que los usuarios estandaricen interfaces según
sus preferencias y normas de productividad. Funciona en la mayoría de las
plataformas (tabletas, teléfonos y computadoras de escritorio) y garantiza flexibilidad
en el control de tareas y de actividades pendientes, indica avances y plazos y mantiene
las cosas en orden. Gratis para hasta 15 usuarios. A partir de allí, los valores
mensuales van de USD 50 a USD 800, según el número de colaboradores que usen la
herramienta.

Trello – Solución gratuita de gestión de proyectos que ofrece una interfaz simple e
intuitiva. Utiliza el modelo llamado Kanban, que se hizo famoso en la década de 1980
al ser propagado por Toyota. Los proyectos se representan y organizan en lo que la
empresa denomina cuadros o tarjetas, que contienen listas de tareas y actividades
que los usuarios comparten en tiempo real.

143
 Bitrix24 – Es un paquete que ofrece CRM, gestión de proyectos, centrales de contacto
con los clientes, herramientas de comunicación y colaboración, y hasta sitios y diseños
de páginas de destino. El módulo de gestión de proyectos incluye control de tareas,
subtareas, monitoreo de tiempo, modelos, papeles, notificaciones, gráficos de Gantt y
Kanban, además de la integración con otras plataformas. Y en el módulo de
comunicación y colaboración, el usuario puede contar con un portal de intranet, una
red social privada, un chat de la empresa, calendarios, gestión de documentos, flujos
de trabajo para aprobación, la estructura de la empresa y otras herramientas.

GanttProject – Ahora, si lo suyo es la gestión de proyectos, esta es “la” herramienta

para usted. Esta aplicación gratis de código abierto para la gestión y programación de
actividades fue desarrollada en 2003 y pasó por muchos ciclos de evolución. La
solución permite que los usuarios creen y organicen tanto tareas como avances.
Permite incluso exportar información en formatos como HTML y PDF. La desventaja es
que no ofrece ninguna funcionalidad de redes sociales para listas de tareas a realizar.
Pero si usted no la necesita, esta tecnología gratuita le resultará muy atractiva.
Fuente: CINCO ferramentas gratuitas para gestão de projetos. Disponible en: < https://cio.com.br/5-ferramentas-
gratuitas-para-gestao-de-proyectos >. Acceso: enero de 2019.

144
CONCLUSIÓN

Si bien la gestión de proyectos sistematizada comenzó en el siglo XX, estamos rodeados de

proyectos que se sucedieron en forma paralela a la existencia de la raza humana. En el primer
módulo vimos que ya en épocas primitivas se encaraban grandes obras –y con excelencia–, lo que
demuestra un mínimo de know-how para concluir esos emprendimientos con éxito. Este trabajo
también se ocupó de la conceptualización de proyectos, entendidos como eventos temporales y
únicos, así como de su diferenciación de otros conceptos fundamentales de la disciplina, como los
trabajos de rutina, subproyectos, programas y carteras. Es importante resaltar la íntima correlación
entre la estrategia empresarial, derivada de la planificación estratégica, y la selección de proyectos
dentro de una corporación.
Por tener igual grado de importancia, vimos las justificaciones de los proyectos – es decir, sus
factores motivadores – y entendimos el papel de los stakeholders en la historia de cada proyecto.
Entre ellos, nos centramos especialmente en el gerente de proyectos y analizamos las principales
habilidades que este debe reunir para aumentar su índice de éxito. En este mismo sentido, en las
organizaciones más evolucionadas debe existir la oficina de proyectos para garantizar mejor la
aplicación de esta ciencia de proyectos. Un elemento que impacta fuertemente en la gestión es la
propia forma de las empresas, tema al que nos referimos diferenciando los tres modelos principales
de estructura y destacando los pros y los contras de cada uno. La gran utilidad de entender estos
diferentes modelos es que nos permite prever la relación o el impacto que tendrán en el día a día de
los proyectos.
En el módulo 2 revisamos el concepto de procesos de la gestión de proyectos, divididos en cinco
grupos o naturalezas, que ocurren en todo proyecto, independientemente del tamaño de la
compañía o del sector de actuación. Diferenciamos los 49 procesos de la 6a edición del PMBOK
del tema de ciclo de vida, un asunto que es evidentemente básico para la ciencia de proyectos, por
cuanto implica la propia temporalidad del concepto. Luego se explicó de qué modo es dable que
diversos parámetros –costos, personas, intervención de stakeholders– se comporten durante la vida
útil de una obra y se relacionaron las funciones de cada una de las diez áreas de conocimiento.
Asimismo, se evaluaron y desentrañaron debidamente las actas de constitución y el plan de gestión
de proyectos, dada su importancia crucial para una buena gestión de proyectos e, inclusive, para
la definición de la línea base del proyecto.
Como vimos, las áreas de alcance, tiempos y costos conforman en conjunto la triple
restricción de todo emprendimiento y tienen una relación entre sí. También vimos que el gerente de
proyectos precisa seguir una metódica gestión de los cambios solicitados de modo de evitar que
estos pedidos traigan aparejado un descontrol durante el ciclo de vida del proyecto. Concluimos el
módulo con el tema de los proyectos exitosos.
En el módulo 3 tratamos la gestión de adquisiciones en el entorno de un proyecto, para lo
cual usamos su ciclo de vida como hilo conductor. Nos detuvimos en la identificación de las
necesidades, la planificación del trabajo, la búsqueda de los recursos y la administración de los
contratos de suministro. Se describieron las opciones más adecuadas de suministro y de selección del
mercado hasta culminar con la elección de un contrato, acuerdo formal entre el cliente y el
proveedor. Vimos las tres fuentes de recursos para un proyecto –la organización anfitriona, su cliente
y el mercado– y los riesgos asociados a cada una de ellas.
En la unidad dedicada al proceso licitatorio, abordamos paso a paso estas adquisiciones,
respetando los criterios básicos de la objetividad, la neutralidad y la viabilidad, hasta finalizar en la
selección del proveedor ganador. También explicamos los modelos de contratos y sus respectivas
ventajas y desventajas, y compartimos varias lecciones de administración de contratos. Por último,
pero no por ello menos fundamental, se describió el cierre de los contratos con la intención de darle
la atención que amerita el final del ciclo de vida del proyecto.
En el módulo final, vimos los recursos tecnológicos y en profundidad dos de las herramientas
más útiles de gestión de proyectos: la EAP (herramienta de alcance) y el cronograma (instrumento de
tiempo). Analizamos sus respectivas funciones y mostramos al lector cuán necesarios son ambos en el
día a día del proyecto. Explicamos que esas herramientas pueden tener innumerables formas y
confeccionarse con diferentes programas, lo que en la práctica demuestra su importancia. De hecho, la
EAP y el cronograma son, hoy en día, los instrumentos más universales de la gestión de proyectos.
En suma, podemos concluir que la gestión de proyectos se ha vuelto una competencia
estratégica para toda organización contemporánea. De igual forma, los profesionales que conozcan
sus fundamentos y apliquen sus buenas prácticas tendrán un evidente diferencial en el ambiente de
trabajo y en el mercado.

146
BIBLIOGRAFÍA
BARCAUI, Andre. Gerente também é gente. Rio de Janeiro: Elsevier, 2012.

BARCAUI, Andre. PMO – Escritórios de projetos, programas e portfólio na prática. Rio de Janeiro:
Brasport, 2012.

CAMARGO, Marta Rocha. Gerenciamento de projetos: fundamentos e prática integrada. Rio de

Janeiro: Elsevier, 2014

CARVALHO, Fabio Câmara de Araujo. Gestão de projetos. San Pablo: Pearson Education do Brasil,
2015.

FOGAÇA, Jennifer Rocha Vargas. Refinamento do petróleo. Brasil Escola. Disponible en:
https://brasilescola.uol.com.br/quimica/refinamento-petroleo.htm. Acceso en enero de 2019.

FOGGETTI, Cristiano. Gestão ágil de projetos. San Pablo: Pearson, 2014.

GOZZI, Marcelo Pupim. Gestao de Projetos I. San Pablo: Biblioteca Universitaria Pearson – BUP,
2016.

KERZNER, Harold. Gestão de projeto: as melhores práticas. Nueva York: John Willey & Sons,
2009.

LEWIS, James. Project planning, scheduling & control. New York: McGraw-Hill, 2009.

MEREDITH, Jack R. Administração de projetos – uma abordagem gerencial. 4. ed. Rio de Janeiro:
LTC editora.

MONTES, Eduardo. Introdução ao gerenciamento de projetos: como gerenciar projetos pode fazer a
diferença na sua vida. 1. ed. San Pablo: PMP, 2017.

PMI – PROJECT MANAGEMENT INSTITUTE. Guia PMBOK®: um guia para o conjunto de

conhecimentos em gerenciamento de projetos. 6. ed. Pensilvania: PMI, 2017.

TORRES, Luis. Fundamentos do gerenciamento de projetos. Rio de Janeiro: Elsevier, 2014.

147
VALERIANO, Dalton L. Gerenciamento estratégico e administração por projetos. San Pablo: Makron
Books, 2001.

VARGAS, Ricardo. Gerenciamento de projetos: estabelecendo diferenciais competitivos. 9. ed. Rio

de Janeiro: Brasport, 2016.

Sites
https://www.cocacolabrasil.com.br/historias/central-gestao-comunitaria-da-agua-muda-realidade-
de-milhares-de-familias-na-bahia?gclid=Cj0KCQiAvqDiBRDAARIsADWh5TfNSLV0OIX7R4
N9a4K5mQ3APmxO2xWs. Acceso en enero de 2019.

https://www.defesa.gov.br/industria-de-defesa/paed/projetos-estrategicos/projetos-estrategicos-da-
marinha-do-brasil. Acceso en enero de 2019.

https://canaltech.com.br/espaco/60-anos-de-nasa-conheca-a-historia-e-os-projetos-da-agencia-
espacial-dos-eua-118996/. Acceso en enero de 2019.

http://www.inovarse.org/filebrowser/download/9152. Acceso en enero de 2019.

https://escritoriodeprojetos.com.br/processos-do-guia-pmbok-sexta-edicao. Acceso en enero de 2019.

https://dicasgp.pmtech.com.br/fluxo-pmbok/. Acceso en enero de 2019.

https://brasil.pmi.org/brazil/CertificationsAndCredentials/WhatarePMICertifications.aspx.
Acceso en enero de 2019.

https://blog.pmtech.com.br/tendencias-gp-2018. Acceso en enero de 2019.

https://escritoriodeprojetos.com.br/portfolio-de-projetos. Acceso en enero de 2019.

http://www5.each.usp.br/wp-content/uploads/2016/07/EAIP-O-Caso-do-Hospital-Albert-
Einstein.pdf. Acceso en enero de 2019.

https://beware.com.br/academia/artigos/os-dez-mandamentos-da-estrutura-analitica-do-projeto/.
Acceso en enero de 2019.

148
http://www.pmisp.org.br/enews/edicao1112/artigo_01.asp. Acceso en enero de 2019.

https://www.pmtech.com.br/Templates/Termo%20de%20Abertura.doc. Acceso en enero de 2019.

http://ri.sulamerica.com.br/static/ptb/perfil-missao-visao-e-valores.asp?idioma=ptb. Acceso en
enero de 2019.

https://beware.com.br/academia/artigos/os-dez-mandamentos-da-estrutura-analitica-do-projeto/.
Acceso en enero de 2019.

https://www.projectbuilder.com.br/blog/caminho-critico-do-projeto-saiba-quando-e-como-
utilizar/. Acceso en enero de 2019.

https://netproject.com.br/imgs/cronograma-gestao-projetos-ampliado.jpg. Acceso en enero de

2019.

https://artia.com/blog/software-de-gerenciamento-de-projetos/. Acceso en enero de 2019.

https://cio.com.br/5-ferramentas-gratuitas-para-gestao-de-projetos/. Acceso en enero de 2019.

149
BIBLIOGRAFÍA INDICADA PARA
ADQUISICIONES
AACE International. TCM Cost Framework 7.3 – cost estimating and budgeting. American
Assotiation of Cost Engineering, 2012.

BRASIL, Ministério da Justiça. Normas para licitações e contratos na administração pública. Lei n.
8.666/1993 e suas alterações. Brasília-DF, Imprensa Nacional, 1993.

BRASIL, Ministério da Justiça. Código Civil Brasileiro. Lei n. 10.406/2002. Brasília-DF, Imprensa
Nacional, 2002.

BRASIL, Ministério da Justiça. Estatuto jurídico da empresa pública, da sociedade de economia

mista e de suas subsidiárias. Lei n. 13.303, de 30 de junho de 2016. Brasília-DF, Imprensa
Nacional, 2016.

COREY JR, J. J. Contract management and administration. 1. ed. [S.l.: s.n.], 2015.

PMI – PROJECT MANAGEMENT INSTITUTE. Guia PMBOK®: um guia para o conjunto de

conhecimentos em gerenciamento de projetos. 6. ed. Pensilvania: PMI, 2017.

XAVIER, C. M. et al. Gerenciamento de aquisições em projetos. 4. ed. Rio de Janeiro: FGV, 2018.

150
PROFESORES-AUTORES
Lorena Benchimol de Veloso es máster en Administración de
Empresas y Comercio Internacional (Master of Business
Administration in International Management) por la European
University (Suiza/Portugal) desde 1999, con la distinción Magna Cum
Laude. En 2005 concluyó su MBA en Gestión de Proyectos en la
Fundación Getulio Vargas (FGV-RJ), con la titulación Summa Cum
Laude y recibió, de esta misma institución, el gran premio por el primer
lugar en el evento nacional Project Management Day.
Es oradora invitada en encuentros nacionales de gestión de proyectos desde 2007 y miembro
del Project Management Institute, PMI (Pensilvania, Estados Unidos), del cual también obtuvo la
certificación como Project Management Professional (PMP)® en 2005.
En 2000 comenzó su experiencia académica como profesora adjunta en los cursos de grado
de Administración, Gestión Empresarial, Comercio Exterior, Gestión de Marketing y Gestión de
Organismos Públicos. En 2006 se convirtió en profesora invitada de la Fundación Getulio Vargas
(FGV), en los cursos de posgrado (MBA) de Gestión de Proyectos, Gestión Presupuestaria,
Gestión Empresarial, Gestión de Proyectos de TI, Publishing Management y Fashion Business.
Desde 2016 es profesora titular del FGV Online, en la disciplina Fundamentos de Gestión de
Proyectos, de la FGV-RJ.
Inició su carrera profesional en el Tribunal de Cuentas de los Municipios y la Federación de
Industrias, donde trabajó durante siete años en proyectos de gestión de la calidad total y de recursos
humanos. Posteriormente, ocupó el cargo de Analista de Proyectos en la creación y mantenimiento
de la Oficina Nacional de Proyectos (Project Management Office – PMO) de la compañía Souza
Cruz/British American Tobacco (BAT), en su sede brasileña, en Río de Janeiro. Comenzó su carrera
de gerente de proyectos en la empresa Hewlett-Packard (HP) de Río de Janeiro, en 2004, donde
actuó en proyectos de tecnología de la información con medianas y grandes corporaciones. Fue
promovida a la gerencia a cargo de los clientes en proyectos de tercerización y, por último, a gerente
de cuenta de los clientes Michelin, Anglo Ferrous, TV Globo, BR Distribuidora, Rexam y
Chocolates Garoto por cuatro años. De 2010 a 2018, se desempeñó como gerente de distrito del
equipo Brasil del sector Printing and Personal Systems Group (PPS), a cargo de la coordinación de
los ingenieros y la red de representantes acreditados HP en atención a clientes corporativos, tarea
para la cual aplicó la gestión de desempeño, controles de los indicadores clave de desempeño y
generó proyectos de experiencia total del cliente. Actualmente se desempeña como consultora
independiente en las áreas de gestión de proyectos, gestión de procesos y recursos humanos.

151
 Maurini Elizardo Brito es ingeniero naval, especialista en gestión de
organizaciones y mercadotecnia, máster en Ingeniería de Producción y
doctorado en Ingeniería Ambiental. Cuenta con más de 30 años de
experiencia en las industrias naval, automotriz, gas y petróleo y energía. Ha
actuado en proyectos durante toda su carrera, además de haberse
desempeñado durante más de 15 años como consultor de gestión de
proyectos y emprendimientos, también participó en diversos megaproyectos
recientes en Brasil.
Es especialista en la puesta en marcha industrial y, en tal condición, ha actuado en diversos
proyectos en los sectores del gas y petróleo y energía, además de haber sido consultor en los Juegos
Olímpicos 2016. También es profesor de la FGV, del Núcleo de Investigación en Planificación y
Gestión de la Escuela Politécnica de la Universidad Federal de Río de Janeiro (NPPG/Poli/UFRJ)
y del Instituto de Investigación en Educación y Tecnología de la Universidad Católica de Petrópolis
(IPETEC/UCP). Primer evaluador de la IPMA Brasil.

152