You are on page 1of 37

CONFIDENCIAL

Optimizando la Planeación del


Portafolio de Proyectos de TI

I Jornada Nacional de Gerencia de Proyectos de TI

Juan José Uribe – McKinsey & Company

Bogotá, Mayo, 2003


AGENDA

• Planeación del Portafolio

• Fase 1: Generando Ideas

• Fase 2: Desarrollando Propuestas


• Fase 3: Construyendo Escenarios

• Fase 4: Seleccionando el Portafolio

1
OBJETIVOS DE LA PLANEACIÓN DEL PORTAFOLIO DE TI

• Asegurar valor económico a través de:


Maximizar el valor – Métodos estándares de evaluación
económico del – Conjunto común de prioridades
portafolio • Crear sinergias a través del empaquetamiento de requerimientos
similares

• Planear a largo plazo para asegurar los recursos suficientes


Optimizar la
y la coordinación para los requerimientos más importantes
utilización de los
• Permitir la implementación oportuna de aquellos proyectos
recursos de IT
más pequeños que se encuentran en marcha

Construir • Lograr un claro compromiso desde el inicio tanto de Sistemas


confianza en el como de la Unidades de Negocio
proceso de • Planear las capacidades de TI con base en el Portafolio
planeación completo de IT

2
PLANEACIÓN DEL PORTAFOLIO DE IT

Desarrollar Construir Seleccionar


Generar Ideas Propuestas Escenarios Portafolio

UNs: UNs/TI: UNs/TI: TI:


• Generar Ideas • Refinar • Dibujar el • Armonizar el
• Formular requerimientos escenario y analizar portafolio TI
requerimientos y y beneficios de acuerdo a los • Preparar
beneficios TI: principales Recomendaciones
• Fijar las primeras • Desarrollar impedimentos UNs:
prioridades en soluciones • Evaluar
talleres de trabajo preliminares recomendaciones
• Estimar costos • Entregar el
portafolio a la
Administración

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

• Planeación del Portafolio

• Fase 1: Generando Ideas

• Fase 2: Desarrollando Propuestas


• Fase 3: Construyendo Escenarios

• Fase 4: Seleccionando el Portafolio

5
GENERANDO IDEAS DE PROYECTOS
Factores a tener en cuenta

• Excluya aquellas ideas que impliquen un esfuerzo pequeño de


implementación (por ejemplo menos de un mes de programador), dado
que estas se realizan en el día día.
• Póngase de acuerdo en prioridades:
– A – Más alta prioridad
Cuantificación detallada del costo/beneficio, desarrollo de la arquitectura
de la aplicación y chequeo de su empalme con la arquitectura general de
sistemas
– B – Alta prioridad
Cuantificación estimada del costo/beneficio, borrador de la solución
– C – Baja prioridad
No se requiere trabajo adicional
• Asegúrese que el 80% - 90% de las ideas se definen en las primeras
reuniones/talleres

6
IDEA DE PROYECTO DE TI (1/2)
Forma diligenciada por:________________

Nombre del proyecto: No.: UN :_______________________


Descripción corta:
Líder proyecto UN: ____________
Nombre del proyecto: e.g.,
Requerimientos clave, "Introducción de SAP R/3" Identificación de la UN
funcionalidades generales responsable – e.g.,
y beneficios esperados Mercadeo, Contabilidad

Número que la UN asigna


mientras la duración Miembro de la UN que vela por el
(centro de costo, etc.) desarrollo de la propuesta;
asignar responsabilidad a esta
persona es necesario para asegurar
"accountability", y por lo tanto éxito

Hitos/Entregas clave: Interfaces con otras UNs:


Número estimado de usuarios de los 1. Aplicaciones que la UN ve como con
nuevos requerimientos 2. posibles conexiones al requerimiento
3. Otras UNs afectadas por la
Fechas de inicio/fin para cada entrega; implementación propuesta o que tienen
Número depor
partir Usuarios:
fases incluyendo fechas Interfaces con otras aplicaciones:
requerimientos similares
Propósito: Clarifica las funcionalidades 1. Propósito: Permitir una identificación
de cada entrega, facilitando así el 2. temprana de dependencias que afecten
desarrollo temprano de soluciones 3. requerimientos/implementación

7
IDEA DE PROYECTO DE TI (2/2)
Forma diligenciada por:____________

Nombre del proyecto*: No.*

A. Urgencia de operación • Posibles razones para la urgencia:


– Necesidad técnica – e.g., reemplazar un
sistema
– Dependencia de un proveedor
– Se requieren cambios por requerimientos
legales o internos

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

C. Beneficios financieros (en $ 000´s)


• Explicación de los beneficios financieros
esperados
• Estrategia para lograr estos beneficios
• Un primer estimado macro

8
EVALUACIÓN DE BENEFICIOS

Ejemplo Medida

• Cambio en regulaciones • De 1 - 5
Urgencia de • Apagar un sistema
operación • Adaptar tipo de moneda

• Ahorros en costos –e.g., empleados, • Cuantificado en $


Beneficios locaciones, equipo
financieros • Incremento en ventas – e.g., a través
de nuevos productos o características

• Más calidad de servicio, mejora en el • De 1 - 5


servicios al cliente
Beneficios
• Aumento en penetración del mercado
estratégicos
• Mejor capacidad de decisión por
contar con mejor información
• Mayor flexibilidad, menor tiempo de Todos los tipos de
reacción beneficios deben
evaluarse

9
RESULTADOS: RANKING DE IDEAS

A Más alta prioridad


Desarrollo de una propuesta detallada del
Ideas
proyecto
clasificadas de
- Ranqueado 5 en urgencia o beneficios
acuerdo con:
Las
• Urgencia de propuestas
operación B Prioridad Alta
Desarrollo de propuesta sin todo el nivel de se deben
• Beneficios detalle trabajar en
- Ranqueado 4 en urgencia o beneficios orden de
estratégicos
clasificación
• Beneficios
Financieros C Prioridad más baja
No trabajo adicional
– Ranqueado 3 o menos

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

Asegúrese que... De lo contrario encontrará que...

• 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

• Da entrenamiento, • Un sentimiento de UNs perdidas resulta en estimados


especialmente al momento de pobres y un desencanto general del proceso
calcular los beneficios

• Pasa rápidamente a la siguiente • Dado que la generación de ideas puede tender a


fase aquellas ideas que son demorarse, el desarrollo de propuestas concretas para
claramente de alta prioridad proyectos urgentes podría retrasarse
considerablemente.

• 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

• Planeación del Portafolio

• Fase 1: Generando Ideas

• Fase 2: Desarrollando Propuestas


• Fase 3: Construyendo Escenarios

• Fase 4: Seleccionando el Portafolio

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

• Empaquete • Seleccione el • Detalle/clarifique • Estime los costos de


ideas de equipo de IT requerimientos del implementación con base en la
proyectos para el sistema • Desarrolle solución básica propuesta
relacionadas desarrollo de la • Junte ideas en soluciones en • Estime el costo total, i.e.,
propuesta grupos de relación con otras adicionando tecnología y costos
• Asigne ideas implementación soluciones y de soporte
empaquetadas con requerimientos oportunidades • Estime beneficios
(TI lideres de similares arquitecturas
proyectos) comunes

14
DESARROLLANDO PROPUESTAS: OUTPUT REQUERIDO

Información del Requerimientos Concepto de la Releases Estimación costos


Proyecto solución

Nombre: • Funcionalidad • Arquitectura del 1. Release • Componente #1


sistema – Funcionalidad (Rel. 1)
Número: – Componente – Tabla: 7
2. Release – Batches: 3
– … – …
Cabeza planeación – ... Costo: 80,000 $
UN: • Componente #2
• Funcionalidad • •Arquitectura de la Riesgos
(Rel. 2)
excluida aplicación
Líder del Proyecto UN: – Interface: 2
Habilidades – SYSTEM 1
– SAP
Beneficios Costo: 20,000 $
Líder del proyecto IT:
• Supuestos para • Descripción escrita Costo Total
la 100,000 $
implementación

Propuesta coordinada con (Firma)


UN:
TI:

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

Identifique los componentes que pueden afectarse

– Componente clave (A: solo una por proyecto)


– Otros componentes (B: múltiples entradas por
proyecto)

16
ASIGNANDO IDEAS DE PROYECTOS

Participantes de IT

Selecciones participantes de IT Seleccione líderes de


con: proyecto de IT para ser
responsables de:
– Conocimiento técnico en las
áreas del sistema afectadas – Desarrollar propuestas a
– Conocimiento de negocios pata partir de ideas de una
un análisis rápido e forma profesional y
implementación oportuna
– Experiencia en planeación y – Realizar un Cronograma
estimación de costos de trabajo

17
DETALLANDO LOS REQUERIMIENTOS

Proceso Objetivo

• Integre al líder del proyecto de la UN en el Dibuje una foto lo


desarrollo de la propuesta suficientemente detallada de
• Desarrolle un cronograma que refleje en los requerimientos que
suficiente nivel de detalle
• Conjuntamente defina los requerimientos del • Se pueda formular una
negocio, solución
– Formulando funcionalidades – qué se • Se pueda hacer un estimado
incluye de costos los suficientemente
– Identificando funcionalidades no confiable
relacionadas – qué no se incluye
– Haciendo supuestos en áreas críticas, si se • Se puedan formar grupos
requiere razonables para
– Calculando beneficios y chequeando su implementaciones conjuntas
validez

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

Evalúe oportunidades para


• Arquitectura común
• Componentes comunes
Evalúe el uso de nuevas tecnologías

19
SOLUCIONES: CONTENIDO

• Arquitectura del sistema • Alternativas


– Cómo encaja la solución? – Qué otras soluciones existen?
– Cuales son los flujos de datos? – Como se comparan con otras alternativas?
– Qué bases de datos se utilizarán? – Cual sería el impacto en proyectos
– Cuales son sus componentes? posteriores?

• Arquitectura de la aplicación • Racional


– Cual es el diseño interno? – Por qué se escogió esta solución?
– Qué niveles de tecnología se planean?
– Qué tecnología debería utilizarse? • Releases/Versiones
– Como se separan sus componentes? – En cuantas versiones puede entregarse la
solución?
– Cuales son los pasos de implementación?

20
ANALIZANDO DEPENDENCIAS

Proceso Objetivo

• Analice matriz de componentes para Para asegurar la calidad de las


formar grupos e identificar: soluciones
– Componentes críticos
– Proyectos con grandes intersecciones – Identificando componentes comunes

• Revise los supuestos para clarificar – Establecer la secuencia de


casos de requerimientos dependientes implementación de proyectos

– Resolver dependencias complejas


que amenazan los desarrollos
paralelos de los proyectos.

21
REVISANDO ARQUITECTURAS/TECNOLOGÍAS

Proceso Objetivos

• Ranquear ideas de proyectos de • Construir una arquitectura de


acuerdo al impacto en la arquitectura sistemas durable
• Revisar soluciones para los proyectos • Asegurar coordinación arquitectónica
críticos que tienen una alta de los distintos proyectos
dependencia de sus componentes • Identificar oportunidades de inversión
• Proveer a los líderes de TI con en arquitecturas comunes
estándares en • Evitar errores de diseño
– Plataformas tecnológicas usadas en • Coordinar uso de tecnologías
el diseño de aplicaciones
– Amplio plan de desarrollo
arquitectónico para la compañía

22
CALCULANDO COSTOS/BENEFICIOS

Solución Estimar costos puros Estimar costos totales


Calcular
desarrollada de implementación
valor neto
• Arquitectura del • De la solución • Con base en el del
sistema recomendada, modelo de costos proyecto
excluyendo todos los incluyendo
otros costos – Implementación Use un
– Nuevas tecnologías
• De soluciones – Costos de soporte
modelo
alternativas razonables para
Abwicklg.
Development.
(e.g., con o sin calcular
• Arquitectura de inversiones en nuevos • Payback
la aplicación sistemas) • VPN
CORBA
Oracle
HP-UX
HP-PARISC
Determinar beneficios para UNs
El líder del proyecto de la UN calcula el flujo
• Releases / de caja para cada versión/release para el
Versiones período de implementación

23
DESARROLLANDO PROPUESTAS DE PROYECTOS – LECCIONES
APRENDIDAS

Asegúrese que... De lo contrario encontrará que...

• Toma el tiempo necesario para • Los estimados no servirán para determinar el


desarrollar la propuesta, antes de presupuesto general
calcular los costos

• Incorpore las consideraciones • Sinergias potenciales con otras propuestas no se


arquitectónicas en la solución utilizan
• Aumenta la probabilidad de malas decisiones en
interfaces / tecnologías de aplicaciones

24
AGENDA

• Planeación del Portafolio

• Fase 1: Generando Ideas

• Fase 2: Desarrollando Propuestas


• Fase 3: Construyendo Escenarios

• Fase 4: Seleccionando el Portafolio

25
CONSTRUYENDO ESCENARIOS DE PORTAFOLIO

Lineamientos amplios del portafolio El equipo de planeación construye


surgen durante la etapa de planeación: escenarios de portafolio de los proyectos
seleccionados, rediseñándolos si es
• Dependencias entre proyectos
necesario de acuerdo a las limitaciones clave
determinan la secuencia
en:
• Estimados de recursos y habilidades
restringen las capacidades de
• Recursos
implementación • Tiempo
• Los "overlaps" de los proyectos limitan • Presupuesto
la habilidad de implementar en paralelo
• Dependencias
• Los requerimientos legales/de mercado
dictan las limitaciones de tiempo
• El análisis costo beneficio indica los
proyectos de alta prioridad

26
CONSTRUYENDO ALTERNATIVAS DE ESCENARIOS

Cada escenario debería


construirse para: Recursos 2001 2002
Project (MP*) QI QII QIII QIV QI QII QIII QIV

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

Est. Beneficio Financiero (VPN) = 100

* 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

Recursos Recursos disponibles


(Internos + externos)
en MP

250
Análisis de Recursos:

• Calcule los recursos 125


totales necesarios para
implementar
• Compare con recursos
actuales para validar Tiempo
factibilidad 2003 2004 2005
• Revise curva de Beneficios
beneficios para Financieros
asegurar realización
óptima $ p.a.
• Sume presupuestos de en mill.
Beneficios financieros
recursos externos anuales alcanzados en la
requeridos medida que se completan
• Reprográmese asigne los proyectos
prioridades de proyectos
si es necesario

Tiempo
2003 2004 2005

29
LIMITACIÓN #2: HABILIDADES

Número de Habilidad: Sistema de


empleados Nómina

10 Capacidad existente
Análisis de habilidades:
5
• Identifique las
habilidades requeridas
para implementar el Tiempo
2003 2004
escenario

• Compare con las Número de


Empleados Habilidad: Cobol
habilidades existentes Capacidad Existente
para estimar factibilidad
30
• Ajuste el escenario
según sea necesario
15

Tiempo
2003 2004
Limite el análisis a 10
habilidades críticas

30
LIMITACIÓN #3: COMPLEJIDAD*

Número de Complejidad: Sistema de


Proyectos RRHH

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

• Provee una visión general Proyecto1, Ver.2


de los proyectos Proyecto 2

• Resalta la necesidad de …
modularización

Por ejemplo: Proyecto 2 no


puede iniciar sin la 2 vers. del
proyecto 1 y el proyecto 3

32
LIMITACIÓN #4: DEPENDENCIAS

Escenario #1 Por proyecto Escenario


completo
Revise todos los proyectos dependientes
y sus fechas de inicio Liste/evalúe todos
Nombre Tamaño ...
los conflictos
Proyecto1 10 MP ...
, Rel.1
Proyecto1 20 MP ... Identifique
, Rel.2 conflictos
Projekt 1, Rel. 1

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

Asegúrese que... De lo contrario encontrará que...

• Usa un horizonte de planeación • Proyectos cortos tienden a favorecerse sobre los


de 2 a 3 años largos, los cuales pueden tener mayor valor estratégico
y financiero

• La capacidad de TI no se elevará de acuerdo con las


necesidades de largo plazo

• El horizonte de captura de beneficios puede ser muy


corto para reflejar el verdadero valor del proyecto

34
AGENDA

• Planeación del Portafolio

• Fase 1: Generando Ideas

• Fase 2: Desarrollando Propuestas


• Fase 3: Construyendo Escenarios

• Fase 4: Seleccionando el Portafolio

35
SELECCIONANDO EL PORTAFOLIO

TI Recomienda UNs evalúan TI/UN Entregan Cierre

TI Prepara recomendaciones: UNs deciden portafolio: UN/TI: Entregan Equipo desarrolla


• Revisa propuesta y chequea • Seleccionan el portafolio portafolio para versión final de:
consistencias en costos, más atractivo para aprobación de la • Solución
soluciones, etc. presentar a la administración, que • Estimados de
• Chequea que encaje en la administración revisa: costos
arquitectura de sistemas • Consideraciones • Plan de entrega
• Mete o saca los proyectos estratégicas
pequeños según se requiera • Limitaciones de
• Analiza/compara escenarios presupuesto
para soportar la toma de
decisiones de la UNs

36

You might also like