juan josé uribe – mckinsey & company bogotá, mayo, 2003 optimizando la planeación del...

Juan José Uribe – McKinsey & Company

Bogotá, Mayo, 2003

Optimizando la Planeación del Portafolio de Proyectos de TI

I Jornada Nacional de Gerencia de Proyectos de TI

CONFIDENCIAL

2

AGENDA

• Planeación del Portafolio

• Fase 1: Generando Ideas

• Fase 2: Desarrollando Propuestas

• Fase 3: Construyendo Escenarios

• Fase 4: Seleccionando el Portafolio

3

OBJETIVOS DE LA PLANEACIÓN DEL PORTAFOLIO DE TI

• Asegurar valor económico a través de:– Métodos estándares de evaluación– Conjunto común de prioridades

• Crear sinergias a través del empaquetamiento de requerimientos similares

• Planear a largo plazo para asegurar los recursos suficientes y la coordinación para los requerimientos más importantes

• Permitir la implementación oportuna de aquellos proyectos más pequeños que se encuentran en marcha

• Lograr un claro compromiso desde el inicio tanto de Sistemas como de la Unidades de Negocio

• Planear las capacidades de TI con base en el Portafolio completo de IT

Maximizar el valor económico del portafolio

Optimizar la utilización de los recursos de IT

Construir confianza en el proceso de planeación

4

PLANEACIÓN DEL PORTAFOLIO DE IT

Construir Escenarios

Seleccionar PortafolioGenerar Ideas Desarrollar

Propuestas

UNs:• Generar Ideas• Formular

requerimientos y beneficios

• Fijar las primeras prioridades en talleres de trabajo

UNs/TI: • Refinar

requerimientos y beneficiosTI:• Desarrollar

soluciones preliminares

• Estimar costos

TI:• Armonizar el

portafolio TI• Preparar

RecomendacionesUNs: • Evaluar

recomendaciones• Entregar el

portafolio a la Administración

Planeación de la implementación no es

parte de la Charla

UNs/TI: • Dibujar el escenario y analizar de acuerdo a los principales impedimentos

5

EQUIPO DE TI PARA LA PLANEACIÓN

Líder de Planeación de Portafolio

Coordinador de Arquitectura

Cabeza de Planeación de

Proyectos

Grupo de Planeación: Proyecto 1

Grupo de planeación:Proyecto 2

...

ParticipantesResponsabilidades

• Administrar el proceso de planeación

• Apoyar a las UNs en la generación/desarrollo de las ideas de proyectos

• Coordinar esfuerzos de IT en el desarrollo de las propuestas

• Desarrollar un modelo estándar de costeo

• Operar y mantener las herramientas de planeación si existen

6

AGENDA






7

GENERANDO IDEAS DE PROYECTOS

• 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 prioridadCuantificació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 prioridadCuantificación estimada del costo/beneficio, borrador de la solución

– C – Baja prioridadNo se requiere trabajo adicional

• Asegúrese que el 80% - 90% de las ideas se definen en las primeras reuniones/talleres

Factores a tener en cuenta

8

IDEA DE PROYECTO DE TI (1/2)

Hitos/Entregas clave: Interfaces con otras UNs:1.2.3.

Número de Usuarios: Interfaces con otras aplicaciones:1.2.3.

No.:

Forma diligenciada por:________________

Nombre del proyecto: UN :_______________________

Descripción corta:

Líder proyecto UN: ____________

Fechas de inicio/fin para cada entrega; partir por fases incluyendo fechasPropósito: Clarifica las funcionalidades de cada entrega, facilitando así el desarrollo temprano de soluciones

Nombre del proyecto: e.g., "Introducción de SAP R/3"

Número que la UN asigna mientras la duración (centro de costo, etc.)

Identificación de la UN responsable – e.g., Mercadeo, Contabilidad

Miembro de la UN que vela por el desarrollo de la propuesta; asignar responsabilidad a esta persona es necesario para asegurar "accountability", y por lo tanto éxito

Otras UNs afectadas por la implementación propuesta o que tienen requerimientos similaresPropósito: Permitir una identificación temprana de dependencias que afecten requerimientos/implementación

Aplicaciones que la UN ve como con posibles conexiones al requerimiento

Número estimado de usuarios de los nuevos requerimientos

Requerimientos clave, funcionalidades generales y beneficios esperados

9

IDEA DE PROYECTO DE TI (2/2)

Forma diligenciada por:____________

Nombre del proyecto*:

A. Urgencia de operación

No.*

B. Beneficios estratégicos

C. Beneficios financieros (en $ 000´s)

• 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

Todos aquellos beneficios estratégicos que no pueden ser cuantificados:– e.g., aumento en competitividad, mayor flexibilidad, mayor valor al cliente, etc

• Explicación de los beneficios financieros esperados

• Estrategia para lograr estos beneficios• Un primer estimado macro

10

EVALUACIÓN DE BENEFICIOS

• Cambio en regulaciones• Apagar un sistema• Adaptar tipo de moneda

• Ahorros en costos –e.g., empleados, locaciones, equipo

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

• Más calidad de servicio, mejora en el servicios al cliente

• Aumento en penetración del mercado• Mejor capacidad de decisión por

contar con mejor información• Mayor flexibilidad, menor tiempo de

reacción

• De 1 - 5

• Cuantificado en $

• De 1 - 5

Medida

Urgencia de operación

Beneficios financieros

Beneficios estratégicos

Todos los tipos de beneficios deben

evaluarse

Ejemplo

11

RESULTADOS: RANKING DE IDEAS

Las propuestas se deben

trabajar en orden de

clasificación

Más alta prioridad Desarrollo de una propuesta detallada del proyecto- Ranqueado 5 en urgencia o beneficios

A

Prioridad AltaDesarrollo de propuesta sin todo el nivel de detalle- Ranqueado 4 en urgencia o beneficios

B

Prioridad más bajaNo trabajo adicional – Ranqueado 3 o menos

C

Ideas clasificadas de acuerdo con:

• Urgencia de operación

• Beneficios estratégicos

• Beneficios Financieros

12

C

GUÍA PARA CLASIFICACIÓN

Urgencia operacional

• Necesidad Técnica

• Necesidad legal o de negocios

Beneficios estratégicos(Ventaja competitiva, valor al diente)

Beneficios Financieros (en $ 000's)

NO necesario técnicamente/sin conflictos con otros sistemas

Elimina limitaciones menores en el uso del sistema

Mejoras notables en seguridad y confiabilidad

Elimina conflictos críticos/introduce nuevas capacidades importantes al sistema

No relevante

Ninguno

< 100

Responde a la acción recomendada

Cumple con requerimientos (posiblemente no críticos)

Cumple con requerimientos críticos

Logra impacto menor en posición competitiva

100 - 200

Lleva a una mejora gradual en mejora de la posición (vía mejoras parciales del sistema)

200 - 500 500 – 1,000

Logra una diferencia significativa en posición (vía una mejor capacidad de decisión)

Ataca una necesidad crítica extrema, la cual representa grandes riesgosCumple con requerimientos necesarios para la continuidad del negocio

Logra un impacto duradero(vía nuevos mecanismos de soporte para decisiones o salto cuántico en calidad de info.)

1,000

1 2 3 4 5

Grado/Categoría

Criterio

AB

EJEMPLO

13

GENERANDO IDEAS DE PROYECTOS: LECCIONES APRENDIDAS

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

• Da entrenamiento, especialmente al momento de calcular los beneficios

• Un sentimiento de UNs perdidas resulta en estimados pobres y un desencanto general del proceso

• Pasa rápidamente a la siguiente fase aquellas ideas que son claramente de alta prioridad

• Dado que la generación de ideas puede tender a demorarse, el desarrollo de propuestas concretas para proyectos urgentes podría retrasarse considerablemente.

• Realiza el ranking solo después de que tiene la mayoría de las ideas (80% por ejemplo)

• Sin una visión general de las ideas, ud. no puede llegar a una clasificación razonable , especialmente para los beneficios financieros, implicando una posible repetición de tareas en el proceso más adelante.

• Excluye ideas con poco esfuerzo de trabajo para lograrlas

• No solo demora el proceso, sino que las UNs se 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)

• Explica claramente el proceso desde el principio

• UNs no toman el proceso seriamente hasta que ven las consecuencias: sus necesidades no aparecen en el presupuesto

14

AGENDA






15

DESARROLLANDO PROPUESTAS DE PROYECTOS

Empaquete/Asigne Ideas Detalle requerimientos Depen-

den-cias

• Empaquete ideas de proyectos relacionadas

• Seleccione el equipo de IT para el desarrollo de la propuesta

• Asigne ideas empaquetadas (TI lideres de proyectos)

Soluciones/ releases

• Detalle/clarifique requerimientos del sistema

• Junte ideas en grupos de implementación con requerimientos similares

Tecnología/Arquitectura

• Desarrolle soluciones en relación con otras soluciones y oportunidades arquitecturas comunes

• Estime los costos de implementación con base en la solución básica propuesta

• Estime el costo total, i.e., adicionando tecnología y costos de soporte

• Estime beneficios

"Costo de implementa-ción "puro"

Costo total

Beneficios estimados

Valor Neto del Proyecto

16

DESARROLLANDO PROPUESTAS: OUTPUT REQUERIDO

Información del Proyecto

Nombre:

Número:

Líder del Proyecto UN:

Líder del proyecto IT:

Requerimientos

• Funcionalidad

• Funcionalidad excluida

• Supuestos para la implementación

Concepto de la solución

• Arquitectura del sistema

• Arquitectura de la aplicación

• Descripción escrita

•

Releases

1. Release– Funcionalidad– Componente

2. Release– …– ...

Riesgos

Habilidades

Beneficios

Estimación costos

• Componente #1 (Rel. 1)– Tabla: 7– Batches: 3– …

Costo: 80,000 $• Componente #2

(Rel. 2)– Interface: 2– SYSTEM 1– SAP

Costo: 20,000 $

Costo Total 100,000 $

Propuesta coordinada con (Firma)UN: TI:

Cabeza planeación UN:

17

EMPAQUETANDO IDEAS DE PROYECTOS

Arquitectura actual de sistemas

Arquitectura ideal del sistema

• _____

• _____

• _____

• _____

• _____

B

B

AA

Matriz de dependencias

Lleva a mayores eficiencias pues: • Promueve uso de

soluciones comunes

• Permite un desarrollo común de algunas 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)

Com

pon

ente

s de

l Sis

tem

a

•__

•__

•__

•__

•__

•__

B

18

ASIGNANDO IDEAS DE PROYECTOS

Participantes de IT

Selecciones participantes de IT con:

– Conocimiento técnico en las áreas del sistema afectadas

– Conocimiento de negocios pata un análisis rápido e implementación

– Experiencia en planeación y estimación de costos

Seleccione líderes de proyecto de IT para ser responsables de:

– Desarrollar propuestas a partir de ideas de una forma profesional y oportuna

– Realizar un Cronograma de trabajo

19

DETALLANDO LOS REQUERIMIENTOS

Proceso

• Integre al líder del proyecto de la UN en el desarrollo de la propuesta

• Desarrolle un cronograma que refleje en suficiente nivel de detalle

• Conjuntamente defina los requerimientos del negocio,– Formulando funcionalidades – qué se

incluye– Identificando funcionalidades no

relacionadas – qué no se incluye– Haciendo supuestos en áreas críticas, si se

requiere– Calculando beneficios y chequeando su

validez

Dibuje una foto lo suficientemente detallada de los requerimientos que

• Se pueda formular una solución

• Se pueda hacer un estimado de costos los suficientemente confiable

• Se puedan formar grupos razonables para implementaciones conjuntas

Objetivo

20

FORMULANDO SOLUCIONES

• Busque integrar soluciones entre ellas

– Empaquetamiento de requerimientos pequeños que permitan un desarrollo conjunto

– Romper soluciones en sub-partes (releases)

• Busque mantener/construir en la arquitectura de sistemas para ayudar a asegurar control.

Soluciones/releases

Desarrolle soluciones • En línea con la

arquitectura de Sistemas

• Defina la arquitectura de la aplicación

Busque soluciones parciales con un fuerte impacto de negocios

Evalúe oportunidades para• Arquitectura común• Componentes comunesEvalúe el uso de nuevas tecnologías

Arquitectura/ tecnología

Depen-dencias

Analice dependencias

• Uso de otros proyectos

• Proveedor para otros proyectos

21

SOLUCIONES: CONTENIDO

• Arquitectura del sistema– Cómo encaja la solución?– Cuales son los flujos de datos?– Qué bases de datos se utilizarán?– Cuales son sus componentes?

• Arquitectura de la aplicación– Cual es el diseño interno?– Qué niveles de tecnología se planean?– Qué tecnología debería utilizarse?– Como se separan sus componentes?

• Alternativas– Qué otras soluciones existen?– Como se comparan con otras alternativas?– Cual sería el impacto en proyectos

posteriores?

• Racional– Por qué se escogió esta solución?

• Releases/Versiones – En cuantas versiones puede entregarse la

solución?– Cuales son los pasos de implementación?

22

ANALIZANDO DEPENDENCIAS

Proceso

• Analice matriz de componentes para formar grupos e identificar: – Componentes críticos– Proyectos con grandes intersecciones

• Revise los supuestos para clarificar casos de requerimientos dependientes

Objetivo

Para asegurar la calidad de las soluciones

– Identificando componentes comunes

– Establecer la secuencia de implementación de proyectos

– Resolver dependencias complejas que amenazan los desarrollos paralelos de los proyectos.

23

REVISANDO ARQUITECTURAS/TECNOLOGÍAS

Proceso

• Construir una arquitectura de sistemas durable

• Asegurar coordinación arquitectónica de los distintos proyectos

• Identificar oportunidades de inversión en arquitecturas comunes

• Evitar errores de diseño• Coordinar uso de tecnologías

• Ranquear ideas de proyectos de acuerdo al impacto en la arquitectura

• Revisar soluciones para los proyectos críticos que tienen una alta dependencia de sus componentes

• Proveer a los líderes de TI con estándares en – Plataformas tecnológicas usadas en

el diseño de aplicaciones– Amplio plan de desarrollo

arquitectónico para la compañía

Objetivos

24

Use un modelo para calcular • Payback• VPN

CALCULANDO COSTOS/BENEFICIOS

Estimar costos puros de implementación

• De la solución recomendada, excluyendo todos los otros costos

• De soluciones alternativas razonables (e.g., con o sin inversiones en nuevos sistemas)

• Con base en el modelo de costos incluyendo– Implementación– Nuevas tecnologías– Costos de soporte

Solución desarrollada

Determinar beneficios para UNs

El líder del proyecto de la UN calcula el flujo de caja para cada versión/release para el período de implementación

Calcular valor neto del proyecto

Abwicklg.

• Releases / Versiones

• Arquitectura de la aplicación

CORBAOracleHP-UXHP-PARISC

Estimar costos totales

• Arquitectura del sistema

Development.

25

DESARROLLANDO PROPUESTAS DE PROYECTOS – LECCIONES APRENDIDAS

• Toma el tiempo necesario para desarrollar la propuesta, antes de calcular los costos

• Los estimados no servirán para determinar el presupuesto general

• Incorpore las consideraciones arquitectónicas en la solución

• Sinergias potenciales con otras propuestas no se utilizan

• Aumenta la probabilidad de malas decisiones en interfaces / tecnologías de aplicaciones


26

AGENDA






27

CONSTRUYENDO ESCENARIOS DE PORTAFOLIO

Lineamientos amplios del portafolio surgen durante la etapa de planeación:

• Dependencias entre proyectos determinan la secuencia

• Estimados de recursos y habilidades restringen las capacidades de implementación

• Los "overlaps" de los proyectos limitan la habilidad de implementar en paralelo

• Los requerimientos legales/de mercado dictan las limitaciones de tiempo

• El análisis costo beneficio indica los proyectos de alta prioridad

El equipo de planeación construye escenarios de portafolio de los proyectos seleccionados, rediseñándolos si es necesario de acuerdo a las limitaciones clave en:

• Recursos

• Tiempo

• Presupuesto

• Dependencias

28

CONSTRUYENDO ALTERNATIVAS DE ESCENARIOS

* Mes programador

Cada escenario debería construirse para:

• Optimizar el valor económico de los proyectos

• Tener en cuenta las dependencias en la secuencia

• Tener en cuenta las restricciones de habilidades/recursos

• Optimizar los cambios tecnológicos

ProjectProyecto 1Proyecto 2Proyecto 3Proyecto 4...Proyecto 1Proyecto 2Proyecto 3Proyecto 4...

Esc

enar

io 1

Esc

enar

io 2

Recursos(MP*)

8020

100 10

80 20

100 10

QI QII QIII QIV2001

20 20 2020

30

20 20 5020

40 4020

2010

40 50 2020

QI QII QIII QIV2002

20

1030 30

30 20

Est. Beneficio financiero (VPN) = 80

50

40 40

4040

10

Est. Beneficio Financiero (VPN) = 100

Recursos

Recursos

29

ANALIZANDO ALTERNATIVAS DE ESCENARIOS

Recursos

Habilidades

Complejidad

Dependencias

Análisis de limitaciones

Escenario # 1

Nombre Tamaño

Proyecto 1, Ver.1

10 MP

Proyecto 1, Rel.2

20 MP

Proyecto 2

30 MP

… … …

Inicio

1.1.2001

1.1.2002

–

…

Duración estimada

2.5 años.

1 año.

–

…

30

LIMITACIÓN #1: RECURSOS

Análisis de Recursos:

• Calcule los recursos totales necesarios para implementar

• Compare con recursos actuales para validar factibilidad

• Revise curva de beneficios para asegurar realización óptima

• Sume presupuestos de recursos externos requeridos

• Reprográmese asigne prioridades de proyectos si es necesario

Recursos

en MP

250

125

2003 2004 2005Tiempo

Recursos disponibles (Internos + externos)

Beneficios Financieros

$ p.a.en mill.

2003 2004 2005Tiempo

Beneficios financieros anuales alcanzados en la medida que se completan

los proyectos

31

LIMITACIÓN #2: HABILIDADES

Análisis de habilidades:

• Identifique las habilidades requeridas para implementar el escenario

• Compare con las habilidades existentes para estimar factibilidad

• Ajuste el escenario según sea necesario

Número de empleados

5

2003 2004Tiempo

Limite el análisis a 10 habilidades críticas

Capacidad existente10

Número de Empleados

15

2003 2004Tiempo

Capacidad Existente

30

Habilidad: Sistema de Nómina

Habilidad: Cobol

32

LIMITACIÓN #3: COMPLEJIDAD*

Análisis de complejidad:

• Identificar los oponentes del sistema que trabajan en múltiples proyectos

• Evalúe impacto de complejidad en la implementación individual de cada proyecto

• Eleve o baje los requerimientos de recursos con base en la complejidad

Número de Proyectos

1

2003 2004Tiempo

Límite de complejidad

2

Número de proyectos

1

2003 2004Tiempo

Límite de Complejidad

3

Complejidad: Sistema de RRHH

Complejidad: Sistema XXXX

2

* Basado en la matriz

33

Una matriz de dependencia de proyectos:

• Provee una visión general de los proyectos

• Resalta la necesidad de modularización

DIBUJANDO UNA MATRIZ DE DEPENDENCIAS

Proyecto1, Ver.1

Proyecto1, Ver.2

Proyecto 2

…

Pro

yect

o1,V

er.1

Pro

yect

o1,V

ar.2

Pro

yect

o2

Pro

yect

o3

Por ejemplo: Proyecto 2 no puede iniciar sin la 2 vers. del

proyecto 1 y el proyecto 3

34

LIMITACIÓN #4: DEPENDENCIAS

Escenario #1

Nombre Tamaño

Proyecto1, Rel.1

10 MP

Proyecto1, Rel.2

20 MP

Proyecto2 30 MP

… …

...

...

...

...

…

Por proyecto

Revise todos los proyectos dependientes y sus fechas de inicio

Escenario completo

Liste/evalúe todos los conflictos

Projekt 1, Rel. 1

Projekt 1, Rel. 2

Projekt 2, Rel. 1

…

Pro

jekt

1,

Re

l. 1

Pro

jekt

1,

Re

l. 2

Pro

jekt

2

Pro

jekt

3

Projekt 1, Rel. 1

Projekt 1, Rel. 2

Projekt 2, Rel. 1

1999 2000

Identifique conflictos

35

ANALIZANDO ESCENARIOS – LECCIONES APRENDIDAS

• Usa un horizonte de planeación de 2 a 3 años

• Proyectos cortos tienden a favorecerse sobre los 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


36

AGENDA






37

SELECCIONANDO EL PORTAFOLIO

TI Prepara recomendaciones:• Revisa propuesta y chequea

consistencias en costos, soluciones, etc.

• Chequea que encaje en la arquitectura de sistemas

• Mete o saca los proyectos pequeños según se requiera

• Analiza/compara escenarios para soportar la toma de decisiones de la UNs

TI Recomienda UNs evalúan

UNs deciden portafolio:• Seleccionan el portafolio

más atractivo para presentar a la administración

Equipo desarrolla versión final de:• Solución• Estimados de

costos• Plan de entrega

Cierre TI/UN Entregan

UN/TI: Entregan portafolio para aprobación de la administración, que revisa:• Consideraciones

estratégicas• Limitaciones de

presupuesto

juan josé uribe – mckinsey & company bogotá, mayo, 2003 optimizando la planeación del...

Documents