El Arte de la Gestión de Proyectos
Este elemento es una expansión del contenido de los cursos y guías de Lawi. Ofrece hechos, comentarios y análisis sobre el arte de la Gestión de Proyectos. Puede ser de interés consultar lo siguiente:
- Glosario de Gestión de Proyectos
- Glosario de Gestión Cuantitativa Empresarial
- Análisis Estratégico
- Análisis de Negocios
- Planificación de la Empresa
La Gestión de Proyectos
Como se ve, hay numerosos contenidos en esta plataforma digital acerca de la gestión de proyectos.
Entonces, ¿qué es la gestión de proyectos y, para el caso, qué es un proyecto? Se puede definir un proyecto como un esfuerzo temporal emprendido para crear un producto, servicio o resultado único (hay otras definiciones en la introducción a este tema). Esto significa que un proyecto se realiza una sola vez. Si es repetitivo, no es un proyecto. Un proyecto debe tener unos puntos de partida y de llegada definidos (tiempo), un presupuesto (coste), un alcance -o magnitud- claramente definido del trabajo que debe realizarse y unos requisitos de rendimiento específicos que deben cumplirse. Decimos “debería” porque rara vez un proyecto se ajusta a la definición deseada. Estas limitaciones de un proyecto, por cierto, se denominan a lo largo de este libro los objetivos PCTS (rendimiento, coste, tiempo, alcance).
Un proyecto, en suma, es un esfuerzo temporal emprendido para producir un producto, servicio o resultado único.
El Dr. J. M. Juran, el difunto gurú de la gestión de la calidad, también define un proyecto como un problema programado para su solución. Me gusta esta definición porque me recuerda que todo proyecto se lleva a cabo para resolver algún tipo de problema para una empresa. Sin embargo, debo advertir que la palabra “problema” suele tener un significado negativo, y los proyectos se ocupan de tipos de problemas tanto positivos como negativos. Por ejemplo, desarrollar un nuevo producto es un problema, pero positivo, mientras que un proyecto de limpieza medioambiental se ocupa de un tipo de problema negativo.
“Un proyecto es un problema programado para su solución”.
-J. M. Juran
Fracasos de los proyectos
Los estudios actuales indican resultados dispares en cuanto a las tasas de éxito de la gestión de proyectos. El informe “Chaos” del Standish Group, centrado en proyectos de desarrollo de software, indica una tasa de éxito del 29%, con un 52% de retos y un 19% de fracasos. Cabe señalar que los factores de éxito se han “modernizado” para significar a tiempo, dentro del presupuesto y con un resultado satisfactorio. La tasa de éxito prácticamente no ha variado desde el informe de 2011. Standish sí destaca que los proyectos más pequeños tienen una tasa de éxito mucho mayor que los grandes. Gartner, una empresa de investigación y asesoramiento en TI, se hizo eco de estas conclusiones con informes recientes según los cuales los proyectos de mayor envergadura (aquellos con presupuestos superiores al millón de dólares) tienen tasas de fracaso más elevadas, que rondan el 28%.
Más reveladores fueron los datos comunicados recientemente por el Instituto de Gestión de Proyectos. El Project Management Institute (PMI) mide sistemáticamente el estado de la gestión de proyectos, programas y carteras. Su estudio “Pulse of the Profession” de 2015 revela algunas tendencias positivas, pero también indica que el porcentaje de proyectos que cumplen sus objetivos se ha mantenido estable en el 64% desde 2012. Para lograr una mejora, el Project Management Institute sugiere que las organizaciones vuelvan a los fundamentos.
Las tres áreas básicas citadas son las siguientes:
- Cultura. Trabaje para crear una mentalidad de gestión de proyectos.
- Talento. Céntrese en la gestión del talento, la formación continua y la transferencia formal de conocimientos.
- Proceso. Apoye la gestión de proyectos mediante el establecimiento y la adopción de prácticas y procesos de proyectos estandarizados.
Otra encuesta, basada en 28 años de gestión de proyectos, identificación de las mejores prácticas, consultoría de proyectos y formación, revela que cuanto más cambian las cosas, más permanecen igual. No se planifica lo suficiente. Grandes o pequeños, de software, de I+D o administrativos, los proyectos de éxito dependen de una buena planificación. Demasiados gestores de proyectos adoptan un enfoque de “listos para disparar” en un intento de completar un proyecto rápidamente. Muchas organizaciones no conceden a los gestores de proyectos un tiempo de planificación significativo o prácticamente ningún tiempo en absoluto. El resultado suele ser que se invierte mucho más tiempo y esfuerzo en corregir errores, calmar a las partes interesadas descontentas y dar marcha atrás en callejones sin salida. En resumen, la falta de una planificación adecuada hace que los proyectos fracasen.
La encuesta del Project Management Institute afirma que “es hora de que las organizaciones revisen los fundamentos de la gestión de proyectos y, esencialmente, vuelvan a lo básico” (p. 4). No podría estar más de acuerdo. Usted, el lector, debe sentar sus bases y comprender los fundamentos presentados aquí para garantizar la mejora y el éxito a medida que avanza y gestiona sus proyectos.
¿Qué es la gestión de proyectos?
Nota: Un término relacionado, la gestión ágil, es la aplicación de los principios del desarrollo ágil de software y del Lean Management a diversos procesos de gestión, en particular al desarrollo de productos.
La definición más o menos oficial de gestión de proyectos es la “aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir los requisitos del mismo”. La gestión de proyectos se lleva a cabo mediante la aplicación e integración de los 47 procesos de gestión de proyectos agrupados lógicamente, según el Project Management Institute, que comprenden los 5 Grupos de Procesos: iniciar, planificar, ejecutar, supervisar y controlar, y cerrar.
“La gestión de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para lograr los requisitos del mismo. La gestión de proyectos se logra mediante la aplicación e integración de los procesos de gestión de proyectos de iniciar, planificar, ejecutar, supervisar y controlar, y cerrar.”
-Guía del PMBOK, del Project Management Institute
La nueva Guía del Project Management Institute ha añadido cinco nuevos procesos de gestión de proyectos:
- Planificar la gestión del alcance.
- Planificar la gestión del calendario.
- Planificar la gestión de costes.
- Planificar la gestión de las partes interesadas.
- Controlar la gestión de las partes interesadas.
Este cambio hace hincapié en el requisito de que el equipo del proyecto planifique antes de gestionar. Los procesos Planificar la Gestión de las Partes Interesadas y Controlar la Implicación de las Partes Interesadas se han añadido para coincidir con la incorporación de la Gestión de las Partes Interesadas del Proyecto como nueva (décima) área de conocimiento (véase la página 22). Esta nueva área de conocimiento destaca la importancia de atraer adecuadamente a las partes interesadas del proyecto en las decisiones y actividades clave.
Los requisitos del proyecto incluyen los objetivos del PCTS mencionados anteriormente. Los diversos procesos de iniciación, planificación, etc. se abordan más adelante, y buena parte de los contenidos sobre la gestión de proyectos en la presente plataforma digital se dedican a explicar cómo se llevan a cabo estos procesos.
Sería mejor que la Guía del Project Management Institute especificara que un director de proyecto debe facilitar la planificación. Un error que cometen los directores de proyecto inexpertos es planificar los proyectos para sus equipos. No sólo no consiguen que se acepten sus planes, sino que éstos suelen estar llenos de agujeros. Los gestores no pueden pensar en todo, sus estimaciones de la duración de las tareas son erróneas y todo se desmorona una vez iniciados los proyectos. La primera regla de la gestión de proyectos es que las personas que deben hacer el trabajo ayuden a planificarlo.
La primera regla de la gestión de proyectos es que las personas que deben hacer el trabajo deben ayudar a planificarlo.
El papel del director de proyecto es el de un facilitador. Su trabajo consiste en ayudar al equipo a realizar el trabajo, “interferir” por el equipo, conseguir los escasos recursos que necesitan los miembros del equipo y protegerlos de las fuerzas externas que podrían perturbar el trabajo. No es un zar del proyecto. Debe ser -por encima de todo- una líder, en el sentido más estricto de la palabra.
La definición de liderazgo puede encontrarse en esta plataforma digital. Una aproximación sencilla es que el liderazgo es el arte de conseguir que los demás quieran hacer algo que usted cree que debe hacerse”. La palabra clave aquí es “querer. Los dictadores consiguen que los demás hagan las cosas que ellos quieren que se hagan. Lo mismo hacen los guardias que supervisan los equipos de trabajo de las prisiones. Pero un líder consigue que la gente quiera hacer el trabajo, y ésa es una diferencia significativa.
La planificación, la programación y el control del trabajo representan las partes de gestión o administrativas del trabajo. Pero, sin liderazgo, los proyectos tienden a limitarse a satisfacer los requisitos mínimos. Con liderazgo, pueden superar esos mínimos. En otro lado de esta plataforma online se ofrece una aplicación exhaustiva de las técnicas de liderazgo de proyectos.
No se trata sólo de programar
Una de las ideas erróneas más comunes sobre la gestión de proyectos es que se trata sólo de programar. En el último informe, Microsoft había vendido un número ingente de copias de Microsoft Project® y, sin embargo, la tasa de fracaso de los proyectos sigue siendo elevada. La programación es ciertamente una herramienta importante utilizada para gestionar proyectos, pero no es ni de lejos tan importante como desarrollar una comprensión compartida de lo que se supone que el proyecto debe lograr o construir una buena estructura de desglose del trabajo (EDT) para identificar todo el trabajo que debe realizarse. De hecho, si no practica una buena gestión de proyectos, lo único que va a hacer un calendario detallado es permitirle documentar sus fracasos con gran precisión.
Quiero hacer una puntualización sobre el software de programación. No importa demasiado qué paquete elija, ya que todos tienen puntos fuertes y débiles. Sin embargo, la tendencia es dar a la gente el software y esperar que aprendan a utilizarlo sin ninguna formación. Esto sencillamente no funciona. Las características del software de programación son tales que la mayoría de la gente no aprende las sutilezas por sí misma. No tienen tiempo porque están intentando hacer sus trabajos habituales, y no a todo el mundo se le da bien el aprendizaje a su propio ritmo. Usted no contrataría a una persona novata para manejar una máquina compleja en una fábrica y la pondría a trabajar sin formación porque sabe que destruirá algo o se lesionará. Entonces, ¿por qué hacerlo con el software?
El director de proyecto accidental
¿Se ha visto empujado de repente al papel de gestor de un proyecto sin el título de “gestor de proyecto” ni mucho apoyo? ¿Se ha considerado a sí mismo el director del proyecto y al equipo del proyecto? No es usted el único. Cada vez son más las personas que gestionan trabajos que se ajustan a la definición de proyecto de la Guía del Project Management Institute de 2013: “un esfuerzo temporal emprendido para crear un producto, servicio o resultado único”. Hay un plazo, un ámbito de trabajo que definir, recursos limitados y, a menudo, un presupuesto fijo.
“Los empresarios deben organizar su negocio para el éxito desarrollando una mentalidad de gestión de proyectos que les permita planificar, construir, dividir y conquistar”.
– Curtis L. Jenkins (De la visión a la realidad: deje de trabajar, empiece a vivir)
Aunque son menos formales y no requieren un equipo de proyecto, estos proyectos deben planificarse, programarse y controlarse. Debe entregarse un producto de proyecto excepcional/aceptable y el cliente debe quedar encantado o al menos satisfecho.
Aspectos esenciales de la gestión de proyectos para el no gestor de proyectos
En esta plataforma digital se trata en profundidad este tema, de interés para directores de proyecto no tradicionales, expertos en la materia, patrocinadores y colaboradores de proyectos. En especial, para directores de ventas, profesionales administrativos, directores de marketing, especialistas en adquisiciones y muchos otros tipos de empresas. Parece que todo el mundo está implicado en proyectos a algún nivel. Estos asistentes no son gestores de proyectos en el sentido tradicional, pero deben gestionar proyectos. Las herramientas de gestión de proyectos pueden ayudar. Las herramientas de proyectos son universales, pero que el valor es evidente en cómo se aplican las herramientas.
En primer lugar, evalúe el trabajo. ¿Está limitado por el alcance, el coste y los recursos limitados? ¿Tiene una fecha límite? A continuación, comprométase a gestionar el trabajo como un proyecto. Determine qué herramientas de proyecto serían adecuadas. Por ejemplo, un proyecto con un plazo de entrega de dos semanas requiere muchas menos aplicaciones de gestión de proyectos que un proyecto con un plazo de entrega de 50 semanas. Racionalice o amplíe su enfoque de gestión para adaptarlo a la longitud, anchura, profundidad y amplitud del proyecto.
La gran trampa: gestores de proyectos que trabajan
Es habitual que haya personas que ejerzan de gestores de proyectos y que, además, se les exija que realicen parte del trabajo real del proyecto. Ésta es una receta segura para los problemas. Si se trata de un verdadero equipo, formado por varias personas, la gestora del proyecto se encuentra inevitablemente dividida entre la gestión y la realización de su parte del trabajo. Naturalmente, el trabajo debe tener prioridad o el calendario se resbalará, así que opta por hacer el trabajo. Eso significa que la gestión no se lleva a cabo. Ella espera que se haga sola, pero nunca lo hace. Después de todo, si el equipo pudiera gestionarse a sí mismo, no habría necesidad de un gestor de proyectos en primer lugar. (¿Recuerda nuestra discusión sobre si la gestión de proyectos es importante?)
Por desgracia, cuando llegue el momento de su evaluación de rendimiento, le dirán que su gestión necesita mejorar. En realidad, lo que necesita es que se le permita practicar la gestión en primer lugar.
Sí, para equipos muy pequeños -quizá de hasta tres o cuatro personas- un gestor de proyectos puede hacer parte del trabajo. Pero, a medida que aumenta el tamaño de los equipos, se hace imposible trabajar y gestionar ambas cosas porque se ve constantemente apartado del trabajo por las necesidades de los miembros de su equipo.
Una de las razones de esta situación es que las organizaciones no comprenden del todo en qué consiste la gestión de proyectos y piensan que es posible que los individuos hagan ambas cosas. El resultado es que casi todo el mundo en la empresa intenta gestionar proyectos y, como ocurre en todas las disciplinas, algunos de ellos serán buenos en ello y otros no tendrán aptitud alguna. He descubierto que un enfoque mucho mejor es seleccionar a unas pocas personas que tengan la aptitud y el deseo de ser gestores de proyectos y dejarles que gestionen una serie de pequeños proyectos. Esto libera a las personas “técnicas” (por utilizar el término en sentido amplio) para que realicen el trabajo técnico sin tener que preocuparse de cuestiones administrativas, al tiempo que permite a los gestores de proyectos llegar a ser realmente buenos en su trabajo.
Queda fuera del alcance de esta sección hablar de cómo seleccionar a los gestores de proyectos, pero, para el lector interesado, el tema se trata en un libro de Robert K. Wysocki y James P. Lewis titulado The World-Class Project Manager (Perseus, 2001).
No se puede tener todo
Una de las causas habituales de los fracasos de los proyectos es que el patrocinador del proyecto exige que el director del proyecto termine el trabajo en un plazo determinado, dentro del presupuesto y con una magnitud o alcance determinados, al tiempo que alcanza unos niveles de rendimiento específicos. En otras palabras, el patrocinador dicta las cuatro limitaciones del proyecto. Esto no funciona.
La relación entre las restricciones P, C, T y S puede redactarse de la siguiente manera:
C = f (x) (P, T, S)
En otras palabras, el coste es una función del rendimiento, el tiempo y el alcance. Gráficamente, me gusta mostrarlo como un triángulo, en el que P, C y T son los lados y S es el área.
En geometría, sabemos que si nos dan valores para los lados de un triángulo, podemos calcular el área. O, si conocemos el área y la longitud de dos lados, podemos calcular la longitud del lado restante. Esto se traduce en una regla muy práctica de la gestión de proyectos: el patrocinador puede asignar valores a tres variables cualesquiera, pero el director del proyecto debe determinar la restante.
Supongamos que el patrocinador exige ciertos parámetros de rendimiento, tiempo y alcance para el proyecto. Es tarea del director del proyecto determinar lo que costará conseguir esos resultados. Sin embargo, siempre advierto a los directores de proyecto que deberían tener a un paramédico a su lado cuando den la cifra de costes al patrocinador porque probablemente sufrirá un derrame cerebral o un infarto y el paramédico tendrá que reanimarla.
Invariablemente, la madrina exclama: “¿Cómo puede costar tanto?”. Ella tenía una cifra en mente, y la suya siempre superará su cifra. Y ella puede decir: “Si va a costar tanto, no podemos justificar hacer el trabajo”. ¡Exacto! Y esa es la decisión que ella debe tomar. Pero es seguro que intentará que el director del proyecto se comprometa a una cifra inferior y, si lo hace, entonces sólo se prepara -y la prepara a ella- para sufrir una gran caída más adelante.
Es su obligación dar a la patrocinadora un coste válido para que pueda tomar una decisión válida sobre la conveniencia de realizar el proyecto. Si se deja intimidar para comprometerse con una cifra inferior, sólo conseguirá un desastre más adelante, y es mucho mejor que asuma sus responsabilidades ahora a que le cuelguen más tarde.
Por supuesto, existe otra posibilidad. Si ella dice que sólo puede permitirse una cantidad determinada por el trabajo, entonces usted puede ofrecerle reducir el alcance. Si el trabajo es viable con ese nivel de alcance, entonces el proyecto puede realizarse. De lo contrario, es prudente olvidarse de este proyecto y hacer otra cosa que pueda reportar beneficios a la empresa. Como alguien ha dicho, hay más probabilidades de que las cosas salgan accidentalmente mal en un proyecto que de que salgan accidentalmente bien. En términos de estimación de costes, esto significa que siempre hay más probabilidades de que el presupuesto se sobrepase que de que el proyecto salga por debajo del presupuesto. Es otra forma de enunciar la ley de Murphy: “Todo lo que pueda salir mal, saldrá mal”.
Basado en la experiencia de varios autores, mis opiniones, perspectivas y recomendaciones se expresarán a continuación (o en otros lugares de esta plataforma, respecto a las características en 2026 o antes, y el futuro de esta cuestión):
Hay más probabilidades de que las cosas salgan mal accidentalmente en un proyecto que de que salgan bien accidentalmente.
Revisor de hechos: Roth
Recursos
[rtbs name=”informes-jurídicos-y-sectoriales”] [rtbs name=”quieres-escribir-tu-libro”]Véase También
Véase también:
📬Si este tipo de historias es justo lo que buscas, y quieres recibir actualizaciones y mucho contenido que no creemos encuentres en otro lugar, suscríbete a este substack. Es gratis, y puedes cancelar tu suscripción cuando quieras: Qué piensas de este contenido? Estamos muy interesados en conocer tu opinión sobre este texto, para mejorar nuestras publicaciones. Por favor, comparte tus sugerencias en los comentarios. Revisaremos cada uno, y los tendremos en cuenta para ofrecer una mejor experiencia.- Construcción ágil
- Ingeniería arquitectónica
- Gestión de la construcción
- Ingeniería de costes
- Facilitación empresarial
- Ingeniería industrial
- Gestión de la producción de proyectos
- Software de gestión de proyectos
- Gestión de la cartera de proyectos
- Oficina de gestión de proyectos
- Gestión de la plantilla de proyectos
- Gestión de proyectos de software
- Ingeniería de sistemas
- Gestión Ágil
- Toma de decisiones
- Teoría de juegos
- Gestión del valor ganado
- Factores humanos
- Kanban (desarrollo)
- Investigación operativa
- Esquema de la gestión de proyectos
- Documentación postmortem (es un proceso utilizado para identificar las causas del fracaso de un proyecto y cómo evitarlas en el futuro)
- Arquitectura de procesos
- Gestión de programas
- Contabilidad del proyecto
- Gobernanza del proyecto
- Oficina de gestión de proyectos
- Simulación de gestión de proyectos
- Gestión de proyectos a pequeña escala
- Proceso de desarrollo de software
- Gestión de proyectos sociales
- Ciclo de vida del desarrollo de sistemas (SDLC)
Bibliografía
▷ Esperamos que haya sido de utilidad. Si conoces a alguien que pueda estar interesado en este tema, por favor comparte con él/ella este contenido. Es la mejor forma de ayudar al Proyecto Lawi.
Muy buena esta frase: El liderazgo es el arte de conseguir que los demás quieran hacer algo que usted cree que debe hacerse.
“A veces corro rápido cuando me apetece, pero si aumento el ritmo acorto la cantidad de tiempo que corro, la cuestión es dejar que el regocijo que siento al final de cada carrera se traslade al día siguiente. Es el mismo tipo de táctica que encuentro necesaria cuando escribo una novela. Paro cada día justo en el punto en el que siento que puedo escribir más. Si hago eso, el trabajo del día siguiente se desarrolla con sorprendente fluidez. Creo que Ernest Hemingway hacía algo parecido. Para seguir adelante, hay que mantener el ritmo. Esto es lo importante para los proyectos a largo plazo. Una vez que marque el ritmo, el resto le seguirá. El problema es conseguir que el volante gire a una velocidad determinada, y para llegar a ese punto se necesita tanta concentración y esfuerzo como uno pueda manejar”.
– Haruki Murakami (“De qué hablo cuando hablo de correr”)
Los hitos dependen del ciclo de vida del proyecto, por ejemplo:
Fase preliminar: reflexión sobre el valor del propio proyecto, en términos de oportunidad estratégica, en función de cómo se presente el futuro.
Etapa de lanzamiento del proyecto: la dirección de la empresa decide si lanza un proyecto concreto (justificado por un rendimiento esperado de la inversión, una restricción reglamentaria, etc.). A continuación, nombra a un gestor, a un jefe de proyecto y a un equipo. También les asigna un presupuesto y recursos materiales.
Fase de expresión de las necesidades: definición de lo que se espera (funciones previstas), el alcance, en qué se evaluará el proyecto, qué es importante y qué no lo es tanto.
Fase de validación de las necesidades: el cliente valida la expresión de sus necesidades (de modo que se puedan rastrear los cambios en el planteamiento de las necesidades y se justifiquen los posibles ajustes del plan del proyecto); son los cimientos sobre los que se construirá el proyecto.
Fase de viabilidad: elestudio de lo que es técnica y económicamente viable. Consulta con los posibles gestores del proyecto, comparación de las propuestas técnicas y financieras de los posibles contratistas.
Hito en la elección de la solución: firma del contrato en el que se especifica qué se hará y cómo se hará.
Fase de diseño: el director del proyecto coordina el trabajo sobre el “producto en papel”, para especificar lo que hay que hacer hasta el último tornillo.
Fase de lanzamiento (si la hay): cuando el “producto de papel” está suficientemente definido, podemos hacer balance antes de lanzar las obras.
Fase de ejecución: el proyecto se pone en marcha y los trabajos avanzan para trasladar el “producto de papel” a la realidad.
Fase de verificación (que puede comenzar muy pronto, sobre el “producto de papel”): sobre el producto real o sobre el producto de papel, comprobamos (o calculamos) que efectivamente se cumplen las características esperadas (con las posibles desviaciones, que luego habrá que gestionar).
Hito de cualificación: tras la verificación, la definición de referencia del producto es la correcta y no volverá a modificarse (al menos, no tan fácilmente).
Hito de entrega (y aceptación), también conocido como aceptación: el producto se entrega al cliente, que se convierte en su propietario (y puede expresar sus reservas sobre cualquier discrepancia encontrada). Este es el final del proyecto propiamente dicho.
La fase operativa, que suele comenzar con la eliminación de las reservas, y ve el final de la relación contractual.
Algunos comentarios adicionales:
Los nombres dados a los hitos dependen de la cultura empresarial del proyecto.
La definición del hito debe ser inequívoca y debe haber criterios observables o medibles que permitan evaluar objetivamente si se ha alcanzado el hito.
Las fases y los hitos pueden estar entrelazados, sobre todo cuando el hito no se utiliza como punto de control. Excepcionalmente, también puede ser el caso si la dirección del proyecto decide, de acuerdo con las partes implicadas, pasar a la fase siguiente con pleno conocimiento de causa, y la realización del hito puede aplazarse sin que ello suponga ningún riesgo para las fases posteriores.
Es importante el ciclo de vida del producto, es cierto.
Etapa de análisis de la receta:
En cuanto se pone a disposición o se recibe el entregable, es necesario realizar comprobaciones para asegurarse de que el resultado fabricado se ajusta al pedido realizado en el momento de la especificación. Estas comprobaciones adoptan la forma de rigurosas pruebas de aceptación basadas en los libros de pruebas que se han preparado.
Al final de la fase de aceptación, se firma un informe de aceptación final.
Dependiendo de la complejidad del proyecto, pueden ser necesarias secuencias de verificación globales.
Cuando se ha recurrido a la subcontratación, el final de la fase de aceptación es un hito importante, ya que desencadena el periodo de garantía legal durante el cual el cliente puede emprender acciones legales contra el proveedor de servicios.
Etapa dedifusión o despliegue:
El producto se pone a disposición del mercado o de los usuarios. Aquí es donde entra en juego la política de comunicación y, de forma más general, lo que se conoce como gestión del cambio.
En esta fase, el proyecto está terminado y su resultado (producto, servicio, cambio organizativo, etc.) entra en la fase operativa. La responsabilidad del resultado del proyecto se devuelve a la dirección (el patrocinador del proyecto), que debe organizar la fase posterior al proyecto:
los equipos del proyecto se reasignan a nuevas tareas
el apoyo al producto del proyecto se confía a los equipos operativos.
Etapa o fases, cierto.
Hace algunos años, un director de proyecto de una de mis empresas cliente me llamó y me dijo: “Acabo de mantener una teleconferencia con miembros clave de mi equipo de proyecto y me he dado cuenta de que no estamos de acuerdo en lo que se supone que debe conseguir el proyecto”.
Le aseguré que esto era habitual.
“¿Qué debo hacer?”, preguntó.
Le dije que no tenía más remedio que conseguir que los miembros del equipo fueran todos en la misma dirección aclarando la misión del proyecto. Me pidió que facilitara una reunión para ello.
En la reunión, me puse delante de un rotafolio y empecé diciendo: “Vamos a redactar un planteamiento del problema”. Alguien contraatacó inmediatamente diciendo: “No necesitamos hacer eso. Todos sabemos cuál es el problema”.
Este comentario no me conmovió. Dije: “Bueno, si eso es cierto, es sólo una formalidad y sólo nos llevará unos minutos, y me ayudaría que lo escribiéramos. Así que que alguien me ayude a empezar”.
Voy a ser un poco jocoso para ilustrar lo que ocurrió a continuación. Alguien dijo: “El”, y yo escribí la palabra en la tabla, y otra persona dijo: “¡No estoy de acuerdo con eso!”.
Tres horas más tarde, por fin terminamos de redactar el planteamiento del problema.
El director del proyecto tenía razón. El equipo no estaba de acuerdo en cuál era el problema, y mucho menos en cómo resolverlo. Esto es fundamental, y ocurre tan a menudo que he empezado a pensar que todos llevamos dentro un gen defectuoso que nos impide insistir en tener una buena definición del problema antes de empezar a trabajar. Recuerde, la gestión de proyectos es resolver un problema a gran escala, y la forma en que defina un problema determina cómo lo resolverá. Si tiene una definición errónea, puede que llegue a la solución correcta, ¡a un problema equivocado!
De hecho, me he convencido de que los proyectos rara vez fracasan al final, sino al principio.