Professional Documents
Culture Documents
1
OBJETIVOS DE LA PLANEACIÓN DEL PORTAFOLIO DE TI
2
PLANEACIÓN DEL PORTAFOLIO DE IT
Planeación de la
implementación no es
parte de la Charla
3
EQUIPO DE TI PARA LA PLANEACIÓN
Responsabilidades Participantes
Líder de
Planeación de
• Administrar el proceso de Portafolio
planeación
• Apoyar a las UNs en la
generación/desarrollo de
las ideas de proyectos
• Coordinar esfuerzos de IT Cabeza de
Coordinador de
en el desarrollo de las Planeación de
Proyectos Arquitectura
propuestas
• Desarrollar un modelo
estándar de costeo
• Operar y mantener las
herramientas de
planeación si existen Grupo de Grupo de
Planeación: planeación: ...
Proyecto 1 Proyecto 2
4
AGENDA
5
GENERANDO IDEAS DE PROYECTOS
Factores a tener en cuenta
6
IDEA DE PROYECTO DE TI (1/2)
Forma diligenciada por:________________
7
IDEA DE PROYECTO DE TI (2/2)
Forma diligenciada por:____________
B. Beneficios estratégicos
Todos aquellos beneficios estratégicos que no
pueden ser cuantificados:– e.g., aumento en
competitividad, mayor flexibilidad, mayor valor
al cliente, etc
8
EVALUACIÓN DE BENEFICIOS
Ejemplo Medida
• Cambio en regulaciones • De 1 - 5
Urgencia de • Apagar un sistema
operación • Adaptar tipo de moneda
9
RESULTADOS: RANKING DE IDEAS
10
GUÍA PARA CLASIFICACIÓN EJEMPLO
Grado/
C B A
Categoría
Criterio 1 2 3 4 5
Urgencia
operacional NO necesario Elimina limitaciones Mejoras notables Elimina conflictos Ataca una
• Necesidad Técnica técnicamente/sin menores en el uso en seguridad y críticos/introduce necesidad crítica
conflictos con otros del sistema confiabilidad nuevas capacidades extrema, la cual
sistemas importantes al representa grandes
sistema riesgos
• Necesidad legal o de No relevante Responde a la Cumple con Cumple con Cumple con
negocios acción requerimientos requerimientos requerimientos
recomendada (posiblemente no críticos necesarios para
críticos) la continuidad del
negocio
Beneficios Ninguno Logra impacto Lleva a una mejora Logra una Logra un impacto
estratégicos menor en posición gradual en mejora diferencia duradero
(Ventaja competitiva, competitiva de la posición (vía significativa en (vía nuevos
valor al diente) mejoras parciales posición (vía una mecanismos de
del sistema) mejor capacidad de soporte para
decisión) decisiones o salto
cuántico en calidad
de info.)
Beneficios < 100 100 - 200 200 - 500 500 – 1,000 1,000
Financieros
(en $ 000's)
11
GENERANDO IDEAS DE PROYECTOS: LECCIONES APRENDIDAS
• Explica claramente el proceso • UNs no toman el proceso seriamente hasta que ven las
desde el principio consecuencias: sus necesidades no aparecen en el
presupuesto
• Realiza el ranking solo después • Sin una visión general de las ideas, ud. no puede llegar
de que tiene la mayoría de las a una clasificación razonable , especialmente para los
ideas (80% por ejemplo) beneficios financieros, implicando una posible repetición
de tareas en el proceso más adelante.
• Excluye ideas con poco esfuerzo • No solo demora el proceso, sino que las UNs se
de trabajo para lograrlas molestan al ver que algunos de sus problemas no son
considerados dado que no caen en "A" o "B" (que es
usualmente el caso de las ideas que requieren poco
esfuerzo para lograrlas)
12
AGENDA
13
DESARROLLANDO PROPUESTAS DE PROYECTOS
Soluciones/
"Costo de
releases
implementa- Costo
ción "puro" total
Detalle Valor Neto
Empaquete/Asigne Ideas Depen- del Proyecto
requerimientos
den- Beneficios
Tecnología/ cias estimados
Arquitectura
14
DESARROLLANDO PROPUESTAS: OUTPUT REQUERIDO
15
EMPAQUETANDO IDEAS DE PROYECTOS
Matriz de
dependencias
Arquitectura
actual de • _____ B Lleva a mayores
sistemas
Componentes
• _____ eficiencias pues:
del Sistema
• _____ B • Promueve uso de
soluciones comunes
• _____
B
Arquitectura
• _____ • Permite un desarrollo
ideal del A A común de algunas
sistema propuestas
__
__
__
__
__
__
•
•
•
•
•
•
Ideas de Proyectos
16
ASIGNANDO IDEAS DE PROYECTOS
Participantes de IT
17
DETALLANDO LOS REQUERIMIENTOS
Proceso Objetivo
18
FORMULANDO SOLUCIONES
Desarrolle
• Busque integrar soluciones soluciones
entre ellas • En línea con la
arquitectura de
– Empaquetamiento de Sistemas Soluciones/
requerimientos pequeños • Defina la releases Analice
que permitan un desarrollo arquitectura de la Depen- dependencias
conjunto aplicación dencias • Uso de otros
– Romper soluciones en Busque soluciones proyectos
sub-partes (releases) parciales con un • Proveedor
fuerte impacto de para otros
• Busque mantener/construir negocios proyectos
en la arquitectura de
sistemas para ayudar a Arquitectura/
asegurar control. tecnología
19
SOLUCIONES: CONTENIDO
20
ANALIZANDO DEPENDENCIAS
Proceso Objetivo
21
REVISANDO ARQUITECTURAS/TECNOLOGÍAS
Proceso Objetivos
22
CALCULANDO COSTOS/BENEFICIOS
23
DESARROLLANDO PROPUESTAS DE PROYECTOS – LECCIONES
APRENDIDAS
24
AGENDA
25
CONSTRUYENDO ESCENARIOS DE PORTAFOLIO
26
CONSTRUYENDO ALTERNATIVAS DE ESCENARIOS
Escenario 1
Proyecto 1 80 20 20 20 20
• Optimizar el valor Proyecto 2 20 20
económico de los Proyecto 3 100 30 30 30 10
proyectos Proyecto 4 10 10
• Tener en cuenta las ...
dependencias en la Recursos 20 20 20 50 50 30 20
secuencia Est. Beneficio financiero (VPN) = 80
• Tener en cuenta las
Escenario 2
restricciones de Proyecto 1 80 40 40
habilidades/recursos Proyecto 2 20 20
• Optimizar los cambios Proyecto 3 100 20 40 40
tecnológicos Proyecto 4 10 10
...
Recursos 20 40 50 20 40 40
* Mes programador
27
ANALIZANDO ALTERNATIVAS DE ESCENARIOS
Análisis de limitaciones
Recursos
Escenario # 1
Duración
Nombre Tamaño Inicio estimada
Habilidades
Proyecto 10 MP 1.1.2001 2.5 años.
1, Ver.1
Proyecto 20 MP 1.1.2002 1 año.
1, Rel.2
Proyecto 30 MP – –
Complejidad
2
… … … … …
Dependencias
28
LIMITACIÓN #1: RECURSOS
250
Análisis de Recursos:
Tiempo
2003 2004 2005
29
LIMITACIÓN #2: HABILIDADES
10 Capacidad existente
Análisis de habilidades:
5
• Identifique las
habilidades requeridas
para implementar el Tiempo
2003 2004
escenario
Tiempo
2003 2004
Limite el análisis a 10
habilidades críticas
30
LIMITACIÓN #3: COMPLEJIDAD*
Análisis de complejidad: 2
Límite de
complejidad
• Identificar los oponentes 1
del sistema que trabajan
en múltiples proyectos
Tiempo
• Evalúe impacto de 2003 2004
complejidad en la
implementación Número de
individual de cada proyectos Complejidad: Sistema XXXX Límite de
proyecto Complejidad
3
• Eleve o baje los
requerimientos de 2
recursos con base en la
1
complejidad
Tiempo
2003 2004
* Basado en la matriz 31
DIBUJANDO UNA MATRIZ DE DEPENDENCIAS
Proyecto1,Ver.1
Proyecto1,Var.2
Proyecto2
Proyecto3
Una matriz de
dependencia de
proyectos: Proyecto1, Ver.1
• Resalta la necesidad de …
modularización
32
LIMITACIÓN #4: DEPENDENCIAS
Projekt 1, Rel. 2
Proyecto2 30 MP ...
Projekt 2
Projekt 3
… … …
Projekt 1, Rel. 1
1999 2000
Projekt 1, Rel. 2
Projekt 1, Rel. 1
Projekt 2, Rel. 1
Projekt 1, Rel. 2
…
Projekt 2, Rel. 1
33
ANALIZANDO ESCENARIOS – LECCIONES APRENDIDAS
34
AGENDA
35
SELECCIONANDO EL PORTAFOLIO
36