1 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 1 AGENDA Planeación del Portafolio Fase 1: Generando Ideas Fase 2: Desarrollando Propuestas Fase 3: Construyendo Escenarios Fase 4: Seleccionando el Portafolio
3 2 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 3 PLANEACIÓN DEL PORTAFOLIO DE IT Construir Escenarios Seleccionar Portafolio Generar Ideas Desarrollar Propuestas 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 TI: Armonizar el portafolio TI Preparar Recomendaciones UNs: 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 4 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 5 AGENDA Planeación del Portafolio Fase 1: Generando Ideas Fase 2: Desarrollando Propuestas Fase 3: Construyendo Escenarios Fase 4: Seleccionando el Portafolio
7 6 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 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 Factores a tener en cuenta
8 7 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 fechas Propó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 similares Propó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 8 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 9 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 10 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 Alta Desarrollo de propuesta sin todo el nivel de detalle - Ranqueado 4 en urgencia o beneficios B Prioridad más baja No trabajo adicional – Ranqueado 3 o menos C Ideas clasificadas de acuerdo con: Urgencia de operación Beneficios estratégicos Beneficios Financieros
12 11 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 - 500500 – 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 riesgos Cumple 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 12345 Grado/ Categoría Criterio AB EJEMPLO
13 12 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 13 AGENDA Planeación del Portafolio Fase 1: Generando Ideas Fase 2: Desarrollando Propuestas Fase 3: Construyendo Escenarios Fase 4: Seleccionando el Portafolio
15 14 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 15 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 16 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) Componentes del Sistema __ B
18 17 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 18 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 19 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 comunes Evalúe el uso de nuevas tecnologías Arquitectura/ tecnología Depen- dencias Analice dependencias Uso de otros proyectos Proveedor para otros proyectos
21 20 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 21 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 22 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 23 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 CORBA Oracle HP-UX HP-PARISC Estimar costos totales Arquitectura del sistema Development.
25 24 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 Asegúrese que...De lo contrario encontrará que...
26 25 AGENDA Planeación del Portafolio Fase 1: Generando Ideas Fase 2: Desarrollando Propuestas Fase 3: Construyendo Escenarios Fase 4: Seleccionando el Portafolio
27 26 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 27 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 Project Proyecto 1 Proyecto 2 Proyecto 3 Proyecto 4... Proyecto 1 Proyecto 2 Proyecto 3 Proyecto 4... Escenario 1 Escenario 2 Recursos (MP*) 80 20 100 10 80 20 100 10 QIQIIQIIIQIV 2001 20 30 20 5020 40 20 10 405020 QIQIIQIIIQIV 2002 20 1030 20 Est. Beneficio financiero (VPN) = 80 50 40 10 Est. Beneficio Financiero (VPN) = 100 Recursos
29 28 ANALIZANDO ALTERNATIVAS DE ESCENARIOS Recursos Habilidades Complejidad Dependencias Análisis de limitaciones Escenario # 1 NombreTamañ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 29 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 200320042005 Tiempo Recursos disponibles (Internos + externos) Beneficios Financieros $ p.a. en mill. 200320042005 Tiempo Beneficios financieros anuales alcanzados en la medida que se completan los proyectos
31 30 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 20032004 Tiempo Limite el análisis a 10 habilidades críticas Capacidad existente 10 Número de Empleados 15 20032004 Tiempo Capacidad Existente 30 Habilidad: Sistema de Nómina Habilidad: Cobol
32 31 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 20032004 Tiempo Límite de complejidad 2 Número de proyectos 1 20032004 Tiempo Límite de Complejidad 3 Complejidad: Sistema de RRHH Complejidad: Sistema XXXX 2 * Basado en la matriz
33 32 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 … Proyecto1,Ver.1 Proyecto1,Var.2 Proyecto2 Proyecto3 Por ejemplo: Proyecto 2 no puede iniciar sin la 2 vers. del proyecto 1 y el proyecto 3
34 33 LIMITACIÓN #4: DEPENDENCIAS Escenario #1 NombreTamaño Proyecto1, Rel.1 10 MP Proyecto1, Rel.2 20 MP Proyecto230 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 … Projekt 1, Rel. 1Projekt 1, Rel. 2 Projekt 2Projekt 3 Projekt 1, Rel. 1 Projekt 1, Rel. 2 Projekt 2, Rel. 1 19992000 Identifique conflictos
35 34 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 Asegúrese que...De lo contrario encontrará que...
36 35 AGENDA Planeación del Portafolio Fase 1: Generando Ideas Fase 2: Desarrollando Propuestas Fase 3: Construyendo Escenarios Fase 4: Seleccionando el Portafolio
37 36 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 RecomiendaUNs 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