archivo

Archivo de la etiqueta: gestión integrada de proyectos

En una organización, incluso en aquellas orientadas principalmente al desarrollo de software existen diferentes planes que se ejecutan en paralelo a los diferentes proyectos en los que se esté trabajando: plan de mejora continua de los procesos, plan de marketing, plan de comunicación interna, plan de análisis de costes, etc…

Un proyecto que se lleva a cabo no puede estar de espaldas a estos otros procesos porque insisto, los proyectos no son procesos independientes (fundamento del nivel 3 de CMMI y que ya comenzamos a tratar en el ámbito de la gestión de proyectos en el artículo anterior) sino que están integrados con otros muchos relacionados directa o indirectamente con el desarrollo de software o con la propia gestión organizativa. Por tanto, es necesario tenerlos en cuenta en la gestión del proyecto, siendo necesario tener bien identificados los interfaces a través de los cuales se envía y recibe información para evitar que llegado el momento no se conozca a quién dirigir unos determinados datos o no pueda recibir aquellos que sean necesarios para la integración con el conjunto de planes y procesos organizativos.

Conforme vayamos mirando de más arriba a los proyectos nos daremos cuenta cómo existen interesados en diferentes áreas dentro de la organización y del cliente que participan en diferentes proyectos en los cuales los equipos de proyecto pueden ser distintos o tener pocos componentes en común. Esta circunstancia recomienda igualmente una gestión integrada de las relaciones con los interesados, ¿cuántas veces se ha hecho llegar un mensaje contradictorio a un cliente desde personas distintas dentro de un equipo de proyecto o entre integrantes de proyectos distintos?. Hay que tener cuidado con estos traspiés ya que merman la credibilidad de los interesados afectados, todavía más grave si el interesado es el cliente (no solo se consigue la confianza de estos obteniendo buenos resultados en el producto, también se consigue a través de las relaciones con los mismos).

También es importante no solo tener controlado lo que se dice a los interesados sino también la información que se recibe de ellos.

Por último, en este proceso se definiría la visión integrada del proyecto y la estructura y selección de los equipos integrados de proyecto (lo veremos más en profundidad en áreas de proceso posteriores).

El nivel 3 de CMMI tiene un ámbito de aplicación a nivel organizativo (o departamental si el desarrollo de software es un departamento más de la entidad), por tanto, resulta lógico que la gestión de proyectos vaya más allá de lo que es el proyecto en sí o de la cartera de proyectos de un jefe de proyectos, ya que lo que se pretende, por un lado es evitar la formación de repúblicas independientes que, pudiendo utilizar determinados procesos organizativos, tengan una dinámica de funcionamiento separada del resto (algo muy común en las empresas de desarrollo de software) y por otro fomentar una visión integrada y organizativa de los proyectos que tienen que estar alineados con las estrategias, objetivos y normativas de la organización.

Se pierde mucho valor en las empresas de desarrollo de software cuando la experiencia, conocimientos y activos de un proyecto no tienen más alcance que el grupo de personas que han trabajado en el proyecto y no existe una proyección hacia la organización. Esto sucede en empresas pequeñas pero también en entidades mastodónticas que no tienen definidos procesos que permitan aprovechar todo ese caudal, lo que las convierte en realidad en multitud de microempresas que solo tienen en común el nombre y las personas que van de un proyecto a otro.

En este proceso, se describen las acciones a realizar para determinar el proceso de desarrollo que seguirá el proyecto, el cual tiene que formar parte, del repositorio de activos de la organización (área de proceso: Definición de proceso organizativo).

Esto quiere decir que todo proyecto a nivel organizativo va a utilizar una metodología, un ciclo de vida, va a generar unos artefactos, seguir una estrategia que ha sido homologada para ser utilizada, lo que permite acotar la forma en que se enfoca el proyecto, algo que resulta ventajoso para tener una visión general de los proyectos en los que se trabaja, facilita la medición y la rotación de los empleados entre los diferentes equipos.

Puede haber excepciones y que el proyecto requiera de excepciones respecto a lo reflejado en algún área de proceso. Siempre hay que estar abiertos a que esto pueda suceder, porque es algo que pasará y es necesario tener presente qué se hará en estos casos. Lo que se hará será poner sobre aviso al área de calidad y/o al área de gestión de los procesos CMMI en la organización, los cuales deberán evaluar sí la excepción o excepciones están justificadas y si es así, dar el visto bueno. Tras la aprobación de las mismas, estas deberán quedar perfectamente documentadas en el plan de proyecto y se contribuirá al repositorio de activos con aquellos artefactos, prácticas o experiencias adquiridas si así resulta de interés para la organización.

Es importante tener en cuenta que cuando me he referido a áreas de proceso, sobre todo a aquellas que acotan procedimental o técnicamente un proyecto, siempre he hecho referencia a la necesidad de definir en las mismas diferentes escenarios en función de la naturaleza del sistema o sistemas con los que se va a trabajar, esto permite una mayor flexibilidad a la hora de seleccionar metodologías, arquitecturas, etc… (dentro de un orden) permitiendo un mayor ajuste a las necesidades del proyecto.