Gestión de Proyectos de TI

Buenas Prácticas

Ing. MBA Percy Diez

Gerente de Gestión de Proyectos TI – Banco de Crédito BCP
Consultor Senior – SolucionaMiProblema.com
Agenda
1. Introducción
2. Complejidad de los proyectos TI
3. Alargamiento de los proyectos TI
4. Iteración y faseo
5. Gestión de Portafolios y Programas
 1
Introducción
Fallas en los proyectos de TI (1 de 2)
• The Standish Group es una organización que presenta resultados en la
ejecución de proyectos de TI clasificándolos en:
– Exitosos (Succesful): Terminan en tiempo, dentro del presupuesto y con el alcance solicitado.
– Con complicaciones (Challenged): Terminan y quedan operativos, pero fuera de tiempo,
fuera del presupuesto o con menos funcionalidad que la solicitada.
– Fallados (Failed): El proyecto es cancelado en algún punto antes de terminar.

31% 16%

53%

Exitosos Con complicaciones Fallados

Fallas en los proyectos de TI (2 de 2)
• Este tipo de análisis son ratificados por las vivencias y experiencias de cientos
de personas relacionadas al mundo de TI.

• Sin embargo, un proyecto de TI es complejo, medirlo sólo por la desviación en

estas tres dimensiones, sobre todo teniendo como base el estimado original,
pone fuera de todo análisis las situaciones y cambios inherentes a un proyecto
de TI.

• Es necesario que los procesos de gestión de proyectos TI, pueda manejar

adecuadamente esa complejidad.

• El hardware de las sondas espaciales suelen resistir muchos años sin la

posibilidad de ser cambiado (están en el espacio); sin embargo, el software es
actualizado de vez en cuando para poder completar su misión.
 2
Complejidad de los
proyectos TI
Escribir software no es como otras ramas de la
ingeniería (1 de 2)
• Diferencia fundamental: Otras ramas de la ingeniería están
restringidas por las limitaciones físicas del mundo real, el
software no.
• Un edificio construido hasta la mitad, aún puede ser utilizado. En
software, es usual que o sirva todo o no sirva nada.
• Los componentes de la ingeniería tradicional existen en el
mundo real y pueden ser verificados y modificados en una
interacción ver-hacer, cosa que no se puede hacer en software.
• La programación orientada a objetos se creó
para acercar la programación a la realidad.
• Por ejemplo, trate de visualizar como
construir una casa en una calabi-yau.
Escribir software no es como otras ramas de la
ingeniería (2 de 2)
• Los componentes físicos de la vida real interactúan de maneras más limitadas y
predecibles. Por ejemplo, al construir un auto es difícil que una luz intermitente genere
fallas en el motor o que al construir una casa por error al jalar la palanca de un
excusado suene el timbre. Un pequeño trozo de software en un programa puede
generar efectos fuertes en toda una aplicación.

• Es más difícil hacer cambios al medio de un proyecto de ingeniería; el mundo físico es

menos maleable que el de software. El congreso de EEUU no puede ir a la mitad de un
lanzamiento a la luna y pedir que en vez de ello vayan a Marte.

• Hacer software es más arte que ciencia. Es como escribir novelas de ficción:
– Es un acto de creación.
– Con pocas reglas definidas.
– En un medio etéreo y con pocas restricciones.
– Es difícil de enseñar.
– Sólo se puede ver si es bueno cuando está listo integralmente, no cuando se está haciendo.

• Por todo lo explicado “ingeniería de software” es más un objetivo a realizar

que una realidad.
 3
Alargamiento de los
proyectos TI
Cuanto menos operacional es el proyecto
más eventos desconocidos existen
No realizar una identificación temprana de ciertos factores clave incrementa la
incertidumbre del proyecto y la polarización de expectativas de TI y el negocio

• Casos de diferentes expectativas

– Alcance:
• Qué debe cubrir
• Qué implementar para dar por concluido
• Cuándo pasa a requerimientos chicos
– Tiempo:
• Cuándo termina el proyecto
• Cuándo se implementará entregables con “valor
para el negocio”
– Costo:
• Cuánto costará la solución total

TI NEGOCIO
• Cuánto costará el mantenimiento
Las factores claves de alto impacto en los proyectos tienen que ver tanto con
aspectos de usuarios como de TI

• Identificar stakeholders • Dependencia y pre- • Validación con usuarios

Alcance requerido por el • Nuevas funcionalidades requisitos finales
usuario y stakeholders • Cambios en • Reportes y procesos que • Necesidades por madurar
funcionalidades existentes cambian de información sin TI (Excel, otros)
Factores clave de reducción de incertidumbre

• Ambiente (software y • Estrés y performance • Respaldo de información

Infraestructura tecnológica hardware) de desarrollo y • Capacity planning • Seguridad, auditoría,
base certificación • Contingencia monitoreo, fraudes
• Ambiente de producción • Alta disponibilidad

• Estabilidad operativa • Reducción de complejidad y Arquitectura

Consideraciones clave de • Inestabilidad existente • Eliminación de aplicaciones
TI • Riesgos latentes de inestabilidad • Migraciones y estándares (soporte)
• Interfaces y servicios, fuentes info.

• Ajustes en la estrategia • Cambios en puestos y roles • Despliegue

Acciones complementarias
del negocio • Capacitación y • Riesgo operativo
al proyecto TI que debe
• Cambios en procesos comunicaciones
realizar el usuario

• Proveedores • Riesgos potenciales inmediato

Estrategia de • Recursos BCP • Estrategia de faseo: no
implementación • Complejidad tecnológica siempre con uso usuario
Signos de falla en un proyecto TI (1 de 2)
Signos de falla en un proyecto TI (2 de 2)
Causas del alargamiento de los proyectos
Errores clásicos en proyectos
 4
Iteración y faseo
La clave es avanzar iterativamente
Macroproceso de Proyectos de TI
Gestión de Portafolio

Gestión de Programas

Evaluación de
proyectos Gestión de Proyectos - General

Planificación
General

Análisis de la
Gestión de Fases Max 6 meses
necesidad

Planificación Ejecución de
Cierre de Fase
de Fase Fase

Asignación de PM

Cierre de
Proyecto

Priorización de
proyectos

Semestral Análisis de la
Necesidad

Gestión de Cartera
Priorización y
planificación Inicio de Ejecución de Cierre de
periódica cartera cartera cartera

Trimestral
Trimestral

Proceso on demand

Proceso adaptativo a la priorización

Proceso periódico
 Faseo (1 de 2)
1 Construir un Log de 2 Identificar los Riesgos Generales
Requerimientos del proyecto
Algunos Sobre todo los relacionados a la incertidumbre
requerimientos
podrían quedar
generales
3 Definir un time-box para el proyecto
y estimar una cantidad de fases
“El time-box será 4 meses” - ”3 a 4 fases”
4 Construir un Cronograma General del proyecto
Fase 1 Fase 2 Fase 3 incorporando Requerimientos Específicos y
actividades para confrontar los Riesgos
4 meses Generales en cada Fase
Este cronograma está más orientado a ser un Gantt de alto nivel. No
existen sub-fases (“Fase 1-A”, “Fase 2 Etapa B”, etc.), sólo fases

SOL Proyecto X Fase 1

5 Crear requerimientos por cada
6 Construir un SOL Proyecto X Fase 2
Fase. Estos requerimientos
Cronograma SOL Proyecto X Fase 3
son Órdenes de Trabajo, una
de Fase el
por Fase
cual es
Se debe identificar las aplicaciones
detallado requeridas de manera obligatoria para
la Fase y las opcionales (que puede
No es relevante un detalle al nivel de actividades
realizarse en próximas fases)
arbitrariamente o basadas en el proceso de
Sólo se generarán los requerimientos
desarrollo, sino: 1) Actividades no mayores a 5
de la fase por iniciar y la
días, 2) Escenario de dependencia entre
inmediatamente siguiente
actividades y actividades especializadas
identificadas para la solución siendo desarrollada
 Faseo (2 de 2)
Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7 Mes 8 Mes 9 Mes 10 Mes 11 Mes 12

Las Fases no empiezan y terminan en los límites del

tiempo predefinido. Empiezan antes y terminan después

Pase
Fase 1 y
Fase 1 periodo
de
soporte

Pero existen hitos de Pase que marcan el quiebre entre las

Fases
Análisis Sdsds dsd sd asd asd
asd dsa asd as

Fase 2

Fase 2
Time-box

Fase 3
Sdsds dsd sd asd asd asd dsa asd
as

Sdsds dsd sd asd asd asd dsa asd as

Si por alguna razón Requerimientos

alguno de los muy largos
requerimientos para ser
específicos no se completados en
pudiera concluir en una fase,
Entre fases, podrían surgir nuevos
una Fase, pasa a la pueden
Requerimientos Específicos, generados por el
siguiente; nunca se empezar antes
usuario o por Sistemas. Sólo se debe aceptar su
altera el tiempo de la fase en la
incorporación al Log si están dentro del
predefinido. Esto se que se espera
alcance del proyecto y resuelven problemas. La
informa en el que esté listo
priorización de lo que va en la fase se decide
Comité de
con el Líder Usuario y se informa (revisa y valida)
Proyecto (para su
al Broker de Negocios y al de Sistemas
aprobación)
 5
Gestión de Portafolios y
Programas
Framework PMO
Conceptos
Sub-proyecto

Proyecto Sub-proyecto

Portafolio de Proyectos
Sub-proyecto
Programa Proyecto
.
Proyecto .
Programa
. .
.
Programa .
.
.
.
Portafolio Programa Proyecto Sub-proyecto
• Conjunto de programas • Conjunto de proyectos interrelacionados • Encargo temporal que realiza • Conjunto de actividades que
y proyectos estratégicos que aportan a un objetivo estratégico del un conjunto de acciones para aporta en la implementación
para el negocio negocio producir un producto o de un proyecto
• Gestión centralizada de • Conjunto de proyectos agrupados debido servicio único • Individualmente un sub-
recursos, presupuesto, a economías de escala y sinergias • Debe entregar uno o más proyecto podría tener poco o
procesos, indicadores, posibles en la gestión de recursos, beneficios al negocio de ningún valor, ganando su valor
etc. stakeholders, proveedores, estrategia de acuerdo a un caso de negocios al aportar al objetivo de un
ejecución, arquitectura, etc. específico proyecto
• Pueden ser temporales o permanentes

Evaluación de Proveedores
Operaciones, Sistemas y
Gestión de Proyectos

Administración Motor de Reglas de Calificación Prueba de concepto con FICO

Incorporación del Motor en

Huascarán Alianzas TC MIC
.
Call Center .
SIGA .
.
. .
. .
.
 Big Bang
Suite de Mercado de Capitales Valerie Camp Derivación de Canales Luis Vásquez
Telecrédito Tarjeta Chip
Every Orellana
Firmas y Poderes
SIPAN – Planificación Comercial Ana Cecilia Espinosa
Alianzas
Negocios

Gestión de Activos y Banca Mayorista (3) Valerie Camp Funcionalidad Tarjeta de Crédito Javier Lee

Riesgos
Giannina Cruz Cobranzas
Ana Yoshikawa
Nuevo Teller Mirtha Arcela
Call Center
Rosario Gonzáles
Rediseño de Plataforma Claudia Lisson Gestión Comercial
Raúl Díaz
Karín Camargo Inteligencia Comercial

Canales Minorista (5) Giannina Cruz Huascarán (4) Gloria Varela

SIGA BCP – F2 Contabilidad/Gerencia Haydeé Urquiaga Basilea II Rafael Guzmán

SIGA Credis José Luis Mendoza Central de Riesgos por Operación

SIGA BCB/Prima/PPS - RRHH Giancarlo Raicovi Cubo de Información Financiera Pablo Gómez-Olmedo

SIGA BCB – F1 Contabilidad/Compras Jorge Yaco Nuevo Reglamento de Provisiones Vincent Espinoza

SIGA (4) Haydeé Urquiaga Información de Gestión (4) Ana López

Staff

Implementación Mejoras Integración Alfonso Príncipe

Sede Chorrillos Milagros Rengifo
Identity Management 2
Silvia Shimabukuro Descentralización de Call Center Luis Apolaya
Migración de Datacom a DB2
OOR (Out Of Region) Carlos Salazar
Datacard Maria Eugenia Aliaga

Operaciones y Sistemas (4) Rosa Villanueva ECO (3) Luis Apolaya

Portafolio de Proyectos (30) Análisis y Planificación de Portafolio (1) Percy Diez Quiñones
 Gestión de Proyectos: Objetivos y Roles
 Objetivos:
 Gestionar proyectos estratégicos (grandes) del negocio relacionados a tecnología de información
 Efectuar las acciones que se requieran para satisfacer los requisitos de alcance y tiempo solicitados para el proyecto
 Administrar los recursos asignados a los proyectos de manera óptima

Project Manager Program Manager Portfolio Manager

• Gestión de evaluación de proveedores
y pruebas de concepto
• Conducción de la Planificación
General (Fase 0) del proyecto
• Diseño de la estrategia de ejecución
del proyecto (stakeholders, alcance,
actividades, fases, recursos,
comunicaciones, etc.)
• Provisión de información del proyecto
a stakeholders en los foros que se
requiera
• Conducción de la ejecución del
proyecto (monitoreo y control)
• Identificación y resolución de riesgos y
problemas
• Elaboración y administración del
presupuesto del proyecto
• Administración de proveedores
• Gestión de controles de cambios
• Supervisión de la planificación y
ejecución del proyecto
• Supervisión y apoyo en la gestión de
riesgos y problemas
• Primer nivel de escalamiento de
problemas
• Identificación e implementación de
sinergias dentro del programa (enfoque
integral, largo plazo, presupuesto,
proveedores)
• Aseguramiento del uso de los procesos
y de las mejores prácticas en gestión de
proyectos
• Identificación e incorporación de
lecciones aprendidas en la gestión
• Gestión de indicadores por programa y
proyectos
• Fortalecimiento del rol Project
Managers (mentoría y desarrollo)
• Planificación y gestión de un portafolio de
proyectos óptimo para el negocio y viable
en su ejecución
• Elaboración y sustentación del
presupuesto
• Gestión de la priorización y asignación de
recursos al proyecto
• Gestión de riesgos y problemas del
portafolio
• Gestión de proveedores (acuerdos
económicos y de asignación de recursos,
búsqueda de optimizaciones)
• Provisión de información sobre el estado
del portafolio en Comité de Productividad,
IT Governance y Sistemas, u otros de ser
requerido
• Gestión de indicadores del portafolio
• Tareas relacionados a la gestión de
recursos humanos (selección, evaluación,
etc.)
 Rol del Program Manager por Tema
Planificación General y Estrategia • Valida la realización integral de la planificación general del proyecto y vela por el cumplimiento de sus premisas
del Proyecto
Ejecución / Seguimiento /
Escalamiento
Riesgos y Problemas
Presupuesto
Proveedores / Contratos /
Facturas
Gestión de Stakeholders / Temas
Políticos
Planificación Trimestral
Priorización Semestral
Controles de Cambios
Procesos
Indicadores
Ausencia del PM
Evaluación del PM
Capacitación y otros aspectos
integrales del programa
• Identifica riesgos, alertas y actividades a realizar que deben ser consideradas en el proyecto
• Identifica sinergias y economías de escala
• Integra e identifica impactos en otros proyectos del programa
• Incorpora una visión a mediano y largo plazo del proyecto en el contexto del programa
• Valida y propone stakeholders y recursos que requiera el proyecto: Proveedores, Usuarios, Sistemas
• El plan de comunicación incorpora al PgM como un nivel de escalamiento
• Participa validando: RDP (alcance estructurado, WBS), Cronogramas, Bitácora, Stakeholders, Entorno
• Es el revisor de pares del RDP en el contexto de proceso
• Monitorea que el seguimiento sea adecuado: a nivel de hitos y entregables, retrasos, prevención y planificación de siguientes actividades
• Supervisa a través de mecanismos formales que establezca con los PMs: reunión individual, reunión de programa, reporte de estado (el mismo de las
reuniones del proyecto)
• Participa en reuniones de seguimiento de proyecto, de Comité de Proyecto y otras relacionados de acuerdo a lo que se requiera
• Identifica necesidades de escalamiento y realiza acciones para apoyar o activarlas
• Identifica problemas de control de alcance y productividad del equipo y realiza acciones para escalarlo o resolverlas
• Supervisa la gestión de riesgos y problemas del proyecto (por la visibilidad que tiene de riesgos adicionales)
• Identifica riesgos y problemas del programa
• Revisa y ajusta el presupuesto
• Sustenta el presupuesto del programa a unidades externas adicionales al ciclo de presupuestación (Auditoría, MAS, Compras, Producción)
• Promueve y vela por un máximo ajuste en los costos y participa en los ciclos de ajustes presupuestales
• Maneja la trazabilidad de la evolución del presupuesto
• Administra el conocimiento y acercamiento inicial al proveedor
• Interactúa con el account-manager
• Asesoría en forma de gestionar al proveedor (planificación del seguimiento, estructura de pagos, etc.)
• En negociación de contratos: vela por el benchmark y estandarización de precios
• Supervisa las consideraciones complementarias de los acuerdos con proveedores: garantía, calidad, soporte, etc.
• Apoya al PM en la negociación
• Apoya el escalamiento a nivel del proveedor
• Resuelve y maneja temas que generen controversia
• Valida la planificación trimestral de requerimientos (recursos, actividades)
• Apoya la elaboración de casos de negocios (cuando se requiera)
• Valida la propuesta de horas requeridas por semestre
• Gestiona la prevención y contención de controles de cambio de usuarios y de sistemas
• Propone mejoras a los procesos y vela por su cumplimiento en su programa
• Lleva y gestiona indicadores a nivel de programa
• Identifica y gestiona mecanismos de respaldo ante la ausencia de PMs
• Hace seguimiento a actividades crítícas previamente acordadas con el PM
• PgM da feedback a PMs de forma permanente
• PgM pre-evalúa y acompaña el proceso de evaluación al PM
• Identifica y presenta necesidades de los PMs como capacitación, infraestructura, etc.
Conceptos clave: PMO y PPM
Project Management Office (PMO) Project Portfolio Management (PPM)

• Procesos (del proyecto y producto TI) Selección y • Información: Inversión, Retorno, Riesgo, Recursos requeridos
• • Peso: Scoring, Ranking
Práctica de
Herramientas, plantillas Priorización • Evaluación
• Estándares (certificaciones, métodos)
PM • Lecciones aprendidas y buenas prácticas de Proyectos • Elección
• Gestión del conocimiento

• Visibilidad del pipeline etc.)

• Recursos disponibles • Revisiones/inspecciones
• Planificación optimización (TCO, Gestión de • Estado de la demanda • Medición
• Uso eficiente y pronóstico de corto/largo plazo) • Proyectos en proceso
recursos • Caso de negocios (parte TI)
los Proyectos
• Riesgos del portafolio (sobre
Consultoría • Toma de decisiones de • Elección de stakeholders y demanda, riesgos operativos,
funcionalidad, presupuesto, niveles de involucramiento
Interna cronograma • Información para toma de
• Idoneidad de la comunicación decisiones
de proyecto • Auditoria a proyectos de alto
• Estimación presupuestal y riesgo • Mantener el pipeline actualizado
Gestión del • Actividades previas a la inclusión de proyectos en proceso:
Pipeline maduración, recursos requeridos, arquitectura,
infraestructura, etc.

• Planeamiento de la capacidad
Gestión de • Asignación
• Entrenamiento y capacitación
PMs • Desarrollo de carrera Gestión de • Programación y contratación de recursos
• Desarrollo de equipo • TI (incluye pruebas, control de cambios, desarrollo, etc.)
Recursos • Proveedores
para • Dependencias entre proyectos
Proyectos • Pronóstico de recursos demandados

• Alineamiento a la estrategia de la empresa

• Punto central de información proyectado)
Alineamiento • Difusión del desempeño y logros de proyectos
• Estado del pipeline • Composición del portafolio
• Relación con sponsors y líderes usuarios
al negocio • Alineamiento a arquitectura
Provisión de • Utilización de recursos (por tipo de proyecto,
• Desempeño del proyecto alineamiento estratégico,
• Project Portfolio Management Información (trabajo en progreso, inversión/gasto, etc.)
inversión y gasto incurrido y • Productividad
Modelo de Maduración de Capacidades de un PMO (Gartner 2007)
 Gestión del Portafolio de Proyectos Grandes
TI Objetivo

Evolucionar del desempeño del

Personas project y program manager

Definir y mejorar continuamente los

procesos de gestión de proyectos y
Procesos de atención de requerimientos TI
relacionados

Asesorar y revisar la planificación y

ejecución de proyectos para su
Proyectos desempeño adecuado

Planificar y programar el uso de

Recursos e recursos internos y externos de BCP
infraestructura para proyectos

Consolidar, mantener actualizada y

Información y distribuir información de proyectos y
presupuesto de sus presupuestos
Preguntas

¿?
 Fin de la presentación

Gestión de Proyectos de TI
Buenas Prácticas
Arquitectura Empresarial de Sistemas

Ing. MBA Percy Diez Quiñones

Gerente de Gestión de Proyectos TI – Banco de Crédito BCP
Consultor Senior – SolucionaMiProblema.com