Optimizando la Planeación del Portafolio de Proyectos de TI

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

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 • Maximizar el valor económico del portafolio • 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 • Optimizar la utilización de los recursos de IT • 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 • Construir confianza en el proceso de planeación

4. Planeación de la implementación no es parte de la Charla PLANEACIÓN DEL PORTAFOLIO DE IT Construir Escenarios Desarrollar Propuestas Seleccionar Portafolio Generar Ideas UNs: • Generar Ideas • Formular requerimientos y beneficios • Fijar las primeras prioridades en talleres de trabajo UNs/TI: • Refinar requerimientos y beneficios TI: • Desarrollar soluciones preliminares • Estimar costos • UNs/TI: • Dibujar el escenario y analizar de acuerdo a los principales impedimentos TI: • Armonizar el portafolio TI • Preparar Recomendaciones UNs: • Evaluar recomendaciones • Entregar el portafolio a la Administración

5. 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 EQUIPO DE TI PARA LA PLANEACIÓN • Responsabilidades • Participantes • Líder de Planeación de Portafolio • Cabeza de Planeación de Proyectos • Coordinador de Arquitectura • Grupo de Planeación: Proyecto 1 • Grupo de planeación: • Proyecto 2 • ...

6. AGENDA • Planeación del Portafolio • Fase 1: Generando Ideas • Fase 2: Desarrollando Propuestas • Fase 3: Construyendo Escenarios • Fase 4: Seleccionando el Portafolio

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

8. Nombre del proyecto: e.g., "Introducción de SAP R/3" Identificación de la UN responsable – e.g., Mercadeo, Contabilidad Requerimientos clave, funcionalidades generales y beneficios esperados Número que la UN asigna mientras la duración (centro de costo, etc.) 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 Número estimado de usuarios de los nuevos requerimientos Aplicaciones que la UN ve como con posibles conexiones al requerimiento Fechas de inicio/fin para cada entrega; partir por fases incluyendo fechas Propósito: Clarifica las funcionalidades de cada entrega, facilitando así el desarrollo temprano de soluciones Otras UNs afectadas por la implementación propuesta o que tienen requerimientos similares Propósito: Permitir una identificación temprana de dependencias que afecten requerimientos/implementación IDEA DE PROYECTO DE TI (1/2) • Forma diligenciada por:________________ • Nombre del proyecto: • No.: • UN :_______________________ • Descripción corta: • Líder proyecto UN: ____________ • Interfaces con otras UNs: • Hitos/Entregas clave: • 1. • 2. • 3. • Número de Usuarios: • Interfaces con otras aplicaciones: • 1. • 2. • 3.

9. 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 IDEA DE PROYECTO DE TI (2/2) • Forma diligenciada por:____________ • Nombre del proyecto*: • No.* • A. Urgencia de operación • B. Beneficios estratégicos • C. Beneficios financieros (en $ 000´s)

10. EVALUACIÓN DE BENEFICIOS • Ejemplo • Medida • Cambio en regulaciones • Apagar un sistema • Adaptar tipo de moneda • De 1 - 5 • Urgencia de operación • Ahorros en costos –e.g., empleados, locaciones, equipo • Incremento en ventas – e.g., a través de nuevos productos o características • Cuantificado en $ • Beneficios financieros • 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 • Beneficios estratégicos Todos los tipos de beneficios deben evaluarse

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

12. GUÍA PARA CLASIFICACIÓN • EJEMPLO Grado/ Categoría C B A Criterio 1 2 3 4 5 • Urgencia operacional • Necesidad Técnica 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 Ataca una necesidad crítica extrema, la cual representa grandes riesgos • Necesidad legal o de negocios No relevante Responde a la acción recomendada Cumple con requerimientos (posiblemente no críticos) Cumple con requerimientos críticos Cumple con requerimientos necesarios para la continuidad del negocio Beneficios estratégicos (Ventaja competitiva, valor al diente) Ninguno Logra impacto menor en posición competitiva Lleva a una mejora gradual en mejora de la posición (vía mejoras parciales del sistema) Logra una diferencia significativa en posición (vía una mejor capacidad de decisión) Logra un impacto duradero (vía nuevos mecanismos de soporte para decisiones o salto cuántico en calidad de info.) Beneficios Financieros (en $ 000's) < 100 100 - 200 200 - 500 500 – 1,000 ³ 1,000

13. GENERANDO IDEAS DE PROYECTOS: LECCIONES APRENDIDAS • Asegúrese que... • De lo contrario encontrará que... • 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 • 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)

14. AGENDA • Planeación del Portafolio • Fase 1: Generando Ideas • Fase 2: Desarrollando Propuestas • Fase 3: Construyendo Escenarios • Fase 4: Seleccionando el Portafolio

15. DESARROLLANDO PROPUESTAS DE PROYECTOS • Soluciones/ releases • "Costo de implementa-ción "puro" • Costo total • Empaquete/Asigne Ideas • Detalle requerimientos • Valor Neto del Proyecto • Depen-den- • cias • Beneficios estimados • Tecnología/ • Arquitectura • Empaquete ideas de proyectos relacionadas • Seleccione el equipo de IT para el desarrollo de la propuesta • Asigne ideas empaquetadas (TI lideres de proyectos) • Detalle/clarifique requerimientos del sistema • Junte ideas en grupos de implementación con requerimientos similares • 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 • Desarrolle soluciones en relación con otras soluciones y oportunidades arquitecturas comunes

16. DESARROLLANDO PROPUESTAS: OUTPUT REQUERIDO • Información del Proyecto • Requerimientos • Concepto de la solución • Releases • Estimación costos • Nombre: • Funcionalidad • Arquitectura del sistema • 1. Release • Funcionalidad • Componente • 2. Release • … • ... • Componente #1 (Rel. 1) • Tabla: 7 • Batches: 3 • … • Costo: 80,000 $ • Componente #2 (Rel. 2) • Interface: 2 • SYSTEM 1 • SAP • Costo: 20,000 $ • Número: • Cabeza planeación UN: • Funcionalidad excluida • Arquitectura de la aplicación • Riesgos • • Líder del Proyecto UN: • Habilidades • Beneficios • Líder del proyecto IT: • Supuestos para la implementación • Descripción escrita • Costo Total 100,000 $ • Propuesta coordinada con (Firma) • UN: • TI:

17. EMPAQUETANDO IDEAS DE PROYECTOS • Matriz de dependencias • Arquitectura actual de sistemas • _____ • _____ • _____ • _____ • _____ • B • Lleva a mayores eficiencias pues: • Promueve uso de soluciones comunes • Permite un desarrollo común de algunas propuestas • Componentes del Sistema • B • B • Arquitectura ideal del sistema • __ • __ • __ • __ • __ • __ • A • A • Ideas de Proyectos Identifique los componentes que pueden afectarse • Componente clave (A: solo una por proyecto) • Otros componentes (B: múltiples entradas por proyecto)

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 • Objetivo • 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

20. FORMULANDO SOLUCIONES • 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 • 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 Analice dependencias • Uso de otros proyectos • Proveedor para otros proyectos • Depen-dencias • Arquitectura/ tecnología • Evalúe oportunidades para • Arquitectura común • Componentes comunes • Evalúe el uso de nuevas tecnologías

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 • Objetivo • 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 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 • Objetivos • 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 • 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

24. Arquitectura del sistema Development. • Arquitectura de la aplicación • CORBA • Oracle • HP-UX • HP-PARISC CALCULANDO COSTOS/BENEFICIOS • Solución desarrollada • Estimar costos puros de implementación • Estimar costos totales • Calcular valor neto del proyecto • 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 • Use un modelo para calcular • Payback • VPN Abwicklg. • 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 • Releases / Versiones

25. DESARROLLANDO PROPUESTAS DE PROYECTOS – LECCIONES APRENDIDAS • Asegúrese que... • De lo contrario encontrará que... • 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 • Planeación delPortafolio • Fase 1: Generando Ideas • Fase 2: Desarrollando Propuestas • Fase 3: Construyendo Escenarios • Fase 4: Seleccionando el Portafolio

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 • Cada escenario debería construirse para: • Recursos(MP*) • 2001 • 2002 • Project • QI • QII • QIII • QIV • QI • QII • QIII • QIV • Proyecto 1 • Proyecto 2 • Proyecto 3 • Proyecto 4 • ... • 80 • 20 • 100 • 10 • 20 • 20 • 20 • 20 • 20 • 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 • Escenario 1 • 30 • 30 • 30 • 10 • 10 • Recursos • 20 • 20 • 20 • 50 • 50 • 30 • 20 • Est. Beneficio financiero (VPN) = 80 • Proyecto 1 • Proyecto 2 • Proyecto 3 • Proyecto 4 • ... • 80 • 20 • 100 • 10 • 40 • 40 • 20 • Escenario 2 • 20 • 40 • 40 • 10 • Recursos • 20 • 40 • 50 • 20 • 40 • 40 • Est. Beneficio Financiero (VPN) = 100 * Mes programador

29. ANALIZANDO ALTERNATIVAS DE ESCENARIOS Análisis de limitaciones • Recursos • Escenario # 1 • Duración estimada • Nombre • Tamaño • Inicio • Habilidades • Proyecto 1, Ver.1 • 10MP • 1.1.2001 • 2.5 años. • Proyecto 1, Rel.2 • 20 MP • 1.1.2002 • 1 año. • Proyecto 2 • 30 MP • – • – • Complejidad • … • … • … • … • … • Dependencias

30. LIMITACIÓN #1: RECURSOS • Recursos disponibles • (Internos + externos) • Recursos • en MP • 250 • 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 • 125 • Tiempo • 2003 • 2004 • 2005 • Beneficios Financieros • $ p.a. • en mill. • Beneficios financieros anuales alcanzados en la medida que se completan los proyectos • Tiempo • 2003 • 2004 • 2005

31. LIMITACIÓN #2: HABILIDADES • Número de empleados • Habilidad: Sistema de Nómina • 10 • Capacidad existente • 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 • 5 • Tiempo • 2003 • 2004 • Número de Empleados • Habilidad: Cobol • Capacidad Existente • 30 • 15 • Tiempo • 2003 • 2004 • Limite el análisis a 10 habilidades críticas

32. LIMITACIÓN #3: COMPLEJIDAD* • Número de Proyectos • Complejidad: Sistema de RRHH • 2 • 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 • Límite de complejidad • 1 • Tiempo • 2003 • 2004 • Número de proyectos • Complejidad: Sistema XXXX • Límite de Complejidad • 3 • 2 • 1 • Tiempo • 2003 • 2004 * Basado en la matriz

33. Proyecto1,Ver.1 • Proyecto1,Var.2 • Proyecto2 • Proyecto3 DIBUJANDO UNA MATRIZ DE DEPENDENCIAS • Una matriz de dependencia de proyectos: • Proyecto1, Ver.1 • Proyecto1, Ver.2 • Provee una visión general de los proyectos • Resalta la necesidad de modularización • Proyecto 2 • … • Por ejemplo: Proyecto 2 no puede iniciar sin la 2 vers. del proyecto 1 y el proyecto 3

34. 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 LIMITACIÓN #4: DEPENDENCIAS • Escenario completo • Liste/evalúe todos los conflictos • Escenario #1 • Por proyecto Revise todos los proyectos dependientes y sus fechas de inicio • Nombre • Tamaño • ... • Proyecto1, Rel.1 • 10 MP • ... • Proyecto1, Rel.2 • 20 MP • ... • Identifique conflictos • Proyecto2 • 30 MP • ... • … • … • …

35. ANALIZANDO ESCENARIOS – LECCIONES APRENDIDAS • Asegúrese que... • De lo contrario encontrará que... • 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 • Planeación del Portafolio • Fase 1: Generando Ideas • Fase 2: Desarrollando Propuestas • Fase 3: Construyendo Escenarios • Fase 4: Seleccionando el Portafolio

37. TI Recomienda • UNs evalúan SELECCIONANDO EL PORTAFOLIO • TI/UN Entregan • Cierre 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 • UNs deciden portafolio: • Seleccionan el portafolio más atractivo para presentar a la administración • UN/TI: Entregan portafolio para aprobación de la administración, que revisa: • Consideraciones estratégicas • Limitaciones de presupuesto • Equipo desarrolla versión final de: • Solución • Estimados de costos • Plan de entrega