Nivelar los requisitos y Resolver requisitos en competencia

Nivelar los requisitos de los interesados

Implica:

  • Asegurarse de que los requisitos puedan cumplirse dentro de los objetivos del proyecto
  • Buscar opciones para ajustar demandas de alcance, tiempo, costos, calidad, recursos, riesgos y satisfacción del cliente
  • Puede ocurrir a lo largo del proyecto
  • Es muy importante intentar identificar y priorizar TODOS los requisitos de TODOS los interesados.

Dar un repaso completo a los requisitos, categorizarlos, priorizarlos y en definitiva analizarlos permite identificar similitudes e incluso duplicidad de requisitos entre distintos stakeholders, a veces una solución satisface varias necesidades por lo que también podemos optimizar el esfuerzo evitando hacer dos veces el mismo trabajo.

Hay que recordar también que cuanto más tarde identifiquemos un requisitos más grande será el esfuerzo de implementarlo (esto aunque PMI vela por reducir su ocurrencia, pasa en el día a día prácticamente en todos los proyectos)

Resolver los requisitos en competencia

Se debe ayudar a resolver (director de proyecto) los requisitos en competencia

Los requisitos en competencia son aquellos que entran en conflicto unos con otros, esto puede deberse a distintos factores, tecnología, impacto de la implementación, tiempos.

Esto se realiza aceptando aquellos que mejor cumplan con lo siguiente:

  • El caso de Negocio que establece la razón por la que el proyecto se inició
  • El acta de constitución del proyecto.
  • El enunciado del alcance del proyecto (si está disponible en ese momento)
  • Las restricciones del proyecto.
  • Los intereses de los distintos Stakeholders
Anuncios

Proceso Planificar el Alcance: Recopilar Requisitos y Categorización

 Recopilar los Requisitos y Categorización


¿Y cómo defino un requisito para el proyecto?

Para ello el PMI agrupa y presenta un conjunto de técnicas para darles forma.

Recopilar los Requisitos

  • Revisión de Registros Históricos
  • Entrevistas (revisar necesidades con los distintos stakeholders)
  • Grupos Focales
  • Talleres Facilitados
  • Tormenta de Ideas
  • Técnica de Grupo Nominal
  • Análisis de decisiones de múltiples criterios
  • Mapas Mentales
  • Diagramas de Afinidad
  • Cuestionarios y Encuestas
  • Observación
  • Prototipos
  • Estudios Comparativos (Benchmarking)
  • Diagramas de Contexto
  • Toma de Decisiones en Grupo
  • Técnica Delphi

La base es, reúne toda la información posible y empieza a darle forma hasta dejar un requisito/s en condiciones (ver post (@Los Requisitos))

Lo importante de esto es reconocer que estas técnicas permiten recoger información valiosa más allá de conocer cada una de ellas, y especialmente tener claro que si estamos recogiendo información significa que todavía estamos planificando.

Cualquier requisito nuevo o modificación se gestionará a través de la gestión del cambio.

Categoría de Requisitos

Agruparlos mejora y facilita su seguimiento y mantenimiento, evita duplicados…

Categoría de los requisitos

Hay que recordar que lo primero, más valioso y necesario durante el examen de certificación es situar la pregunta en el contexto y saber en que punto estamos del proyecto y de la gestión del proyecto para poder responder.

Los Requisitos

NOTA: Este post no es para el examen PMP, pero es un buen recurso que nunca está de más!

Me parece necesario e interesante hacer una pausa y detenernos en el concepto de @los requisitos, voy a dejar un pequeño esquema de lo que tiene que ser un requisito, es algo que me acompaña desde la carrera, lo dimos en ingeniería del Software pero sirve para cualquier proyecto, de cualquier rama, tipo o naturaleza del mismo, desde un proyecto de desarrollo de software a un proyecto de una campaña de marketing, como de montar una tienda.

Es importante tener claro también que estos requisitos se listan después de hacer la recopilación del análisis funcional para un proyecto.

Sobre estos requisitos por norma general se generan y asocian las pruebas, si son necesarias.

@Las cualidades de los requisitos: 7 principios que tiene que cumplir un requisito.

  • Tiene que ser Necesario.
  • No ambiguo. que no entre en conflicto con otros requisitos
  • Conciso, breve
  • Consistente (que no sea contradictorio con otros requisitos).
  • Completo (es una utopía no se suele cumplir, pero hay que intentarlo).
  • Alcanzable
  • Verificable (se tiene que poder comprobar).

En todo proyecto pueden existir y de hecho se pueden agrupar por tipología o categoría de requisitos que veremos más adelante, una agrupación clásica por ejemplo en Ingerniería informática es agrupar primero por requisitos funcionales y no funcionales

Procesos de Dirección Alcance

Vamos a empezar con @La Gestión del Alcance en los proyectos

Desde mi punto de vista y aunque tiempo y costo, tienen mucho peso, es el alcance el que marca realmente y da entidad a un proyecto.

La gestión del alcance se encarga de definir aquello que se quiere construir-desarrollar-obtener con el proyecto.

Tiene que ser un proceso en cadena, me explico, intentar siempre ir desde un nivel abstracto o general, a poco a poco ir profundizando y dando forma a entregables o paquetes concretos, a fin de conseguir un mapa coherente de aquello que es necesario para cumplir los objetivos.

WBS

De los tres pilares, el alcance es el que más sufre y el factor que mayoritariamente marca la pauta del tiempo y el costo.

Los procesos de Dirección son los que siguen:

Procesos - Gestión Alcance

El alcance hay que mimarlo, dedicarle tiempo, consensuarlo y estar cómodos con lo que se defina.

NOTA: Un detalle importante, todas las áreas de conocimiento tienen procesos tanto del grupo de planificación cómo del grupo de seguimiento y control, son los dos únicos grupos que tienen procesos para cada una de las áreas

Grupo de proceso de Planificación

  • Planificar la gestión del alcance Este proceso “siempre lo encontraremos como “planificar la gestión de” (alcance, tiempo, coste…) y pretende enmarcar y englobar todo lo necesario para definir cómo vamos (valga la redundancia) a definir y manejar el alcance, básicamente es crear el plan de alcance, esto es especialmente importante en proyectos muy grandes (ejemplo: construir un aeropuerto)
  • Recopilar requisitos Hay poco que decir, revisar y conseguir definir todos los requisitos que serán necesarios para completar el proyecto.
  • Definir el alcance Hacer una descripción en profundidad de lo que se va a producir o realizar en el proyecto
  • Crear la EDT De sus siglas Estructura de Desglose de trabajo o en inglés WBS (Work Breakdown Structure) y viene a ser la descomposición de todo el alcance en entregables manejables. Es especialmente importante que en este proceso participe el equipo que va a producir los entregables.

Grupo de procesos de Seguimiento y Control

  • Validar el alcance Durante el proyecto a medida que vamos completando trabajo es necesario confirmar por parte del cliente su aceptación formal. Este proceso se complicará con un alcance ambiguo o requisitos mal definidos y será más sencillo y natural si los requisitos son claros y por tanto lo es el alcance.

  • Controlar el alcance Igualmente durante el proyecto tenemos que medir continuamente como vamos con respecto a la estimación que hemos realizado en el plan de proyecto e ir realizando ajustes y cambios.

Herramientas y Técnicas

Herramientas y Técnicas

Esta es una imagen sintetizada de las @herramientas y técnicas utilizadas en el área de conocimiento de integración, y en cada grupo de procesos

Técnicas y Herramientas - Integración

Como se aprecia en este caso, por ejemplo, el juicio de expertos está presente como herramienta para los seis procesos (en seguimiento y control (S y C) hay dos procesos.

Los colores indican una relación herramienta-proceso para casos concretos.

Este cuadro agrupa la información que en el PMBOK aparecería de la siguiente forma:

Herramientas - Integración

Con este post damos por finalizado el repaso general para los procesos directivos dentro del área de conocimiento de integración.

Recordar que en el examen en todo momento lo primero que hay que hacer con cada pregunta es identificar a qué área de conocimiento y grupo de procesos pertenece una pregunta.

Proceso para realizar cambios

He aquí uno de los pilares de la gestión de proyectos como tal y del día a día de los proyectos y del trabajo de un jefe de proyecto.

Los @Cambios por normal general son una fuente ilimitada ya no de problemas, sino de discordia pues es una conversación en la que el proveedor suele limitar al cliente. Lo romántico e ideal es que el alcance sea en su definición siempre algo claro y sencillo, especialmente en los requisitos, y de hecho este debe ser este el objetivo, cuanto más claro y sencillo, mejor vamos a vivir el día a día del proyecto.

La realidad es que, aunque nuestro esfuerzo sea máximo a la hora de definir el alcance siempre faltará algo, o incluso cambiará algo (por avances tecnológicos, por necesidad cambiante del cliente…).

También es importante recordar y es especialmente cierto en los proyectos de IT, que el alcance a veces no está del todo claro, es decir, que el cliente no sabe exactamente lo que quiere sobre este escenario la metodología PMP sufre si no hay herramientas bien definidas, y por el contrario las metodologías ágiles lo llevan mejor.

Lo que hay que tener presente siempre, es basarnos en el alcance que se ha definido en el plan de proyecto, los entregables que esto implica y que cubren los requisitos detallados acordados.

Cuando el cliente solicita cambios, nuestro equipo detecta cambios, otros proveedores detectan cambios, o se dispara un riesgo, se traduce en:

  • Solicitud de cambio, cuando todavía estamos por ejemplo desarrollando o elaborando un entregable.
  • Cuando un entregable ya se ha desplegado implica un CR (siglas que vienen de Change Request) con los detalles resumen, costos económicos y tiempo, que generalmente va de la mano de un SOW (Statement of Work) con las especificaciones técnicas del cambio o necesidad.
    Un CR tiene siempre una dimensión acordada, por ejemplo, será necesario un CR cuando un cambio supere los XXXX euros o tenga unas ciertas características.
  • Nueva Fase o Evolutivo del proyecto, cuando se han detectado varios cambios o necesidades durante el proyecto no esenciales pero deseables en el futuro se puede agrupar en un nuevo proyecto (evolución del anterior o fase II) que amplíe la funcionalidad. Este será un nuevo proyecto independiente.
  • A veces los proyectos una vez desplegados van de la mano de un contrato de Servicio de Soporte (en proyectos IT debería intentarse siempre) que dé cobertura a la operación del cliente, y que suele incluir distintos tipos de peticiones, entre los que hay un tipo que es @petición tipo evolutivo, no confundir con la anterior, pero el alcance se limita a una funcionalidad concreta (mostrar nueva información, modificar una interfaz…)

 

Respecto al examen tener claro esta síntesis:

Es responsabilidad del Jefe de proyecto y del Sponsor/Patrocinador, velar por cumplir dichos requisitos, si empiezan a surgir cambios hay que canalizarlos mediante las herramientas establecidas.

El proceso de gestión de cambios resumido es:

  1. Prevenir la Causa Raíz de los cambios.
  2. Identificar el cambio
  3. Revisar el impacto en el área de conocimiento
  4. Realizar el control integrado de cambios
    1. Evaluar el cambio
    2. Buscar Opciones
    3. Aprobar o Rechazar el Cambio
    4. Actualizar el estado de cambio en el Registro de Cambios
    5. Ajustar el plan para la dirección de proyecto, los documentos del proyecto y las líneas base según sea necesario.
  5. Gestionar las expectativas de los interesados comunicando los cambios a los afectados
  6. Gestionar el proyecto de acuerdo con el plan de dirección y los documentos modificad

 

El director puede aprobar muchos de los cambios que surjan, pero, los que afecten al plan de dirección, líneas base, acta de constitución deben ser aprobados por el comité de control de cambios.

Líneas Base (Plan de dirección Proyecto)

Líneas base


Línea Base de Alcance:

Está compuesto por el enunciado del alcance, la estructura de datos (EDT) y el diccionario de la EDT

Aunque durante la planificación se itera varias veces para generar versiones finales, la línea base del alcance sirve de eje y cimiento para generar tanto el cronograma como la línea base de costos.

Define lo que se va a realizar, partiendo de las necesidades del cliente que es el enunciado del alcance, se generaran los requisitos a los que se da forma (especificaciones) para finalmente generar el mapa completo EDT.

Línea Base de Cronograma:

El cronograma acordado, incluidos fecha de inicio y cierre de cada actividad.

Tanto para esta línea base como para la siguiente (costos) es fundamental la disposición de recursos para acometer el proyecto.

Línea Base de Costos:

El presupuesto de costos en fases, es decir, el plan de gastos que indica cuánto dinero se aprueba para el proyecto y cómo se requerirán los fondos.

En conjunto estas líneas base son llamadas Líneas base para la medición del desempeño.

Las desviaciones de las líneas base comúnmente se deben a una identificación y gestión de riesgos incompletas (eventos no controlados, eventos infra/supra valorados)  o a carencias en la planificación (estimaciones que no se ajustan a la realidad, carencias no controladas…), por lo que generalmente una desviación requiere:

  • revisar los riesgos del proyecto.
  • probablemente una solicitud de cambio

[importante]

  • Cualquier modificación sobre las líneas base tienen que ser aprobadas por el comité o por el sponsor del proyecto.
  • Las líneas base se modifican siempre a visión de futuro, de fecha actual a fecha futura, nunca las estimaciones anteriores para proteger la integridad del histórico y de las líneas base anteriores. (es como una re-calibración o re-planificación)