calaix[À]gil

www.calaixagil.com

CAT | ESP | EN



Gestión del cambio en proyectos tecnológicos. Empoderar a los miembros del equipo

ES / CAT

Que significa empoderar Esta expresión debe entenderse, no desde una semántica de poder, sino de responsabilidad.

descarrega la versió pdf d’aquest article


1. Empoderar e los usuarios clave

Que significa empoderar? Esta expresión debe entenderse, no desde una semántica de poder, sino de responsabilidad. La responsabilidad de todos los actores del proyecto es clave para garantizar un flujo correcto de las comunicaciones, las relaciones y el cumplimiento de los objetivos del proyecto.

Los usuarios clave son un elemento especialmente importante para garantizar el éxito final del proyecto y de sus productos. Un usuario clave que no asume sus responsabilidades en el proyecto puede generar serios problemas en la comprensión de la necesidad y de la solución, que pueden acabar en fracaso o en la cancelación del proyecto.

Metodologías tradicionales (y extensivas) como PRINCE2 hace años que son conscientes de la importancia del equilibrio de responsabilidades entre todos los participantes, y establecen mecanismos de dirección, seguimiento, cumplimiento de la calidad y aceptación muy estrictas.

Con la aparición de marcos de trabajo ágiles puede parecer que estos aspectos son más laxos, e incluso podemos pensar que son inútiles, pero esto es un elemento más de confusión en la vorágine actual de asimilación desordenada de Agile.

En este sentido es importante asegurar que el usuario clave realmente asume la responsabilidad que le corresponde. Las responsabilidades no se delegan; el trabajo sí puede delegarse. Es decir: el usuario clave debe asegurarse de que él u otra persona a la que delegue cumple las metas que se le encomienden. Pero la responsabilidad en el desempeño de las metas pactadas será del responsable y no de los delegados.

Conocimiento del negocio

Una premisa importante que proporciona tranquilidad en la gestión de un proyecto es la elección acertada de los usuarios clave. Los usuarios clave los elige el negocio y no el proyecto; y es responsabilidad suya hacer una elección adecuada y realista. Un usuario clave es una persona que, además de su trabajo habitual, dedica un tiempo (a menudo considerable) en colaborar en la definición de las necesidades, y en la aceptación posterior de los resultados.

El usuario clave es una persona que principalmente:

  • Conoce el negocio en detalle
  • Debe disponer del tiempo imprescindible para tener la interlocución necesaria con los equipos del proyecto

Clima de las comunicaciones

Para poder asimilar toda la información necesaria para diseñar una solución completamente satisfactoria, debemos asegurar un buen clima de comunicación con estos usuarios. Esto sólo es posible si tenemos en cuenta una serie de factores que deben quedar claros desde el primer momento:

  • La responsabilidad de los usuarios clave en el proyecto
  • Las metas, las tareas, las reuniones y, en definitiva, el peso de estas responsabilidades por parte de los usuarios clave
  • El alcance del proyecto (que se hace y que no se hace)

En el punto anterior hablábamos que la principal responsabilidad del usuario clave es asegurarse de que el equipo del proyecto entiende la problemática a cubrir por la solución. En este sentido, hay algunos ítems que afectan a la forma de comunicar o en “que se comunica” que a menudo genera malentendidos en el equipo del proyecto. Para completar la lista anterior podemos añadir que el usuario clave debe:

  • Debe ser abierto, en cuanto a la definición de la situación actual del flujo de trabajo de su competencia. Explicando la realidad de su día a día de forma clara, suficiente y completa.
  • Debe ser pedagógico en sus explicaciones. El equipo del proyecto probablemente no conoce todos los detalles de su flujo de trabajo. El usuario clave debe focalizarse en asegurar que el equipo comparte con él el detalle de la problemática.
  • Debe entender el alcance y los límites del proyecto. Que se puede hacer ahora, que se puede hacer más tarde y que no puede hacerse. El usuario clave debe tener muy presente el alcance del proyecto que se ha pactado, los límites de la tecnología, los límites de la organización y cualquier otro factor que afecte lo que él entiende como la solución ideal
  • Debe ser consciente de que la organización es una maquinaria compleja de múltiples partes. Y la solución idónea para él puede ser un gran escollo para otras áreas, departamentos o personas de la organización. Lo mejor para un departamento no necesariamente tiene que ser la mejor de las soluciones posibles

Un proyecto es una acción de equipo en la que suele participar un grupo heterogéneo de personas, con diferentes grados de conocimiento o especialidad. Es necesario generar un clima de transparencia en el trabajo y asunción de responsabilidades, para favorecer la generación de un clima de confianza que facilite la construcción de la solución idónea.

Hablar el mismo idioma (argot del negocio)

Todo el mundo debe entender lo mismo respecto al alcance y con respecto al flujo del negocio del usuario. El equipo del proyecto y los usuarios deben hablar el mismo idioma. Y el único idioma válido en este sentido es el idioma del negocio, con todas sus particularidades y jerga. Únicamente así podemos estar seguros de que el alcance del proyecto es bien entendido por todas las partes.

2. Empoderar al equipo del proyecto

Una vez tenemos empoderado al usuario clave, el siguiente paso es incluirlo dentro de la dinámica del proyecto, y dotar al equipo de las herramientas que faciliten su organización interna y su coordinación, un marco de trabajo que les permita trabajar de forma ordenada y racional, y un ámbito de decisión que les permita ser operativos, eficientes y autónomos.

¿Que demonios es eso de “equipo”?

Un equipo es un conjunto de personas que colaboran para el logro de unos objetivos comunes. Esta sencilla definición a menudo es olvidada para pasar a ser “un grupo de personas que trabajan juntas”. Para que un “grupo” pase a ser un “equipo” es necesario que:

  • Trabajen juntas: En contacto directo. Que se puedan hablar y que se conozcan
  • Responsabilidades claras: Para que un grupo sea un equipo, cada componente debe ser perfectamente consciente de cuál es su papel en el equipo
  • Todo el mundo tiene algo que hacer: Asumir responsabilidades significa ser conscientes de que tenemos una misión en el equipo y que aportamos un valor. En un equipo no hay personas que van por libre
  • Generan un clima constructivo y colaborativo: Todos los miembros del equipo explican abiertamente lo que hacen, y lo que esperamos de los demás. Presentan resultados, piden ayuda, etc.

Para alcanzar este nivel de colaboración, el equipo del proyecto debe disponer de espacios y tiempo para alcanzar el clima necesario para llegar a acuerdos internos y trabajar colaborativa y constructivamente.

El equipo del proyecto es algo más que un jefe de proyectos + constructores o proveedores

El equipo del proyecto son todas aquellas personas con responsabilidad sobre la infraestructura, la arquitectura y la calidad. Todos ellos forman parte del equipo del proyecto. La complejidad de las organizaciones influyen también en la organización interna del departamento tecnológico; donde se crean subdepartamentos especializados en ciertos aspectos del software, hardware, seguridad, procesos o gestión.

Un elemento más de complejidad suele ser la externalización de los servicios, que afecta a muchas operativas del área tecnológica, pero especialmente al desarrollo de soluciones. Llegando al extremo en que el área tecnológica adquiere un rol de liderazgo de proyecto, con equipos humanos y recursos externalizados.

Todos los miembros del proyecto tienen tareas asignadas

Todo el mundo debe tener una responsabilidad clara en el proyecto; y se pide de todos la máxima implicación en el proyecto. Algunas personas piensan que participar en un proyecto es “opinar”. Van, dicen lo que les apetece decir, y se van. Debe evitarse esta actitud.

Toda persona que participa en un proyecto tiene una responsabilidad, y la asunción de esta responsabilidad es deriva necesariamente en la asunción de una serie de tareas asignadas. Huye de los opinadores sin trabajo en el proyecto.

Los facilitadores también formen parte del equipo del proyecto

Algunas organizaciones dedican recursos a asegurar que el conocimiento funcional y de negocio no se pierde; de forma que este conocimiento está en manos de un equipo de personas que vela por transmitirlo cuando es necesario, y por su coherencia situacional y evolutiva.

Estas personas también son parte del equipo del proyecto. El jefe de proyecto necesita estar asesorado por alguien con una visión más transversal del negocio que los usuarios clave y que él mismo. Para asegurar lo mejor posible que las situaciones descritas son coherentes con este conocimiento; y que las propuestas de solución también son coherentes desde una perspectiva global.

Estos facilitadores también pueden desempeñar el papel de negociadores en situaciones de conflicto. Y dar soporte a los usuarios clave en la toma de requerimientos. Este equipo requiere una formación muy específica, y de la asunción de un rol muy concreto. Estas personas deben ocupar un lugar de equidistancia entre los interlocutores. Y deben basar sus intervenciones en función de los impactos sobre los procesos de trabajo del área de negocio; o bien si generan consecuencias negativas fuera del área destinataria del proyecto. No toman decisiones unilaterales que afectan el proyecto, y no son el abogado del usuario.

Conocimiento suficiente del negocio

Un factor muy importante corresponde al hecho de que los jefes de proyecto, aparte del conocimiento tecnológico suficiente; y los conocimientos de gestión del proyecto y de los equipos; deben tener un conocimiento suficiente sobre el área de negocio y sobre la organización, para poder ejercer su trabajo. Esto implica no sólo conocer el flujo de negocio del departamento en cuestión, sino también conocer “como hablan” en ese departamento.

Responsabilidad del jefe de proyecto

Los jefes de proyecto son los directores operativos del proyecto. Tienen la máxima responsabilidad, y están para tomar decisiones y buscar consensos. De este hecho deben ser conscientes todos los participantes. El objetivo de todo proyecto es la creación de un producto útil. Y para ello conlleva una acción continua de negociación y consenso, pero por encima de esto, conlleva la toma de decisiones que no siempre deja contento a todo el mundo.

En este sentido el jefe de proyecto toma decisiones en función de los acuerdos que negocio, intereses de todos los participantes, y la misma organización. Tomar decisiones no necesariamente significa el establecimiento de una jerarquía al interno del equipo, donde la figura máxima es el jefe del proyecto. Más bien tomar decisiones significa facilitar el clima óptimo en el equipo para que este protagonice las decisiones y lidere las acciones necesarias.

Esto representa un cambio en el paradigma tradicional del jefe de proyectos, que pasa a ser un facilitador más que un mando. Esto requiere confianza en el equipo, y proactividad por parte de los integrantes. Un equipo pasivo no es un buen punto de partida para comprometerse con un plan conjunto. Hay pedagogía para motivar la autoorganización necesaria para que el equipo sea el motor del proyecto de forma continua. Las decisiones no se toman un día D a una hora H. Se toman cada día, cuando es necesario.

Canales claros para rendir cuentas

Relacionado con el punto anterior, la única forma de garantizar que el proyecto realiza las acciones, y que estas son parejas con las decisiones que se han tomado, es estableciendo un sistema de información o seguimiento entre las personas que toman las decisiones. Los jefes de proyecto rinden cuentas al grupo de seguimiento directivo que se haya establecido.

Rendir cuentas es la acción de casar las decisiones tomadas con las acciones realizadas en el proyecto. Y para que esto sea coherente, las personas que toman decisiones y que tienen la responsabilidad, deben ser las mismas que articulan el seguimiento.

El jefe de proyecto no rinde cuentas a nadie más. El equipo directivo lo protege para evitar que el proyecto se vea influido de forma externa. Parece una obviedad, pero muchos proyectos sufren este tipo de interferencias y generan conflicto entre lo que inicialmente se decide, y lo que finalmente se realiza.

El control de todos los aspectos de gestión

Por último, un factor importante corresponde al control de las variables del proyecto. La atribución principal del jefe de proyecto es el control de estas variables, y la libertad suficiente para poder tomar decisiones. Si no se tiene este control, el jefe de proyecto no es un gestor, es otra cosa.

Las variables bajo control del jefe de proyectos son:

  1. Recursos internos, externos y proveedores.
  2. Calendario y planificación del proyecto.
  3. Presupuesto, compras, contrataciones, negociaciones de las gestiones del cambio, gestión de las limitaciones presupuestarias, priorización
  4. Determinación de las normas de calidad estándar (las establecidas por la organización) y particulares (según las particularidades del proyecto): calidad documental, flujo de gestión, flujo de ejecución, calidad del código, calidad del producto, flujo de testing y política de aceptaciones

3. Las acciones para fomentar el cambio en la organización

Empoderar e los miembros del equipo (usuarios clave incluidos)

Para que los diferentes miembros del equipo asuman su responsabilidad, y trabajen de forma coordinada entre sí, hay que proporcionar básicamente cuatro pilares:

  • Un espacio de trabajo que facilite la agilidad
  • Una estructura de relaciones, que responda a quién es responsable de qué, o quién hace qué
  • Un flujo de trabajo, que ayude al equipo a llevar a cabo sus tareas en el proyecto
  • Unos “momentos” o hitos, en el que el equipo se coordina, muestra los avances, resuelve problemas, etc

La agilidad como herramienta de empoderamiento

Para aplicar agilidad en procesos complejos, donde intervienen a menudo un gran número de personas, es necesario ser conscientes de que las operaciones de gestión (el management) es demasiado importante para dejarlo sólo en manos de gestores. Debemos transmitir la idea de que la gestión también es una tarea de equipo, y que el jefe del proyecto focaliza sus esfuerzos en crear el clima necesario para el fomento de la gestión eficiente y la creatividad, (cuida un jardín).

Se trata de encontrar un clima de trabajo en el que el equipo es el auténtico protagonista sobre el “cómo” se hacen las cosas en su interno. Y aquí el jefe del proyecto es un miembro más en el equipo.

Las principales barreras en la adopción del agilismo son diversas, pero se pueden destacar:

  • Resistencia general al cambio en la organización
  • Posibilidades reales de hacer efectivo un cambio cultural en la organización
  • Aplicar conceptos ágiles en un sistema organizativo anti-ágil, por causas tecnológicas, por el cumplimiento de normativa o burocracia externa, o de la misma organización, o por el sistema de relaciones entre departamentos y personas de la organización

Que es una organización anti-ágil? Una organización anti-ágil es aquella en la que sus elementos de coordinación interna y productivos se articulan en torno a dos elementos característicos: Burocracia y jerarquía. De forma que, con el fin de llevar a cabo cualquier acción prevista en la organización, ésta es evaluada a través de un proceso formal o informal que la pauta y la delimita (burocracia), y da respuesta a intereses de grupos que coordinan su idoneidad, alcance y temporalidad, y que tienen la atribución a diferentes escalas de validar o no su conveniencia (jerarquía). Con la existencia de un núcleo que centraliza las decisiones, y que extiende su poder a toda la organización (Taylorismo)

Este tipo de organización son vistos como una máquina; capaz de hacer un número concreto de acciones, y de una forma determinada, que además tenderá siempre a ser la más eficiente posible. Para alcanzar este máximo de eficiencia, muestra una tendencia en especializarse por secciones (o nichos). Los nichos actúan como engranajes independientes que tienen visión sólo de una parte de la cadena de valor de la empresa, y donde se establecen vías estrictas de contacto con otros engranajes.

Cuando este tipo de organizaciones es sorprendida con cambios tecnológicos, humanos, organizativos, políticos, presupuestarios, y un largo etc. que ponen en peligro su status quo actual, necesitan adaptarse. La adaptación en una organización-máquina es posible, pero es lenta y a menudo desemboca en adaptaciones parciales que no cubren completamente lo que las forzó a cambiar.

Organización-máquina

Una organización ágil es aquella en la que los engranajes tienen todos ellos (o gran parte) una visión completa de la cadena de valor de la organización. Son autoorganizadas y tienen capacidad de decisión. El centro de la organización no es visto como un centro de poder, sino como una guía en la dirección. La capacidad de adaptación de estas organizaciones vienen determinadas por su flexibilidad interna y externa. Los diferentes núcleos (o células) operativos pueden crecer, disminuir y alterar su organización interna y especialización. Pueden aparecer nuevas células para cubrir nuevas necesidades y adaptarse a los cambios, sean los que sean.

Definición de la estructura de relaciones

Una estructura de relaciones documentada es un esfuerzo para explicar de forma gráfica las relaciones entre los diversos miembros del equipo, focalizadas en la asunción de responsabilidades. En el gráfico siguiente se muestra una propuesta de estructura de relaciones, con todos los grupos y personas que intervienen en un proyecto:

Estructura de relaciones

En este gráfico podemos describir los roles siguientes:

El Jefe de proyecto corresponde a la figura que, en última instancia, tiene la responsabilidad principal de asegurar el contacto continuado de todos los miembros del equipo. Estas responsabilidades las podemos resumir de la forma siguiente:

  • Asegurar que todos los miembros asumen sus responsabilidades
  • Asegurar que el equipo entiende el marco de trabajo y que lo sigue. Esto incluye principalmente el ciclo de vida, las metas de la gestión y la ejecución del proyecto, y la calidad
  • Asegurar que el equipo comprende la necesidad de pautar la ejecución, priorizar las tareas y seguir un plan consensuado
  • Asegurar que se cumplen los baremos de calidad que el equipo ha determinado para el proyecto

El Grupo de Seguimiento es el órgano que tiene la función principal de evaluar el seguimiento del proyecto, en función a la información que el equipo, y principalmente el jefe de proyecto le traslada. Toma decisiones y ayuda a la priorización de los objetivos, y la resolución de los problemas y riesgos que sean de su competencia

Idealmente, los miembros del grupo de seguimiento deben ver reflejados todos los intereses del proyecto y de la organización. Así pues, deben verse cubiertas las visiones tecnológicas, pero también la visión del negocio y de los constructores / proveedores.

La PMO es el órgano que apoya al equipo de proyecto para que se cumplan los requerimientos de calidad tanto en lo referente al producto del proyecto, como para el mismo proceso. Su vinculación con el proyecto no debe confundirse con una auditoría. Son parte del equipo y tienen tareas y responsabilidades asignadas. Por tanto colaboran con el equipo en el aseguramiento de la calidad del proyecto.

El Usuario clave es una figura primordial en el equipo; y tiene un nivel de participación en el que va más allá de ser un facilitador estático de información del negocio. Ayuda al equipo a priorizar los objetivos. Ayuda a definir la profundidad (el detalle) de los objetivos del proyecto y de su alcance. Ayuda a resolver los problemas, y en preverlos, identificarlos y mitigarlos. Y por encima de todo ayuda a validar que el resultado del proyecto cumple las expectativas de calidad de forma iterativa e incremental. Y por eso se compromete a trabajar con el producto desde el primer momento

Los Facilitadores, tal como hemos explicado en secciones anteriores, se constituyen como un puente en la comunicación entre los usuarios clave y el equipo del proyecto. Los facilitadores tienen sentido cuando la información de negocio necesaria para la ejecución del proyecto es o muy compleja, o muy dispersa. Si no es así, no debería haber ningún inconveniente en que tecnólogos y usuarios entren en contacto directo. Muchas organizaciones han llegado a la conclusión de que tecnólogos y usuarios nunca podrán entenderse. Es una visión típica de los años 90, que actualmente aún perdura.

Los Jefes de Proyecto proveedores son los responsables de la operativa de la construcción / implantación / adquisición por parte de los constructores asignados al proyecto. Tienen un papel muy parecido al Jefe del Proyecto general, pero su ámbito de responsabilidad se centra en su equipo de construcción. A menudo el equipo de construcción se encuentra en las instalaciones del proveedor, y es poco conocido y poco accesible para el equipo del proyecto. El Jefe de proyecto proveedor hace de pasarela entre los desarrolladores y el resto del equipo.

Por último, aglutinamos el resto de miembros del equipo bajo el epígrafe de Colaboradores. Un colaborador es aquel que dentro del equipo desarrolla uno o más roles que son necesarios para poder ejecutar alguna de las tareas del proyecto. En el ámbito de un proyecto, todas las tareas necesarias necesitan ser cubiertas, o bien lideradas por un miembro del equipo. No pueden haber tareas sin un responsable asignado.

Como hemos dicho antes, colaborar implica necesariamente desarrollar una tarea dentro del proyecto. Una tarea es un trabajo que tiene como resultado final un subproducto útil para el producto del proyecto o para el equipo (un informe, una acción de I + D, código, etc.). No es un subproducto útil para el proyecto una opinión no contrastada.

Tampoco es un subproducto útil para el proyecto la auditoría de una acción ya realizada en el interno del equipo. Un NOK de un subproducto finalizado es un trauma en el proyecto. Significa que los creadores del subproducto no han entendido las reglas. Pero también significa que los auditores han actuado de forma reactiva en la construcción del subproducto. Si una auditoría debe formar parte de las tareas del proyecto, significa que los auditores forman parte del equipo del proyecto. Y significa que son ellos quienes lideran las acciones necesarias para alcanzar un OK en el subproducto.

Los momentos que acotan el proyecto: El kickoff y el cierre del proyecto

De todos los hitos de gobierno de un proyecto, podemos determinar dos que son especialmente importantes. Estos son:

  • El inicio de proyecto, o Kickoff
  • La finalización del proyecto, o Cierre

El kickoff

El kickoff es una acción en forma de una sesión, en la que todos los miembros del proyecto, y las personas impactadas o interesadas se reúnen y exponen todos los aspectos clave, con el objetivo de obtener una luz verde por parte de todos los asistentes, que permita el inicio de las acciones de ejecución del proyecto

Pero para llegar al día en que se realiza una sesión, que termina en la aceptación de todo lo que se expone, el jefe de proyecto debe realizar un trabajo ingente destinado a asegurar este resultado. Este procedimiento, descrito como procedimiento de Inicio del proyecto, lo veremos a continuación

De forma resumida, el proceso de inicio de proyecto tiene como objetivo principal definir en detalle los objetivos, el alcance, y la relación de los miembros del equipo de proyecto, y sus responsabilidades. Un kickoff que define con éxito estos aspectos es una muy buena manera de iniciar un proyecto. De hecho, muchos proyectos fracasan por:

  • Falta de acuerdo sobre su alcance
  • Carencia de una visión clara de los objetivos y beneficios que se obtienen con el producto del proyecto
  • Identificación errónea del impacto del producto de proyecto en el departamento destinatario; o en otros departamentos
  • Selección errónea de los miembros del equipo del proyecto
  • No identificación, o identificación errónea de las responsabilidades de los miembros del equipo del proyecto
  • No identificación, o identificación errónea de los principales riesgos del proyecto, ni proporcionar el detalle suficiente de planes de mitigación de estos riesgos

Para alcanzar un relato que sea aceptado por todas las partes en una sesión de inicio de proyecto, es necesario antes iniciar un proceso que tiene como finalidad determinar los objetivos, el alcance, las claves de éxito, la planificación inicial / deseada, la organización del equipo, las responsabilidades y los riesgos

Esto requiere reuniones con los usuarios clave, con los proveedores y con otras áreas afectadas; y negociar con ellos una visión clara y consensuada del proyecto y del producto resultante. Una vez hecho esto, la sesión de kickoff se convierte en una coreografía de final controlado que tiene como único objetivo explicitar este consenso entre todas las partes.

El Cierre

¿Cuando podemos determinar que un proyecto ha finalizado?

  • ¿Cuando el producto del proyecto entra en productivo?
  • ¿Cuando los usuarios clave dan su visto bueno?
  • ¿Cuando los proveedores finalizan su contrato?

Igual que el inicio del proyecto es una acción de consenso que da el pistoletazo de salida a la ejecución, la finalización del proyecto no puede ser de otra manera. Un proyecto finaliza únicamente en dos escenarios posibles:

  • El equipo del proyecto formaliza la cancelación del proyecto
  • El equipo del proyecto formaliza la finalización del proyecto

Lo que está claro es que el único estamento que tiene la prerrogativa de finalizar un proyecto es el mismo equipo del proyecto. De forma ordenada, consensuada y documentada. En ambos casos es necesario exponer la situación final del proyecto y del producto del proyecto, Las acciones de continuidad, garantía y mantenimiento que se desprenden, y la valoración respecto a la satisfacción del proceso, del producto y respecto a las lecciones aprendidas.

Los principales hitos en la gestión de un proyecto

A modo de resumen, los principales hitos o “momentos” en un proyecto pueden resumirse en el siguiente diagrama:

hitos en la gestión

Inicio de proyecto

El inicio del proyecto es un procedimiento que tiene como objetivo sentar las bases del gobierno y de la ejecución del proyecto. Para lograr esto es necesario establecer una serie de premisas que podemos resumir en la siguiente lista:

  • Conocimiento por todas las partes del propósito del proyecto, y aceptación de este propósito
  • Determinar los objetivos que persigue cumplir con el producto del proyecto, a través de su uso o el impacto que tendrá. Así como el alcance
  • Consensuar una planificación, un marco presupuestario y una disponibilidad de recursos materiales y humanos
  • Cerrar un modelo organizativo para el proyecto, con roles y responsabilidades claras
  • Conocer los riesgos o impedimentos para la construcción del producto del proyecto, o que la generación de este producto puede causar

Para determinar el detalle de todos estos aspectos se trabaja con todos los implicados siguiendo el flujo de trabajo siguiente:

Inicio de proyecto

  1. Preparatoria: En esta fase, el Jefe de proyecto que lo recepciona realiza una serie de tareas destinadas a abrir los sistemas de gestión y documentales del proyecto
  2. Pre-kickoff: Esta fase consiste en una o varias sesiones con los principales interesados del proyecto (de negocio y proveedores) con el objetivo de documentar de forma completa el kickoff, de forma que incluyan todos los aspectos importantes necesarios para la ejecución del proyecto.
  3. Sesión de kickoff: El kickoff se configura como una sesión presencial donde todos los interesados en el proyecto ya han trabajado los acuerdos que se presentarán allí. Y por lo tanto debe ser una representación de un acuerdo previo. Basado en una presentación de kickoff cuyo contenido veremos en secciones posteriores
  4. Post-kickoff: En la fase de post-kickoff se rubrica el acuerdo con la distribución de un acta, que incluye todos los acuerdos presentados en la sesión. Este punto da el pistoletazo de salida a la conformación oficial del equipo de proyecto; con la disponibilidad de todos los miembros del equipo; y al inicio de las tareas de ejecución.

Cierre de proyecto

Al igual que al inicio del proyecto, la finalización requiere la consecución de una serie de actividades que tienen como objetivo el cierre ordenado de las actividades, el aseguramiento de la explotación del producto del proyecto, la evaluación de la satisfacción de todos los implicados, y la evaluación de los beneficios obtenidos por el producto del proyecto

  1. Documentos de continuidad: El proyecto no termina cuando el producto se encuentra en explotación, sinó cuando se ven cumplidos todos los requerimientos documentales e informativos necesarios para la explotación, el mantenimiento y el conocimiento de los usuarios. Esto incluye:

    • Manuales de usuario y plan de formación
    • Documentos de paso a operaciones
    • Documentos de paso al servicio de mantenimiento
    • Acuerdos y activación del servicio de mantenimiento, licenciamiento, evolutivo, adaptativo y correctivo
  2. Reunión de cierre: La reunión de cierre, al igual que en el inicio del proyecto, tiene como objetivo que todas las partes muestren un acuerdo sobre los objetivos cumplidos en el proyecto, las vías de evolución posibles, las lecciones aprendidas, la valoración en función de los objetivos cumplidos y la satisfacción, los acuerdos respecto a la garantía del producto del proyecto y los canales de mantenimiento

  3. Reunión de lecciones aprendidas: Junto con la reunión de cierre, o bien en reunión aparte, el equipo reflexiona sobre la satisfacción tanto desde la perspectiva del producto logrado, como del proceso de coordinación del proyecto. En esta reflexión el equipo documenta una serie de lecciones aprendidas que pueden servir para cambiar aspectos del proceso en futuros proyectos Además, en este punto, el equipo confecciona la forma en que se evaluará la satisfacción de todas las partes involucradas en este proyecto. Consensúa el contenido de encuestas y/o entrevistas que tendrán lugar en diferentes momentos posteriores a la puesta en productivo del producto del proyecto

  4. Evaluación de beneficios y satisfacción: En este punto, y tiempo después del cierre oficial del proyecto, el equipo evalúa el resultado de encuestas y entrevistas de satisfacción, con el que actualizará el archivo de lecciones aprendidas, o levantará las alarmas o iniciativas que considere útiles en función de los resultados Esto puede incluir acciones de evolución o adaptación del producto del proyecto, cambios sobre el gobierno del proyecto, y/o cambios sobre las normas de calidad

Reunión de planificación de ciclo

La planificación (PLN) no es una acción única que se lleva a cabo al inicio de un proyecto. Esta concepción de la planificación como acción única inicial es una forma ineficiente de afrontar el cambio inevitable en las organizaciones actuales.

Se necesita más agilidad en la planificación; y proporcionar un método de trabajo que facilite una planificación dinámica basada en ciclos iterativos de construcción de valor para la organización. Pero es importante tener claros y cerrados el alcance y los objetivos que persigue el producto del proyecto. El dinamismo en la planificación no puede significar incluir o quitar arbitrariamente aspectos funcionales, operativos o tecnológicos considerados críticos.

Si planteamos la planificación como un elemento vivo que aparece de forma iterativa como meta en cada ciclo del proyecto, entonces nos veremos abocados a plantear la construcción de todos los documentos de ingeniería necesarios para el proyecto (diseño funcional, técnico, desarrollo, testing, etc.) también de forma iterativa e incremental. E incluso plantearemos las acciones de puesta en productivo y plan de formación de la misma manera. Esto facilita enormemente la tarea de evaluación continua y aceptación por parte de los usuarios clave y las áreas usuarias a las que va destinado el producto.

La planificación iterativa tiene una contrapartida importante: Hay que ser muy cuidadoso a la hora de mantener la coherencia de una planificación focalizada en ciclos, respecto al compromiso global en el desempeño de un alcance, unos objetivos, un presupuesto y un calendario global. Esto requiere de un esfuerzo para que el equipo mantenga constantemente una visión global del proyecto. Esto es extensible a todos los elementos documentales y de ingeniería necesarios para la ejecución del proyecto. Todos los elementos que se construyen incrementalmente requieren de un esfuerzo adicional para mantener la coherencia global.

El documento que articula la planificación es el documento de Planificación (PLN), en el que quedan definidos el calendario, la forma en que se evalúa la calidad, la forma en que se comunicará y se organizará el proyecto, y la relación de riesgos y planes de mitigación

Reunión de seguimiento

No se ha de entender la reunión de seguimiento como el órgano de gobierno interno de proyecto. El equipo de proyecto no hace reuniones de seguimiento programadas en calendario. Se coordina cada día, y evalúa los resultados internos, o trata los problemas cada día

La reunión de seguimiento es una acción que está por encima de la operativa diaria del proyecto, y que tiene como objetivo informar a los órganos de seguimiento, sobre las acciones realizadas hasta la fecha. Estas reuniones pueden ser planificadas, o tener lugar a demanda (cuando aparece un hito clave, o un problema que no se puede resolver en el interno del equipo)

El documento que articula la reunión de seguimiento es el Informe de Seguimiento (IFS). Y se conforma como acta de reunión donde se expresa la situación general del proyecto, la situación de los riesgos, y las principales decisiones tomadas. Los informes de seguimiento son conocidos por todo el equipo del proyecto y determinan su priorización a alto nivel. El equipo es autoorganizado, pero no completamente autónomo. El órgano de seguimiento tiene la potestad de marcar la priorización de los grandes elementos funcionales, pero no la forma o el orden en que se realizan las tareas en el interno del equipo, ya que tenemos que respetar la premisa de que el equipo es autoorganizado

Reunión de resultados y aceptación

La reunión de resultados es la pieza que nos ayuda a determinar hasta qué punto somos de ágiles en la ejecución del proyecto. Un proyecto con un número elevado de sesiones de presentación de resultados y aceptación implica un flujo de trabajo focalizado en la obtención iterativa de producto de valor. Es decir, en la construcción iterativa e incremental del producto del proyecto, que es explotado por el usuario desde el primer ciclo.

La presentación de resultados y aceptación se articula directamente a través del producto creado, y de cómo este resuelve los objetivos planteados para el ciclo en curso. Sin documentos de presentación. Directamente con el producto. En la presentación de resultados también se busca activamente una acción práctica de aceptación por parte de los usuarios clave. La aceptación implica obligatoriamente la aceptación del incremento de producto proporcionado, y el inicio del ciclo siguiente.