CAPÍTULO 5

El Proyecto en el
Estructura organizativa
Una empresa, si tiene éxito, tiende a crecer, sumando recursos y personas, desarrollando una
estructura organizativa. Comúnmente, el enfoque de la estructura es la especialización de los
elementos humanos del grupo. Mientras su estructura organizativa sea suficiente para las tareas que
se le imponen, la estructura tiende a persistir. Cuando la estructura comienza a inhibir el trabajo de la
empresa, surgen presiones para reorganizarse en alguna otra línea. El principio subyacente seguirá
siendo la especialización, pero se cambiará la naturaleza específica de la especialización.
Cualquier libro de texto de administración elemental cubre las bases comunes de la especialización.
Además de la siempre popular división funcional, las empresas se organizan por línea de producto, por
ubicación geográfica, por proceso de producción, por proceso de negocio, por tipo de cliente, por
organización subsidiaria, por tiempo y por los elementos de integración vertical u horizontal. De hecho, las
grandes empresas se organizan con frecuencia mediante varios de estos métodos en diferentes niveles. Por
ejemplo, una empresa puede organizarse por subsidiarias importantes en el nivel superior; las filiales se
organizan por grupos de productos; y los grupos de productos se organizan en divisiones de clientes. Estos,
a su vez, pueden dividirse en departamentos funcionales que se desglosan en secciones del proceso de
producción, que se configuran como unidades operativas de tres turnos.
En la última década, ha aparecido un nuevo tipo de estructura organizativa en números
crecientes: la organización de proyectos, también conocida como "gestión de proyectos
empresariales" (Dinsmore, 1998; Levine, 1998; Williams, 1997), también conocida como
"organizaciones de gestión por proyectos ”, la“ empresa orientada a proyectos ”y otros nombres. Se
ha descrito que estas organizaciones aplican “prácticas y herramientas de gestión de proyectos en
toda la empresa” (Levine, 1998). La industria del software es un gran usuario del concepto de gestión
de proyectos empresariales, ya que durante mucho tiempo ha hecho una práctica de desarrollar los
principales programas de aplicaciones de software descomponiéndolos en una serie de proyectos de
software comparativamente pequeños, generalmente conocidos como un "programa" (pero no un
programa informático de software). Una vez finalizados los proyectos, se integran en todo el sistema
de aplicación. Y más allá de los programas internos que consisten en múltiples proyectos, también
hay proyectos multiorganizacionales donde muchas organizaciones externas están involucradas en
los proyectos. Y aún más grandes son los megaproyectos que involucran grandes sumas de dinero,
tremenda complejidad, múltiples organizaciones y contratistas y cronogramas de años, por ejemplo,
el Proyecto Manhattan, la terminal Heathrow T5, Big Dig de Boston, Proyecto Apollo y otros.
Un gran número de empresas, tanto de software como de no software, han adoptado ahora un sistema
mediante el cual su negocio tradicional se lleva a cabo de la manera tradicional, pero todo lo que representa
un cambio se lleva a cabo como un proyecto. Un hospital, por ejemplo, opera los departamentos habituales
en lo que, para ellos, son las formas habituales. Al mismo tiempo, el hospital apoya varias docenas de
proyectos orientados al desarrollo de nuevos productos para el cuidado de la salud o al cambio de varios
aspectos de los métodos médicos y administrativos estándar.

145
146CAPÍTULO 5 El proyecto en la estructura organizativa

En algunos casos, una estructura orientada a proyectos es un ajuste natural al negocio tradicional de una
organización. Por ejemplo, las empresas consultoras asignan personal a compromisos específicos con clientes y, a
medida que se completan los compromisos, los empleados se reasignan a nuevos compromisos con clientes.
Asimismo, las empresas que construyen grandes edificios de oficinas destinan sus equipos y recursos humanos a
proyectos específicos.
Hay muchas razones para el rápido crecimiento de las organizaciones orientadas a proyectos, pero la
mayoría de ellas pueden incluirse en cuatro áreas generales. Primero, la velocidad y la capacidad de
respuesta al mercado se han convertido en requisitos absolutos para una competencia exitosa. Ya no es
competitivamente aceptable desarrollar un nuevo producto o servicio utilizando métodos tradicionales en los
que el nuevo producto potencial pasa de un área funcional a otra hasta que se considere adecuado para la
producción y distribución.Primero en el mercado es una poderosa ventaja competitiva. Además, en muchas
industrias es común (y necesario) adaptar productos específicamente para clientes individuales. Los
proveedores de productos para el cuidado del cabello o cosméticos, por ejemplo, pueden suministrar a las
tiendas individuales de una cadena de medicamentos diferentes mezclas de productos según los patrones de
compra, la mezcla étnica de los clientes y las preferencias de estilo local de cada tienda.
En segundo lugar, el desarrollo de nuevos productos, procesos o servicios requiere
regularmente aportaciones de diversas áreas de conocimiento especializado. Desafortunadamente, la
combinación exacta de especialidades apropiadas para el diseño y desarrollo de un producto o
servicio rara vez es adecuada para otro producto o servicio. Los equipos de especialistas que se crean
para lograr su propósito ad hoc y se disuelven tipifican todo el proceso.
En tercer lugar, la rápida expansión de las posibilidades tecnológicas en casi todas las áreas de la empresa
tiende a desestabilizar la estructura de las organizaciones. Considere las comunicaciones, el entretenimiento, los
bancos, la fabricación y venta de productos de consumo, la industria automotriz, la fabricación de aviones, los
equipos eléctricos pesados, las máquinas herramienta, etc., sin fin. Las fusiones, reducciones, reorganizaciones,
escisiones, nuevos canales de comercialización y otras perturbaciones importantes similares requieren la capacidad
de respuesta de toda la organización en todo el sistema. Una vez más, no existe ningún mecanismo tradicional para
manejar el cambio a una escala tan grande de manera satisfactoria, pero la organización del proyecto puede hacerlo.

Por último, en la televisión, las películas, las novelas y otras mitologías, por el contrario, una gran
mayoría de los altos directivos que conocemos rara vez sienten mucha confianza en su comprensión y
control sobre muchas de las actividades que se desarrollan en sus organizaciones. El hospital mencionado
anteriormente se convirtió en una organización orientada a proyectos porque su nueva directora ejecutiva
sentía firmemente que no tenía forma de comprender, medir o controlar nada que sucediera en el hospital,
excepto las actividades tradicionales más rutinarias. La transformación de actividades no rutinarias en
proyectos le permitió asegurarse de que se estableciera la responsabilidad, que los proyectos se planificaran
adecuadamente, se integraran con otras actividades relacionadas y se informara de manera rutinaria sobre
su progreso.
Pasar de un entorno que no es de proyectos a uno en el que los proyectos se organizan y
utilizan para realizar tareas especiales a una organización totalmente orientada a proyectos
presenta a la alta dirección de una empresa una transición extraordinariamente difícil. Un
tratamiento completo de este tema está más allá del alcance de este libro, pero conviene hacer
varias observaciones. Primero, el proceso lleva mucho tiempo. Incluso cuando los recursos
necesarios están disponibles y la alta dirección está totalmente comprometida con la transición,
sigue siendo un proceso arduo. Nuestra experiencia indica que cuando todo va bien, la
transición rara vez requiere menos de 3 años. En un excelente artículo sobre el proceso de
liderar un cambio fundamental en una organización compleja, Kotter (1997) enumera ocho
pasos que deben completarse con éxito si se quiere lograr el cambio.
Es importante señalar que no existe la mejor estructura organizativa universal. Para industrias como la
consultoría de gestión, la naturaleza del trabajo se presta naturalmente a una organización orientada a
proyectos. En otras industrias, la naturaleza del trabajo, la estrategia competitiva de la empresa, el entorno
regulatorio, etc., pueden sugerir otras estructuras organizativas, como organizar el trabajo por disciplina,
geografía o proceso empresarial.
 Proyectos en una organización funcional147

Independientemente de si la organización está llevando a cabo algunos proyectos ocasionales o si está

totalmente orientada al proyecto y lleva a cabo decenas de proyectos, cada vez que se inicia un proyecto, surgen
inmediatamente tres cuestiones organizativas. Primero, se debe tomar una decisión sobre cómo vincular el proyecto
a la empresa matriz. En segundo lugar, se debe tomar una decisión sobre cómo organizar el proyecto en sí. En tercer
lugar, se debe tomar una decisión sobre cómo organizar las actividades que son comunes a otros proyectos.

En el Capítulo 3 discutimos la selección del gerente de proyecto (PM) y describimos las

dificultades y responsabilidades inherentes al rol del PM. Este capítulo se centra en la interfaz
entre el proyecto y su organización matriz (es decir, cómo se organiza el proyecto como parte
de su anfitrión). En la última parte de este capítulo, comenzamos una discusión sobre cómo
está organizado el proyecto en sí, una discusión que continuará en el próximo capítulo.
Primero, analizamos las tres formas organizativas principales que se utilizan comúnmente para
albergar proyectos y vemos cómo encaja cada una de ellas en la organización matriz. (Estas tres formas
también se enfatizan enPMBOK.) Examinamos las ventajas y desventajas de cada forma y discutimos algunos PMBOK
de los factores críticos que podrían llevarnos a elegir una forma sobre las otras. Luego consideramos algunas
combinaciones de las formas fundamentales y examinamos brevemente las implicaciones de usar 2.1.3
estructuras de combinación. Finalmente, discutimos algunos de los detalles de la organización del equipo del
proyecto, describiendo las diversas funciones del personal del proyecto. Luego pasamos a la formación y
operación de unOficina de Gestión de Proyectos (PMO) cuyo cargo suele ser aumentar la “madurez” de la
gestión de proyectos (Aubry, 2015) en toda la organización y, por lo tanto, puede proporcionar servicios de
importancia crítica para todos los proyectos. La habilidad con la que la PMO organiza, administra y lleva a
cabo sus responsabilidades tendrá un impacto importante en la capacidad de los proyectos para alcanzar sus
objetivos. También describimos algunos de los problemas de comportamiento que enfrenta cualquier equipo
de proyecto. Finalmente, discutimos el impacto que varias formas de estructurar proyectos pueden tener
sobre el conflicto intraproyecto en empresas orientadas a proyectos.

Hasta donde sabemos, es raro que un PM tenga mucha influencia sobre la interfaz entre la
organización y el proyecto; la elección de dichas interfaces suele ser realizada por la alta dirección. El
trabajo del PM, sin embargo, se ve fuertemente afectado por la posición del proyecto en la estructura
organizacional, y el PM debe entender su funcionamiento. Los PM experimentados parecen moldear
la organización del proyecto para que se ajuste a sus nociones de lo que es mejor. Un miembro del
equipo de proyecto que conocemos comentó extensamente sobre lo diferente que era la vida en dos
proyectos dirigidos por diferentes PM. El estudio de los impactos sutiles del PM en la estructura del
proyecto merece más atención por parte de los investigadores de las ciencias del comportamiento.

5.1 Proyectos en una organización funcional

Como una alternativa para darle al proyecto un “hogar” en una organización estructurada
funcionalmente, podemos convertirlo en parte de una de las divisiones funcionales de la firma,
generalmente la función que tiene más interés en asegurar su éxito o puede ser más útil. en su
implementación. Por lo general, pensamos que las funciones de una organización son las de
finanzas, marketing, operaciones (o fabricación), recursos humanos, etc. Sin embargo, para
considerar un tipo de organización ligeramente diferente, la Figura 5.1 es el organigrama de la
Universidad de Cincinnati, una institución organizada funcionalmente. Si la UC (el "financiador")
emprendiera el desarrollo de un programa de Maestría en Ciencias en Gestión de Proyectos (o
quizás un MPM), el proyecto probablemente se ubicaría bajo elsupervisión general
del vicepresidente senior y rector (el "patrocinador"), bajo el supervisión específica
del decano de la Facultad de Negocios (el "propietario del proyecto"), y podría ser administrado por
un miembro superior de la facultad (el PM) con especialidad en gestión de operaciones. Que podría
148CAPÍTULO 5 El proyecto en la estructura organizativa

Junta directiva

Acción a fi rmativa presidente Enlace de desarrollo Fundador de UC

Asuntos de exalumnos Radio WGUC

Defensor del Pueblo Atletismo

Vicepresidente sénior Vicepresidente sénior Vicepresidente sénior

y Provost para la administración Director del Centro Médico

Colegios de: Facultad de Ciencias Política administrativa Oficial de nombramiento Colegios de: Centro Médico
Artes y ciencias Aplicadas de OMI Procedimientos Oficina de contratación Medicamento Unidades Administrativas
Negocio Raymond Walters Coordinación Custodio de registros Enfermería y Salud (incluido Medical
Colegio Clermont Universidad Personal Auditoría interna/ Farmacia Personal del centro)
Conservatorio universitario Asuntos Académicos Beneficios Gestión Bibliotecas del Centro Médico
de musica Educación continua y servicios Compensación Servicios Hospital Universitario
Servicios comunitarios metropolitanos Empleo Asesoría legal (General y Holmes
Diseño, Arquitectura, Política de inscripción y Mano de obra y empleado Servicios Divisiones)
Y arte Investigacion Educativa Relaciones Secretario de la
Educación y Hogar Asuntos de la facultad Registros Junta
Ciencias económicas Practica profesional Entrenar y
Ingenieria Asuntos Estudiantiles Desarrollo
Universidad de la tarde Bibliotecas Universitarias

Ley

Vicepresidente de Vicepresidente y Decano de Estudios de Vicepresidente de Vicepresidente de

Asuntos publicos Posgrado e Investigación Tesorero y Finanzas Asuntos de negocios

Inscripción Gobierno y Ciencia del comportamiento Educacion universitaria Contabilidad y Informes financieros Planificación del campus y Planta física
Publicidad Enlace legislativo Laboratorio Institutos de investigación en Control presupuestario y control Construcción Sistemas energéticos

Publicidad y Servicios de información (locales, Instituto de Investigaciones administración de la investigación Planificación presupuestaria Gestión de inversiones Seguridad del campus y Operaciones y
Promoción estatales y nacionales) Gubernamentales Cajero y Administración de nómina Seguridad Mantenimiento
Relaciones públicas Investigación institucional Cuentas de estudiantes Nómina y empleado Servicios del campus Compras y
Procesamiento de registros Correo del campus Gestión de materiales
Servicios de estacionamiento Cumplimiento de contrato
Servicios de impresión Control de propiedad

Publicaciones Centro de Computación UC

Empleado subsidiado Académico y administrativo

Programas de trabajo Servicios informáticos

Teléfono Servicios por contrato
Comunicaciones
Transporte
Servicios
Librerías Universitarias

FIGURA 5.1Organigrama de la Universidad de Cincinnati.

 Proyectos en una organización funcional149

también estar bajo la supervisión general del VP y decano de Estudios de Posgrado e Investigación.
Tenga en cuenta que puede existir más de una opción de supervisión, y si el proyecto necesita
recursos de algunas de las otras áreas funcionales, se espera que ayuden a respaldar el proyecto. Por
ejemplo, si el proyecto está ubicado en la escuela de negocios bajo la supervisión directa del decano
de la escuela de negocios, es posible que se necesite información de la escuela de ingeniería.

Otra forma en que se puede organizar un proyecto en una organización funcional es asignar el
trabajo a todas las divisiones funcionales relevantes con la alta dirección supervisando el esfuerzo o
alguien asignado para coordinar sus esfuerzos, tal vez como gerente de proyecto o posiblemente
simplemente como facilitador. Un proyecto para aumentar el porcentaje de mujeres en la
administración superior podría involucrar todas las funciones de la universidad y podría ser
coordinado a través de la oficina del presidente, la oficina de Acción Afirmativa o posiblemente
utilizando a alguien del personal en la función de administración.
Existen ventajas y desventajas de utilizar una ubicación funcional para un proyecto,
asumiendo que la organización está organizada funcionalmente. Las principales ventajas son
las siguientes:

1. Existe la máxima flexibilidad en el uso del personal. Si la división funcional adecuada ha

elegida como sede del proyecto, la división será la base administrativa principal para las
personas con experiencia técnica en los campos relevantes para el proyecto. Los expertos
pueden ser asignados temporalmente al proyecto, hacer las contribuciones requeridas e
inmediatamente ser reasignados a su trabajo normal.

2. Los expertos individuales pueden ser utilizados por muchos proyectos diferentes. Con la amplia base de
personal técnico disponible en las divisiones funcionales, las personas pueden
intercambiarse entre los diferentes proyectos con relativa facilidad.
3. Los especialistas de la división se pueden agrupar para compartir conocimientos y experiencias. Allí

Por lo tanto, el equipo del proyecto tiene acceso a los conocimientos técnicos que residen en el grupo
funcional. Esta profundidad de conocimiento es una fuente potencial de soluciones creativas y
sinérgicas a problemas técnicos.

4. La división funcional también sirve como base de continuidad tecnológica cuando indi
Los particulares eligen abandonar el proyecto e incluso la empresa matriz. Quizás tan importante como
la continuidad tecnológica es la continuidad de los procedimientos, la administración y la política
general que resulta cuando el proyecto se mantiene en una división funcional específica de la empresa
matriz.

5. Finalmente, y no menos importante, la división funcional contiene la ruta normal

de avance para las personas cuya experiencia se encuentra en el área funcional. El
proyecto puede ser una fuente de gloria para quienes participan en su finalización exitosa,
pero el campo funcional es su hogar profesional y el foco de su crecimiento y avance
profesional.

Así como existen ventajas en el uso de una ubicación funcional, también existen desventajas:

1. Una desventaja principal de este arreglo es que el cliente no es el centro de la actividad.

y preocupación. La unidad funcional tiene su propio trabajo que hacer, que suele primar
sobre el trabajo del proyecto y, por tanto, sobre los intereses del cliente.
2. La división funcional tiende a orientarse hacia las actividades propias de su
función. Por lo general, no está orientado a problemas en el sentido en que un proyecto debería tener
éxito.

3. Ocasionalmente, en proyectos organizados funcionalmente, ningún individuo recibe una respuesta completa.
sibilidad para el proyecto. Esta falta de identificación de la responsabilidad generalmente significa que el PM se hace

responsable de algunas partes del proyecto, pero se hace a otra persona

150CAPÍTULO 5 El proyecto en la estructura organizativa

responsable de una o más partes. Se requiere poca imaginación para pronosticar la

falta de coordinación y el caos resultante.
4. Las mismas razones que conducen a la falta de un esfuerzo coordinado tienden a hacer que el cliente responda
Necesita lento y arduo. A menudo hay varios niveles de gestión entre el
proyecto y el cliente.
5. Existe una tendencia a suboptimizar el proyecto. La suboptimización ocurre cuando una parte de
la organización está optimizada en detrimento de la organización en general. Los problemas del proyecto que
están directamente dentro del área de interés del hogar funcional pueden tratarse con cuidado, pero los que
están fuera de las áreas de interés normales pueden recibir poca atención, si no totalmente ignorados.

6. La motivación de las personas asignadas al proyecto tiende a ser débil. El proyecto no es

en la corriente principal de actividad e interés, y algunos miembros del equipo del proyecto pueden ver
el servicio en el proyecto como un desvío profesional.

7. Tal arreglo organizativo no facilita un enfoque holístico de la

proyecto. Los proyectos técnicos complejos, como el desarrollo de un avión a reacción o una sala de
emergencias en un hospital, simplemente no pueden diseñarse bien a menos que estén diseñados como una
totalidad. No importa cuán buenas sean las intenciones, ninguna división funcional puede evitar centrarse en
sus áreas únicas de interés. La comunicación entre divisiones y el intercambio de conocimientos son, en el
mejor de los casos, lentos y difíciles.

Gestión de proyectos en la práctica

Reorganización para la gestión de proyectos
en Prevost Car
En Prevost Car en la ciudad de Quebec, Canadá, se le dijo al
vicepresidente (VP) de producción que tendría que expandir la
capacidad de producción en un 31 por ciento en los próximos 5 meses.
En el pasado, tal tarea comenzaba con una excavadora al día siguiente
y el trabajo estaría en marcha, pero nadie sabía a qué costo, qué
cronograma o qué valor para la empresa. Al darse cuenta de que
necesitaba algunas ideas nuevas, un enfoque estructurado y que no
había margen para un error, el vicepresidente se puso en contacto con
una empresa consultora de gestión de proyectos para que lo ayudara.
La firma consultora organizó una reunión de cinco días entre sus
gerentes de proyecto, un experto en ingeniería de valor y los siete
capataces de la fábrica principal de Prevost para analizar el proyecto. El
grupo elaboró un informe para la alta gerencia en el que se describe
un proyecto de $ 10 millones para expandir la fábrica principal en
60,000 pies cuadrados y un potencial de seguimiento para hacer una
expansión adicional de un 20 por ciento más. El detalle del plan fue
una revelación para la alta dirección, que lo aprobó después de solo 2
en Prevost. El uso de la gestión de proyectos en las empresas
manufactureras es muy apropiado dada su necesidad de adaptarse
rápidamente a la feroz competencia internacional, el cambio
tecnológico acelerado y las condiciones del mercado que cambian
rápidamente. Además, Prevost ha descubierto que la gestión de
proyectos fomenta la cooperación productiva entre departamentos, el
pensamiento fresco y la innovación, los enfoques de equipo a los
problemas y el uso altamente valorado de expertos externos para
aportar nuevas ideas, rompiendo así los hábitos y el pensamiento
miopes actuales. Como afirma el vicepresidente de Prevost: "En este
momento, es una cuestión de encontrar lo que no se podría gestionar
mejor por proyecto".
Preguntas
1. Seguramente esta no era la primera vez que Prevost necesitaba
realizar un cambio significativo en su empresa. ¿Por qué cree que
fue la primera vez que el vicepresidente recurrió a una empresa
consultora de gestión de proyectos?
2. ¿Espera que haya alguna preocupación entre la alta dirección de

días de estudio. Después de que se completó a tiempo y dentro del que no haya ninguna topadora trabajando el día siguiente?

presupuesto, la empresa también se comprometió con la expansión
adicional del 20 por ciento, que también llegó según lo planeado.
El éxito de este proyecto resultó en "infectar" Prevost Car
con el "error" de gestión del proyecto. La siguiente gran tarea,
una iniciativa para reducir las lesiones en el lugar de trabajo, se
organizó como un proyecto y también tuvo un gran éxito. Pronto,
todo tipo de actividades se estaban manejando como proyectos.
3. Este ejemplo ilustra bien la tendencia a utilizar la gestión de
proyectos para hacer todo en las organizaciones que antes se
hacía de otras formas. ¿Se puede ejecutar todo mejor
utilizando la gestión de proyectos? Si no es así, ¿cuáles son las
características de aquellas tareas que no pueden?
Fuente: M. Gagne, "Prevost Car — The Power of Project Management",
PM Network, Vol. 11.
 Proyectos en una organización proyectada151

5.2Proyectos en una organización proyectada

En el otro extremo del espectro organizacional (en términos de estructura del proyecto) está la
organización proyectada. Aquí, los grupos de apoyo administrativo de la firma (RR.HH., Legal,
Finanzas, Contralor, etc.) reportan al Presidente o CEO como unidades de personal. Las unidades de
línea son los diversos proyectos independientes que se llevan a cabo en la organización. Cada
proyecto tiene un complemento completo de las funciones necesarias para su funcionamiento,
aunque algunos miembros pueden servir en dos o más proyectos. Cada proyecto independiente es
una unidad autónoma con su propio equipo técnico, su propio personal, etc. Algunas organizaciones
de padres prescriben procedimientos administrativos, financieros, de personal y de control en detalle.
Otros permiten al proyecto una libertad casi total dentro de los límites de la responsabilidad final. Hay
ejemplos de casi todas las posibles posiciones intermedias. Figura 5.
Al igual que con la organización funcional, los proyectos independientes tienen ventajas y desventajas
únicas. Los primeros son los siguientes:

1. El director del proyecto tiene autoridad de línea completa sobre el proyecto. Aunque el primer ministro debe
reportar a un alto ejecutivo en la organización matriz, existe una fuerza laboral
completa dedicada al proyecto. El PM es como el CEO de una firma que se dedica a
realizar el proyecto.
2. Todos los miembros de la fuerza laboral del proyecto son directamente responsables ante el PM. Existen
no hay jefes de división funcional cuyo permiso deba solicitarse o cuyo consejo deba ser atendido antes de tomar

decisiones tecnológicas. El PM es verdaderamente el director del proyecto.

3.Cuando el proyecto se retira de la división funcional, las líneas de comunicación se acortan.

Se pasa por alto toda la estructura funcional y el PM se comunica directamente con la alta
dirección corporativa. Las líneas de comunicación acortadas dan como resultado
comunicaciones más rápidas con menos fallas de comunicación.
4.Cuando hay varios proyectos sucesivos de un tipo similar, la organización proyectada puede
mantener un cuadro más o menos permanente de expertos que desarrollan habilidades
considerables en tecnologías específicas. De hecho, la existencia de tales grupos de habilidades
puede atraer clientes a la empresa matriz. El famoso "Skunk Works" de Lockheed era un equipo
de expertos que se enorgullecía de su capacidad para resolver problemas de ingeniería difíciles.
El nombre del grupo, tomado de la tira cómica de Li'l Abner, refleja el orgullo, la actitud
irreverente y el fuerte sentido de identidad del grupo.

presidente

Administrativo
Apoyo

Proyecto DcX Proyecto Beta Proyecto rojo Proyecto Grow Guardar proyecto

Equipo Equipo Equipo Equipo Equipo

FIGURA 5.2La organización proyectizada.

152CAPÍTULO 5 El proyecto en la estructura organizativa

5. El equipo del proyecto que tiene una identidad propia fuerte y separada tiende a desarrollar una
alto nivel de compromiso de sus miembros. La motivación es alta y actúa para fomentar la
orientación a la tarea discutida en el Capítulo 3.

6. Debido a que la autoridad está centralizada, la capacidad de tomar decisiones rápidas aumenta enormemente.
Toda la organización del proyecto puede reaccionar más rápidamente a los requisitos del cliente
y las necesidades de la alta dirección.

7. Existe unidad de mando. Si bien es fácil sobreestimar el valor de este particular

principio organizacional, hay pocas dudas de que la calidad de vida de los
subordinados mejora cuando cada subordinado tiene un solo jefe.
8. Las organizaciones proyectadas son estructuralmente simples y flexibles, lo que las hace
relativamente fácil de entender e implementar.
9. La estructura organizativa tiende a apoyar un enfoque holístico del proyecto. Una breve
En el Capítulo 3 se dio una explicación del enfoque de sistemas, y en la Sección 5.3 de este
capítulo aparece un ejemplo de los problemas que surgen cuando no se utiliza el enfoque de
sistemas. Los peligros de la suboptimización o de enfocarse y optimizar los subsistemas del
proyecto en lugar del proyecto total son a menudo una de las principales causas de fallas
técnicas en los proyectos.

Si bien las ventajas de la organización proyectizada constituyen un poderoso argumento a favor

de esta estructura, sus desventajas también son graves:

1.Cuando la organización matriz asume varios proyectos, es común que cada uno tenga todo el personal.
Esto puede llevar a una considerable duplicación de esfuerzos en todas las áreas, desde el personal
administrativo hasta las unidades de apoyo tecnológico más sofisticadas (y costosas). Si un proyecto no
requiere un gerente de personal a tiempo completo, por ejemplo, debe tener uno porque los gerentes
de personal vienen en números enteros, no en fracciones, y el personal generalmente no se comparte
entre los proyectos.

2. De hecho, la necesidad de garantizar el acceso a los conocimientos y habilidades tecnológicos se traduce en una
Intento por parte del PM de almacenar equipo y asistencia técnica para asegurarse de que estará
disponible cuando sea necesario. Por lo tanto, el proyecto puede contratar personas con habilidades
técnicas críticas cuando estén disponibles en lugar de cuando se necesiten. Del mismo modo, tienden a
mantenerse en el proyecto más tiempo del necesario, "por si acaso". Las desventajas 1 y 2 se combinan
para hacer que esta forma de organizar proyectos sea muy costosa.

3. Sacar el proyecto del control técnico por parte de un departamento funcional tiene su ventaja
tages, pero también tiene una seria desventaja si el proyecto se caracteriza como "alta
tecnología". Aunque las personas que participan en proyectos desarrollan una profundidad
considerable en la tecnología del proyecto, tienden a quedarse atrás en otras áreas de su
experiencia técnica. La división funcional es un depósito de conocimientos técnicos y está bien
posicionada para avanzar en el estado de la técnica en la disciplina, pero no es fácilmente
accesible para los miembros del equipo del proyecto independiente.

4. Los equipos de proyectos proyectados parecen fomentar la inconsistencia en la forma en que las políticas
y se llevan a cabo los trámites. En el entorno relativamente protegido del proyecto, los
recortes administrativos son comunes y se justifican fácilmente como una respuesta al
cliente oa una exigencia técnica. “No comprenden nuestros problemas” se convierte en
una excusa fácil para ignorar los dictados de la sede.
5. En las organizaciones proyectizadas, el proyecto cobra vida propia. Miembros del equipo
Formen fuertes lazos con el proyecto y entre sí. Una enfermedad conocida comoPro-
jectitis se desarrolla. Crece una fuerte división de "nosotros-ellos", que distorsiona las relaciones entre
los miembros del equipo del proyecto y sus contrapartes en la organización matriz. La rivalidad
amistosa puede convertirse en una competencia encarnizada, y las luchas políticas internas entre
proyectos son comunes.
 Proyectos en una organización matricial153

6. Otro síntoma de proyectitis es la preocupación por "la vida después de que termine el proyecto".
Por lo general, existe una incertidumbre considerable sobre lo que sucederá cuando se complete
el proyecto. ¿Los miembros del equipo serán despedidos? ¿Serán asignados a trabajos de bajo
prestigio? ¿Sus habilidades técnicas estarán demasiado oxidadas para integrarse con éxito en
otros proyectos? ¿Se dividirá nuestro equipo ("esa vieja pandilla mía")?

5.3Proyectos en una organización matricial

En un intento de acoplar algunas de las ventajas del proyecto independiente en la organización
proyectada con algunas de las características deseables del proyecto funcional, y para evitar algunas
de las desventajas de cada uno, se desarrolló la organización del proyecto matricial. En efecto, las
organizaciones funcionales y proyectadas representan extremos. La organización matricial del
proyecto es una combinación ohíbrido de los dos. Es una organización de proyecto independiente
superpuesta a las divisiones funcionales de la empresa matriz.
Al ser una combinación de estructuras de organización independientes proyectadas y
funcionales, una organización matricial puede adoptar una amplia variedad de formas
específicas, dependiendo de cuál de los dos extremos (funcional o independiente) se parezca
más. La matriz “proyectada” o “fuerte” se parece más a la organización proyectada. La matriz
"funcional" o "débil" se parece más a la forma funcional de organización. Finalmente, la matriz
"equilibrada" se encuentra entre las otras dos. En la práctica, existe una variedad casi infinita de
formas organizativas entre los extremos, y la principal diferencia entre estas formas tiene que
ver con el poder relativo / autoridad de decisión del director del proyecto y el director funcional.
Debido a que es más simple de explicar, consideremos primero una matriz fuerte, una que sea
similar a un proyecto independiente. En lugar de ser una organización independiente, como el
proyecto independiente, el proyecto de matriz no está separado de la organización matriz. Considere
la Figura 5.3. Aunque no siempre es el caso, aquí el director de proyecto del Proyecto 1,
PM1, reporta a un gerente de programa que también supervisa otros dos proyectos que tienen
que ver con el mismo programa. El proyecto 1 le ha asignado tres personas del hombre.
división de fabricación, una persona y media de marketing, la mitad de una persona de
finanzas y personal, cuatro personas de I + D y quizás otras personas que no se muestran. Estas
personas provienen de sus respectivas divisiones funcionales y están asignadas al proyecto a
tiempo completo o parcial, según las necesidades del proyecto. Debe ser enfatizado
que el PM controla cuándo y qué harán estas personas, mientras que los gerentes funcionales
controlan quién será asignado al proyecto y cómo se realizará el trabajo, incluida la tecnología
utilizada.

presidente

Director del programa Fabricación Márketing Finanzas I+D Personal

PM1 3 1 1/2 1/2 4 1/2

PM2 1 4 1/4 1 1/2 1/4

PM3 0 1/2 3 1/2 1

FIGURA 5.3La organización matricial.

154CAPÍTULO 5 El proyecto en la estructura organizativa

Con una gran representación de la fabricación y la I + D, el Proyecto 1 podría implicar el diseño y

la instalación de un nuevo tipo de proceso de fabricación para un nuevo producto Alpha. El proyecto 2
podría involucrar la comercialización del nuevo producto. El proyecto 3 podría referirse a la
instalación de un nuevo sistema de control financiero para el nuevo producto. Mientras tanto, las
divisiones funcionales continúan con sus actividades de rutina.
No hay un solo ejecutivo a quien los PM generalmente reporten. Si un proyecto es
simplemente uno de varios en un programa específico, el PM generalmente informa a un
gerente de programa, si lo hay. Sin embargo, no es infrecuente que el PM informe al gerente
del área funcional que tiene un interés particular en el proyecto. Si se están llevando a cabo
varios proyectos sobre matemáticas para la Oficina de Investigación Naval (ONR), por ejemplo,
sería normal que los PM informaran al jefe de la sección de Ciencias Matemáticas de la ONR. En
firmas más pequeñas con pocos proyectos, es común que el PM dependa directamente de un
ejecutivo senior.
En el otro extremo del espectro de organizaciones matriciales se encuentra la matriz funcional o
débil. Un proyecto podría, por ejemplo, tener solo una persona a tiempo completo, el PM. En lugar de
tener un trabajador funcional individual realmente asignado al proyecto, los departamentos
funcionales dedicancapacidad al proyecto, y la tarea principal del PM es coordinar las actividades del
proyecto llevadas a cabo por los departamentos funcionales. Por ejemplo, el director de proyectos de
un proyecto creado para crear una nueva base de datos para el personal podría solicitar que el diseño
básico lo realice el grupo de tecnología de la información (TI) de la división administrativa. Luego, el
trabajo de personal se agregaría a la carga de trabajo normal del grupo de TI. La prioridad dada al
diseño puede ser asignada por la alta dirección o puede ser el resultado de negociaciones entre el PM
y el jefe del grupo de TI. En algunos casos, los cargos del grupo de TI por el trabajo también pueden
estar sujetos a negociación. La tarea incluso podría subcontratarse a un proveedor externo.

Entre estos extremos se encuentra la matriz equilibrada, que normalmente es cualquier cosa menos
equilibrada. Hay muchas mezclas diferentes de proyectos y responsabilidades funcionales. Cuando los
proyectos requieren con frecuencia el trabajo de un grupo funcional, es común operar el grupo como una
unidad funcional en lugar de transferir a su gente al proyecto. Por ejemplo, una unidad de toxicología en una
empresa de cosméticos, un grupo de garantía de calidad en una empresa de fabricación de varios productos
o un grupo de gráficos por computadora en una empresa editorial pueden estar organizados
funcionalmente y asumir el trabajo del proyecto de manera muy similar a los contratistas externos. Si bien el
control del PM sobre el trabajo se ve disminuido por este arreglo, el proyecto tiene acceso inmediato a
cualquier experiencia en el grupo, y el grupo puede mantener su integridad tecnológica.

Anteriormente hemos discutido la diferencia entre los individuos orientados a la disciplina y aquellos que están
orientados hacia los problemas, lo que indica que estos últimos son muy deseables como miembros de los equipos
de proyectos. Tanto de Laat (1994) como Kalu (1993) constituyen un testimonio adecuado del hecho de que los
miembros del equipo orientados a la disciplina tienden a convertirse en fervientes defensores de sus áreas
funcionales, a veces en detrimento del proyecto en su conjunto. Las luchas de poder resultantes pueden hacer
hincapié en las habilidades del PM en la reducción de conflictos.
El enfoque de proyecto matricial tiene sus propias ventajas y desventajas únicas. Sus puntos
fuertes son los siguientes:

1. El proyecto es el punto de énfasis. Un individuo, el PM, asume la responsabilidad

para gestionar el proyecto, para llevarlo a cabo a tiempo, dentro del costo y según las especificaciones
(alcance). La organización matricial comparte esta virtud con la organización del proyecto
independiente.

2. Debido a que la organización del proyecto se superpone a las divisiones funcionales, temporalmente
extrayendo mano de obra y talento de ellos, el proyecto tiene un acceso razonable a todo el depósito de
tecnología en todas las divisiones funcionales. Cuando hay varios proyectos, los talentos de las
divisiones funcionales están disponibles para todos los proyectos, lo que reduce drásticamente la
duplicación requerida por la estructura del proyecto independiente.
 Proyectos en una organización matricial155

3. Hay menos ansiedad sobre lo que sucede cuando se completa el proyecto de lo que es típico.
de la organización del proyecto independiente. Aunque los miembros del equipo tienden a desarrollar
un fuerte apego por el proyecto, también se sienten cerca de su “hogar” funcional.

4. La respuesta a las necesidades del cliente es tan rápida como en el caso del proyecto independiente, y la organización matricial

La nización es igual de flexible. De manera similar, la organización matricial responde de manera flexible y
rápida a las demandas de quienes están dentro de la organización matriz. Un proyecto anidado dentro de una
empresa operativa debe adaptarse a las necesidades de la empresa matriz o el proyecto no sobrevivirá.

5.Con la gestión matricial, el proyecto tendrá —o tendrá acceso a— representantes de las unidades
administrativas de la empresa matriz. Como resultado, se tiende a preservar la coherencia con
las políticas, prácticas y procedimientos de la empresa matriz. Por lo menos, esta coherencia con
los procedimientos de la empresa matriz tiende a fomentar la credibilidad del proyecto en la
administración de la organización matriz, una condición que comúnmente se infravalora.

6.Cuando hay varios proyectos en marcha simultáneamente, la organización matricial permite un

mejor equilibrio de recursos en toda la empresa para lograr los diferentes objetivos de tiempo /
costo / alcance de los proyectos individuales. Este enfoque holístico de las necesidades totales de
la organización permite que los proyectos cuenten con personal y se programen para optimizar
el rendimiento total del sistema en lugar de lograr los objetivos de un proyecto a expensas de
otros.

7.Si bien los proyectos independientes y los proyectos organizados funcionalmente representan los
extremos del espectro organizacional, las organizaciones matriciales cubren una amplia gama
intermedia. Hemos diferenciado entre matrices fuertes y débiles en términos de si las unidades
funcionales suministraron individuos o capacidad a los proyectos. Evidentemente, algunas unidades
funcionales pueden proporcionar a las personas y otras solo pueden proporcionar capacidad. Por lo
tanto, existe una gran flexibilidad en la forma precisa en que se organiza el proyecto, todo dentro de la
estructura matricial básica, de modo que pueda adaptarse a una amplia variedad de proyectos y
siempre esté sujeto a las necesidades, habilidades y deseos de la organización matriz.

Las ventajas derivadas de la estructura de la matriz son potentes, pero las desventajas también
son graves. Todas las siguientes desventajas implican conflictos, entre los gerentes funcionales y de
proyecto en su mayor parte.

1. En el caso de proyectos organizados funcionalmente, no hay duda de que la divi funcional

sion es el foco del poder de toma de decisiones. En el caso del proyecto independiente, está claro que el
PM es el centro de poder del proyecto. Con las organizaciones matriciales, el poder está más
equilibrado. A menudo, el equilibrio es bastante delicado. Cuando existe la duda sobre quién está a
cargo, el trabajo del proyecto se resiente. Si el proyecto tiene éxito y es muy visible, la duda sobre quién
está a cargo puede fomentar las luchas políticas internas por el crédito y la gloria. Si el proyecto fracasa,
las luchas políticas internas serán aún más brutales para evitar culpas.

2.Si bien la capacidad de equilibrar el tiempo, el costo y el alcance entre varios proyectos es una ventaja de las
organizaciones matriciales, esa capacidad tiene su lado oscuro. El conjunto de proyectos debe ser
cuidadosamente monitoreado como un conjunto, un trabajo duro. Además, el movimiento de recursos de un
proyecto a otro con el fin de satisfacer los diversos programas puede fomentar las luchas políticas internas
entre los varios PM, todos los cuales tienden a estar más interesados en asegurar el éxito de sus proyectos
individuales que en ayudar al sistema total a optimizar la organización. metas amplias.

3. Para matrices fuertes, los problemas asociados con el cierre de un proyecto son casi tan
severos como los de organizaciones de proyectos independientes. Los proyectos, al tener identidades individuales, resisten la

muerte. Incluso en organizaciones matrices, la proyectitis sigue siendo una enfermedad grave.

4. En los proyectos organizados por Inmatrix, el PM controla las decisiones administrativas y

los jefes controlan las decisiones tecnológicas. La distinción es bastante simple cuando se
escribe sobre gestión de proyectos, pero para el PM operativo, la división de autoridad y
responsabilidad inherente a la gestión matricial es compleja. La capacidad del PM para negociar
156CAPÍTULO 5 El proyecto en la estructura organizativa

TABLA 5.1Características del proyecto y inicio del proyecto

Proyecto Inicio

Organización matricial
Proyecto Funcional
Caracteristicas Organización Débil Equilibrado Fuerte Proyectado

Autoridad de PM Poco a nada Bajo Bajo a Moderado a Alto a

Moderar Elevado Completo

Disponibilidad de Poco a nada Bajo Bajo a Moderado a Alto a

Recursos Moderar Elevado Completo

Propiedad de Funcional Funcional Compartido PM PM

Presupuesto del proyecto Gerente Gerente

Papel del PM Tiempo parcial Tiempo parcial Tiempo completo Tiempo completo Tiempo completo

Proyecto administrativo Tiempo parcial Tiempo parcial Tiempo parcial Tiempo completo Tiempo completo

Personal

(Adaptado de la Tabla 2-1, PMI PMBOK 5ª edición, pág. 22.)

cualquier cosa, desde los recursos hasta la asistencia técnica y las fechas de entrega, es un factor clave para el
PMBOK
éxito del proyecto. El éxito es dudoso para un PM sin fuertes habilidades de negociación.

5.La gestión matricial viola el principio de gestión de la unidad de mando. Los trabajadores
del proyecto tienen al menos dos jefes, sus jefes funcionales y el PM. No hay forma de
evitar las lealtades divididas y la confusión que resulta. Cualquiera que haya trabajado bajo
tal arreglo comprende las dificultades. Quienes no lo han hecho no pueden apreciar las
molestias que causa. Parafraseando el comentario de Platón sobre la democracia, la
gestión matricial "es una forma encantadora de gestión, llena de variedad y desorden".

La gestión matricial moderna hoy se esfuerza por lograr muchos más

objetivos que cuando se adoptó hace décadas. Por ejemplo, IBM está
organizado como una matriz multidimensional (Grant, 2008). Existe una
organización "empresarial" (estructurada en torno a hardware, software y
servicios), una orientación "geográfica" (regiones / países), un hogar "funcional",
agrupaciones de "clientes", especialidades de "canal de distribución" y "nuevos
negocios" desarrollo ”impulsa. Si la antigua forma de gestión matricial era
confusa, la nueva forma puede resultar abrumadora. Pero las organizaciones
modernas descubren que tienen muchas más metas que alcanzar y deben ser
múltiples, logrando una integración organizacional más compleja pero sin
obstaculizar su flexibilidad, capacidad de respuesta y desempeño.

La Tabla 5.1 contrasta y resume las características clave de los proyectos en organizaciones
funcionales, proyectadas y matriciales.

Proyectos virtuales

Los proyectos virtuales son aquellos en los que el trabajo en el equipo del proyecto cruza fronteras temporales, espaciales, organizativas o

culturales. Por lo tanto, un equipo virtual puede trabajar en diferentes zonas horarias, estar geográficamente disperso, trabajar en

diferentes organizaciones o trabajar en diferentes culturas. En todos los casos, el auge de los proyectos virtuales se ha visto facilitado por

el uso de Internet y otras tecnologías de la comunicación. En muchos de estos casos, el equipo del proyecto suele estar organizado
 Proyectos en una organización matricial157

en algún tipo de estructura matricial en lugar de una forma de proyecto funcional o independiente. Kalu
(1993, p. 175) define con más detalleposiciones virtuales como "procesos de tareas, cuyo desempeño
requiere una membresía compuesta" tanto en el proyecto como en las organizaciones funcionales. Cuando
las organizaciones complejas llevan a cabo proyectos, los puestos virtuales son típicos porque los proyectos
generalmente requieren la participación de varios departamentos funcionales. Esto crea una responsabilidad
compartida y superpuesta para el trabajo con los gerentes funcionales y los PM que comparten la
responsabilidad de la ejecución del proyecto.
Gratton (2007) también ofrece algunas reglas para el éxito cuando las organizaciones descubren que deben
utilizar equipos virtuales dispersos geográficamente para algunos de sus proyectos.

• Utilice equipos virtuales solo para proyectos que sean desafiantes e interesantes. Pero también asegúrese de
que el proyecto sea significativo tanto para la empresa como para el equipo.

• Solicite voluntarios tanto como sea posible; estarán más entusiasmados y dedicados
al éxito del proyecto.
• Incluya algunos miembros en el equipo que ya se conozcan, y asegúrese de que uno de cada
seis o siete sean "traspasadores de fronteras" con muchos contactos externos.

• Cree un recurso en línea para que los miembros del equipo se conozcan entre sí (especialmente
cómo prefieren trabajar), colaboren, intercambien ideas y se inspiren.

• Fomente la comunicación frecuente, pero no las reuniones sociales (que ocurrirán en momentos más
naturales de todos modos).

• Divida el trabajo del proyecto en módulos geográficamente independientes tanto como sea posible para que el
progreso en una ubicación no se vea obstaculizado por retrasos en otras ubicaciones.

Gestión de proyectos en la práctica

La empresa de software Yunio evita
tecnologías complejas
Chris Mathews, cofundador y director ejecutivo de Yunio,
fabricante de software de nueva creación con sede en China, evita
los dispositivos engorrosos y las interfaces complejas para
gestionar sus equipos de proyectos globales. Prefiere técnicas y
tecnologías que parezcan naturales y cómodas para los equipos
virtuales. Su enfoque es la comunicación clara,
independientemente de la tecnología utilizada. Y cuando un
mensaje puede enviarse con el ejemplo, lo prefiere a otras formas
de comunicación menos efectivas. Por ejemplo, cuando trabajaba
con sus equipos chinos, descubrió que no era la norma que los
miembros del equipo informaran a sus colegas cuándo estarían
ausentes o cómo comunicarse con ellos. Para dar ejemplo,
comenzó a enviar mensajes de correo electrónico a los miembros
del equipo cada vez que no podía asistir a una reunión. Para
equipos o grupos individuales, crea listas de correo distintas y
separadas. Como su ejemplo fue adoptado por los equipos,
wiki para equipos de más de 15 personas porque es una gran inversión que
requiere la participación de una comunidad en línea de usuarios para crear
contenido. Los wikis se vuelven cada vez más eficientes, especialmente para
la gestión del conocimiento, a medida que crece el equipo. Para menos de 15
personas, prefiere los chats grupales, pero complementados con registros
de chat. Los mensajes instantáneos no requieren respuestas instantáneas,
por lo que permiten a los miembros del equipo enviar una nota rápida a
alguien sin requerir una respuesta. Dado que sus trabajadores usan la
mensajería instantánea de todos modos, es una herramienta de
comunicación natural para los chats. Mathews cree que el uso de productos
tecnológicos no define cómo administrar equipos virtuales, sino que son
solo parte del conjunto de herramientas; La gestión inteligente consiste en
elegir la herramienta más adecuada para comunicarse con claridad.
Preguntas
1. ¿La gestión de equipos virtuales requiere más atención a la
tecnología de la comunicación?
2. ¿La comunicación con el ejemplo funcionaría para los gerentes de
proyectos no virtuales?

3. ¿Cuáles son las compensaciones que los gerentes de proyectos

Aunque Mathews usa el correo electrónico para asuntos
deben considerar al intentar seleccionar el medio de
importantes en los que es deseable un registro escrito, encuentra que
comunicación más efectivo?
otras tecnologías pueden ser más apropiadas para otros usos. Para
mantener la comunicación lo más simple y fluida posible, solo usa Fuente: MS Zoninsein, "Less Is More", PM Network, Vol. 24.
158CAPÍTULO 5 El proyecto en la estructura organizativa

5.4 Proyectos en estructuras organizativas

compuestas
Las complejidades del mundo real rara vez llevan a las empresas a organizar sus proyectos en cualquiera de
las formas "puras" anteriores, por lo que lo que tendemos a ver en la práctica es una combinación de dos o
tres o más formas diferentes. En una organización funcional, puede haber divisiones de proyectos junto con
marketing y finanzas, o en una división matricial puede haber un proyecto de personal que informe al
director general (o tesorero, o ...), y así sucesivamente. Llamamos a estas estructuras "compuestas".
Por ejemplo, la organización por territorio es especialmente atractiva para las
organizaciones nacionales cuyas actividades están esparcidas física o geográficamente y donde
los productos tienen alguna singularidad geográfica, como las prendas de mujer. Por lo tanto,
es posible que tengamos proyectos como diseños de moda de primavera que se ejecutan
dentro de cada territorio. Pero suponga que cada territorio también vende a diferentes tipos de
clientes, como minoristas, mayoristas y consumidores; o quizás civiles y militares. La
organización de proyectos dentro de las divisiones de clientes se encuentra típicamente cuando
los proyectos reflejan un interés primordial en las necesidades de diferentes tipos de clientes.
Luego, también podríamos tener proyectos matriciales que cruzan los diversos territorios y se
centran en las preferencias del cliente, o proyectados si se trata de un solo proyecto,
Si en una empresa coexisten divisiones funcionales y proyectadas, esto resultaría en la forma compuesta que se
muestra en la Figura 5.4. Esta forma rara vez se observa durante un período prolongado. Lo que se hace, en cambio,
es escindir los proyectos grandes, exitosos y de largo plazo como subsidiarias u operaciones independientes. Muchas
empresas fomentan proyectos jóvenes, inestables y más pequeños bajo el ala de una división existente, luego los
destetan a proyectos independientes con su propia identidad, como en la Figura 5.4, y finalmente permiten la
formación de una división.equipo de riesgo—O, para un proyecto más grande,
empresa de riesgo—Dentro de la empresa matriz. Por ejemplo, Texas Instruments hizo esto
con Speak and Spell® juguete que fue desarrollado por uno de sus empleados, y 3M hizo esto
con su Post-It®Notas.
La forma compuesta conduce a la flexibilidad. Permite a la empresa resolver problemas especiales
mediante la adaptación adecuada de su estructura organizativa. Sin embargo, existen distintos peligros
involucrados en el uso de la estructura compuesta. Las agrupaciones disímiles dentro del mismo centro de
rendición de cuentas tienden a fomentar la superposición, la duplicación y la fricción debido a la
incompatibilidad de intereses. Nuevamente, tenemos las condiciones que tienden a resultar en conflictos
entre los gerentes funcionales y de proyecto.
La figura 5.5 ilustra otra solución común al problema de cómo organizar un proyecto. La
empresa establece lo que parece ser una forma estándar de organización funcional, pero agrega una
oficina de personal para administrar todos los proyectos. Esto libera a los grupos funcionales de
problemas administrativos mientras utiliza sus talentos técnicos. En una gran empresa química
especializada, esta forma organizativa funcionó tan bien que la oficina de personal se convirtió en el
núcleo de una división a gran escala de la empresa cuyo único propósito era administrar proyectos.
Mucho se ha escrito sobre el uso de una “oficina de gestión de proyectos”, que, como se señaló en
capítulos anteriores y se muestra en la Figura 5.5, es una estructura equivalente; se hablará más
sobre la PMO en la Sección 5.6.

presidente

Proyecto Proyecto
Finanzas Ingenieria Fabricación
METRO Z

FIGURA 5.4Una organización compuesta funcional / proyectada.

 Seleccionar un formulario de proyecto159

Para proyectos individuales, esta es básicamente la organización funcional presidente

descrita anteriormente, pero si se usa para múltiples proyectos, y
PMO
particularmente si se usa una PMO, esta organización es similar a la forma
matricial. La principal diferencia es que este formulario se utilizaría normalmente
para proyectos pequeños a corto plazo en los que no se justifica la formación de
un sistema matricial completo. Esta forma mixta comparte varias ventajas y
desventajas de la estructura de la matriz, pero la vida del proyecto suele ser tan Finanzas Fabricación Ingenieria

corta que la enfermedad de la proyectitis rara vez se contrae. Si aumenta el

número o el tamaño de los proyectos que cuentan con personal de esta manera,
naturalmente se produce un cambio a una organización matricial formal.
Aunque las formas de interconectar el proyecto y la organización matriz
son muchas y variadas, la mayoría de las empresas finalmente adoptan la forma
matricial como método básico para albergar su creciente número de proyectos. FIGURA 5.5Una organización funcional / de personal.

A esta base, ocasionalmente independiente, funcional y profesional compuesto

Se pueden agregar proyectos si estos poseen ventajas especiales; de lo contrario, se agregarán a la
matriz debido al costo relativamente bajo de administrarlos y su mayor capacidad para obtener
acceso a un amplio soporte técnico.

5.5Seleccionar un formulario de proyecto

La elección de cómo organizar un proyecto no está dirigida a los PM o aspirantes a PM. Está dirigido a la alta
dirección. Muy rara vez el PM tiene la opción de elegir la forma en que el proyecto interactúa con la
organización matriz. De hecho, rara vez se le pide al PM que participe en la elección de la interfaz. Incluso a
los practicantes experimentados les resulta difícil explicar cómo se debe proceder al intentar elegir. La
elección está determinada por la situación, pero aun así es en parte intuitiva. Hay pocos principios de diseño
aceptados y ningún procedimiento paso a paso que brinde instrucciones detalladas para determinar qué tipo
de estructura se necesita y cómo se puede construir. Todo lo que podemos hacer es considerar la naturaleza
del proyecto potencial, las características de las distintas opciones organizativas, las ventajas y desventajas
de cada una,

En general, la forma funcional tiende a ser la forma organizativa de elección para proyectos en
los que el enfoque principal debe estar en la aplicación en profundidad de una tecnología. Además, la
forma funcional se prefiere para proyectos que requerirán grandes inversiones de capital en equipos
o edificios de un tipo que normalmente utiliza la función.
Si la empresa participa en un gran número de proyectos similares (por ejemplo, proyectos de
construcción), se prefiere la forma de organización proyectada. Por lo general, el mismo formulario se usaría
para tareas únicas, altamente específicas y puntuales que requieren un control cuidadoso y no son
apropiadas para una sola área funcional, por ejemplo, el desarrollo de una nueva línea de productos. Un
problema que suelen afrontar las organizaciones proyectizadas es cómo resolver las tensiones entre la
flexibilidad y el control. La investigación sobre empresas proyectadas (Gann et al., 2012) indica que estas
empresas tienden a desarrollar “baronías” suborganizacionales de tres tipos: dominios, federaciones
estrechas o federaciones flexibles. Cada uno de estos ofrece competencias importantes para la empresa,
pero también presenta desafíos especiales de gestión y liderazgo.
Cuando el proyecto requiere la integración de insumos de varias áreas funcionales e involucra
tecnología razonablemente sofisticada, pero no requiere que todos los especialistas técnicos trabajen
para el proyecto a tiempo completo, la organización matricial es la única solución satisfactoria. Esto es
particularmente cierto cuando varios de estos proyectos deben compartir expertos técnicos. Otro
caso especial es cuando se crean proyectos para cambiar la forma en que la organización matriz se
organiza o se comunica internamente. Por lo general, estos proyectos requieren la representación de
todas las partes principales de la matriz para tener éxito. Las organizaciones matriciales son
complejas y presentan un desafío difícil para el PM, pero a veces son necesarias.
160CAPÍTULO 5 El proyecto en la estructura organizativa

Si existe la elección de la estructura del proyecto, el primer problema es determinar el tipo de trabajo que debe realizarse. Para hacer esto, se

requiere un plan de proyecto tentativo inicial (un tema que se trata en detalle en la Sección 6.1). Primero, identifique los entregables principales del

proyecto. A continuación, enumere las principales tareas asociadas con cada entregable. Para cada tarea, determine la unidad funcional que

probablemente será responsable de realizar la tarea. Estos son los elementos que deben estar involucrados para llevar a cabo el proyecto. El problema

es cómo reunirlos mejor o cómo integrar mejor su trabajo. Otros asuntos a considerar son los individuos (o pequeños grupos) que harán el trabajo, sus

personalidades, la tecnología que se empleará, los clientes a los que se atenderá, las relaciones políticas de las unidades funcionales involucradas, y la

cultura de la organización matriz. También deben tenerse en cuenta los factores ambientales dentro y fuera de la organización matriz. Al comprender las

diversas estructuras, sus ventajas y desventajas, una empresa puede seleccionar la estructura organizativa que parezca ofrecer la opción más eficaz y

eficiente. Investigaciones recientes (Lechler et al., 2010) indican que las formas de organización de proyectos sí impactan en el éxito del proyecto y que

cuanta más autoridad y responsabilidad tenga el PM, es más probable que el proyecto sea un éxito; por lo tanto, el uso de gerentes funcionales como

PM aumentará las posibilidades de éxito. una empresa puede seleccionar la estructura organizativa que parezca ofrecer la opción más eficaz y eficiente.

Investigaciones recientes (Lechler et al., 2010) indican que las formas de organización de proyectos sí impactan en el éxito del proyecto y que cuanta más

autoridad y responsabilidad tenga el PM, más probabilidades habrá de que el proyecto sea un éxito; por lo tanto, el uso de gerentes funcionales como

PM aumentará las posibilidades de éxito. una empresa puede seleccionar la estructura organizativa que parezca ofrecer la opción más eficaz y eficiente.

Investigaciones recientes (Lechler et al., 2010) indican que las formas de organización de proyectos sí impactan en el éxito del proyecto y que cuanta más

autoridad y responsabilidad tenga el PM, es más probable que el proyecto sea un éxito; por lo tanto, el uso de gerentes funcionales como PM aumentará

las posibilidades de éxito.

Ilustramos el proceso con un ejemplo en el cuadro de Trinatronic, Inc. utilizando el

siguiente procedimiento.

1. Definir el proyecto con una declaración de los objetivos que identifican los principales
viene deseado.
2. Determine las tareas clave asociadas con cada objetivo y ubique las unidades en el par.
organización entrante que sirven como “hogares” funcionales para este tipo de tareas.

3. Organice las tareas clave por secuencia y descompóngalas en paquetes de trabajo.

4. Determinar qué unidades organizativas se requieren para llevar a cabo los paquetes de trabajo y
qué unidades trabajarán particularmente de cerca con cuáles otras.

5. Enumere todas las características especiales o suposiciones asociadas con el proyecto, por ejemplo,
nivel de tecnología necesaria, duración probable y tamaño del proyecto, cualquier problema
potencial con las personas que puedan ser asignadas al trabajo, posibles problemas políticos
entre las diferentes funciones involucradas y cualquier otra cosa que parezca relevante, incluidas
las experiencias previas de la empresa matriz con diferentes formas de organizar proyectos.

6. A la luz de lo anterior, y con pleno conocimiento de los pros y los contras asociados con
cada forma estructural, elija una estructura.

5,6 La Oficina de Gestión de Proyectos

Hasta ahora en este capítulo se ha asumido tácitamente que, independientemente de cómo se haya
organizado el proyecto, tiene o tiene acceso a suficientes habilidades, conocimientos y recursos para realizar
cualquier actividad que pueda ser necesaria. Como veremos, esta suposición no siempre es cierta. Una tarea
primordial del PM es adquirir los recursos, las habilidades técnicas, el conocimiento y todo lo que necesite el
proyecto. Si bien esto puede ser difícil, la adquisición de los recursos técnicos del proyecto depende
principalmente de la habilidad del PM en la negociación como se describe en el Capítulo 4 y la relación con el
patrocinador del proyecto.
Incluso si el PM tiene todos los recursos necesarios, persisten dos problemas. En primer lugar, en toda
la historia de los proyectos desde el principio de los tiempos hasta pasado mañana, ningún proyecto se ha
completado exactamente como se planeó. La incertidumbre es una forma de vida para los PM y sus
proyectos. En segundo lugar, la ejecución exitosa de un proyecto es una tarea administrativa compleja y
requiere el uso de herramientas de planificación, presupuestación, programación y control con

Gestión de proyectos en la práctica
Trinatronic, Inc.
Objetivo del proyecto: diseñar, construir y comercializar una computadora
portátil que utilice estándares abiertos siempre que sea posible y que sea
capaz de ejecutar todos los paquetes de software de producción de oficina y
diseño de ingeniería actuales. Para satisfacer las consideraciones de
seguridad y confidencialidad, la computadora debe poder mantener
múltiples versiones de su información operativa sin necesidad de usar
almacenamiento fuera de línea.
Tareas clave
A. Escriba las especificaciones.
B. Diseñar hardware, realizar pruebas iniciales.
C. Ingeniero de hardware para producción.
D. Configurar la línea de producción.
E. Fabricar series pequeñas, realizar pruebas de calidad y confiabilidad.
F. Escribir (o adoptar) sistemas operativos.
G. Pruebe los sistemas operativos.
H. Escriba (o adopte) software de aplicaciones.
I. Prueba de software de aplicaciones.
J. Preparar todos los manuales de usuario, reparación y documentación.
K. Configurar el sistema de servicio con manuales y repuestos.
L. Preparar el programa de marketing.
M. Preparar demostraciones de marketing.
Sin intentar generar una secuencia específica para estas
tareas, observamos que parecen pertenecer a siete
categorías de trabajo.
1. Desarrollar y priorizar requisitos.
2. Diseñar, construir y probar hardware.
3. Diseñe, escriba y pruebe software.
4. Configurar sistemas de producción y servicio / reparación con repuestos
y manuales.
5. Prepare e implemente un análisis de fabricación o compra.
6. Desarrolle un plan de lanzamiento.
7. Esfuerzo de marketing de diseño, con demostraciones, hermano
chures y manuales.
Según este análisis, parecería que el proyecto
necesitará los siguientes elementos:
• Grupos para diseñar el hardware y el software.
• Grupos para probar el hardware y escribir y probar el
software.
La Oficina de Gestión de Proyectos161
Además, la computadora debe ser compatible con las capacidades de
videoconferencia y audio, y debe ser compatible con el mercado común
europeo y los estándares “ecológicos” de EE. UU. Para el uso de energía. El
precio deseado para esta computadora debería estar un 10 por ciento por
debajo de lo que sospechamos que podrían ofrecer los competidores.
Unidades organizativas
Mktg. Div. e I + DR +
D
Eng. Dpto., Mfg. Div.
Eng. Dpto., Mfg. Div.
Mfg. Div. y Depto. de QA, Exec. VP personal
Software Prod. Div.
Departamento de QA, Exec. VP
personal Software Prod. Div.
Departamento de QA, Exec. VP personal
Tech. Sección de Redacción (Div. Ing.) Y Tech. Sección de escritura
(Div. De producción de software)
Tech. Sección de Redacción (Div. Ing.) Y Tech.
Mktg. Div.
Mktg. Div.
• Un grupo para diseñar el sistema de producción del
hardware.
• Un grupo para diseñar el programa de marketing.
• Un grupo para preparar todos los documentos y manuales
apropiados.
• Y, no lo olvidemos, un grupo para administrar todos los grupos
anteriores.
Estos subsistemas representan al menos tres divisiones
principales y quizás media docena de departamentos en la
organización matriz. Los grupos que diseñan el hardware y los
múltiples sistemas operativos deberán trabajar en estrecha
colaboración. Los grupos de prueba pueden trabajar de forma
bastante independiente de los diseñadores de hardware y software,
pero los resultados mejoran cuando cooperan.
Trinatronics cuenta con personas capaces de realizar el proyecto.
El diseño del hardware y los sistemas operativos es posible en el
estado actual de la técnica, pero diseñar tales sistemas a un costo de
10% por debajo de los competidores potenciales requerirá un avance
en el estado de la técnica. Se estima que el proyecto
162CAPÍTULO 5 El proyecto en la estructura organizativa

tomar entre 18 y 24 meses, y ser el proyecto más caro
hasta ahora realizado por Trinatronics.
Con base en la información esquemática anterior, parece claro que
una organización de proyecto funcional no sería apropiada. Se requiere
demasiada interacción entre las divisiones principales para convertir una
sola función en un hogar organizacional cómodo para todos. Es factible un
proyecto independiente o una estructura matricial y, dada la opción, parece
sensato elegir la organización de proyecto independiente más simple si el
costo de personal adicional no es demasiado alto. Tenga en cuenta que si el
proyecto hubiera requerido solo la participación a tiempo parcial de
profesionales científicos altamente calificados, la organización matricial
podría haber sido preferible. También una
La estructura matricial probablemente se habría elegido si este proyecto
fuera solo uno de varios proyectos de este tipo que se basaban en una base
de personal común.
Preguntas
1. Considere la aplicabilidad de una estructura matricial
“débil” para este proyecto. ¿Cuáles serían los pros y los
contras de este enfoque?
2. Considere la aplicabilidad de una matriz "fuerte" o una
estructura "equilibrada". ¿Cuáles serían los pros y los
contras aquí?
Fuente: SJ Mantel, III. Proyecto de consultoría.

que el neófito PM puede no estar completamente familiarizado. Además, existen obligaciones

contractuales, administrativas y de presentación de informes que deben realizarse de acuerdo con la
ley, los deseos del financiador o propietario del proyecto y las reglas de la organización de origen del
proyecto.
Lidiar con las incertidumbres se conoce como gestión de riesgos, y además
La gestión de las compensaciones es una de las funciones principales del PM. Introdujimos el tema en el Capítulo 2
cuando se discutieron las incertidumbres de la selección de proyectos. Para hacer frente a la incertidumbre, la
organización matriz debe crear algún mecanismo para gestionarla, un tema que se trata en detalle en el Capítulo 6.
Con el fin de abordar las cuestiones de gestión y administración de todos sus proyectos, y de una manera que cumpla
con los requisitos de la organización matriz. reglas, muchas empresas han creado unPMO (Oficina de Gestión de
Proyectos). Liu y col. (2007) han demostrado que las PMO tienen un impacto significativamente positivo en los
proyectos que operan con una alta incertidumbre en las tareas. En un PMI reciente
(2011), se encontró que tres de cada cinco organizaciones de encuestados tienen PMO. La
PMBOK PMO y sus responsabilidades se detallan en el capítulo introductorio dePMBOK®.
Con el papel cada vez más importante de los proyectos en las organizaciones actuales y el movimiento
1.4.4 hacia la “gestión por proyectos”, ha surgido la necesidad de una entidad organizativa que ayude a gestionar
estas formas de hacer el trabajo que se multiplican rápidamente. Este es el papel de la PMO. Según
Greengard (2013), casi 7 de cada 10 organizaciones tienen una PMO, aunque tienen nombres diferentes. La
más popular es la PMO (Unidad de organización); la siguiente más común con un poco menos de la mitad es
la Oficina de Apoyo a Proyectos; la siguiente es la PMO empresarial; luego, a poco más de un tercio está el
Centro de Excelencia; luego la PMO específica del proyecto; y por último en aproximadamente uno de cada
seis es la Oficina de Gestión del Cambio.
¿Cómo sabe una organización si necesita una PMO? Greengard afirma que si la organización está proyectada,
necesita una PMO. De lo contrario, ¿cómo saben quién está impulsando la entrega de sus proyectos, quién está
estableciendo su metodología, quién está administrando los recursos de manera eficiente? Cualquier organización
que haga más de un puñado de proyectos debería tener una PMO. Algunas señales son: falta de transparencia del
proyecto, discrepancias significativas en los resultados del proyecto, índices de satisfacción de los financiadores
deficientes, incapacidad para calcular el costo de los proyectos con precisión, un alto porcentaje de proyectos
retrasados o cancelados, la existencia de proyectos sin un propietario claro, falta de visibilidad. sobre cómo se están
desempeñando los proyectos y las altas tasas de fracaso de los proyectos. Además, se puede realizar una evaluación
de la madurez de la gestión de proyectos para comparar las métricas internas y los indicadores clave de rendimiento
con los promedios de la industria.
También hay una variedad de formas de PMO para satisfacer una variedad de necesidades. Algunos de
estos se encuentran en un nivel bajo en la organización y otros reportan a los niveles más altos. Las mejores
PMO (Baker, 2007) tienen algunas características en común, sin embargo, entre ellas las de ser manejadas
como las mejores empresas (un plan de negocios, enfocado, énfasis en resultados), disfrutar
 La Oficina de Gestión de Proyectos163

fuerte apoyo ejecutivo, siendo organizaciones de aprendizaje orientadas al futuro y ofreciendo el

mejor liderazgo de proyectos en la organización.
Los resultados recientes de una sesión de trabajo de investigación del Project Management
Institute (2013a) también encontraron que otras características comunes de las PMO
contemporáneas es que son centros de excelencia que agregan valor al facilitar la toma de decisiones
y la gestión del cambio; establecer procesos, estándares y procedimientos de mejores prácticas; y
alinear los proyectos con la estrategia organizacional. Además, en contraste con la especificidad de la
gestión de proyectos, las PMO deben ser abiertas y estar adaptadas a las necesidades de la
organización específica en función de su cultura y estrategia, ya sea que adopten la gestión de
proyectos o no, y su grado de apoyo ejecutivo para una organización. PMO.
PMI (2013b) también lanzó una Thought Leadership Series para abordar los problemas de
demostrar el valor de las PMO, cómo se las ve en el mundo empresarial, qué implica una PMO, qué
diferentes tipos de PMO existen y qué hacen. El resultado fueron cinco informes: "Por qué fracasan
las buenas estrategias: lecciones para el C ‐ Suite", "Las PMO estratégicas juegan un papel vital en
impulsar los resultados comerciales", "El impacto de las PMO en la implementación de estrategias",
"Marcos de PMO" y " Gestión de iniciativas estratégicas: el imperativo de la PMO ".

Propósitos de la Oficina de Gestión de Proyectos

Antes de discutir el propósito y los servicios ofrecidos por las PMO, considere las siguientes
estadísticas informadas por Block et al. (2001). Cuando se les preguntó por las razones para iniciar
una PMO, casi dos tercios de los encuestados indicaron la necesidad de establecer estándares y
métodos de gestión de proyectos consistentes y que la PMO fue iniciada por la dirección de la alta
dirección. Aproximadamente la mitad de los encuestados también indicaron la necesidad de eliminar
las demoras en los proyectos y corregir la planificación deficiente del proyecto. Un poco menos del 40
por ciento quería mejorar el rendimiento del proyecto y eliminar los sobrecostos. Por último,
aproximadamente una cuarta parte de los encuestados indicó que deseaba reducir la insatisfacción
de los clientes. La encuesta de PMI de 2011 mencionada anteriormente encontró que tener una PMO
era una práctica clave para mejorar el desempeño del proyecto, y sus roles ahora comúnmente
incluyen administración de cartera, administración de programas,
Una de las principales contribuciones de las PMO es establecer procedimientos de
administración de proyectos para seleccionar, planificar, presupuestar y programar proyectos, así
como servir como repositorio de informes sobre el desempeño de los procesos de planificación,
presupuestación, programación y asignación de recursos. Los archivos de PMO también suelen
contener informes sobre gestión de riesgos, auditorías de proyectos, evaluaciones e historiales. Como
se refleja en las razones para iniciar las PMO en primer lugar, el 78 por ciento de los encuestados de
Block et al. (2001) indicaron que su PMO estableció y mantuvo procesos de proyectos estándar
(prácticas y procedimientos), el 64 por ciento ofreció ayuda de consultoría en proyectos y el 58 por
ciento ofreció servicios de capacitación y tutoría. Aproximadamente la mitad realizó el seguimiento de
proyectos y un poco menos realizó la gestión de cartera.
Aunque se pueden articular metas específicas para la PMO, un propósito
principal (Block, 1998; Bolles, 1998) es inculcar buenas prácticas de gestión de
proyectos en toda la organización, lo que se conoce como su función de “apoyo”.
Otro propósito importante, conocido como su función de "control", es garantizar que
la cartera de proyectos de la empresa respalde las metas y la estrategia generales de
la organización, como se describe en el Capítulo 2. En este caso, la PMO es el vínculo
crítico entre la gestión estratégica y el proyecto. gerentes. En los casos en que la
PMO ha asumido la responsabilidad de proyectos en toda la organización, la PMO a
menudo se renombra como Oficina de Gestión de Proyectos Empresariales (EPMO),
o se le da un nombre similar. Mihalic (2013) afirma que los ejecutivos en estos días
están buscando EPMO para fusionar la integración estratégica con la ejecución
táctica para lograr un mayor éxito del proyecto.
164CAPÍTULO 5 El proyecto en la estructura organizativa

Gestión de proyectos en la práctica

El éxito de una oficina de gestión de proyectos para la
administración de seguridad en el transporte
La Administración de Seguridad en el Transporte (TSA) tenía solo 3
meses y $ 20 millones para construir un centro de coordinación de
13,500 pies cuadrados, que involucraba la coordinación de hasta 300
comerciantes que trabajaban simultáneamente en varios aspectos del
centro. Una PMO sólida fue crucial para que el esfuerzo fuera un éxito.
La PMO aceleró el proceso de adquisición y aprobación, reduciendo los
tiempos a la mitad en algunos casos. Contrataron a un líder de equipo,
un programador maestro, un gerente financiero maestro, un
especialista en adquisiciones, un ingeniero civil y otros especialistas
para administrar las múltiples facetas de la construcción.
proyecto, terminando todo el proyecto en 97 días y dentro del presupuesto,
recibiendo un premio de la Asociación Nacional. de Propiedades Industriales
y de Oficinas por la calidad de su gestión de proyectos e instalaciones en
general.
Preguntas
1. ¿Qué sorprende del éxito de esta agencia sin fines
de lucro?
2. ¿Es el papel de la PMO en este caso inusual?
Fuente: Project Management Institute. "PMO acelera el éxito de las
instalaciones de transporte"PM Network, Vol. 18.

En un estudio reciente de las PMO después de la crisis financiera y la Gran Recesión de 2008-2009 (Gale
2010), se encontró que más de la mitad de las PMO informan ahora a los niveles más altos de gestión y
trabajan en tareas estratégicas de alto valor como la gestión. el proceso de gobierno (72 por ciento de los
que informan), asesorar a los ejecutivos (64 por ciento) y participar en la planificación estratégica (62 por
ciento). En términos de beneficios, redujeron el número de proyectos fallidos en un 31 por ciento, entregaron
el 30 por ciento de los proyectos por debajo del presupuesto y ahorraron
Las empresas estadounidenses un promedio de 567.000 dólares por proyecto. Las PMO muestran el mayor
valor cuando el desempeño de su cartera de proyectos coincide con los objetivos estratégicos de la
organización. Si no tienen una visión o misión y no tienen medidas de éxito, corren el riesgo de ser
etiquetados como gastos administrativos y cortar en tiempos difíciles.
En un caso, se inició una PMO cuando la gerencia quería más información sobre lo que estaba sucediendo en
sus proyectos. La PMO reorganizó los proyectos para asegurarse de que todos estuvieran sincronizados con los
objetivos de la empresa y tuvieran un caso de negocio claro que se alineara con la estrategia organizativa. Luego, la
PMO no solo realizó un seguimiento de los proyectos, sino que también emitió informes de gestión mensuales con
información de un vistazo sobre cada proyecto. Los informes también muestran cómo cada proyecto completado
ayuda a la empresa a alcanzar sus objetivos. Para proporcionar a la gerencia información prospectiva sobre
problemas potenciales que podrían poner en peligro la capacidad de cada proyecto para cumplir con sus objetivos
estratégicos, todos los proyectos mantienen registros de riesgos que se consolidan en un informe de riesgos al final
de cada mes.
Es importante comprender que el papel de la PMO es el de un habilitador / facilitador
de proyectos, no el hacedor de proyectos. La alta dirección no puede permitir que la EPMO o la PMO
usurpen los aspectos técnicos (programación, presupuesto, etc.) de la ejecución del proyecto. Esas
son responsabilidad del director del proyecto. Aunque la PMO puede, en ocasiones, involucrarse en
algunas tareas de gestión del proyecto, debe ser con el propósito de facilitar el enlace con la alta
dirección, no para hacer el trabajo del equipo del proyecto.

Formas de oficinas de gestión de proyectos

Hay varios niveles de competencia, sofisticación y responsabilidad de las PMO. Es decir, es posible que algunas organizaciones

solo deseen una PMO limitada que represente un centro de información, que informe sobre el progreso del proyecto y evalúe

la madurez del proyecto de la organización. En el siguiente nivel, la PMO puede establecer procedimientos y prácticas de

gestión de proyectos, promulgar lecciones aprendidas de proyectos anteriores, crear una base de datos para el análisis de

riesgos, ayudar a los gerentes de proyectos con asuntos administrativos y gerenciales y posiblemente incluso ofrecer

capacitación básica en
 La Oficina de Gestión de Proyectos165

gestión de proyectos. En el nivel superior, la PMO puede establecer una base de datos de recursos y
monitorear las dependencias entre proyectos, administrar la cartera de proyectos para garantizar el logro de
los objetivos de la organización, auditar y priorizar proyectos individuales y, en general, establecer un
sistema de gestión de proyectos empresariales. Aubry (2015) estudió 184 cambios de PMO y descubrió que
aumentar el rol de apoyo de la PMO mejoraba el desempeño del proyecto, el desempeño comercial y la
madurez de la gestión de proyectos, pero aumentar su rol de control no tenía ningún efecto sobre el
desempeño del proyecto.
Otra forma de organizar la PMO tiene que ver con el nivel de informes de la oficina. Si lo ubican
en un departamento funcional como Tecnología de la Información o Ingeniería, la principal
responsabilidad de la PMO será ayudar a los gerentes de proyectos del departamento con sus
proyectos individuales. Si la PMO se establece a nivel empresarial, puede asumir más responsabilidad
por las buenas prácticas de gestión de proyectos y posiblemente ofrecer formación básica. En los
niveles organizativos más altos, las responsabilidades de la PMO se ampliarán y se volverán menos
tácticas y más estratégicas.
En los últimos años, varias organizaciones grandes que llevan a cabo decenas o más (a veces
cientos) de proyectos han creado varias PMO, cada una de las cuales supervisa y ayuda a los
proyectos en su unidad individual de la organización. En ocasiones, también se crea una EPMO para
supervisar las múltiples PMO y garantizar que sigan los estándares organizativos para la gestión de
proyectos. Mientras que una PMO generalmente es solo para toda la división en una organización
grande, la EPMO es para todo el sistema y es responsable de la formulación de políticas y el cambio
organizacional. La encuesta de PMI de 2011 también encontró que las EPMO tienden a centrarse en
los aspectos estratégicos de la gestión de proyectos. En tales casos, el contacto de la PMO con la alta
dirección se lleva a cabo a través de la EPMO, que normalmente se utiliza para gestionar el proceso de
selección de proyectos, así como para comunicar la política organizativa relevante a las PMO, las
actividades directas de gestión de riesgos,

Tareas de la Oficina de Gestión de Proyectos

Para lograr sus objetivos, las PMO y las EPMO suelen realizar muchas de las siguientes tareas
(Block, 1999):

• Establecer y hacer cumplir buenos procesos de gestión de proyectos, como procedimientos para licitación,
análisis de riesgos, selección de proyectos, informes de progreso, ejecución de contratos y selección de
software.

• Evaluar y mejorar la madurez de la gestión de proyectos de la organización.

• Desarrollar y mejorar un sistema de gestión de proyectos empresariales.

• Ofrezca capacitación en gestión de proyectos y ayude a los gerentes de proyectos a obtener la certificación.

• Identificar, desarrollar y orientar a los gerentes de proyectos y mantener un grupo estable de candidatos
competentes.

• Ofrecer servicios de consultoría a los jefes de proyecto de la organización.

• Ayude a los gerentes de proyecto con detalles administrativos como informes de estado

• Establecer un proceso de estimación y evaluación de riesgo.

• Determinar si un nuevo proyecto es adecuado para la organización cambiante.

• Identificar los cambios posteriores (mercado, organización) y sus impactos en los proyectos actuales:
¿Los proyectos siguen siendo relevantes? ¿Es necesario cambiar el alcance de algún proyecto? ¿Hay
efectos de costos en los proyectos?

• Revisar y administrar la cartera de riesgos de proyectos de la organización, incluida la limitación del

número de proyectos activos en un momento dado e identificar y controlar los proyectos fuera de
control, así como la gestión de desastres potenciales.
166CAPÍTULO 5 El proyecto en la estructura organizativa

• Llevar a cabo revisiones y auditorías de proyectos, particularmente al principio del ciclo de vida de cada proyecto, e

informar el progreso del proyecto en relación con los objetivos de la organización.

• Mantener y almacenar archivos de proyectos

• Establecer una base de datos de recursos del proyecto y administrar el grupo de recursos

• Servir de campeón para perseguir la excelencia en la gestión de proyectos en la organización y

fomentar la discusión sobre el valor de los proyectos individuales en la empresa.

• Servir como un "hogar" para que los gerentes de proyectos se comuniquen entre sí y con el personal
de la PMO

• Recopilar y difundir información, técnicas y lecciones aprendidas según se informa en las evaluaciones
de proyectos que pueden mejorar las prácticas de gestión de proyectos.

• Ayudar en el cierre del proyecto

No todos estos objetivos se pueden lograr a la vez. En el corto plazo, o en los primeros meses, la
PMO solo podrá evaluar las prácticas actuales de gestión de proyectos de la organización y quizás
evaluar el progreso de cada uno de los muchos proyectos de la organización. A medio plazo, la PMO
puede comenzar a estandarizar los procesos y procedimientos de gestión de proyectos, comenzar a
ayudar a proyectos individuales con, por ejemplo, análisis de riesgo y detalles administrativos, y
quizás iniciar un análisis de cartera estratégica de los proyectos actuales. A largo plazo, o después de
aproximadamente un año, se pueden emprender las tareas más integrales, como armar una base de
datos de recursos, capacitar a los gerentes de proyectos, realizar auditorías de proyectos y asesorar
sobre proyectos individuales.
En nuestra opinión, sería raro que una PMO o EPMO manejara, o intentara manejar, todos los asuntos
anteriores. Más bien, muchos controlan el proceso de selección de proyectos y gestionan algunos otros asuntos
relacionados con el proyecto, por ejemplo, manteniendo registros y archivos del proyecto, manejando la gestión de
riesgos y / o capacitando a nuevos gerentes de proyecto. Un consultor experimentado nos dijo:

Últimamente, en mis viajes, en la mayoría de las empresas con las que me cruzo, el papel principal
de la PMO es crear y facilitar la metodología del proceso de selección de proyectos para apoyar la
toma de decisiones de la alta dirección. La PMO evalúa todas las iniciativas propuestas en
comparación con los objetivos de la empresa, estima los costos y prueba el ROI propuesto por la
empresa si la iniciativa está financiada. Una vez que se selecciona un proyecto, la PMO cambia su
esfuerzo para determinar si el proyecto está cumpliendo con todos sus objetivos. Muchas PMO
brindan poco o ningún apoyo directo de gestión de proyectos a los proyectos a medida que se
llevan a cabo, pero las PMO realizan varias evaluaciones importantes de todos los proyectos en
una cartera, tanto durante los ciclos de vida de los proyectos como después del hecho, para ver si
logran lo que dijeron que harían durante el proceso de selección.

A continuación, abordamos el otro propósito principal de la mayoría de las PMO: evaluar y mejorar la
madurez de la gestión de proyectos de la organización.

Madurez de la gestión de proyectos

Una encuesta reciente de PMI (2011) indicó que uno de los factores clave para mejorar la tasa de éxito de los
proyectos era la competencia de gestión de proyectos de la organización, ahora conocida como "madurez",
incluida la estandarización de las técnicas de gestión de proyectos, lo que aumentó las tasas de éxito de los
proyectos. en más del 25 por ciento. No hace mucho, cuando los gerentes senior se preguntaban si los
gerentes de proyectos de su organización tenían un dominio de las habilidades requeridas para administrar
proyectos de manera competente, la respuesta para muchas organizaciones parecía ser "no". El historial de
proyectos de TI / software fue particularmente pobre, con menos del 15 por ciento de alcanzar las
“expectativas planificadas” (KPMG, 2005; Cicmil et al., 2006; y en otros lugares).
 La Oficina de Gestión de Proyectos167

Dinsmore (1998) describe una de esas medidas de “madurez de la gestión de proyectos”

que puntúa a las empresas en cinco niveles sucesivos de madurez. En el primer nivel, “Inicial”,
no existe un proceso formal para administrar proyectos. El segundo nivel, "Repetible", tiene
procedimientos establecidos para la planificación, programación, seguimiento y estimación. El
tercer nivel es "Definido". En este nivel, la empresa tiene sistemas integrados para el
seguimiento y la gestión de proyectos, pero no se comprenden ni se utilizan de forma rutinaria
para controlar los proyectos. En el nivel cuatro, "Administrado", los sistemas se instalan y
utilizan para administrar y controlar proyectos. La tasa de éxito del proyecto es alta. El nivel
cinco, “Optimización”, tiene bases de datos integradas que se utilizan para generar información
a nivel de alta gerencia, así como para gerentes de proyectos, programas o carteras de
proyectos individuales.
En los últimos años, se han sugerido varias formas diferentes de medir la "madurez
de la gestión de proyectos" (Pennypacker et al., 2003), como basar la evaluación en los
PMI PMBOK Guide (Lubianiker, 2000), Modelo de madurez de gestión de proyectos PMBOK
organizativos del PMI (OPM3; consulte www.pmi.org/opm3/). Se ha diseñado y aplicado
otro modelo de madurez a 38 organizaciones en cuatro industrias diferentes (Ibbs et al., 1.8
2000). Este modelo consta de 148 preguntas divididas en seis procesos / fases del ciclo de
vida (inicio, planificación, ejecución, control, cierre y entorno organizacional), y las nueve
PMBOK áreas de conocimiento (integración, alcance, tiempo, costo, calidad, recursos humanos, PMBOK
comunicación, riesgo y adquisiciones). El modelo evalúa la madurez de la gestión de proyectos
de una organización en términos de cinco etapas de madurez: ad-hoc, planificado, gestionado, Tabla 3‐1
integrado y sostenido (el nivel más alto).
Independientemente de la forma del modelo, parece que la mayoría de las organizaciones no obtienen una
puntuación muy buena en términos de madurez. Tras la prueba, el promedio de las 38 organizaciones fue solo
ligeramente superior a 3, aunque las empresas individuales oscilaron entre 1.8 y 4.6 en la escala de cinco puntos. En
otra encuesta, alrededor de tres cuartas partes no obtuvieron una puntuación superior al nivel 2 (planificado) y
menos del 6 por ciento estaban por encima del nivel 3 (gestionado). Volveremos a referirnos a los modelos de
madurez de la gestión de proyectos en el Capítulo 11 sobre Control de proyectos.

Implementación de la Oficina de Gestión de Proyectos

Como se señaló anteriormente, la mejor manera de implementar una PMO es tratarla como un
proyecto y aplicar buenos procedimientos de gestión de proyectos. Además, dado el papel de este
tipo especial de proyecto, también se sugiere que el esfuerzo no se inicie hasta que tenga el
compromiso total de los altos directivos de la organización, ya que una PMO bien puede significar el
cambio de roles y responsabilidades para funciones que interactuar con él. También debe tener un
patrocinador / defensor de la alta dirección que esté decidido a llevar este proyecto al éxito.

Gale (2011, p. 36) señala que la mejor posibilidad de éxito permanente para la PMO es si existe
una visión clara de lo que logrará y esto está alineado con los objetivos más amplios del negocio: “Una
PMO tiene que abordar los problemas específicos a los que se enfrenta la organización sean
relevantes ". Más allá de esto, la PMO no solo puede tener éxito en la ejecución de proyectos, sino que
debe tener objetivos estratégicos claros, relevantes; medir sus resultados; y luego comunicar esos
resultados a toda la organización. Gale enumera cinco pasos para hacer esto:

1. Identificar medidas cuantificables para demostrar logros.Primero, establezca una base

línea para el estado actual, luego establezca metas de mejora y finalmente mida los resultados.
Respaldar su valor con resultados medibles ganará el apoyo de las partes interesadas.

2. Establezca un marco de tiempo realista para los resultadosAsegúrese de dejar en claro a la alta dirección que los

resultados no se obtienen de inmediato, sino que llevan tiempo, por lo general al menos un año.

3. Asegúrese de tener los recursos necesarios para lograr sus objetivosLas PMO no son mágicas,
requieren presupuesto, apoyo y talento para tener éxito. Sin eso, la PMO probablemente fracasará.
168CAPÍTULO 5 El proyecto en la estructura organizativa

4. Establecer credibilidad en toda la organización.El apoyo de uno o dos

las partes interesadas es insuficiente. Generar informes que demuestren los éxitos de la PMO en
el lenguaje de los ejecutivos. Utilice medidas simples y claras que muestren el impacto de la PMO
en el negocio. Limite cada informe a una página de texto y gráficos que cuente una historia de
un vistazo; sea breve y simple.

5. Consiga las mejores personas para la PMOLos buenos métodos y prácticas nunca pueden compensar
la falta de personal y PM de calidad.

Otra forma de iniciar el proyecto es a través de un programa piloto en una de las áreas
que es responsabilidad del patrocinador del proyecto PMO. Una vez finalizado, se puede
evaluar el proyecto piloto, corregir cualquier error y dar a conocer los beneficios al resto de la
organización. A medida que la PMO se expande e interactúa con más y más proyectos, sus
beneficios para la organización aumentarán progresivamente con su alcance.
Desafortunadamente, no todas las PMO tienen éxito. Greengard (2013) informa que
alrededor de un tercio no logra los resultados deseados, y Gale (2011) señala además que la
mitad de todas las PMO fallan la primera vez que se prueban. Según Tennant (2001), uno de los
principales problemas de las PMO es que los ejecutivos que establecen PMO a menudo no
comprenden las prácticas de gestión de proyectos. Por lo tanto, tienen expectativas poco
realistas de la PMO, como proporcionar ayuda temporal para un proyecto en problemas o para
obtener reducciones de costos de proyectos en curso. La PMO no es una solución rápida para
guardar proyectos que fallan; su objetivo principal es mejorar los procesos de gestión de
proyectos a largo plazo.
No se puede esperar que las PMO corrijan las fallas de la alta dirección, como objetivos de proyecto
inapropiados, apoyo de proyecto insuficiente y disponibilidad de recursos inadecuados. Curiosamente, una
tendencia reciente en las organizaciones de proyectos es la subcontratación de las propias funciones de la
PMO. Uno tiene que preguntarse si esto es un signo de problemas inminentes o un sabio reconocimiento de
las limitaciones del conocimiento de la alta dirección. En ese sentido, algunas de las señales de advertencia
de que es hora de cerrar o subcontratar una PMO son las siguientes (Greengard, 2013): cuando el apoyo de
nivel superior está disminuyendo, cuando la organización ya no tiene la experiencia institucional para la
PMO , cuando la PMO no parece estar pagando, y cuando la PMO ha cumplido sus objetivos.

Una clave para implementar con éxito una PMO es contar con el personal adecuado. Como Gale
(2013) señala que esta tarea se compone de dos partes: obtener el líder adecuado para la PMO y luego
obtener la cantidad adecuada y capacitada del personal. Para las PMO encargadas de implementar iniciativas
estratégicas de alta prioridad, solo el 41 por ciento recibió personal adecuadamente capacitado y solo el 31
por ciento recibió personal suficiente para llevar a cabo proyectos, por lo que aparentemente este es un
problema importante en la implementación de las PMO.
Gale señala que el líder de la PMO debe ser alguien no solo con los conjuntos de
herramientas adecuados para esa organización, sino también alguien que será
responsable del desarrollo profesional de los gerentes de proyecto con los que está
trabajando la PMO. Para el personal, es fundamental contar con personas con una
amplia gama de habilidades y experiencia, especialmente si el personal será
limitado. Por lo tanto, no es prudente elegir simplemente entre las personas que
están "disponibles", sino seleccionar aquellas que tengan la formación adecuada en
gestión, experiencia diversa en gestión de proyectos y certificación en gestión de
proyectos. Como parte de su experiencia, todos los miembros del personal deben
tener experiencia con un proyecto que fracasó y poder reflexionar sobre por qué
fracasó y qué aprendieron de él. También es útil una variedad diversa de personal;

La PMO también necesita personal que sea honesto sobre los riesgos y problemas y pueda examinar los datos y
la información para llegar a soluciones que resuelvan el problema central. Las habilidades de comunicación son
especialmente importantes para el personal de la PMO, en términos de honestidad brutal pero
 El equipo del proyecto169

también fluidez en el habla tanto a nivel estratégico, ejecutivo como táctico, técnico. Esto
incluye la creación de presentaciones que comuniquen su mensaje de manera rápida y efectiva
a cada audiencia. Por último, deben ser buenos para influir en otros para que sigan sus
consejos.

5.7 El equipo del proyecto

El trabajo en equipo es mucha gente haciendo lo que digo. Jefe anónimo

En esta sección consideramos la composición del equipo del proyecto, teniendo en cuenta que los diferentes
proyectos tienen necesidades de personal muy diferentes. El rol del equipo del proyecto ocupa la mayor parte del
Capítulo 9 enPMBOK®. Luego abordamos algunos problemas asociados con la dotación de personal del equipo. Por PMBOK
último, nos ocupamos de algunos de los problemas de comportamiento en la gestión de este equipo.
Para ser concretos durante nuestra discusión de los equipos de proyecto, usemos el ejemplo de un 9.2–9.4
proyecto de ingeniería de software para determinar cómo formar un equipo de proyecto. Suponga que el
tamaño de nuestro proyecto hipotético es bastante grande. Además del PM, es posible que se necesiten los
siguientes miembros clave del equipo, además de una cantidad adecuada de arquitectos de sistemas,
ingenieros, evaluadores, empleados y similares. Este ejemplo se puede aplicar a un proyecto de construcción,
un proyecto de investigación médica o cualquiera de una amplia variedad de otros tipos de proyectos. Los
títulos de los individuos cambiarían, pero los roles desempeñados serían similares.

• Arquitecto de sistemasEl arquitecto de sistemas está a cargo del diseño y desarrollo básico del
producto y es responsable del análisis funcional, especificaciones, dibujos, estimaciones de
costos y documentación.

• Ingeniero de DesarrolloLa tarea de este ingeniero es la producción eficiente del producto o

proceso que el ingeniero del proyecto ha diseñado, incluida la responsabilidad de la ingeniería
de fabricación, el diseño y la producción de código, las pruebas unitarias, la programación de la
producción y otras tareas de producción.

• Ingeniero de pruebasEsta persona es responsable de la instalación, prueba y soporte del

producto (proceso) una vez que se completa su ingeniería.

• Administrador de contratosEl administrador está a cargo de todo el papeleo oficial, haciendo un seguimiento
del cumplimiento de los estándares (incluida la calidad / confiabilidad), los cambios de los financiadores
(ingeniería), la facturación, las preguntas, las quejas, los aspectos legales, los costos y la negociación de otros
asuntos relacionados con la autorización del contrato. el proyecto. No es raro que el administrador del
contrato también se desempeñe como historiador y archivero del proyecto.
Proyecto
• Controlador de proyectoEl controlador lleva una cuenta diaria de los gerente
presupuestos, variaciones de costos, cargos laborales, suministros del
proyecto, estado de los equipos de capital, etc. El controlador también
realiza informes regulares y se mantiene en estrecho contacto con el PM
Sistemas Proyecto
y el controlador de la empresa. Si el administrador no actúa como arquitecto controlador

historiador, el controlador puede hacerlo.

• Gerente de Servicios de SoporteEsta persona está a cargo de Desarrollo Contrato

soporte de productos, subcontratistas, procesamiento de datos, ingeniero administrador

compras, negociación de contratos y funciones de soporte de

gestión general. Prueba Servicios de apoyo
ingeniero gerente
De estas personas principales del proyecto, es más importante que el
arquitecto del sistema y el controlador del proyecto informen directamente al PM FIGURA 5.6Organización típica para proyectos de
(consulte la Figura 5.6). Esto facilita el control sobre dos de los principales objetivos. software.
170CAPÍTULO 5 El proyecto en la estructura organizativa

del proyecto: desempeño técnico y presupuesto. (El PM generalmente tiene el control personal del cronograma). Para
un proyecto grande, los seis funcionarios del proyecto podrían trabajar fuera de la oficina del proyecto e informar
directamente al PM.
Para dotar de personal al proyecto, el PM trabaja a partir de una previsión de las necesidades de personal
durante el ciclo de vida del proyecto. Esto se hace con la ayuda de algunos gráficos especiales. Primero untrabaja
estructura de desgloseWBS) está preparado para determinar la naturaleza exacta de las tareas necesarias
para completar el proyecto. (La WBS se describe en detalle y se ilustra en el Capítulo 6.) Los requisitos de
habilidades para estas tareas se evalúan y las habilidades similares se agregan para determinar las
necesidades de la fuerza laboral. Tenga en cuenta que el desarrollo de la WBS puede implicar consultas con
expertos externos. El PM debe comprender, planificar y monitorear de cerca los efectos en los proyectos
actuales de estas consultas. Es común que estos expertos se alejen de su propio trabajo para hacer frente a
las necesidades de planificación que surgen en otros lugares de una WBS. Desde esta base, se contacta con
los departamentos funcionales para localizar a las personas que puedan satisfacer estas necesidades.

En ocasiones, se pueden subcontratar determinadas tareas. Esta opción puede

adoptarse porque el personal debidamente capacitado no está disponible o no se
puede ubicar, o los subcontratistas pueden realizar entregas a un costo menor, o
incluso porque algunos equipos especiales requeridos para el proyecto no están
disponibles internamente. La necesidad de subcontratar aumenta a medida que las
empresas "reducen su tamaño". Sin embargo, si se encuentran las personas (y el
equipo) adecuados dentro de la organización, el PM generalmente debe obtener sus
servicios en sus departamentos de origen. Muchas empresas insisten en utilizar
recursos "locales" cuando están disponibles, a fin de mantener un mejor control
sobre el uso y la calidad de los recursos. Normalmente, el PM tendrá que negociar
tanto con el jefe de departamento funcional como con el empleado,

Hay otras personas, no necesariamente técnicas, que también son fundamentales para el éxito
del proyecto y deben informar directamente al PM o al adjunto del PM (a menudo, el arquitecto de
sistemas):

• Miembros senior del equipo del proyecto que tendrán una relación a largo plazo con el
proyecto.
• Aquellos con quienes el PM requerirá una comunicación continua o cercana
• Aquellos con habilidades raras necesarias para proyectar el éxito.

Recuerde que el PM debe depender de la razón cuando intenta convencer a un jefe de

departamento para que preste su gente valiosa al proyecto. El jefe de departamento funcional, que ve
el proyecto como una fuente de prestigio más o menos glamorosa en la que el departamento no
puede compartir, tiene poca motivación natural para cooperar. Una vez más, el éxito del proyecto
depende tanto de la habilidad política y negociadora del PM como de la habilidad técnica del equipo.

Hasta ahora, hemos asumido tácitamente una matriz u organización proyectada bastante
fuerte para el proyecto en nuestro ejemplo. En los últimos años, el uso de matrices más débiles
se ha vuelto cada vez más frecuente. En muchas empresas, cuando se les pregunta a los PM la
cantidad de personas que les reportan directamente, la respuesta es “¡Ninguna!”. no es
infrecuente. Nos parece que lo más común de todo es la organización matricial con un gerente
de proyecto, uno o dos contribuyentes calificados clave que pueden ser miembros a tiempo
completo del proyecto, y una amplia variedad de servicios o capacidad suministrada al proyecto
por personal funcional. grupos en la organización matriz. Estas estructuras se encuentran a
menudo en proyectos de I + D que forman parte de programas más amplios que lleva a cabo
una empresa matriz. En un proyecto farmacéutico, por ejemplo, se pueden asignar al proyecto
uno o dos científicos y técnicos de laboratorio superiores,
 Los factores humanos y el equipo del proyecto171

de entregables de unidades funcionales en lugar de personas asignadas directamente al proyecto para llevar
a cabo el trabajo.
Aunque el PM tiene que negociar por menos individuos en estas estructuras matriciales más
débiles que en el caso de matrices más fuertes, las habilidades de negociación del PM son igualmente
críticas. Es típico que el éxito de los proyectos de matriz débil dependa de las habilidades de los pocos
especialistas técnicos que se asignan directamente al proyecto. La capacidad del PM para negociar
por técnicos calificados, así como poroportuno la prestación de servicios desde departamentos
funcionales es un factor determinante del éxito.

5.8Los factores humanos y el equipo del proyecto

Con un recordatorio de la necesidad de que el PM posea un alto nivel de sensibilidad política,

podemos discutir algunos otros factores en la gestión de equipos de proyectos, mientras recordamos
que los principios y prácticas de una buena gestión general también se aplican a la gestión de
proyectos. . Los discutimos desde el punto de vista del PM como un individuo que debe hacer frente a
las victorias y frustraciones tanto personales como técnicas de la vida en un proyecto. Las cuestiones
de la gestión del equipo del proyecto se incluyen principalmente en el área de conocimiento de
Gestión de Recursos Humanos dePMBOK®. PMBOK
Cumplir con el cronograma y los objetivos de costos sin comprometer el desempeño
parece ser un problema técnico para el PM. En realidad, es sólo en parte técnico porque Capítulo 9

también es un problema humano; más exactamente, un problema técnico con una dimensión
humana. Los profesionales de proyectos tienden a ser perfeccionistas. Ya es bastante difícil
cumplir los objetivos del proyecto en condiciones normales, pero cuando, por orgullo de la
mano de obra, los profesionales quieren seguir mejorando (y por lo tanto cambiando) el
producto, la tarea se vuelve casi imposible. Los cambios provocan retrasos. A lo largo del
proyecto, el gerente debe continuar enfatizando la importancia de cumplir con las fechas de
vencimiento. También ayuda si el PM establece, al comienzo del proyecto, un procedimiento de
cambio técnico para asegurar el control sobre la incidencia y frecuencia del cambio. (Sin
embargo, no
Otro problema es motivar a los miembros del equipo del proyecto para que realicen el trabajo
del proyecto. Desafortunadamente, el PM a menudo tiene poco control sobre las recompensas
económicas y las promociones de las personas que trabajan en el proyecto. Esto es especialmente
cierto cuando la matriz es débil. Sin embargo, esto no significa que el PM no pueda motivar a los
miembros del equipo del proyecto. En un famoso estudio clásico sobre lo que motiva a los empleados
técnicos como ingenieros, científicos y profesionales en un equipo de proyecto, encontraron que el
reconocimiento, los logros, el trabajo en sí, la responsabilidad, el avance y la oportunidad de aprender
nuevas habilidades son fuertes motivadores (ver Herzberg, 1968). Es responsabilidad del PM
asegurarse de que el trabajo del proyecto esté estructurado de tal manera que enfatice estos factores
motivacionales. También hemos encontrado que el uso juicioso de notas de agradecimiento del PM a
aquellos gerentes funcionales que han proporcionado al proyecto individuos capaces y
comprometidos y / o capacidad efectiva y eficiente es un poderoso motivador: copias a los individuos
relevantes. y al jefe del gerente funcional, por supuesto. (También es importante no escribir tales
notas si el desempeño fue mediocre o pobre).
El uso de la gestión participativa también es una forma de motivar a las personas. Ésta no es una
teoría nueva. El concepto sugiere que el trabajador individual (o el equipo) debería desempeñar un
papel importante a la hora de decidir qué medios deben emplearse para alcanzar los fines deseados y
encontrar mejores formas de lograr las cosas. Programas participativos recientes como Six Sigma,
Total Quality Management (TQM), equipos de mejora continua (CIT), equipos de trabajo autodirigidos
(SDWT) y, más recientemente, los equipos de gestión de proyectos ágiles pueden tener estructuras
ligeramente diferentes y variar algo en la cantidad. de la toma de decisiones
172CAPÍTULO 5 El proyecto en la estructura organizativa

autoridad y autonomía que ejerce el equipo, pero todas ellas tienen como objetivo mejorar el desempeño de los
trabajadores, así como mejorar los métodos de producción y la calidad del producto. Analizaremos la gestión ágil de
proyectos con más detalle en el Capítulo 6.
La adopción de tales métodos empodera el equipo (así como sus miembros individuales) para asumir la
responsabilidad y rendir cuentas de la entrega de los objetivos del proyecto. Algunas ventajas del
empoderamiento para los equipos de proyecto se dan a continuación:

1. Aprovecha la capacidad de los miembros del equipo para manipular tareas para que el proyecto objec
tives se cumplen. Se anima al equipo a encontrar mejores formas de hacer las cosas.

2. A los profesionales no les gusta ser microgestionados. La gestión participativa no dice

cómo trabajar pero, dado un objetivo, les permite diseñar sus propios métodos (generalmente
dentro de algunas limitaciones de su autoridad).

3. Los miembros del equipo saben que son responsables y responsables de lograr el proyecto.
ect entregables.
4. Existe una buena posibilidad de que las soluciones sinérgicas resulten de la interacción del equipo.

5. Los miembros del equipo reciben comentarios oportunos sobre su desempeño.

6. Se proporciona al PM una herramienta para evaluar el desempeño del equipo.

Gestión de proyectos en la práctica

Éxito de las reparaciones en Sudáfrica a través del
trabajo en equipo
Cuando estalló un incendio en la columna de regeneración de
carbonato en una importante instalación de Sasol, una empresa
sudafricana líder en petróleo, petróleo y carbón, fue crucial repararlo
de inmediato. Se determinó que la parte dañada de la columna de 19
pies de ancho y 231 pies de largo tendría que cortarse y reemplazarse
antes de que la instalación pudiera operar nuevamente. El tiempo era
esencial y solo se permitieron 40 días para el proyecto de reparación.
Para lograr este programa inaudito, se establecieron una
serie de reglas básicas especiales:
• El proyecto se basará en el cronograma, no en los costos.
• No hay flotador en ninguna parte del proyecto.
• Siempre planifique reducir los tiempos programados, no
cumplirlos.
las adaptaciones eran aceptables, había comida disponible, se evitaban
las horas extraordinarias excesivas, los formularios de comunicación
coincidían con las preferencias de cada miembro (verbal, telefónica,
escrita, etc.), etc. Se instaló un tablero de comunicación y se actualizó
dos veces al día para comunicar el avance del proyecto, y
especialmente el tiempo ahorrado en el cronograma con el nombre de
la persona que lo logró. Hubo reuniones de cambio de turno dos veces
al día, donde cada turno se comunicaba con el turno anterior sobre el
progreso y los problemas, y reuniones de planificación dos veces al
día, donde las actividades laborales de los dos días siguientes se
planificaron en detalle.
La respuesta a este nivel de atención del equipo del proyecto fue
abrumadora. La gente planteó ideas para ahorrar incluso 5 minutos en
el horario. El entusiasmo por el proyecto y el ahorro de tiempo del
proyecto se convirtió en la cultura dominante. Como resultado, el
proyecto se completó en solo 25 días, 15 días antes, con un ahorro de
costos correspondiente de más de $ 21 millones de un presupuesto de
$ 85 millones.

• Los recursos no deben considerarse una limitación. Preguntas

• La comunicación será continua en todos los niveles.
• La seguridad no se verá comprometida.
• La calidad no se verá comprometida.
Además, se hizo un esfuerzo especial para que el equipo del
proyecto se esforzara por reducir el tiempo en el proyecto. En
1. De las reglas básicas especiales, ¿cuáles crees que
realmente impulsaron la velocidad del proyecto?
2. ¿Cuál crees que fue el factor principal que cambió la
cultura de este proyecto?
3. Dado que este proyecto redujo alrededor del 40 por ciento del

primer lugar, quedó claro que se concedería más importancia al cronograma y el 25 por ciento del costo, ¿cuál es el mensaje

rendimiento del equipo que al rendimiento individual. Los sobre la importancia del trabajo en equipo?

aspectos "suaves" de la gestión siempre se tuvieron en cuenta: Fuente: I. Boggon, "The Benfield Column Repair Project",
asegurarse de que el transporte estuviera disponible, PM Network, Vol. 10.
 Los factores humanos y el equipo del proyecto173

Todos estos elementos sirven para aumentar la motivación entre los miembros del equipo del proyecto.
Las discusiones informales con muchos líderes de equipos de proyectos nos llevan a las mismas
conclusiones, pero el éxito de los SDWT (y de todos los demás equipos) depende en última instancia de una
declaración clara de lo que se espera que logre el equipo. La alta dirección debe “hacer el esfuerzo de
delinear claramente los objetivos, responsabilidades y autoridad del proyecto” para aprovechar las ventajas
de los equipos de proyecto (Nelson, 1998, p. 43). Por último, es importante recordar que entregar un
proyecto a un equipo no reemplaza la necesidad de contar con habilidades de gestión de proyectos
competentes.
En el Capítulo 6, cubrimos el proceso de planificación de proyectos en detalle y enfatizamos el
uso de la EDT para organizar las actividades del proyecto. Es una técnica de planificación detallada y
programación dirigida hacia el logro de los objetivos del proyecto. El PM (ya veces el cliente) trabaja
con miembros del equipo del proyecto y este proceso genera un conjunto completo de planes
escritos. El documento resultante no es solo un plan, sino también un mecanismo de control. Debido
a que el sistema de desarrollo del plan es participativo y hace que los miembros del equipo sean
responsables de sus partes específicas del plan general, los motiva y también denota claramente el
grado en que los miembros del equipo son mutuamente dependientes. La importancia de este último
resultado del proceso de planificación no está bien reconocida en la literatura sobre formación de
equipos.
Sin embargo, reunir a las personas, incluso cuando pertenecen a la misma organización y contribuyen
con sus esfuerzos a los mismos objetivos, no significa necesariamente que se comporten como un equipo.
Organizar el trabajo del equipo de tal manera que los miembros del equipo sean mutuamente dependientes
y lo reconozcan producirá un fuerte impulso para que el grupo forme un equipo real. El éxito del proyecto
estará asociado con el trabajo en equipo, y el fracaso del proyecto seguramente resultará si el grupo no
trabaja en equipo.1 Si muchos o la mayoría de los miembros del equipo también están "orientados hacia los
problemas", la probabilidad de que el grupo forme un equipo eficaz aumenta aún más.

En un extenso estudio de investigación sobre el tema, Tippet et al. (1995) concluyen que los resultados
generales muestran que las empresas generalmente están haciendo un mal trabajo en la formación de equipos. La
falta de recompensas efectivas, los mecanismos inadecuados de retroalimentación del desempeño individual y de
equipo y el establecimiento inadecuado de metas individuales y de equipo son áreas débiles (Tippet, 1995, p. 35). Con
respecto a un comportamiento de equipo perjudicial en particular, He (2012) investigó el efecto del "aprovechamiento
libre" en los equipos y encontró que una combinación de mejorar la moral del equipo y controlar el tamaño del
equipo contrarresta este comportamiento indeseable. Finalmente, Lencioni (2002) ha escrito un pequeño libro
maravilloso sobre la formación de equipos que describe como "una fábula de liderazgo". Si uno solo puede leer un
trabajo en equipos, esta sería nuestra primera opción.

1 Aunque ni siquiera se menciona la formación de equipos, la lectura del artículo de AS Carlisle (1976), “MacGregor”, es
instructiva. El artículo es un clásico sobre el poder de la delegación y fue claramente la inspiración para Blanchard y Johnson.
El administrador de un minuto. El documento de Carlisle informa sobre un gerente de planta que delega la mayoría de las
decisiones operativas en sus subordinados e insiste en que se ayudan a resolver los problemas de los demás. Como
resultado, forman un equipo que sería la envidia de cualquier jefe de proyecto.
174CAPÍTULO 5 El proyecto en la estructura organizativa

El uso de organizaciones de proyectos matriciales plantea un problema adicional. Los miembros del
equipo van y vienen. La constante rotación de los miembros del equipo dificulta la creación y el
mantenimiento de un equipo (Bushe, 2010). Cuando llega un nuevo miembro del equipo, se le debe poner al
día sobre el proyecto. Casi siempre, este trabajo se deja en manos de miembros de equipo experimentados,
que a menudo se ven acosados por la presión de su propio trabajo y resienten la interrupción. Se pueden
hacer algunas cosas para ayudar, si no resolver totalmente el problema. El PM debe identificar a algunos
miembros del equipo que sean personalmente extrovertidos y estén bien informados. Se puede pedir a estas
personas que se reúnan con nuevos miembros y les ayuden a participar en los aspectos técnicos del
proyecto. El PM debe, por supuesto, asegurarse de que este trabajo adicional se pueda acomodar en los
horarios de los veteranos. El contacto interpersonal a menudo se facilita para todas las partes mediante el
uso de software (Underwood, 2008). Además, una mayor especialización puede reducir la cantidad de
información que debe transmitirse y puede resultar en un énfasis en el hecho de que todos los miembros del
equipo dependen de otros miembros del equipo para el éxito. Un sentido de dependencia mutua también
tenderá a elevar el nivel de cohesión y compromiso de todos los miembros del proyecto.

Otro problema de comportamiento para el PM es el conflicto interpersonal. El problema es tan

generalizado que el conflicto entre los miembros del equipo del proyecto y entre los miembros del equipo y
los externos (incluido el cliente) parece ser el estado natural de existencia de los proyectos. Es nuestro fuerte
sentimiento que el PM que no puede manejar los conflictos está condenado al fracaso. La negociación, como
hemos indicado antes, es la herramienta principal del PM para resolver conflictos, pero advertimos al lector
una vez más que el conflicto también puede ser una fuerza altamente creativa en un equipo de proyecto,
particularmente cuando está controlado por un PM astuto.
En 1975, Thamhain et al. (1975) publicó el trabajo clásico sobre el enfoque y la naturaleza del conflicto en los proyectos. A pesar de su antigüedad, esta

información sigue siendo válida hoy en día y la incluimos aquí. Hemos encontrado sus ideas tan relevantes hoy como lo eran en 1975. La Tabla 5.2, basada en Thamhain

et al., Relaciona el foco de conflicto más probable con etapas específicas del ciclo de vida del proyecto. La tabla también sugiere algunas soluciones. Cuando el proyecto se

organiza por primera vez, las prioridades, los procedimientos y los cronogramas tienen aproximadamente el mismo potencial como foco de conflicto. Durante la fase de

desarrollo, las prioridades se vuelven significativamente más importantes que cualquier otro factor de conflicto; Los procedimientos están casi completamente

establecidos en este momento. En la fase principal del programa, finalmente se establecen las prioridades y los cronogramas son la causa más importante de problemas

dentro del proyecto, seguidos de desacuerdos técnicos. Obtener el apoyo adecuado para el proyecto también es un motivo de preocupación. Al finalizar el proyecto,

cumplir con el cronograma es la cuestión fundamental, pero las tensiones interpersonales que se ignoraron fácilmente al principio del proyecto pueden estallar

repentinamente en conflicto durante las últimas semanas agitadas del ciclo de vida. La preocupación por la reasignación agrava la situación. Ambas tablas 5.2 y 5.3

muestran el conflicto como una función de la etapa en el ciclo de vida del proyecto, así como por la fuente del conflicto, pero la tabla 5.3 también muestra la pero las

tensiones interpersonales que fueron fácilmente ignoradas al principio del proyecto pueden estallar repentinamente en conflicto durante las últimas semanas agitadas

del ciclo de vida. La preocupación por la reasignación agrava la situación. Ambas tablas 5.2 y 5.3 muestran el conflicto como una función de la etapa en el ciclo de vida del

proyecto, así como por la fuente del conflicto, pero la tabla 5.3 también muestra la pero las tensiones interpersonales que fueron fácilmente ignoradas al principio del

proyecto pueden estallar repentinamente en conflicto durante las últimas semanas agitadas del ciclo de vida. La preocupación por la reasignación agrava la situación.

Ambas tablas 5.2 y 5.3 muestran el conflicto como una función de la etapa en el ciclo de vida del proyecto, así como por la fuente del conflicto, pero la tabla 5.3 también

muestra lafrecuencia de conflicto por fuente y etapa del ciclo de vida.

Nos parece claro que la mayor parte del conflicto en los equipos de proyecto es el resultado de individuos que
se enfocan en el proyecto a través de los ojos de su disciplina o departamento individual (de Laat, 1994). Estas
personas no están orientadas a problemas y, por lo tanto, rara vez son miembros efectivos de los equipos de
proyectos. Dewhurst (1998, p. 34) define a un grupo de personas que trabajan de forma independiente como un
"Equipo solo por nombre" o un "NO". Si el trabajo en equipo es vital para el éxito, entonces para un NO, el "grupo de
trabajo matemático (es) 2 2 3 o menos". La mayoría de los miembros del equipo perciben que las luchas internas que
resultan cuando las personas orientadas a la disciplina introducen conflictos en un equipo de proyecto son "políticas".
Si el PM permite que las decisiones del proyecto sean dictadas por las luchas internas, el proyecto puede fracasar
(Pinto, 1997, p. 31).
Los conflictos se pueden manejar de varias formas, como se describe en el Capítulo 4, pero una cosa es cierta: los que

evitan los conflictos no son gerentes de proyectos exitosos. En ocasiones, el compromiso parece ser útil, pero la mayoría de las

veces, el método de elección es confrontar suavemente el conflicto. Se ha escrito mucho sobre la resolución de conflictos y no

es necesario resumir
 Los factores humanos y el equipo del proyecto175

TABLA 5.2Principales fuentes de conflicto durante varias etapas del ciclo de vida del proyecto

Principales fuentes de conflicto y recomendaciones

para minimizar las consecuencias disfuncionales

Conflicto
Fase del ciclo de elevación Fuente Recomendaciones

Formación de proyectos Prioridades Planes claramente definidos. Toma de decisiones conjunta y / o consulta con las partes
afectadas. Haga hincapié en la importancia del proyecto para los objetivos de la organización.

Procedimientos Desarrollar procedimientos operativos administrativos detallados que se seguirán en la

realización del proyecto.

Aprobación segura de administradores clave. Desarrollar

una declaración de entendimiento o estatuto.

Horarios Desarrollar compromisos de cronograma antes del inicio real

del proyecto.

Pronosticar otras prioridades departamentales y el posible impacto en el proyecto.

Fase de acumulación Prioridades Proporcione comentarios efectivos para apoyar las áreas sobre los planes y necesidades de proyectos

previstos a través de sesiones de revisión de estado.

Horarios Programar paquetes de desglose del trabajo (subunidades del proyecto) en cooperación
con los grupos funcionales.

Procedimientos Planificación de contingencias sobre cuestiones administrativas clave.

Programa principal Horarios Supervise continuamente el trabajo en curso.

Comunique los resultados a las partes afectadas.

Pronostique problemas y considere alternativas.

Identifique los posibles puntos problemáticos que necesiten una vigilancia más

Técnico cercana. Resolución temprana de problemas técnicos.

Comunicación de restricciones de cronograma y presupuesto al personal técnico.

Enfatice las pruebas técnicas tempranas y adecuadas.

Facilitar un acuerdo temprano sobre los diseños finales.

Labor Pronostique y comunique los requisitos de personal con anticipación.

Establecer requisitos y prioridades de personal con grupos funcionales y de

personal.

Reducir progresivamente Horarios Seguimiento cercano del cronograma en el ciclo de vida del proyecto.

Considere la reasignación del personal disponible a áreas críticas del proyecto propensas a
retrasos en la programación.

Obtenga una rápida resolución de los problemas técnicos que puedan afectar los horarios.

Personalidad Desarrollar planes para la reasignación de personas una vez finalizado el proyecto.
y trabajo Mantenga relaciones de trabajo armoniosas con el equipo del proyecto y los
grupos de apoyo. Trate de relajar el entorno de mucho estrés.

Fuente: Thamhain et al., 1975.

176CAPÍTULO 5 El proyecto en la estructura organizativa

TABLA 5.3Número de conflictos durante un proyecto de muestra

Fase del proyecto

Comienzo Temprano Principal Tarde Fuentes de conflicto

27 35 24 dieciséis Prioridades del proyecto

26 27 15 09 Administración. procedimientos

18 26 31 11 Compensación técnica

21 25 25 17 Dotación de personal

20 13 15 11 Estimaciones de costos de soporte

25 29 36 30 Horarios
dieciséis 19 15 17 Alusiones personales

153 174 161 111 Total

Fuente: Thamhain et al., 1975.

que la literatura aquí más allá de señalar que la clave para la resolución de conflictos se basa en la capacidad del
gerente para transformar una situación de ganar-perder en ganar-ganar.
En el siguiente capítulo, pasamos de los problemas organizativos a las tareas de planificación de
proyectos. Abordamos los temas de coordinación, gestión de interfaces y gestión de riesgos. También
presentamos algunos conceptos y herramientas importantes de gestión de proyectos, como la matriz WBS y
RACI.

Resumen
En este capítulo se describen las diversas estructuras organizativas y de
gobierno que se pueden utilizar para proyectos y se detallan sus ventajas.
Se describió un procedimiento apropiado para elegir la mejor forma y se
dieron dos ejemplos. Luego, el capítulo pasó a una discusión sobre el
papel de la PMO y la madurez de la gestión de proyectos. Después de esto,
la discusión se dirigió al propio equipo del proyecto, describiendo la
organización del personal de la oficina del proyecto y los problemas
un caso particular requiere la consideración de las características del
proyecto en comparación con las diversas ventajas y desventajas de
cada forma.
Un procedimiento útil para seleccionar una forma organizativa para un
proyecto es:
1. Identifique los resultados específicos deseados.

humanos, como la motivación y el conflicto, que enfrentará el gerente del
proyecto. Los puntos específicos que se hicieron en el capítulo fueron
estos:
Si el proyecto se va a incluir en una organización funcional,
debe ubicarse en la unidad con mayor interés en su éxito o en la
unidad que pueda brindar más ayuda. Aunque hay ventajas en
este modo de organización, las desventajas son mayores.
La forma proyectual de organización tiene sus
ventajas y desventajas. Aunque las desventajas no son
tan graves como con la forma funcional, son importantes.
2. Determine las tareas clave para lograr estos resultados e iden
tificar las unidades dentro de la organización matriz donde
normalmente se asignarían estas tareas.
3. Secuenciar las tareas clave y agruparlas en pasos de trabajo lógicos.
4. Determinar qué subsistemas del proyecto se asignarán
qué pasos y qué subsistemas deben cooperar
estrechamente.
5. Identifique las características especiales de la firma o del proyecto, con
limitaciones o problemas que pueden afectar la forma en que se debe organizar

La organización matricial combina las formas funcionales y proyectadas en un el proyecto.

intento de aprovechar las ventajas de cada una. Si bien este enfoque ha tenido bastante 6. Considere todo lo anterior en relación con los pros y los contras de
éxito, también tiene sus propias desventajas únicas. Hay muchas variantes de las formas se toma cada forma organizativa como una decisión final.
puras de organización, y para manejar proyectos especiales se utilizan habitualmente
diversas estructuras de personal y "mixtas". La mejor forma para Cada proyecto debe tener una oficina de proyectos, incluso si debe
compartirse con otro proyecto.
 Preguntas177

Los megaproyectos o multiorganizacionales más grandes y complejos 2. Aquellos con quienes el PM estará de manera continua o cercana
pueden incluir, además del PM, un ingeniero de proyecto, un ingeniero de comunicado.
fabricación, un gerente de campo, un administrador de contratos, un 3. Aquellos con habilidades raras necesarias para el éxito del proyecto.
controlador de proyecto y un gerente de servicio de soporte. Si una organización
participa en varios proyectos, también se puede justificar una PMO (o EPMO). El perfeccionismo, la motivación y el conflicto son a menudo los principales
problemas de comportamiento que enfrenta el PM. Los programas de manejo

Aquellos en el equipo del proyecto que deben reportar directamente al PM participativo pueden ser una herramienta útil para abordar los dos primeros, mientras

son el ingeniero del proyecto y el controlador del proyecto, así como: que la confrontación suave generalmente funciona mejor para el segundo.
Las fuentes de conflicto del proyecto suelen ser prioridades y políticas al
1. Miembros del equipo senior que tendrán una relación a largo plazo principio, problemas técnicos y de programación durante la fase principal, y
enviar con el proyecto. problemas personales y de programación próximos a la terminación.

Glosario
Gestión funcionalEl estandar
Departamentos de la organización que
representan disciplinas individuales
como ingeniería, marketing, compras, etc.
Organización MixtaEste enfoque en con la mejora de la madurez y la experiencia en
incluye tanto funciones (disciplinas) como gestión de proyectos de la organización, así
proyectos en su jerarquía. como el aumento de la tasa de éxito de los
Multi-organizacional ProyectosEstas proyectos.

HolísticoTodo visto de una vez en lugar suelen ser proyectos muy grandes que involucran a ProyectitisUn fenómeno social, apego
de cada pieza individualmente. muchas organizaciones. inapropiadamente intenso al proyecto.

MatrixOrganizationUn método de órgano Organización matrizLa firma u órgano SubcontratarSubarrendamiento de tareas a

que mantiene tanto a los supervisores funcionales
como a los supervisores de proyectos. Una matriz
fuerte opera más cerca de una organización
proyectada, mientras que una matriz débil opera
más como una organización funcional.
MadurezLa sofisticación y experiencia de
una organización en la gestión de múltiples
proyectos.
MegaproyectosSe trata de proyectos enormes
y muy complejos que cuestan enormes
cantidades, consisten en varios contratistas y
subcontratistas y tardan años en completarse.
ización dentro de la cual se está llevando a cabo el
proyecto.
Director del programaEsta persona es típicamente
responsable de una serie de proyectos relacionados, cada uno
con su propio director de proyecto.
Organización proyectadaEsta forma de
la organización se caracteriza porque los proyectos son
las subdivisiones principales de la organización, y las
funciones administrativas generales comunes a todos
los proyectos son una oficina de personal que depende
del presidente o director ejecutivo.
Oficina de Gestión de ProyectosUna oficina para
lidiar con múltiples proyectos y cargar
contratistas más pequeños.
SuboptimizaciónLa optimización de un
subelemento de un sistema, quizás en
detrimento del sistema global.
Estructura de desglose del trabajo (WBS)
La WBS muestra los elementos de trabajo de un
proyecto jerárquicamente, pasando de tareas a
subtareas, a paquetes de trabajo, etc. La WBS
se puede considerar como la base del plan del
proyecto donde cada nivel en la WBS desglosa
las actividades de trabajo en mayor detalle (ver
Capítulo 6).

Preguntas
Revisión de material Preguntas
6. Identificar tres formas de lidiar con un conflicto asociado
con proyectos.
1.¿Qué es un administrador de programas? ¿En qué se diferencia este trabajo
7.¿Cuáles son algunas de las ventajas y desventajas de albergar un
del de director de proyecto?
proyecto de forma funcional?
2. Identificar las ventajas y desventajas de la matriz. 8.¿Cuáles son las funciones del arquitecto de sistemas?
forma de organización.
9.¿Cuáles son las principales fuentes de conflicto a lo largo del ciclo de
3. Nombrar los cuatro tipos básicos de organización de proyectos y enumerarlos en
vida?
al menos una característica, ventaja y desventaja de cada uno.
10.¿Cuáles son las principales tareas de una PMO?
4. Dé algunas pautas importantes para elegir una organización
11.¿Qué significa el término "madurez de la gestión de proyectos"?
formulario para un proyecto.

12.¿Dónde se ubican la mayoría de las empresas en la escala de vencimientos?

5.¿Por qué es tan importante la PMO?
178CAPÍTULO 5 El proyecto en la estructura organizativa
Preguntas para debatir en clase
13. Discuta algunas de las diferencias entre la gestión de profes
profesionales y la gestión de otros trabajadores o miembros del equipo.
14. Los factores humanos y políticos cobran gran importancia en el éxito de
proyectos. Dada la falta general de cobertura de este tema en la
educación en ingeniería y ciencias, ¿cómo podría un PM adquirir la
capacidad de abordar estos problemas?
15. Una desventaja de la organización proyectizada tiene que ver
con la tendencia de los profesionales del proyecto a quedarse atrás
en áreas de experiencia técnica que no se utilizan en el proyecto.
Nombra varias formas en que un gerente de proyecto podría evitar
este problema.
dieciséis. Discuta los efectos de las diversas formas organizativas en
coordinación e interacción, tanto dentro del equipo del proyecto
como entre el equipo y el resto de la firma.
17. Describa, a partir de la tabla 5.3, las razones probables de la
cambiar el número de conflictos en el transcurso del proyecto en
las siguientes áreas:
una. Prioridades
B. Procedimientos administrativos
C. Compensación técnica
D. Horarios
Incidentes para discusión
Estrategia de Shaw
Colin Shaw ha sido elegido para ser director de proyectos contables
por segunda vez este año. Aunque disfruta de los desafíos y la
oportunidad de desarrollo personal que se le brindan como gerente
de proyectos, teme los problemas interpersonales asociados con el
puesto. A veces se siente como un niñero glorificado repartiendo
tareas, controlando el progreso y asegurándose de que todos estén
haciendo lo que les corresponde. Recientemente, Colin leyó un
artículo que recomendaba un enfoque muy diferente para el gerente
de proyecto al supervisar y controlar a los miembros del equipo.
Colin pensó que era una idea útil y decidió probarla en su próximo
proyecto.
El proyecto en cuestión implicó tomar una decisión sobre si implementar
un sistema de costeo basado en actividades (ABC) en toda la organización. Colin
había sido una vez el gerente a cargo de implementar un sistema de costos de
procesos en esta misma división, por lo que se sentía muy cómodo con su
capacidad para liderar el equipo y resolver esta pregunta. Definió el objetivo del
proyecto y detalló todas las tareas principales involucradas, así como la mayoría
de las subtareas. Cuando tuvo lugar la primera reunión del equipo del proyecto,
Colin se sentía más seguro acerca del control y la dirección del proyecto que al
comienzo de cualquiera de sus proyectos anteriores. Tenía objetivos y tareas
definidos específicamente
18. ¿Cómo organizaría un proyecto para desarrollar un complejo
¿Producto nuevo, como una nueva máquina de fax, copia, escáner,
impresora en color? ¿Cómo se organizaría si el producto fuera más
simple, como una nueva unidad flash?
19.¿Cuál crees que puede ser el propósito de una EDT? ¿Cómo podría
ayudar al PM en la organización del proyecto?
20.¿Por qué cree que el conflicto total promedio aumenta durante la
“fase inicial del programa” (Tabla 5.3)?
21.¿Cuál debería ser el papel del director de proyecto en la gestión de
conflictos?
22. ¿Es ético emplear la gestión participativa únicamente como
forma de motivar a los empleados?
23.¿Cuáles son los pros y los contras de que el jefe de una PMO
informe a la alta dirección? ¿A la gestión departamental?
24. ¿La madurez de la gestión de proyectos se centra en mejorar
múltiples proyectos o proyectos únicos?
25.¿Cuáles de los muchos propósitos de la gestión de la cartera de proyectos son
más importantes para una empresa con una baja madurez en la gestión de
proyectos? ¿Cuál para una empresa con alta madurez?
para cada miembro del equipo y se le asignaron fechas de finalización para
cada tarea. Incluso había inventado “contratos” individuales para que cada
miembro del equipo los firmara como una indicación de su compromiso de
completar las tareas asignadas según las fechas programadas. La reunión
transcurrió sin problemas, casi sin comentarios de los miembros del
equipo. Todos tomaron una copia de su “contrato” y se fueron a trabajar
en el proyecto. Colin estaba extasiado por el éxito de este nuevo enfoque.
Preguntas
¿Crees que se sentirá de la misma manera en 6 semanas a partir de
ahora? Compare este enfoque con su enfoque anterior.
Hydrobuck
Hydrobuck es un productor de tamaño mediano de motores fuera de
borda a gasolina. En el pasado, ha fabricado y comercializado con éxito
motores en el rango de 3 a 40 caballos de fuerza. Los ejecutivos de
Hydrobuck ahora están interesados en motores más grandes e incluso les
gustaría producir motores en el rango de 50 a 150 caballos de fuerza.
El funcionamiento interno de los motores grandes es bastante similar al de los
motores más pequeños. Sin embargo, los motores fueraborda grandes y de alto
rendimiento requieren un ajuste de potencia. La compensación hidráulica es
simplemente un sistema hidráulico que sirve para inclinar el motor fuera de borda.

hacia arriba o hacia abajo en el espejo de popa del barco. Hydrobuck no puede
comercializar con éxito los motores fuera de borda más grandes sin diseñar un sistema
de compensación de potencia para complementar el motor.
La empresa tiene seguridad financiera y es el principal productor de
pequeños motores fuera de borda. La dirección ha decidido que los siguientes
objetivos deben cumplirse en los próximos 2 años:
1. Diseñe un sistema de compensación hidráulica de calidad.
2. Diseñar y construir el equipo para producir dicho sistema.
eficientemente.
3. Desarrollar las operaciones necesarias para instalar el sistema en el
Motor fuera de borda.
Proyecto de clase integradora continua
El trabajo de organizar el proyecto para una ejecución rápida y competente dentro del
presupuesto es un factor importante en el éxito de cada proyecto. Aquí no nos preocupa
dónde reside el proyecto en la universidad y a quién informa (informa al instructor), sino
más bien la organización interna del proyecto. Puede manejarse como un conjunto de
tareas donde todos en la clase tienen algunas responsabilidades asignadas y un tiempo
específico para entregar los resultados, o mediante un conjunto de equipos
responsables de diferentes conjuntos de tareas del proyecto. Si la clase es pequeña, lo
primero puede ser adecuado, pero para una clase más grande, puede ser más eficiente
y práctico establecer subequipos (aunque probablemente NO una tercera capa de sub-
sub-equipos). Para una clase de, digamos, 35, cinco o seis subequipos pueden ser
óptimos. Esto da un conjunto uniforme de alrededor de cinco a siete informes directos
para cada
Bibliografía
Aubry, M. “Transformaciones de la oficina de gestión de proyectos:
efectos directos y moderadores que mejoran el rendimiento y Matu
ridad ". Diario de gestión de proyectos, Noviembre de 2015.
Baker, B. "En común".Diario de gestión de proyectos,
Septiembre de 2007.
Block, TR "El fenómeno de la oficina de proyectos". PM Network,
Marzo de 1998.
Block, TR "Los siete secretos de una oficina de proyectos exitosa".
PM Network, Abril de 1999.
Block, TR y JD Frame. "Oficina de proyectos de hoy: calibrar
actitudes".PM Network, Agosto de 2001.
Bolles, D. "La Oficina de Apoyo al Proyecto".PM Network,
Marzo de 1998.
Bushe, GR, "Cuando la gente va y viene". El Wall Street
Diario, 23 de agosto de 2010.
Bibliografía179
La tecnología, las instalaciones y las habilidades de marketing
necesarias para producir y vender los motores grandes ya existen dentro
de la empresa.
Preguntas
¿Qué tipos alternativos de organización de proyectos se adaptarían al
desarrollo del sistema de compensación hidráulica? ¿Cuál sería mejor
si la madurez de la gestión de proyectos de Hydrobuck es alta? ¿Si es
bajo? Analice sus razones para seleccionar este tipo de
organizaciones.
gerente, incluido el PM. Por supuesto, algunos subequipos pueden
necesitar menos trabajadores y otros más, pero deben tener el
tamaño adecuado. Una vez más, recuerde que una limitación de la
organización es que los subequipos no pueden ser completamente
independientes. Hay dos razones para esto. Una es que hacer parte
del trabajo en todos los capítulos será más valioso para un estudiante
individual (por ejemplo, responder todas las preguntas de repaso)
que hacer todo el trabajo de un solo capítulo y luego ignorar todos
los demás temas. La segunda es que en los proyectos reales suele
haber una interacción considerable, incluso conflicto. Si el proyecto
se puede dividir en un conjunto de tareas que pueden ser realizadas
por diferentes departamentos sin interactuar entre sí, ¡no es
necesario configurar un proyecto para hacer el trabajo!
Carlisle, COMO "MacGregor". Dinámica organizacional. Nuevo
York: AMACOM, verano de 1976.
Cicmil, S. y D. Hodgson. "Nuevas posibilidades para la teoría de
la gestión de proyectos: un juicio crítico".Gestión de proyectos
Diario, Diciembre de 2006.
Cleland, DI Gestión estratégica de equipos. Nueva York:
Wiley, 1996.
de Laat, PB "Gestión matricial de proyectos y luchas de poder: un
estudio de caso de un laboratorio de I + D". IEEE Engi-
revisión de gestión neering,Invierno de 1995. Reimpreso de
Relaciones humanas, Vol. 47, N ° 9, 1994.
Dewhurst, HD "Equipos de proyecto: ¿Qué hemos aprendido?"
PM Network, Abril de 1998.
Dinsmore, PC, "¿Qué tan adulta es su organización?"
PM Network, Junio de 1998.
180CAPÍTULO 5 El proyecto en la estructura organizativa
Dinsmore, PC "Converging on Enterprise Project
Management". PM Network, Octubre de 1998.
Gale, SF "The PMO Survival Guide". PM Network, noviembre
2010.
Gale, SF "La PMO: algo de valor". PM Network,
Agosto de 2011.
Gale, SF "Se busca la tripulación adecuada". PM Network, diciembre
2013.
Gann, D., S. Salter, M. Dodgson y N. Phillips. "Inside the World of the
Project Baron".Revisión de la gestión Sloan del MIT,
Primavera de 2012.
Grant, RM "El futuro de la gestión: ¿Adónde nos lleva Gary
Hamel?" Planificación a largo plazo, 2008, págs. 469–482.
Gratton, L. “Trabajando juntos. . . Cuando estén separados ".mundo financiero
Diario, 16-17 de junio de 2007.
Greengard, S. “¿No hay PMO? Cómo saber cuándo lo necesita ".
PM Network, Diciembre 2013.
Él, J. “Contrarrestar la conducción libre con la moral del equipo: una
Estudio experimental." Diario de gestión de proyectos, junio
2012.
Herzberg, FH "Una vez más: ¿Cómo motivar a los
empleados?" Harvard Business Review, Enero febrero
1968.
Ibbs, CW y YH Kwak. "Evaluación de la gestión de proyectos
Madurez." Diario de gestión de proyectos, Marzo de 2000.
Kalu, T. Ch. U. “Un marco para la gestión de proyectos
en organizaciones complejas ". Transacciones IEEE sobre
gestión de ingeniería, Mayo de 1993.
Kotter, JP "Liderar el cambio: por qué fracasan los esfuerzos de
transformación".Harvard Business Review,Marzo / abril de 1995.
Reimpreso en Revisión de gestión de ingeniería IEEE,
Primavera de 1997.
KPMG, "Gestión global de proyectos de TI". <http://www.kpmg
. com />, 2005.
Lechler, G. y D. Dvir. “Una taxonomía alternativa de las estructuras de
gestión de proyectos: vincular las estructuras de gestión de proyectos
tures y el éxito del proyecto ". Gestión de ingeniería IEEE
Revisar, Vol. 57, N ° 2, 2010.
El siguiente caso describe una empresa que lucha con su estructura organizativa a medida que expande su
exitoso negocio comercial en el ámbito de los contratos gubernamentales. Sin embargo, esta nueva fuente
de negocios requiere una amplia competencia en la gestión de proyectos, que es nueva para la empresa. A
medida que crece el negocio gubernamental, la empresa ha seguido alterando su estructura organizativa,
pero sus sistemas de rendimiento e incentivos también deben cambiarse ahora, y el impacto de esos
cambios en el negocio comercial no está claro.
Caso
Industrias Bellota2 Harold R. Kerzner, PhD
Acorn Industries, antes de julio de 1996, era una corporación relativamente
pequeña del Medio Oeste que se ocupaba de una sola línea de productos. La
2Reproducido con permiso. Copyright John Wiley & Sons, 2013.
Lencioni, P. Las cinco disfunciones de un equipo. San Francisco,
CA: Jossey-Bass, 2002.
Levine, HA “Gestión de proyectos empresariales: ¿Qué necesitan los
usuarios? ¿Qué pueden tener? "PM Network, Julio de 1998.
Liu, L. y P. Yetton. "Los efectos contingentes en el desempeño del proyecto
de la realización de revisiones de proyectos y la implementación de
oficinas de gestión de proyectos".Transacciones IEEE en Engi-
gestión neering Noviembre de 2007.
Lubianiker, S. "Abriendo el libro sobre el modelo de madurez
abierto". PM Network, Marzo de 2000.
Mihalic, J. "De la Junta: liderando el camino con el liderazgo
intelectual". PMI hoy, Septiembre 2013.
Nelson, B. "EnergizedTeams: RealWorldExamples". PMNetwork,
Julio de 1998.
Pennypacker, JS y K.P. Grant. “ProjectManagementMaturity: An
IndustryBenchmark”.Diario de gestión de proyectos, Marzo de 2003.
Pinto, JK "Doce maneras de sacar lo mínimo de usted mismo y de
su proyecto". PM Network, Mayo de 1997.
Instituto de manejo proyectos. "La encuesta revela cómo
triunfan las organizaciones".PMI hoy, Febrero de 2011.
Instituto de manejo proyectos. "Sesión de trabajo de investigación:
Transformación y transformación: el ciclo de vida, la asignación de
roles y el futuro de la PMO".PMI hoy, Enero de 2013a.
Instituto de manejo proyectos. "Thought Leadership Series:
PMO: esencial para gestionar iniciativas estratégicas".PMI
Hoy, Diciembre de 2013b.
Tennant, D. "PMO Failure: An Observation", PM Network,
Octubre de 2001.
Thamhain, HJ y DL Wilemon. "Gestión de conflictos en los ciclos de vida de los
proyectos".Revisión de la gestión de Sloan, Verano de 1975.
Tippet, DD y JF Peters. "TeamBuilding y Project Management:
¿Cómo lo estamos haciendo?"Revista de gestión de proyectos,
Diciembre de 1995.
Underwood, R., “OK, todos, ¡hagamos esto! Gestión de proyectos
y colaboración con compañeros de trabajo ".Revista Inc.,
Julio de 2008.
Williams, G. "Implementación de una solución de gestión de
proyectos empresariales". PM Network, Octubre de 1997.
La empresa se ocupaba únicamente de contratos comerciales y rara
vez, si es que alguna vez, consideraba presentar propuestas para
contratos gubernamentales. La corporación en ese momento
funcionaba bajo una forma tradicional de estructura organizacional,
aunque poseía una filosofía gerencial algo descentralizada dentro de
cada división. En 1993, la alta dirección decidió que la dirección de la