Está en la página 1de 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

2
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

3
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

4
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

5
AGENDA

• Planeación del Portafolio


• Fase 1: Generando Ideas

• Fase 2: Desarrollando Propuestas

• Fase 3: Construyendo Escenarios

• Fase 4: Seleccionando el Portafolio

6
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

7
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

8
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

9
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
estratégicos
• Aumento en penetración del mercado
• 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

10
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
trabajar en
• Beneficios detalle
- 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

11
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)

12
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)
13
AGENDA

• Planeación del Portafolio


• Fase 1: Generando Ideas

• Fase 2: Desarrollando Propuestas

• Fase 3: Construyendo Escenarios

• Fase 4: Seleccionando el Portafolio

14
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

15
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 – Interface: 2
Líder del Proyecto UN:
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:

16
EMPAQUETANDO IDEAS DE PROYECTOS

Matriz de
dependencias
Arquitectura
actual de • _____ B Lleva a mayores
sistemas eficiencias pues:

Componentes
• _____

del Sistema
• _____ B • Promueve uso de
soluciones comunes
• _____ B
Arquitectura • Permite un desarrollo
ideal del • _____ común de algunas
A A
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)

17
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

18
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
incluye • Se pueda hacer un estimado
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

19
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 arquitectura de la Depen- dependencias
desarrollo 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

20
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?

21
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.

22
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

23
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
– Implementación Use un
otros costos
– Nuevas tecnologías modelo
• De soluciones – Costos de soporte
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

24
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

25
AGENDA

• Planeación del Portafolio


• Fase 1: Generando Ideas

• Fase 2: Desarrollando Propuestas

• Fase 3: Construyendo Escenarios

• Fase 4: Seleccionando el Portafolio

26
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
determinan la secuencia
clave 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

27
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 80 20 20 20 20
• Optimizar el valor 1 20 20
económico de los Proyecto 100 30 30 30 10
proyectos 2 10 10
• Tener en cuenta las Proyecto
dependencias en la 3 Recursos 20 20 20 50 50 30 20
secuencia Proyecto
Est. Beneficio financiero (VPN) = 80
• Tener en cuenta las 4
...
Escenario 2

restricciones de Proyecto 80 40 40
habilidades/recursos 1 20 20
• Optimizar los cambios Proyecto 100 20 40 40
tecnológicos 2 10 10
Proyecto
3 Recursos 20 40 50 20 40 40
Proyecto
4 Est. Beneficio Financiero (VPN) = 100
...

* Mes programador
28
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

29
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 Beneficios financieros
en mill.
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

30
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
Número de
• Compare con las 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

31
LIMITACIÓN #3: COMPLEJIDAD*

Número de Complejidad: Sistema de


Proyectos RRHH

Análisis de 2
Límite de
complejidad: complejidad
1
• Identificar los oponentes
del sistema que
trabajan en múltiples Tiempo
proyectos 2003 2004

Número de
• Evalúe impacto de Complejidad: Sistema XXXX
complejidad en la proyectos Límite de
implementación Complejidad
individual de cada 3
proyecto
2
• Eleve o baje los 1
requerimientos de
recursos con base en la Tiempo
complejidad 2003 2004

* Basado en la matriz 32
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

33
LIMITACIÓN #4: DEPENDENCIAS

Escenario #1 Por proyecto Escenario


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

Projekt 1, Rel. 2
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

34
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

35
AGENDA

• Planeación del Portafolio


• Fase 1: Generando Ideas

• Fase 2: Desarrollando Propuestas

• Fase 3: Construyendo Escenarios

• Fase 4: Seleccionando el Portafolio

36
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

37

También podría gustarte