Facultad de Ciencias Sociales, Área de

Empresa
Prof. José Luis Pérez Martínez
Máster Universitario en Dirección y Organización de
Proyectos
Fundamentos de la Dirección de Proyectos y Marco
Conceptual

Fundamentos en la Dirección de
Proyectos y Marco Conceptual
Nota técnica 4. Aplicación práctica
Nombre y apellidos

Cargo

Introducción 3

La aplicación práctica según el ciclo de vida del proyecto 4

Cómo determinar el ciclo de vida del proyecto en la práctica 4

El rol de la PMO en ciclos de vida adaptativos o ágiles 8

Mejores prácticas. Tips para casos reales 9

¿Por qué fracasan en la práctica los proyectos tecnológicos? 11

Overambition 12

Ignorance 13

Arrogance 13

Abstinence 14

Fraudulence 14

Resumen global de la asignatura 19

FDP – UD4. Aplicación práctica 2021

[2]
Introducción
Estamos en la última unidad didáctica de la asignatura Fundamentos de la Dirección de Proyectos y
Marco Conceptual. Esta unidad, como en el resto de las asignaturas del programa, se dedicará a
analizar tres aspectos principales:

 La influencia del tipo de ciclo de vida del proyecto en la aplicación del contenido de la
asignatura.
 Las mejores prácticas en la vida real relacionadas con dicho contenido
 Las conclusiones que obtenemos de lo aprendido.

Y, ¿por qué nos parece que debemos terminar la asignatura revisando estos tres aspectos?

Porque, como se irá vislumbrando a lo largo del Máster, un PM no se va a encontrar con el mismo
proyecto siempre y no va a aplicar su experiencia y conocimientos de la misma forma. Uno de los ejes
que determinará en gran medida cómo será esa aplicación será la tipología de ciclo de vida que tenga
su proyecto.

Es necesario, por tanto, que las distintas asignaturas realicen una reflexión sobre los matices que
presentarán sus contenidos según esa tipología.

Por otra parte, estamos en un Máster. Por definición, los programas de estudios calificados de esta
forma deben tener una vertiente eminentemente práctica. Eso no se cumpliría si no terminamos la
asignatura con otra reflexión, en este caso relacionada con la aplicación en la vida real de sus
contenidos y, aún más, la “mejor” aplicación.

Finalmente, es conveniente fijar los puntos clave del contenido de la asignatura, acudiendo a un
apartado de “conclusiones o resumen” que sirva de colofón didáctico a todo lo aprendido.

Dicho lo cual, pasamos a tratar los temas referidos.

FDP – UD4. Aplicación práctica 2021

[3]
El ciclo de vida del proyecto en la práctica
El ciclo de vida del proyecto en cuanto a las fases en las que se desarrolla éste, junto con sus
tipologías, se ha estudiado en la Unidad Didáctica 2 de esta asignatura inicial del Máster.

Representa un elemento estructural para el PM y su posición respecto al mismo dista mucho de ser
determinante ya que, en nuestra opinión, depende mucho más de circunstancias del proyecto que de
la opinión que tenga el propio líder. Como hemos visto, para el PMBOK 7ª ed, estamos ante un
“dominio de rendimiento” del proyecto.

En esta Unidad Didáctica dirigida a la aplicación práctica de lo aprendido en la asignatura, nos

interesa detenernos en la posición que va a tener el PM en un caso real. ¿Puede decidir o no al
respecto? Nuestra respuesta inicial es no, eso sí, con algunos matices.

En este sentido, no hubiera sido extraño del todo tratar este asunto como parte del entorno del
proyecto, aunque nosotros consideramos que, en este caso, el PM tiene algo más que decir. No tanto
como para decidirlo, pero sí para al menos, tras el análisis de las circunstancias de aquél, pensar qué
sería más conveniente hacer y, además, poder justificar dicha propuesta.

Cómo determinar el ciclo de vida del proyecto en la práctica

Estudiamos en la unidad didáctica 2 lo que era el ciclo de vida del proyecto, así como los principales
tipos de ciclos de vida y sus características.

No vamos a repetir todo lo que allí dijimos, obviamente. Ahora nos interesa la posición del PM ante
las circunstancias que pueden delimitar cuál debe ser el ciclo de vida del proyecto. Tampoco hubiera
sido extraño del todo tratar este asunto como parte del entorno del proyecto, aunque nosotros
consideramos que, en este caso, el PM tiene algo más que decir. No tanto como para decidirlo, pero
sí para al menos, tras el análisis de las circunstancias de aquél, pensar qué sería más conveniente
hacer.

Por un lado, y desde nuestro punto de vista de forma determinante, el tipo de ciclo de vida del
proyecto va a depender de la situación de requisitos al comienzo del proyecto. Sin ánimo de ser
exhaustivos:

 Son requisitos detallados y sin vocación de cambio ni por razones internas o externas (una
obra de construcción pública: una escuela, un parque, una operación asfalto).
 Son requisitos con cierto detalle, pero el ámbito y el contexto del proyecto pueden predecir
una alta probabilidad de modificación (mercados acelerados en su progresión, proyectos
tecnológicos en general, etc.).
 Son requisitos detallados en cuanto a que el proyecto podría comenzar y que se refieren a
alguna fase de este, pero, en realidad, no contienen todo lo necesario para definir el producto
final buscado (instalación de un software que tiene unos requerimientos de infraestructura
definidos -máquinas, memoria, almacenamiento mínimo, etc- pero cuya interacción con el
usuario está por ver o un plan de urbanización de una zona cuyas acometidas de suministros
están por decidir, etc.)

FDP – UD4. Aplicación práctica 2021

[4]
  Los requisitos conocidos son una estructura, un cierto enfoque, un esqueleto, una idea de lo
que se pretende sea el resultado final, pero no lo definen claramente (un nuevo refresco,
automatización de tareas administrativas con distintos tipos de usuarios, diseño de un plan de
producto, un plan de formación, etc.).

Está claro que no son situaciones estancas y tendremos casos intermedios. También puede ser que
nuestro cliente no viva precisamente en la “agilidad” y esté acostumbrado a recibir una planificación
detallada del proyecto a 1 año vista nada más empezar. Pero, al final, el nivel de predictibilidad real
sobre el alcance, en nuestra opinión, sería el que nos debería marcar el ciclo de vida del proyecto y
probablemente el tipo de metodología a utilizar.

Siguiendo con esta misma idea, y aunque en nuestra opinión en menor medida, es cierto que hay
otros aspectos del proyecto que pueden influir para considerar cuál debe ser el ciclo de vida
“conveniente”. En función del entorno del proyecto, el PM será soberano en la decisión o no, porque
también deberá tener en cuenta:

 La opinión del cliente para quién se desarrolla el proyecto.

 La formación del equipo de proyecto
 La cultura de proyecto, tanto de la empresa cliente como del proveedor del mismo
 El entorno cambiante del proyecto, en particular, el mercado con el que se relaciona su
resultado.

La siguiente figura estructura bastante bien la relación entre ciclo de vida del proyecto y ciertos
aspectos clave del proyecto:

Figura 1: Tipología de ciclos de proyectos y su relación con aspectos clave de estos

Fuente: PMBOK 6ª edición y elaboración propia

El tipo de ciclo de vida del proyecto, finalmente, va a ser capital, para empezar, con los roles de
ciertas personas del equipo y el grado de autoorganización de éste.

Respecto a cómo entender los requisitos de la asignatura en los distintos tipos de ciclo de vida del
proyecto, lo primero que debemos decir es que no se ve afectada la mayor parte del apartado
conceptual que hemos recorrido. Lógico cuando estamos ante una asignatura de corte introductorio.

FDP – UD4. Aplicación práctica 2021

[5]
Sí que es cierto que, a la hora de determinar el procedimiento o la metodología a seguir y los roles del
propio proyecto, el PM va a verse influido por la situación. De hecho, podríamos hablar de una
retroalimentación entre características del proyecto y ciclo de vida de éste.

Figura 2: Influencia del proyecto en su ciclo de vida y de éste en los roles del proyecto
Fuente: elaboración propia

Si las circunstancias conllevan la elección o necesidad de seguir un ciclo de vida predictivo (en
nuestra opinión, cada vez menos frecuente) podemos decir que el PM se encontraría en su “hábitat
natural”. Lógicamente, la organización del proyecto tendería a una mayor verticalidad que en otros
casos. El PM se rodearía de expertos en los distintos aspectos del proyecto y el equipo o equipos de
ejecución en los que podría existir un rol de coordinación, estarían reportando directamente al PM.
Esta es solo una de las opciones, lógicamente.

Figura 3: Un ejemplo de roles de proyecto en ciclo de vida predictivo

Fuente: elaboración propia

Si las circunstancias externas e internas del proyecto hacen (u obligan) al PM elegir un ciclo de vida
ágil o adaptativo, es más que posible que su rol cambie. Como tal, un PM al uso, es una figura un
tanto extraña y que queda un tanto difuminada entre el product owner y la autoorganización del
equipo. Probablemente, deberá subir un escalón 1 y mirar el proyecto desde arriba, intentando

1
Tomémoslo desde un punto de vista “físico” y no de nivel de poder.

FDP – UD4. Aplicación práctica 2021

[6]
colaborar en aspectos estructurales o contractuales, solucionando problemas a otro nivel. También
puede bajar dicho escalón y ser directamente el product owner, si tiene los conocimientos del negocio
suficientes. Si en esa situación, se decide seguir SCRUM, se necesitará un rol nuevo: Scrum Master.
Un ejemplo de roles en este caso sería el de la figura 4.

Figura 4: Un ejemplo de roles de proyecto en ciclo de vida adaptativo o ágil

Fuente: elaboración propia

En el caso de que tengamos unos requisitos parcialmente detallados pero que permiten plantearse
seguir con un ciclo de vida iterativo, realizando subproyectos por bloques de requisitos y tomando
realmente toda la actividad como un programa y, en ese caso, situarse al frente del programa y con
un PM al frente de cada subproyecto. Es más que probable que se precisase algún experto para cada
subproyecto (o también podría ser el mismo para los distintos subproyectos).

Lógicamente toda esta estructura también va a estar influida por el tamaño del proyecto y podría no
llegar a nivel de programa, por lo que la figura 5 es un mero ejemplo de una posible opción.

Figura 5: Un posible ejemplo de roles de proyecto en ciclo de vida iterativo o incremental

Fuente: elaboración propia

FDP – UD4. Aplicación práctica 2021

[7]
En resumen, el principal impacto en los contenidos de la asignatura por parte del tipo de ciclo de vida
del proyecto va a estar en las propias funciones del PM, en los roles del mismo, así como en la
metodología a utilizar.

El rol de la PMO en ciclos de vida adaptativos o ágiles

Para terminar, y por su más reciente origen, no nos resistimos a tratar, aunque sea brevemente, el rol
de la PMO en una forma de hacer “ágil” 2. En un primer análisis puede llegar a resultar un
contrasentido ese rol dentro de un mundo ágil en el que se va aprendiendo con la ejecución. Esta
circunstancia implica que realmente no existe previsibilidad más allá del siguiente sprint en cuanto al
devenir de cada proyecto y, consecuentemente, se dificulta enormemente su integración y
coordinación.

El enfoque metodológico que proponemos aquí está basado en la implantación de oficinas de

proyectos conocida como PMOStep (Mochal, PMOStep, 2002).

El modelo contempla una implementación evolutiva de los procesos de la PMO a través de la

ejecución de hasta 4 iteraciones evolutivas. Con este método, la organización está en posibilidad de
contar con una PMO básica, una vez concluida la primera iteración, en un periodo de 5 a 6 semanas,
sin considerar el tiempo requerido para llevar a cabo el diagnóstico, pues éste no siempre es
necesario.

Este enfoque tiene varias ventajas:

 Priorización: es posible instrumentar primero los procesos de la PMO que mayor prioridad
tengan para la organización y hacer ajustes, si es preciso, de una iteración a otra.
 Flexibilidad: desde varios puntos de vista pues, por una parte, permite revisar las prioridades
y hacer ajustes de una iteración a otra. Por otra parte, permite dosificar el esfuerzo de
implementación, considerando el grado de asimilación del cambio organizacional, o bien
dosificar el ritmo de implementación en función del presupuesto y recursos disponibles de la
organización.
 Resultados: la organización se beneficia de los resultados de la implantación, desde las
etapas tempranas del proyecto (5 a 6 semanas).
 Holístico: contempla todos los elementos que requiere un Sistema de Dirección de Proyectos
Profesional.

La implantación de una PMO-ágil3 se desarrolla en cuatro fases bastante reconocibles:

 Diagnóstico: entender el funcionamiento de la organización para tener un plan de acción

destinado a la implementación de la PMO.
 Planificación: donde se establece de forma acordada un plan detallado de acciones y
compromisos entre el personal asignado al proyecto y el cliente y patrocinador. En esta fase,
se incluye además la planificación de la formación centralizada en dirección de proyectos.

2
En este punto, seguimos el enfoque de https://www.pmi.org/learning/library/agile-project-
management-office-expectations-7069
3
Que salvo por el matiz de las iteraciones, podría servirnos perfectamente para implantar una PMO
estándar.

FDP – UD4. Aplicación práctica 2021

[8]
  Ejecución: definición conceptual de la PMO y de los entregables del proyecto de su
implementación y elaboración de los mismos, con su fase de pruebas correspondiente.
Incluye la formación planificada en la fase anterior.
 Implantación: donde se pone en marcha la primera iteración de la PMO que se irá
robusteciendo en fases subsiguientes.

En nuestra opinión, sigue quedando un tanto “oscura” la manera de llevar a cabo algunas de sus
funciones de una PMO en un entorno ágil con proyectos cuyo horizonte próximo es un sprint y
posiblemente con periodos de sprint diferentes en cada uno de ellos.

Mejores prácticas. Tips para casos reales

En el caso de esta asignatura, las buenas prácticas relacionadas con su contenido y aplicables a los
proyectos tienen que ser de tipo general, ligadas a la figura del PM y su cometido.

1) Respecto al periodo de licitación previo al inicio del proyecto

a. Como PM “futuro” nos interesará matizar el “empuje” comercial para hacerse con un
cliente evitando que se planteen plazos o costes que se tornen inviables al ejecutar.
b. Procurad que la oferta o el acuerdo recoja alguna cláusula “anti-cambios” o, por el
contrario, que reconozca que pueden existir (mejor que lo anterior) y que, ese caso,
se deberá revisar plazo y coste del proyecto.
c. Tanto si lo anterior ha sido posible como si no, pidamos el contrato firmado con el
cliente y leámoslo con detenimiento. Podemos encontrarnos sorpresas respecto a lo
hablado inicialmente.
2) Con relación al ciclo de vida del proyecto
a. El ciclo de vida del proyecto no debe ni puede ser una decisión basada en el gusto
personal. Analicemos las circunstancias del proyecto y decidamos en consecuencia.
b. Si los requisitos están un tanto “turbios” y no vemos la opción de utilizar un ciclo
adaptativo de proyecto, intentemos que se ejecute, de manera separada, un
subproyecto dedicado en exclusiva a definir con detalle dichos requisitos.
c. Si lo anterior no es posible, planifiquemos un periodo solvente (una reserva o
“colchón”) en nuestro cronograma para cierre de requisitos, sean totales o para cada
fase del proyecto.
d. Liderar un proyecto utilizando un ciclo ágil implica que tanto cliente como proveedor
acepten lo que significa y nuestro equipo esté entrenado en esa forma de trabajar.
3) Un aspecto clave, la transparencia
a. Cultivémosla, con todos los stakeholders, pero, en particular, con nuestro equipo. La
transparencia hoy es la confianza mañana.
b. Digamos que “no” cuando así lo pensemos. Nos ahorraremos disgustos posteriores.

FDP – UD4. Aplicación práctica 2021

[9]
 c. No seamos voluntaristas para llegar a unas fechas difíciles. No es una buena práctica
y se volverá contra nosotros más tarde.
4) Otra clave, el equipo
a. En la práctica no es extraño que el equipo se nos intente dar confeccionado.
Intentemos evitarlo, el equipo debemos elegirlo nosotros como PM. Si no nos lo
permiten, levantemos la mano y dejemos por escrito las discrepancias y su
justificación.
b. Cuidémosle. Llevar al equipo a un estrés permanente conducirá con toda seguridad
al fracaso del proyecto.
c. Motivemos su autoorganización e independencia.
d. El PM debe ser un líder, no un simple “jefe” que genera órdenes. Si el equipo nos
reconoce como líderes y aplicamos con él la premisa de la transparencia, tenemos
medio proyecto ganado.
5) Por lo que respecta a las metodologías
a. Están para ayudarnos, no para ser una restricción. Adaptémoslas a nuestro proyecto,
no al revés.
b. No pretendamos trabajar sin método, improvisando. No tengamos miedo en aplicar
“nuestro” método aunque no se haya convertido en algo certificable.
c. Repetimos aquí la idea antes avanzada: utilizar una metodología ágil no es solo
coger un taco de post it y un tablero y empezar a pegar elementos. Es mucho más,
involucra a cliente y proveedor y, sobre todo, al equipo, que precisará una formación
específica y tendrá que aprender a autoorganizarse.
d. Si vamos a trabajar para otro cliente de acuerdo con su organización, no olvidemos
interesarnos por si utilizan una metodología determinada para la realización de
proyectos.
6) Respecto a la PMO
a. Interesémonos por si existe en el entorno en el que vamos a trabajar.
b. En caso de existir, hagamos que pase de ser un riesgo a una oportunidad en cuanto
a nuestro trabajo como PM de un proyecto.
c. No es nada fácil implantar una PMO. Precisa una cierta cultura de la dirección de
proyectos, una fácil adaptación a estándares y un compromiso general de toda la
compañía.
7) En Dirección de Proyectos:
a. La experiencia es un grado, pero no nos relajemos: todos los proyectos son distintos.
b. Seamos humildes, es una soft skill muy recomendable en un PM.

FDP – UD4. Aplicación práctica 2021

[10]
 c. Dos soft skills adicionales básicas: liderazgo, comunicación
d. Hard skills: no queramos saberlo todo, no ocurre nada ni somos peores PM por tener
un especialista de negocio en el equipo.
e. Seamos conscientes de la gran cantidad de habilidades necesarias para ser un buen
PM. Eso no lo garantiza la mejor certificación del mundo por el mero hecho de
tenerla.
f. Cumplir el plan no es el objetivo, el objetivo es la satisfacción del cliente y la creación
de valor. Si el cliente está satisfecho no se hablará mucho de las fechas.
g. El alcance de un proyecto va a cambiar de una u otra forma y en mayor o menor
medida.

FDP – UD4. Aplicación práctica 2021

[11]
¿Por qué fracasan en la práctica los proyectos tecnológicos?
Es un hecho que muchos proyectos fracasan. Este hecho es especialmente relevante cuando
hablamos de proyectos tecnológicos.

Pero ¿qué significa el “fracaso” de un proyecto? Como vamos a ir comprobando a lo largo del
programa máster que habéis elegido, a lo largo de un proyecto vamos a tener que ir manejando tres
variables fundamentales (alcance, coste, plazo) además de otras que no quiero denominar
secundarias pero que tienen pueden tener un peso diferente en distintos proyectos.

Serán esas variables fundamentales, las que nos ayuden a calificar de “fracaso” o “éxito el resultado
de un proyecto.

Lo mejor para saber el significado de una palabra es acercarse al diccionario, en este caso, de la Real
Academia Española de la Lengua:

Como podemos observar, el término, aplicado a un proyecto, estaría diciendo que el proyecto ha
tenido un resultado adverso para el caso de negocio a resolver y le añadiría un componente negativo
en cuanto al desempeño realizado (funesto, caída con estrépito…).

Un estándar comúnmente aceptado para valorar el éxito de los proyectos en el ámbito tecnológico es
el Chaos Report. Este informe lo publica The Standish Group desde el año 1994 y clasifica los
proyectos por su resultado en tres categorías:

 Exitosos: cumplen las expectativas

 Discutidos: se terminan, pero con sobrecoste, sobreplazo y/o carencia de funcionalidades
necesarias
 Fallidos: se abandonan.

Pues bien, los datos en 2019 son bastante clarificadores: 16% fueron exitosos, un 53% se
considerarían en la categoría de discutidos y, en fin, un 31% habrían sido fallidos. Que conste que no
es que 2019 sea un año especialmente negativo. Son porcentajes habituales en este ámbito de la
dirección de proyectos. Veamos unos datos del periodo 2010 a 2014:

FDP – UD4. Aplicación práctica 2021

[12]
 Figura 6: Porcentaje de proyectos tecnológicos finalizados y su resultado
Fuente: www.thestandishgroup.com

Como vemos, los proyectos exitosos se mueven sobre un tercio del total, ni más ni menos. El estudio
se realiza sobre una muestra de 50.000 proyectos llevados a cabo en los últimos 5 años. En la última
información disponible, la de 2020, el porcentaje de exitosos se sitúa en un 31%.

Pero ¿qué tienen los proyectos tecnológicos para que se manifiesten tantas dificultades para su
realización exitosa? The Standish Group, habla de la existencia de 5 pecados capitales4:

Overambition

La ambición no es un problema, facilita la mejora continua y convierte la ejecución de un proyecto en

un reto constante por ser mejores.

El problema es la “sobre ambición”: el querer ir un paso más allá, sin tener en cuenta los recursos (y
sus habilidades reales y presentes), el coste y el interés real de los stakeholders. Es una actuación
diríamos que un poco patológica que lleva a hacer algo de forma perfeccionista como si solo existiera
esa opción. Pasa en algunos directores de proyecto.

Siempre debemos tener como guía el coste y el plazo. Calidad siempre, pero ligada a las
posibilidades financieras y de plazo que el proyecto permite.

Ignorance

4
Las imágenes de las definiciones están tomadas directamente de www.thestandishgroup.com

FDP – UD4. Aplicación práctica 2021

[13]
Este pecado tiene un componente de cierta desidia. Se da con cierta frecuencia en algunos
stakeholders, pensando que la especificación de la necesidad irá saliendo por sí sola. No es solo un
“no saber”, sino también un “no importa” o al menos no me compensa el esfuerzo de enterarme
suficientemente del asunto en cuestión.
Esta actitud, como puede verse ya solo terminológicamente, es incompatible con ser un “interesado”
real, al que se supone el proyecto no solo interesa, sino que afecta y del que se presupone una
actitud proactiva y positiva en aras de que el proyecto tenga éxito.

Arrogance

Este pecado se da en algunos directores de proyecto con necesidad de ser “el que manda” y también
en algunos supervisores de estos. También esconde, en ocasiones, una defensa ante un cierto
desconocimiento del tema en cuestión.
No obstante, en nuestra experiencia, lo hemos visto con cierta frecuencia en equipos o en ciertos
miembros del equipo y es dónde resulta más peligroso para el proyecto.
A veces, la necesidad de mantener el estatus en un ámbito como el tecnológico en el que, en un
plazo muy reducido, se producen avances que pueden hacer perder una cierta posición simplemente
por obsolescencia del conocimiento, puede llevar a una actitud defensiva que acabe por derivar en
arrogancia.

FDP – UD4. Aplicación práctica 2021

[14]
 Abstinence

Es un “alejamiento” del proyecto como preocupación. Se evidencia en una actitud pasiva al respecto.
A veces, es un signo de que el día a día es tan intenso que, con cierto automatismo, el equipo o
alguna persona del equipo, no consigue mantener la visión global ni la importancia de la participación.
También puede ser que no se esté permitiendo participar al equipo lo necesario tomando decisiones a
todos los niveles (incluso los de detalle) que lleven a ciertos miembros de aquél a no considerar el
proyecto como algo suyo.
A veces revela un cierto hastío de “lo mismo de siempre” o problemas específicos personales o con la
compañía por parte de ciertas personas.
Finalmente, también podría provenir de que la persona o personas no deseen ser identificados con el
proyecto por alguna razón de interés personal u organizacional. Puede tratarse de una actitud
consciente derivada de alguna lucha de poder en la organización en la que se esté desarrollando el
proyecto.

Fraudulence

Aquí ya hablamos de una actuación intencionada, deliberada, por interés personal, totalmente alejada
de lo que significa trabajar en equipo y sobre una base de realidad. La transparencia es clave como
habilidad del PM porque atrae a la confianza y le da credibilidad en sus actuaciones y a sus informes,
tanto frente a su cliente como con su equipo.

Este punto débil aparece cuando el director de proyecto no asume a tiempo y, sobre todo, no traslada
al nivel que corresponda, los problemas que puedan aparecer durante la ejecución del proyecto. Esto
puede conllevar a que dichos problemas crezcan sin tomar decisiones adecuadas a la situación. Se
entra en una rueda letal para el proyecto, al no “levantar la mano” para que se realicen las acciones
que correspondan o se tomen las decisiones al nivel que sea necesario. Al final, incluso, el director de
proyecto puede conseguir engañarse a sí mismo en cuanto a cuál es la situación real del proyecto.

FDP – UD4. Aplicación práctica 2021

[15]
Después de analizar la opinión de The Standish Group, y sus razones un tanto dramatizadas en su
exposición, vamos a efectuar nuestro propio análisis, basándonos en la experiencia. Estas son
nuestras hipótesis sobre por qué los proyectos tecnológicos tienen una tasa tan alta de fracaso:

 Con frecuencia, el punto de partida de un proyecto tecnológico es una mera idea general de
lo que se quiere resolver.
 Esta idea puede partir de la necesidad de cubrir alguna nueva regulación (aún no confirmado
su alcance) o de mejorar algún proceso que se entiende obsoleto.
 A partir de esa idea general, el proyecto se suele calificar previamente como anual o
plurianual. A veces, la calificación temporal la da la nueva regulación que hay que cubrir.
 La asignación presupuestaria se efectúa de manera general y previa al análisis del alcance.
La razón es que el reparto presupuestario de la compañía para la realización de proyectos se
produce con mucha antelación a que se pueda efectuar una mínima definición.
 El plazo es también un punto de partida habitual. Recalco, no el alcance sino el plazo 5. Esto
ocurre, en gran parte de las ocasiones, porque existe algún hito normativo o comercial que no
puede esperar más que hasta un límite.
 En conclusión, el director de proyecto recibe habitualmente como input:
o Un límite de plazo para finalizar.
o Un presupuesto máximo fijado.
o Un alcance generalmente poco detallado, reducido a unas pocas líneas en la
definición del proyecto.

Esto, que puede parecer un poco caricaturizado, podemos afirmar haberlo vivido en persona muchas
veces.

¿Y por qué ocurre esto? ¿Qué explica que se realicen esas asignaciones previas de plazo y coste
antes de determinar un nivel de alcance mínimo? ¿Cuál será la causa que explique un comienzo de
proyecto tan absurdo que, además, se ha demostrado acaba siempre en otros plazos y con otros
costes (generalmente mayores)?

 Es probable que se piense que el desarrollo tecnológico es más “maleable” en cuanto a su

producto (el software).
 Quizá se crea que la eficiencia y productividad en este campo permita ganar tiempo
posteriormente, cuando el análisis de la necesidad a cubrir se haya realizado.
 Por otra parte, no será la primera vez que escuchemos que “en informática todo se puede
hacer”. ¿se estará minusvalorando la asunción de riesgos?
 ¿Será que, en este ámbito, y en parte por todo lo dicho, se parta de una posición más
“arrogante” y/o “ambiciosa”?

Desde otro punto de partida, también aparece a veces la “ignorancia técnica” por el lado de los
solicitantes, que pueden pensar que las adaptaciones o los cambios de software son rápidas y fáciles.
Si unimos esa suposición a la ya comentada idea de que la posibilidad de reacción cuando el
producto es un software es mucho mayor, tenemos otra posible explicación a las preguntas iniciales.

Y, finalmente, los proyectos tecnológicos suelen partir de una dura licitación entre varios posibles
ejecutores, dentro de una ardua competencia, y estos se ven en la necesidad de aquilatar en demasía
precios y plazos para “vencer” en la licitación. Eso obliga a comprometerse a unos parámetros de

5
No hemos participado en ningún proyecto en el que no haya sido necesario modificar el plazo inicial de
finalización.

FDP – UD4. Aplicación práctica 2021

[16]
partida muy difíciles de cumplir desde la firma del contrato dado que el nivel de definición es cercano
a 0.

Cuando alguien quiere mecanizar un proceso manual, no suele quedarse en ese punto. Quiere,
además, mejorarlo (nada más lógico) y, estando claro el proceso, no lo está la mejora. Del “qué
quiere” al “cómo lo quiere” hay un mundo. Este aspecto es especialmente relevante en el caso de que
el proyecto teconológico incluya un interfaz de usuario con las múltiples posibilidades de lo que
significa usabilidad que cada persona tiene en su cabeza.

Hay algo que también considero característico en este tipo de proyectos. Se trata del voluntarismo
(mal entendido) que a veces se aplica para sustituir una especificación detallada que debería salir de
quién precisa satisfacer la necesidad. Esto hace que el equipo ejecutor, acuciado por un plazo sobre
el que no ha podido opinar (o ha dado igual lo que opine), interpreta o incluso “define” lo que ese
software tiene que ser capaz de hacer a un nivel de detalle totalmente fuera de lo que teniendo en
cuenta su rol debiera llegar. Rara vez acertará y, además, será responsable de las decisiones.

Vamos a terminar este apartado, revisando las conclusiones que realiza Henny Portman 6 tras la
publicación del The Standish Group Chaos Report de 2020. Es un análisis interesante que lleva a un
terreno muy práctico el interior de los proyectos que consiguen el éxito.

Henny Portman es Blogger, articulista, coach, formador en metodologías de proyectos y director de

Portman PM [O]. Ha publicado diversos libros sobre Project Management.

Figura 7: Los proyectos tecnológicos de éxito. Las claves

Fuente: Chaos Report 2020 y https://hennyportman.wordpress.com/

6
https://hennyportman.wordpress.com/

FDP – UD4. Aplicación práctica 2021

[17]
La información más actualizada del Chaos Report, hasta la fecha, nos sigue manteniendo en un nivel
de éxito de solo el 31% en relación con los proyectos tecnológicos.

El informe basa el éxito de los proyectos en tres bloques: Place, Team, Sponsor. El quid de la
cuestión está en que el nivel de madurez de estos bloques es determinante en el éxito del proyecto.

 The Good Place

o Se identifica “lugar” con “entorno”. Es donde trabaja el equipo dedicado a crear el
producto final.
o Este entorno del equipo y el espónsor es fundamental y se afirma que el más difícil
de manejar, en particular, porque al final ese entorno depende de las personas que
se encuentran en él.
o En esta línea, el hecho de que puedan existir personas que ayuden, pero también
personas que dificulten el proyecto, es otra roca sobre el éxito del proyecto..
o En este apartado el informe sitúa como elemento importante a los 5 pecados
capitales que hemos analizado anteriormente. Pero también integra aquí los factores
de decisión, emocionales, de comunicación, el nivel de involucración del cliente final,
la organización de la empresa, etc.
 The Good Team

o El informe no hace más que recalcar un punto que ya no nos sorprende: es el equipo
el que consigue el producto final.
o Otro punto que cada vez está siendo más reconocido por todas las metodologías es
que la creación de valor como elemento clave del resultado. Si el producto no añade
valor a la organización, el proyecto habrá sido en vano.
o El informe recomienda equipos pequeños. Estamos totalmente de acuerdo´, pero el
problema es que no siempre es posible.
o Si no es posible lo anterior, lo que sí podemos intentar es realizar una división del
trabajo que permita acercarse a ese objetivo.
o Los aspectos clave que se indican en este apartado son la comunicación, la
aceptación, el respeto mutuo, los conflictos y su solución adecuada, la resolución de
problemas y, por supuesto, los 5 pecados capitales que es un elemento troncal.
 The Good Sponsor

o El patrocinador del proyecto es definido en el informe como el “alma” de éste. Sin

patrocinador no hay proyecto.
o Se entiende que el patrocinador tiene como función principal proveer de recursos al
proyecto, por tanto, parece obvio que su importancia es crucial.
o El informe llega a firmar que mejorar las habilidades del patrocinador es el punto
crucial del éxito del proyecto y que probablemente sea el más fácil de realizar.
o Los elementos que integra en este bloque son los de visión o estrategia, pasión,
tensión, la influencia y la relación con personas.
o Pero ¿dónde está el patrocinador? En una estructura base de un proyecto
tecnológico donde tenemos a un lado la “parte cliente” y, al otro, la “parte proveedor”,
lo encontraríamos formando parte de la “parte cliente” 7. Pero ¿es el director del
proyecto por parte del cliente? Podría ser, pero no es lo habitual. Lo que existe una

7
También veremos a veces que se habla de la existencia de un patrocinador tanto del lado del cliente como del
proveedor. Podrían perfectamente representar los dos niveles más altos de ambas organizaciones respecto al
ámbito contractual.

FDP – UD4. Aplicación práctica 2021

[18]
 figura que está relacionada con el negocio que es ámbito del proyecto que es quien
suele tener este rol y que da instrucciones a ese director proyecto del cliente
o En la figura siguiente, podemos observar una estructura bastante típica de proyecto
con un cliente y un proveedor y dónde situamos a la figura del patrocinador.

Figura 8: El patrocinador o sponsor del proyecto.

Fuente: https://generacionproyectos.wordpress.com/

FDP – UD4. Aplicación práctica 2021

[19]
Resumen global de la asignatura
.

Un proyecto se caracteriza por:

 Tener un objetivo que debe cumplir las siglas S.M.A.R.T

 El resultado debe ser algo novedoso
 Se realiza por personas
 Es temporal, existiendo restricción de plazo
 Existe restricción de costes.

Hay que diferenciar proyecto y actividad operativa. Una actividad

operativa no es temporal sino permanente y forma parte de las
actuaciones del día a día en una compañía.

Un director de proyectos tiene que ser un líder, pero necesita tener

muchas otras habilidades para poder llevar a cabo su labor. La
metodología IPMA nos habla de 29, clasificadas en tres bloques:

 Práctica: planificación, costes, cronograma, alcance, riesgos, etc.

 Personas: liderazgo, trabajo en equipo, comunicación,
transparencia, resolución de conflictos, etc.
 Perspectiva: estrategia, visión de mercado, estándares, normativa
y su evolución, globalización,

A nivel teórico, es importante diferenciar proyecto, programa y portafolio:

 Programa es un conjunto de proyectos interdependientes.

 Portafolio es un conjunto de proyectos y programas, no
necesariamente interdependientes entre todos ellos, que pone en
marcha una idea o plan estratégico en una compañía

Las metodologías de dirección de proyectos son “herramientas

sistemáticas” que deben ayudar al director de proyectos a llevar a cabo
su trabajo, pero no lo hacen por él.

FDP – UD4. Aplicación práctica 2021

[20]
Existen muchas asociaciones promotoras de buenas prácticas y
distintas certificaciones en cada una de ellas. Destacamos:

 PMI
 PRINCE2
 IPMA
 PM2
 PM4R
 SCRUM

El ciclo de vida del proyecto suele definirse como el conjunto y tipo de

fases que lo conforman. No es inmediato saber el ciclo de vida de
nuestro proyecto, sino que viene determinado por las circunstancias del
propio proyecto. Diferenciamos:

 Predictivos
 Iterativos
 Adaptativos o ágiles

Una PMO (Project Management Office) es un departamento o área de

una organización cuyo cometido es homogeneizar las metodologías
utilizadas en la gestión de proyectos y ejercer un cierto control sobre las
ejecuciones de estos. En función de la intensidad de ese control,
diferenciamos:

 PMO de apoyo
 PMO de control
 PMO directiva

El PM no maneja todos los hilos que afectan al proyecto, sino que está
influido y mediatizado por el entorno. En este entorno, existen factores
internos y externos que, en general, no serán modificables por el PM. Es
importante para desarrollar su labor de manera efectiva que se informe
de dichos factores.

El PM debe intentar ser conocedor del proyecto desde el momento más

inicial posible y solicitar estar presente a la hora de la redacción de la
oferta que su compañía presenta a la hora de la licitación.

FDP – UD4. Aplicación práctica 2021

[21]
La gestión de proyectos no es una disciplina moderna. Los primeros
proyectos datan del mundo antiguo. Es a partir de los años 50 del siglo
pasado cuando se sistematiza y generaliza.

FDP – UD4. Aplicación práctica 2021

[22]
Finalicemos con la última transparencia del Informe del Project Management 2021 elaborado por PMI
Spain, que trasluce las opiniones de PM españoles sobre diversos aspectos de esta profesión y que
se relacionan con distintos aspectos que hemos visto en la asignatura.

Figura 9: Conclusiones
Fuente: Informe del Project Management en 2021. PMI Spain

REFLEXIÓN: ¿consideras que es siempre necesario ser fiel a una manera de hacer
las cosas? ¿no se dice que cada proyecto es distinto? ¿por qué no vamos a aplicar

FDP – UD4. Aplicación práctica 2021

[23]
distintos conjuntos de buenas prácticas e incluso intersecciones de ellos en nuestra
labor como PM?

Bibliografía

Buttrick, R. (2012). PRINCE2 and the National and International Standards. The Stationery Office.

Directrices para la gestión de proyectos. (2012). UNE-ISO 21500. AENOR.

Fleming, Q., y Koppelman, J. M. J. (1998). Earned value project management. The Journal of
Defense Software Engineering, 16(July), 19-23. http://doi.org/10.1016/S0263-7863(97)82251-X

Gasik, S. (2011). Comparison of ISO 21500 and PMBOK ® Guide.

Holopainen, M., y Toivonen, M. (2012). Weak signals: Ansoff today. Futures, 44(3), 198-205.
http://doi.org/10.1016/j.futures.2011.10.002

IPMA Competence Baseline Version 4.0. (s. f.) (2019). International Project Management Association.

Project Management Institute. (2017). Project Management Body of Knowledge (PMBOK). (I. Project
Management Institute, Ed.) (6th edition). Project Management Institute, Inc.

Project Management Institute. (2021). Project Management Body of Knowledge (PMBOK). (I. Project
Management Institute, Ed.) (7th edition). Project Management Institute, Inc.

www.thestandishgroup.com

www.greenprojectmanagement.org

FDP – UD4. Aplicación práctica 2021

[24]