CALIDAD Y TÉCNICAS DE EVALUACIÓN DE LOS

SISTEMAS

GESTIÓN DE
PROYECTOS
(PMBOK)
PIERRE SERGEI ZUPPA AZÚA
 GESTIÓN DE PROYECTOS

Es la disciplina que guía e integra los

procesos de planificar, captar,
dinamizar, organizar talentos y
administrar recursos, con el fin de
culminar todo el trabajo, pero
sobretodo cumplir con el alcance,
dentro de límites de tiempo, y costo
definidos: sin estrés y con buen clima
interpersonal.

También requiere liderar los talentos,

evaluar y regular continuamente las
acciones necesarias y suficientes.
ENFOQUES DE PROYECTO

Ejemplos:
• lean (producción esbelta)
• Reiterativo
• Incremental
• fase

Sin importar la metodología

utilizada, se deben considerar
los objetivos totales del
proyecto, los tiempos, los
costos, los roles y
responsabilidades de cada
participante (Interesados o
stakeholders).
Project Management
Knowledge
Body of PMBOK
Desarrollada por el PMI formada por
el conjunto de conocimientos en
Dirección/ Gestión/ Administración
de Proyectos generalmente
reconocidos como «buenas
prácticas», y que se constituye
como estándar de Administración de
proyectos.

Esta guía comprende:

1. Los procesos y contextos de un
proyecto.
2. Las áreas de conocimientos
específicos para la gestión de un
proyecto.
 ¿POR QUÉ USAR PMBOK?

La ventaja de utilizar es que

es de aplicación general, es Áreas del
decir que las practicas y Procesos conocimiento
conocimientos descritos en básicos
él pueden ser, en su mayoría,
adaptados a muchas
realidades organizacionales.
Además, puede decirse que
existe una conciencia global
acerca de su valor y utilidad.
MARCO DE REFERENCIA DE PROYECTOS DE TI

Se desarrolla a partir de aspectos

teóricos, conceptuales,
legales, geográficos e institucionale
s del objeto a investigar.
 FUNCIONES DEL MARCO DE REFERENCIA

1. Ayuda a prevenir errores que se han cometido en otros estudios.

2. Nos permite dar cuenta de cómo ha sido tratado un problema (qué tipos de
estudios se han efectuado, con qué tipo de sujetos, cómo se han recolectado los
datos, en qué lugares se han llevado a cabo, qué diseños se han utilizado).

3. Nos permite centrarnos en el problema evitando desviaciones del

planteamiento original.

4. Conduce al establecimiento de hipótesis o afirmaciones que más tarde habrán

de someterse a prueba en la realidad.
 DISCUSIONES ACERCA DE LAS FALLAS Y EL ÉXITO

El éxito del proyecto depende directamente del cuidado que se tenga en obtener y
gestionar los requisitos del proyecto y del producto.

Recopilar requisitos significa definir y gestionar las expectativas del cliente.

La planificación del costo, del cronograma y de la calidad se efectúa en función de.

Hay que distinguir entre requisitos del proyecto y requisitos del producto.

Proyecto: pueden incluir los requisitos de la empresa, de dirección de

proyectos, de entrega, etc.

Producto: pueden incluir la información sobre requisitos técnicos, requisitos de

seguridad, de desempeño, etc.
HERRAMIENTAS Y TÉCNICAS

Entrevistas, cuestionarios, encuestas y

observación: A través de estas técnicas,
se obtiene información de los interesados,
ya sea de manera formal o informal.

Grupos de opinión: Se reúne a los

interesados claves del proyecto junto con
un moderador que guiará al grupo.

Talleres facilitados: Se trata de sesiones

en las que los interesados interfuncionales,
se reúnen para definir los requisitos del
producto. Estos talleres proporcionan una
definición rápida de los requisitos de
funcionabilidad y ayudan a conciliar las
diferencias entres los interesados.
 HERRAMIENTAS Y TÉCNICAS

Técnicas grupales de creatividad: ayudan a

identificar los requisitos del proyecto y/o del
producto:
• Tormenta de ideas (Brainstorm) y técnicas de grupo
nominal
• Técnica Delphi
• Mapa conceptual
• Diagrama de afinidad
• Etc.

Técnicas grupales de toma de decisiones:

Es un proceso de evaluación de múltiples
alternativas con relación a un resultado
esperado. (Unanimidad, Mayoría, Pluralidad,
Dictadura)

Prototipos: Elaboración de una versión

preliminar del producto final, para obtener
una retroalimentación sobre los requisitos del
producto, antes de construirlo
 SALIDAS

Documentación de requisitos: Describe

el modo en que los requisitos individuales
cumplen con las necesidades del Proyecto.

– Justificación del Proyecto (necesidad

comercial u oportunidad)
– Objetivos de la organización y el Proyecto
– Requisitos de funcionabilidad del producto o
servicio
– Requisitos no funcionales (nivel de servicio,
desempeño, seguridad, ect.)
– Requisitos de calidad
– Criterios de aceptación
– Supuestos
– Restricciones
– Impactos del Proyecto en otras áreas o
entidades
– Etc.
SALIDA

Plan de Gestión de
requisitos : Documenta cómo
se analizarán, documentarán
y gestionarán los requisitos a
lo largo del Proyecto.

Matriz de trazabilidad de
requisitos: Tabla que vincula
los requisitos con el objetivo
que le dio origen, que permite
monitorizarlos a lo largo del
ciclo de vida del Proyecto.
 FASES DE INICIACIÓN

Consiste en entender el problema o la oportunidad.

En primer lugar se requiere diferenciar entre necesidad y

solución.

Necesidad:
• Describe el fin para cliente
• Especifica metas y objetivos
• Deja abierta la pregunta de cómo hacerlo
• La respuesta al porque se esta haciendo debe apuntar
a una justificación de negocio.

Solución:
• Describe los medios para el equipo
• Especifica estrategias e ideas para conseguir las metas
y objetivos.
• Especifica cómo hacerlo.
• La respuesta al porque se esta haciendo debe apuntar
al requerimiento del cliente.
• Preguntar para identificar la necesidad real puede
hacer sentir incomodo a terceros por desconfiar de su
criterio.
 FASE INICIAL

Esta fase debe tener como output la generación del

documento de requerimientos del proyecto, el cual no
ofrece una solución sino que únicamente describe una
necesidad.

Este documento debe contener los siguientes apartados:

• Descripción del problema o oportunidad
• Impacto o efecto del problema
• Identificar quien o que se encuentra afectado por el
problema
• Impacto de ignorar el problema
• Situación deseada
• Beneficios asociados a conseguir la situación deseada
• Alineación con la estrategia de la organización
• Conflicto de compatibilidades con otras áreas de la
organización
Coste del proyecto y nivel de personal típicos a lo
• Incertidumbres
• Suposiciones clave
largo del ciclo de vida del proyecto
• Limitaciones de la solución
• Consideraciones del entorno
• Información histórica de soporte
• A partir de la recopilación de toda esta información, se
requiere valorar nuevamente si merece la pena resolver el
problema y determinar si existe una solución potencial.
 ARTEFACTOS DE LA FASE DE INICIO

Visión del negocio: Describe los objetivos y

restricciones a alto nivel.

Modelo de casos de uso.

Especificación adicional: requisitos no funcionales.

Glosario: Terminología clave del dominio.

Lista de riesgos y planes de contingencia.

El caso de negocio (business case).

Prototipos exploratorios para probar conceptos o

la arquitectura.

Plan de iteración para la primera iteración de la

fase de elaboración.

Plan de fases.
CONCLUSIONES DE LA FASE DE INICIO

Se deben comprobar los criterios de evaluación para

continuar.

Todos los interesados en el proyecto coinciden en la

definición del ámbito del sistema y las estimaciones
de agenda, también deben quedar bien establecidos
algunos elementos claves para el correcto desarrollo
del proyecto en cuestión, como por ejemplo:

• Entendimiento de los requisitos, evidenciado por

la fidelidad de los casos de uso principales.
• Las estimaciones de tiempo, coste y riesgo deben
ser creíbles.
• Comprensión total de cualquier prototipo de la
arquitectura desarrollado.
• Los gastos hasta el momento se asemejan a los
planeados.
• Si el proyecto no pasa estos criterios hay que
plantearse abandonarlo o repensarlo
profundamente.
 FASES DE PLANIFICACIÓN

Consiste en Identificar la solución más

óptima

Con objeto de identificar soluciones que

cubran la necesidad establecida se puede
seguir el siguiente procedimiento:
1. Brainstorming grupal con miembros del
futuro equipo de trabajo o
stakeholders.
2. Comprobar en que grado satisfacen los
planteamientos del documento de
requerimientos del proyecto.
3. Seleccionar entre 2 y 5 soluciones.
Influencia de la estructura de la
4. Realizar un análisis detallado para
organización en los proyectos identificar cual de ellas es la que mejor
se adapta a la necesidad a cubrir e
implica un coste asumible.
 ANÁLISIS FINANCIERO
(COSTES VS BENEFICIOS)

Para validar la viabilidad

financiera del proyecto es
necesario identificar los flujos
de entrada de dinero que este
puede generar, por ejemplo
beneficios obtenidos por la
implementación del proyecto
(incremento en ventas,
reducción en costes, etc…) y
Influencia de los interesados a lo largo
los gastos que representa la del tiempo
puesta en marcha y gestión del
proyecto.
 CASH FLOWS

Para identificar que proyecto nos aporta

una mayor rentabilidad financiera.

• Net Present Value (NPV). Determina

cuanto dinero va a generar el proyecto
teniendo en cuenta el valor del dinero
en el tiempo.

• Internal Rate of Return (IRR). Determina

la rentabilidad de la inversión.

• Payback period. Determina cuando se

recuperará la inversión (NPV = 0).

• Cash hole. Determina la máxima

inversión necesaria.
ANÁLISIS NO FINANCIERO (MODELO DE PUNTUACIÓN
DE FACTORES PONDERADOS – DECISION MATRIX)

Se inicia mediante la
elaboración de un listado
de atributos a valorar.
Para cada uno de ellos se
establece una
ponderación y se asignan
puntuaciones que
denoten el nivel de
cumplimiento de cada una
de las soluciones.
Ventajas:
• Permite el uso de diversos
datos, incluidos los
financieros.
• Permite la implicación de
gerencia y el análisis de
sensibilidad.

Desventajas:
• Proceso altamente subjetivo.
• Muestra el atractivo del
proyecto pero no representa
una justificación de negocio.
OTRAS HERRAMIENTAS

Estudios de mercado

Pruebas piloto. Prueba en área

limitada.

Prototyping. Construcción de
una pequeña parte del
proyecto para validar las
correctas predicciones.

Simulación por ordenador.

 FASES DE CONTROL

Consiste en desarrollo de la solución y

elaboración de un plan

En esta fase se desarrollará en un mayor

detalle la solución escogida mediante el uso
de un Logframe (esquema básico de
definición del proyecto).
– Objetivo
– Propósito
– Resultados
– Actividades

Para cada uno de estos niveles se debe

especificar:
– Indicadores que permitan verificar la evolución.
– Medios para obtener la información necesaria
para constituir los indicadores.
– Supuestos clave y el riesgo asociado.
STAKEHOLDERS

El logframe permitirá monitorizar y evaluar la

evolución del mismo. Un logframe debe ser
conciso y fácilmente comprensible por personas
que se incorporan a mitad de proyecto.

Paralelamente a la elaboración del logframe, se

requiere realizar un análisis de los
stakeholders del proyecto con el objetivo de
gestionar las relaciones y prever oposiciones.
Se considera stakeholders aquellos individuos o
instituciones que:
– Pueden ganar o perder dependiendo del éxito del
proyecto.
– Proveen fondos económicos
– Proveen recursos al proyecto
– Participa/trabaja en el proyecto
– Se encuentran afectados por el rendimiento del
proyecto
– Se encuentran afectados por el resultado del
proyecto
 DOCUMENTO DE DEFINICIÓN DE PROYECTO

Se realiza con la finalidad de:

– Identificar el trabajo a realizar.
– Durante la ejecución, permite
identificar cuando se esta
sobrepasando los limites y
permite renegociar el contrato
original.
– Establece el criterio para
considerar completado el
proyecto.
– Establece los criterios para
considerar exitoso el proyecto.
– Permite llegar a acuerdos y
facilitar la comunicación.
EL DOCUMENTO DEBE CONTENER

• Breve descripción del problema u

oportunidad
• Breve descripción de la solución propuesta
• Descripción del trabajo y la estrategia de
ejecución. Identificar las diferentes grandes
tareas y sus interrelaciones. Parte más
importante del documento. Será la base
para el WBS.
• Entregables acordados.
• Criterios de finalización de proyecto.
• Riesgos e incertidumbres.
• Suposiciones.
• Plan preeliminar de ejecución.
• Listado de los stakeholders involucrados.
• Criterios de éxito del proyecto.
FASE CIERRE

Se considerará que el proyecto

ha llegado a su fin cuando todos
los entregables hayan sido
enviados al cliente, todo esté
documentado y el cierre formal
del proyecto haya sido aceptado
por él. En ese momento los
recursos asignados al proyecto se
liberarán y entrará en juego el
servicio de Soporte Post-
Venta para resolver cualquier
duda o incidencia que pudiera
surgir.
 CIERRE PMBOK

- La administración y cierre de
contratos: Evaluando el proceso y
extrayendo de este las posibles
lecciones aprendidas.

- El cierre administrativo del

proyecto: este proceso consiste en
la revisión de todos los reportes de
avance generados durante el
proyecto, para garantizar que se hay
cumplido con todas las actividades
y se han obtenido los entregables
esperados.
 IMPORTANCIA DEL CIERRE DEL PROYECTO

¿Qué aprender después del cierre?

Incorporar a próximos proyectos actividades que no se habían visualizado.

Reconsiderar estimados en la duración o en el costo de una actividad.
Identificar riesgos, previamente no considerados.
Incorporar nuevas cláusulas o quitar trabas legales, para potenciar una
contratación más transparente.
Determinar mejores especificaciones de calidad.
Introducir novedosos incentivos al personal.
Concientizar en lo referente a la necesidad de subcontratar algunas
actividades, en las que no se tiene un know – how de primer nivel.