Algunos productos se desarrollan “a medida”, comenzando por el diseño, y ejecutando después un plan de ejecución; otros sin embargo son el resultado en serie de cadenas o procesos de producción.
Con los servicios ocurre algo similar: algunos son actuaciones únicas y específicas concebidas y realizadas para las necesidades de la ocasión, y otros son procedimientos normalizados, ejecutados según protocolos y prácticas estandarizadas, que con carácter repetitivo se emplean siempre para prestar el mismo servicio, o servicios del mismo tipo.
Se dice que los primeros son proyectos, y los segundos operaciones. Unos y otros tienen tres características comunes:
- Los realizan personas.
- Se ejecutan con recursos limitados.
- Se llevan a cabo siguiendo una estrategia de actuación.
Los productos o servicios realizados por las organizaciones pueden ser el resultado de operaciones o de proyectos. Las operaciones desarrollan productos de características similares, o prestan servicios con un mismo protocolo de actuación.
Los electrodomésticos, muebles, automóviles, refrescos, prendas de vestir, etc. son ejemplos de productos realizados a través de operaciones.
La evaluación SCAMPI para medir la madurez CMMI de una empresa de software, o la impartición de un curso reglado de java son ejemplos de servicios habitualmente realizados como operaciones
Los proyectos, además de las tres características anteriores:
- Producen un resultado único.
- Se desarrollan en un marco temporal pre-establecido.
La gestión de proyectos define proyecto como:
Además de ser trabajos realizados por personas, de forma controlada, y con recursos limitados, los proyectos tienen por objetivo desarrollar resultados únicos, en un marco de tiempo pre-establecido.
Las construcciones de ingeniería civil, como puentes o edificios, son ejemplos clásicos de proyectos, y con carácter general lo es el desarrollo de cualquier sistema singular.
Cada proyecto tiene objetivos y características propias y únicas.
Algunos necesitan el trabajo de una sola persona, y otros el de cientos de ellas; pueden durar unos días o varios años.
Algunos ejemplos de proyectos:
- Diseño de un nuevo ordenador portátil.
- Construcción de un edificio.
- Desarrollo de un sistema de software.
- Implantación de una nueva línea de producto en una empresa.
- Diseño de una campaña de marketing.
Origen de la gestión de proyectos
En los años 50, el desarrollo de grandes proyectos militares evidenció la necesidad de coordinación entre los equipos y disciplinas diferentes que trabajaban de forma simultánea en la construcción del mismo sistema.
Los proyectos grandes y complejos requerían el trabajo concurrente y sincronizado de múltiples ingenierías, e hicieron evidente, en los 60, la necesidad de elaborar modelos de organización y gestión para evitar los problemas que aparecían con recurrencia en todos los proyectos:
- Incumplimiento de agendas.
- Desbordamiento de costes.
- Funcionalidad deficiente.
Los proyectos han existido siempre.
Todo trabajo para producir un resultado único es un proyecto; pero la gestión de proyectos es una disciplina relativamente reciente que comenzó a forjarse en los años sesenta.
A partir de los años 60 surgieron las organizaciones que han desarrollado el cuerpo de conocimientos y las prácticas necesarias para gestionar los trabajos con las mejores garantías de previsibilidad de los resultados.
Ese cuerpo de conocimientos se ha ido desarrollando y configurando como currículo de una nueva profesión garante del éxito en los proyectos: La gestión de proyectos.
La búsqueda de patrones comunes a todos los proyectos parte de los tres puntos señalados en los 50, por Meter Norden, (Norden, Julio 1958)
- Es posible relacionar los nuevos proyectos con otros pasados y terminados para estimar sus costes.
- Se producen regularidades en todos los proyectos
- Es absolutamente necesario descomponer los proyectos en partes de menor dimensión para realizar planificaciones.
Los proyectos desarrollan obras, artefactos o servicios con un plan exclusivo. El plan de trabajo recorre un camino nunca antes realizado, y por tanto con niveles de riesgo altos, que suelen terminar torciendo, y a veces mucho, las estimaciones iniciales, e incluso generando problemas de calado suficiente para abortar la ejecución del proyecto.
Principios de la gestión de proyectos predictiva (clásica)
Patrón de trabajo de la gestión predictiva:
El producto final
1.- ¿Qué hay que construir?.
La gestión de proyectos parte de la descripción detallada de cómo debe ser el resultado (planos, requisitos…)
Con fecha y coste pre-estimados
2.-El plan del proyecto
Identificación de las tareas y recursos que se necesitarán para construir el producto.
Diseño del plan que consigue la coordinación y ejecución, con una combinación de recursos y tiempo adecuada a las necesidades y posibilidades del proyecto.
3.- Supervisión y coordinación de la ejecución para evitar desviaciones del plan.
Ámbito de la gestión de proyectos
Desde la perspectiva ortodoxa, un gestor de proyectos es un “gestor formal,” un planificador y controlador de las áreas que intervienen en el desarrollo del proyecto.
Para PMI (por ejemplo) las áreas de gestión que tiene a su cargo son (PMI, 2005):
- Gestión de la integración del proyecto.
- Gestión de costes.
- Gestión de la calidad.
- Gestión de tiempos y agendas.
- Gestión del alcance del proyecto.
- Gestión de la comunicación en el proyecto.
- Gestión de los riesgos.
- Gestión de proveedores.
Las industrias militar y automovilística fueron las primeras en adoptar las nuevas prácticas de gestión de proyectos, y por los buenos resultados que obtenían en la calidad y previsión de fechas y costes, su uso se ha ido extendiendo a prácticamente todos los sectores, y se ha ido formando un cuerpo de conocimiento común y único de gestión de proyectos.
Errores frecuentes de enfoque en la gestión predictiva
La gestión de proyectos predictiva centra la atención en la planificación, ejecución y control del trabajo.
La base de conocimiento desarrollada pone a disposición de los gestores técnicas y herramientas útiles para: ordenar ideas, registrar, consultar y analizar información.
- Diagramas de Gantt.
- Ruta crítica.
- Plan de comunicación.
- Plan de riesgos.
- Plan de calidad.
- Plan de recursos.
- Matriz de responsabilidades.
- Actas de reuniones.
- Etc.
Pero esto son herramientas, y no el trabajo que deben realizar.
El trabajo del gestor de proyectos no es: hacer el Gantt, el presupuesto, el plan de comunicación, el plan de riesgos, moderar las reuniones y redactar actas o registrar tiempos y gastos.
Su misión es garantizar el seguimiento del plan previsto, y según sea la organización de la empresa en la que trabaje tendrá mayor o menor libertad para usar unas u otras herramientas.
Las organizaciones que gestionan los proyectos con patrones predictivos, y disponen de modelos de procesos maduros, tienen definidas e institucionalizadas las prácticas de trabajo de los gestores de proyectos.
Procedimentar el trabajo es útil y necesario en entornos basados en procesos, pero se debe evitar que la rutina desvirtúe el objetivo de la gestión.
El objetivo no es tener dibujado un plan sobre un diagrama de Gantt. El objetivo es diseñar el plan con la distribución de recursos y con las rutas de tareas más adecuadas. El diagrama es solo un lenguaje para transmitir ese diseño.
Ídem con todas las tareas de gestión: selección de proveedores, recursos, comunicación, reuniones, riesgos, etc.
Los procesos ponen junto a ellas modos y protocolos de trabajo y registro, y se pueden hacer malas gestiones, malos planes y malos seguimientos con documentos y registros preciosos, confeccionados siempre en fecha y según las normas de la empresa.
El hecho de que el cumplimiento de “lo prescrito” suela funcionar bien como escudo para eludir responsabilidades cuando las cosas van mal, refuerza el “complejo burócrata” en los mismos gestores.
Por estas razones a veces los gestores de proyectos terminan trabajando como cumplidores de procesos.
Se deben evitar las ideas erróneas:
- Considerar que los sub-productos de la gestión son el trabajo del gestor.
- Asumir la obligación de control del equipo.
- Transmitir al equipo una cultura de cumplimiento.
Los sub-productos no son “deberes”
Considerar a los sub-productos del proyecto (requisitos, planificación, informes, registros…) como los “deberes del colegio” o los “deberes del gestor”, termina por darles el rango de “su obligación” o, la “obligación de su trabajo”; considerando por tanto que si hace la obligación, hace su trabajo.
La mejor medida para evitar este vicio es que sean conscientes del riesgo, y lo conozcan tanto el departamento de calidad y procesos (si lo hay) como los responsables y directivos de las diferentes áreas, porque tienen una compromiso notable en los valores culturales de la organización, y son por ello los más indicados para evitar una “cultura de cumplimiento”, que hace olvidar que el fin de un diseño, o de un plan, una gestión… no es escribirlas y registrarlas según las normas, sino que sean el mejor, o el más innovador o el más adecuado (diseño, plan, gestión…) según los casos.
Gestionar no es controlar
En la gestión de proyectos predictiva el gestor diseña, traza el plan y es el responsable de su cumplimiento.
Además, a diferencia de la gestión ágil, no tiene por qué ser un conocedor de la tecnología empleada en el desarrollo.
La mezcla de estos factores tiende a dibujar puestos de “controladores”. No son miembros integrados del equipo con aportación en las decisiones técnicas; y por el sentimiento de propiedad del plan y la responsabilidad de su ejecución es fácil que se limiten a adoptar posturas de control y orden jerárquico.
Sin entrar en preferencias sobre estilos de gestión, puede ser un patrón válido en trabajos y producciones de tipo industrial o mecánico cuyos resultados se deben más al valor de los procesos y la tecnología que al de las personas.
En proyectos de desarrollo de software, este modelo puede crear ambientes de trabajo inhibidores del talento personal.
La cultura de cumplimiento es contagiosa
La gestión que cae en el error de la cultura del cumplimiento, funciona como una fuente más de propagación en la organización, y la transmite al equipo.
Las formas pasan a ser también más importantes que los fines, y se da más relevancia a las horas de dedicación o al cumplimiento de las normas que a la eficiencia o calidad de los resultados.
Para mayor información pueden descargar el libro: Flexibilidad con Scrum – CC by-nc – Juan Palacio
0 Comments