es t n pu Gestin de A Proyectos TIC

APUNTES GPTIC - AGOSTO 2012

Fase 1: Conceptualizacin e Inicializacin de un proyecto TIC

TITO ROLANDO ARMAS A rolandoarmas@gmail.com Agosto 2012

FACULTAD DE INGENIERA DE SISTEMAS - EPN

Prefacio
Este texto es una recopilacin de los temas tratados en el curso de Gestin de Proyectos TIC de la Maestra de Gestin en TICs de la Facultad de Ingeniera de Sistemas de la Escuela Politcnica Nacional de Quito, a lo largo de algunos semestres previos. La mayora de los temas y su contenido son referencias directas tomadas desde algunos sitios y obras de las cuales constan al nal de cada seccin. Algunas de las imgenes utilizadas en este texto tienen licencias de uso libre. Aquellas que no son libres se hace constar la fuente de donde se han tomado. Este es un texto activo, cualquier sugerencia sobre los contenidos y el formato del texto, por favor escrbame a rolandoarmas@gmail.com
Agosto 2012 Apuntes Gestin de Proyectos TIC por Rolando Armas se encuentra bajo una Licencia

Creative Commons Atribucin-NoComercial-CompartirIgual 3.0 Ecuador

C APTULO 1

El Caso de Negocio o Business Case

En este captulo se responder a la pregunta: Como se justifica objetivamente el desarrollo de un proyecto TIC?. Se revisarn los conceptos preliminares sobre gestin de proyectos y se plantear la metodologa para responder a la pregunta a travs del desarrollo de un caso de negocio o business case

S ECCIN 1

1.- Introduccin

La naturaleza y caracterstica de un proyecto TIC

C ONTENIDO 1. Introduccin 2. Ciclo de vida de un proyecto TIC 3. Ciclo de vida de un producto TIC 4. Relacin entre los ciclos de vida 5. Exito y fracaso de los proyectos TIC

En primera instancia es necesario entender y revisar las caractersticas propias de los proyectos de tecnologa de la informacin: Que los distingue del resto de proyectos? Cuales son sus caractersticas propias? Primero, requerimos contestar la pregunta: Que es un proyecto? La aplicacin de conocimiento, habilidades, herramientas y tcnicas a las actividades del proyecto para cumplir con los requerimientos del proyecto. PMBOK Un proyecto puede generar: un producto que puede ser un componente de otro elemento o un elemento final en s mismo, la capacidad de realizar un servicio (por ej., una funcin comercial que brinda apoyo a la produccin o distribucin), o un resultado tal como un producto o un documento (por ej., un proyecto de investigacin que desarrolla conocimientos que se pueden emplear para determinar si existe una tendencia o si un nuevo proceso beneficiar a la sociedad). Luego la siguiente pregunta a responder es:Que es un proyecto de IT y cuales son sus caractersticas?. En las siguientes secciones responderemos a esta pregunta.

2. Ciclo de vida de un proyecto TIC Un ciclo de vida de un proyecto es una coleccin de etapas o fases lgicas que guan la vida de un proyecto desde su principio a su final. Cada proyecto debe entregar uno mas entregables. Un entregable es un producto tangible y verificable (por ejemplo: plan del proyecto, especificaciones de diseo, etc.)

A continuacin se da un breve rasgo de las fases: Definicin del Objetivo: El objetivo debe estar enfocado en proveer el valor agregado a la organizacin. Planificacin del Proyecto: Una planificacin de proyectos debe responder las siguientes preguntas: Que vamos a hacer? Porqu lo vamos hacer? Como lo vamos a hacer? Quien va a estar involucrado? Cuanto tiempo no va a tomar? Cuanto va a costar? Que puede ir mal y que podemos hacer al respecto? Como estimamos el tiempo y el costo? Porque tomamos ciertas decisiones?

Figura 1.1 Ciclo de vida de un proyecto TIC (tomado de Marchewka JT (2003))

Como conoceremos si llegamos a cumplir exitosamente?

Adicionalmente los entregables, tareas, recursos y tiempo para completar cada tarea deben ser definidos por cada fase del proyecto. Este plan inicial es llamado linea base, define lo acordado en alcance, tiempo y presupuesto y es usado como
4

herramienta para medir el comportamiento o rendimiento del proyecto a lo largo del ciclo de vida. Ejecucin del Plan: La ejecucin del plan es poner en accin las tareas especificadas. El progreso del del proyecto debe ser documentado y comparado con la linea base del proyecto. El comportamiento y avance del proyecto debe ser comunicado a todos los socios y auspiciantes del proyecto. Al final de esta fase, el equipo del proyecto debe desarrollar los entregables o entregar el producto completo a la organizacin. Cierre del Proyecto: La fase de cierre del proyecto asegura que todo el trabajo es completado segn lo planeado y acordado con el equipo del proyecto y el auspiciante (cliente). Evaluacin del proyecto: Como evaluar el xito de un proyecto de IT? La primera forma es llegar a medir cuanto del valor agregado o valor organizacional medible se ha alcanzado. Esto se lo realiza una vez que el sistema esta en produccin y se le ha dado el plazo respectivo para que cumpla con el valor agregado acordado. La otra forma de evaluacin es documentar la experiencia en trminos de lecciones aprendidas, aquellas cosas que se haran igual y aquellas que se deben cambiar en el siguiente proyecto, basados en la experiencia actual del proyecto. Estas experiencias se convertirn luego en las mejores prcticas que sern tomadas en cuenta en los siguientes proyectos.

Adicionalmente, tanto el equipo del proyecto y el proyecto en si deben ser evaluados. Una auditora externa es recomendable tambin para conocer si el proyecto fue bien gestionado, los entregables fueron los acordados, si se siguieron o no los debidos procesos, y si se consiguieron los estndares de calidad. 3. Ciclo de Vida de un producto de IT A pesar de que los proyectos siguen un ciclo de vida, el desarrollo de los sistemas de informacin siguen un ciclo de vida de produccin. El mas comn ciclo de produccin en IT es el ciclo de vida de desarrollo de sistemas, que representa las fases o etapas secuenciales que un sistema de informacin sigue a travs de su ciclo de vida til. En general este ciclo de vida se lo puede representar a travs de las siguientes etapas: planificacin, anlisis, diseo, implementacin, mantenimiento y soporte. Planificacin: La pregunta a responder en esta etapa es: Cual proceso de desarrollo y que actividades a considerar?. Aqu el proceso formal de planificacin asegura que estn correctamente especificados: el objetivo, el presupuesto, el plazo, la tecnologa, el proceso de desarrollo, mtodos y herramientas. Anlisis: Etapa en la que se realiza una investigacin tcnica sobre la problemtica. El trabajo se refiere a identificar y documentar cualquier problema o cuello de botella en el actual sistema. Se deber especificar las necesidades y los requerimientos.
5

Diseo: Usando los requerimientos y los modelos lgicos como entradas, se disea la arquitectura del nuevo sistema. La arquitectura incluye el diseo de la red, la configuracin del hardware, bases de datos, interfaces de usuario, y aplicaciones. Implementacin: Desarrollo y construccin del sistema, pruebas, instalacin. Adicionalmente: capacitacin, soporte y documentacin. Mantenimiento y soporte: Fase en la que una vez puesto en produccin, se corrigen errores que podran aparecer durante la operacin del sistema. 4. La relacin del ciclo de vida de un proyecto y un producto de IT Aunque el ciclo de vida del proyecto TIC pueda ser muy similar al ciclo de vida del producto, la diferencia es que el primero se enfoca en los procesos de gestin del proyecto, mientras que el segundo se enfoca en en la creacin e implementacin del producto.

figura 1.2 Integracin de los ciclos de vida (tomado de Marchewka JT (2003)) El ciclo de vida del producto es parte del ciclo de vida del proyecto porque muchas de las fases de creacin del producto ocurren durante la fase de ejecucin del proyecto. Esta integracin entre el ciclo de vida del producto y el ciclo de vida del proyecto en un componente importante que distingue a los proyectos de TIC del resto de los proyectos. 5.- Exito y fracaso de los proyectos TIC Porque fallan los proyectos de TIC? Una de las caractersticas de las TI es que en ltima instancia son intangibles. Que implicaciones tienen que las TI sean intangibles?

Falta de comunicacin eficiente y eficaz. Planificacin irracional. Utilizacin irracional de los recursos Diseo inadecuado a las necesidades y realidades de la organizacin. Requerimientos incompletos,mal definidos o poco estables.

seleccionar los procesos adecuados requeridos para alcanzar los objetivos del proyecto, utilizar un enfoque definido que pueda adoptarse para cumplir con los requisitos, cumplir con los requisitos a fin de satisfacer las necesidades y expectativas de los interesados, y equilibrar las demandas contrapuestas relativas al alcance, tiempo, costo, calidad, recursos y riesgo para producir el producto, servicio o resultado especificado. Referencias: Marchewka J.T.(2003), Information Technology Project Management Gua de los fundamentos para la direccin de proyectos (Gua del PMBOK) Cuarta Edicin

CHAOS Report El reporte CHAOS es una encuesta realizada en 1995 por el Standish Group a 365 gestores de TIC en Estados Unidos. En este reporte se estudia el porque del xito o fracaso de los proyectos TIC. Segn el reporte, factores como el involucramiento del usuario, el soporte en la gestin y una clara definicin de los requerimientos, son algunos de los factores de xito en un proyecto de TIC. El estudio muestra el top 10 de los factores de incidencia para que los proyectos sean exitosos, estn en peligro o fracasen. Como asegurar el xito de un proyecto? De acuerdo al PMBOK, para que un proyecto tenga xito se debe asegurar lo siguiente:

S ECCIN 2

1. Introduccin

Visin general de la metodologa

C ONTENIDO 1. Introduccin 2. PMBOK 3. ITPM

En esta seccin se har referencia a la metodologa ITPM (Information Technology Project Management) propuesto en Marchewka J.T.(2003). De acuerdo al autor, la metodologa ITPM se la debe ver como una plantilla para la inicializacin, planificacin y desarrollo de sistemas de informacin. La metodologa recomienda las fases, entregables, procesos, herramientas y reas de conocimiento para soportar proyectos TIC. Se recalca en que la metodologa sugiere, debido a las caractersticas propias de cada uno de los proyectos TIC, por ejemplo, no es lo mismo un proyecto de comercio electrnico que uno de migracin de infraestructura. En este curso tambin se usar la gua PMBOK mostrando aquellas consideraciones a tomar en cuenta en cada una de las reas de gestin que se integran con la metodologa ITPM. 2. PMBOK Propsito del PMBOK: La Gua del PMBOK identifica ese subconjunto de fundamentos de la direccin de proyectos generalmente reconocido como buenas prcticas. Generalmente reconocido significa que los conocimientos y prcticas descritos se aplican a la mayora de los proyectos, la mayor parte del tiempo, y que existe consenso sobre su valor y utilidad. (PMBOK)

Que ES y NO ES el PMBOK: El PMBOK es una gua que describe los procesos de la direccin de los proyectos, es decir aquellos que aseguran que el proyecto avance de manera eficaz durante toda su existencia. Estos procesos incluyen las herramientas y tcnicas involucradas en la aplicacin de las habilidades y capacidades que se describen en las reas de conocimiento. El PMBOK NO ES una gua que describa los procesos orientados al producto, es decir aquellos que especifican y crean el producto. Esos procesos varan segn el rea de aplicacin. El alcance del proyecto no puede definirse si no se cuenta con una comprensin bsica acerca de cmo generar el producto especificado. Portafolio, programas y oficina de proyectos Portafolio de proyectos: Conjunto de proyectos agrupados de acuerdo a un criterio unificador comn para cumplir con los objetivos estratgicos de la organizacin, por ejemplo: portafolio energtico, hdrico, de desarrollo de software, e infraestructura de comunicaciones, etc. Referentes comunes pueden ser por ejemplo: un cliente, vendedor, tecnologa o recurso en comn. Programas: Un programa se define como un grupo de proyectos relacionados administrados de forma coordinada para obtener beneficios y control, que no se obtendran si se gestionaran en forma individual.

Oficina: Una oficina de direccin de proyectos es un cuerpo o entidad dentro de una organizacin que tiene varias responsabilidades asignadas con relacin a la direccin centralizada y coordinada de aquellos proyectos que se encuentran bajo su jurisdiccin. Las responsabilidades de una oficina de gestin de proyectos pueden abarcar desde proveer funciones de apoyo para la direccin de proyectos hasta la responsabilidad de dirigir proyectos directamente. Cual es el papel del PMBOK en la gestin de proyectos TIC? PMBOK es una gua que provee una base para identificar y describir principios y practicas generalmente aceptadas en la gestin de proyectos. Sin embargo la determinacin de esas practicas dependen del equipo de trabajo y de su experiencia. El PMBOK, dentro del campo de gestin de proyectos de IT ser usado como una base referencial sobre algunos procesos y herramientas que se integran al ciclo de vida de los proyectos TIC. Procesos y Areas de Gestin La Gua del PMBOK es una coleccin de procesos (5) y reas de conocimiento (9) generalmente aceptadas como las mejores prcticas dentro de la gestin de proyectos. La Gua del PMBOK reconoce 5 grupos de procesos bsicos (Iniciacin, Planeacin, Ejecucin, Monitorio y Control, y Cierre) y 9 reas de conocimiento comunes a casi todos los proyectos:
9

1. Gestin de la Integracin 2. Gestin del Alcance 3. Gestin del Tiempo 4. Gestin de la Calidad 5. Gestin de los Costos 6. Gestin de los Riesgos 7. Gestin de Recursos Humanos 8. Gestin de las Comunicaciones 9. Gestin de las Adquisiciones Se traslapan e interactan a travs de un proyecto o fase. Los procesos son descritos en trminos de: Entradas (documentos, planes, diseos, etc.), Herramientas y Tcnicas (mecanismos aplicados a las entradas) y Salidas (documentos, productos, etc.). Los procesos de direccin de proyectos se agrupan en cinco categoras conocidas como Grupos de Procesos de la Direccin de Proyectos (o grupos de procesos): Grupo del Proceso de Iniciacin. Aquellos procesos realizados para definir un nuevo proyecto o una nueva fase de un proyecto ya existente, mediante la obtencin de la autorizacin para comenzar dicho proyecto o fase.

Grupo del Proceso de Planificacin. Aquellos procesos requeridos para establecer el alcance del proyecto, refinar los objetivos y definir el curso de accin necesario para alcanzar los objetivos para cuyo logro se emprendi el proyecto. Grupo del Proceso de Ejecucin. Aquellos procesos realizados para completar el trabajo definido en el plan para la direccin del proyecto a fin de cumplir con las especificaciones del mismo. Grupo del Proceso de Seguimiento y Control. Aquellos procesos requeridos para dar seguimiento, analizar y regular el progreso y el desempeo del proyecto, para identificar reas en las que el plan requiera cambios y para iniciar los cambios correspondientes. Grupo del Proceso de Cierre. Aquellos procesos realizados para finalizar todas las actividades a travs de todos los grupos de procesos, a fin de cerrar formalmente el proyecto o una fase del mismo.

10

3. ITPM La metodologa ITPM propone las siguientes fases y entregables .

Fase 1: Conceptualizacin e Inicializacin El primer paso de la metodologa se enfoca en definir la META, el objetivo final del proyecto. Un proyecto es llevado a cabo para un propsito especfico, y ese propsito especfico debe ser brindar un valor agregado a la organizacin. La definicin de la meta del proyecto es un paso importante en la metodologa pues la meta ayudar a definir el alcance ya guiar las decisiones en el ciclo de vida del proyecto. Este le permitir incluso evaluar el proyecto al final para encontrar el grado de cumplimiento o xito del proyecto. El entregable de esta fase es el caso de negocio o business case.

Figura 2.1 Fases de ITPM (tomado de Marchewka J.T.(2003) ) Fundamentos ITPM

Inicializacin, planificacin, ejecucin, control, cierre. Alcance, tiempo, presupuesto, calidad. Gestin de proyectos, Desarrollo de sistemas de informacin Organizacional, de proyectos, tcnicos Integracin, alcance, tiempo, costo, calidad, recursos humanos, comunicacin, riesgo y adquisiciones.

Fase 2: Desarrollo del plan del proyecto El project charter (constitucin del proyecto) es el que define como el proyecto estar organizado y como ser implementado. El project charte ofrece la oportunidad para clarificar los objeyivos del proyecto y definir los objetivos en trminos de alcance, plazos, presupuesto y estndares de calidad.

Procesos Objetivos Herramientas Infraestructura reas PMBOK

11

El project chart debe responder a las siguientes preguntas: 1.

Quien es el administrador del proyecto?

Fase 3: Ejecutar y controlar el proyecto Esta fase se refiere a como se lleva a cabo el proyecto para la entrega de la solucin tecnolgica y la gestin de los procesos del proyecto para lograr la meta del proyecto. Es durante esta fase que el equipo de trabajo usa su particular enfoque y conjunto de herramientas y procesos de anlisis y diseo para llegar a implementar la solucin tecnolgica (ciclo de vida de desarrollo del producto). Adicionalmente el administrador del proyecto debe garantizar que el ambiente y la infraestructura del proyecto incluya:
Involucramiento del personal con la apropiada capacidad, experiencia y conocimiento.








Infraestructura tcnica para el desarrollo Mtodos y herramientas de desarrollo Ambiente adecuado de trabajo Controles para el alcance, plazo, presupuesto y calidad. Un plan detallado de riesgos Un plan de adquisiciones para proveedores. Un plan de gestin de la calidad. Un plan de gestin de cambios. Un plan de comunicaciones.
12

2.
Quien es el patrocinador (financiador) del proyecto? 3.
Quien est en el equipo de trabajo del proyecto? 4.
Que rol ejecuta cada uno de los socios del proyecto? 5.
Cual es el alcance del proyecto? 6.
Cuanto costar el proyecto? 7.
Cuanto tomar completar el proyecto? 8.
Que recursos y tecnologa ser requerido? 9.
Que enfoque, herramientas y tcnicas ser usado para desarrollar la solucin tecnolgica? 10.
Que tareas y actividades se requerirn para realizar el proyecto? 11.
Cuanto tiempo toman esas tareas y actividades? 12.
Quien es el que ejecutar esas tareas y actividades? 13.
Que recibir la organizacin por el tiempo, dinero y recursos invertidos en el proyecto? Adicionalmente, son definidos en detalle, el alcance, el plazo, el presupuesto y los objetivos de calidad del proyecto

Un plan de pruebas. Un plan de implementacin.

Cual es la posibilidad de que el proyecto alcance su objetivo? El proyecto alcanz su alcance, plazos, presupuesto y objetivos de calidad? El equipo de trabajo entreg todo lo acordado al cliente? Est el cliente satisfecho con el trabajo? Tanto el equipo de trabajo como el administrador del proyecto, siguieron los procesos del proyecto y del producto? Que riesgos y desafos enfrent el equipo de trabajo? Como manejaron los riesgos? Cuan bien trabajaron conjuntamente el cliente, el administrado y el equipo de trabajo? El equipo de trabajo y el administrado actuaron de forma etica y profesional? Finalmente, el proyecto debe evaluar para determinar si el proyecto provey del valor agregado a la organizacin. Referencias Gua de los fundamentos para la direccin de proyectos (Gua del PMBOK) Cuarta Edicin Marchewka J.T.(2003), Information Technology Project Management

Un plan de evaluacin, incentivos y reconocimiento al equipo de trabajo. Fase 4: Cierre Despus de que la solucin tecnolgica ha sido desarrollada, probada, instalada, una aceptacin formal debe transferir el control del equipo del proyecto al cliente o al patrocinador. El equipo de trabajo debe preparar un reporte final del proyecto y un documento donde conste la verificacin de que todos los entregables cumplen con el alcance del proyecto. Fase 5: Evaluacin del proyecto Esta fase se enfoca en la evaluacin de las cuatro fases del proyecto. La revisin la hace el administrador del proyecto conjuntamente con el equipo de trabajo. La revisin debe enfocarse en todo el proyecto y evaluar que fue hecho bien y que pudo hacerse mejor. Subsecuentemente, las lecciones aprendidas de la experiencia del equipo de trabajo debe ser documentado y compartido con otros en la organizacin. Adicionalmente, el administrador del proyecto y el equipo debe identificar las mejores practicas que pueden ser institucionalizadas e incorporadas en la metodologa. Una parte externa al proyecto debe evaluar al proyecto, al administrador del proyecto y al equipo de trabajo. El enfoque de esta revisin debe responder las siguientes preguntas:

13

S ECCIN 3

Business Case (BC) En esta fase se determinar el valor agregado que el proyecto brindar a la organizacin y se propondrn mas de una alternativa, de las cuales bajo un anlisis objetivo se escoger la mejor. Esto se lo realiza a travs del mtodo denominado caso de negocio o Business Case. 1.- Que es un BC? Es el primer entregable de un ciclo de vida de proyecto de IT. Provee un anlisis del valor organizacional, factibilidad, costos, riesgos y beneficios de algunas alternativas u opciones propuestas. Sin embargo, un business case no es un presupuesto o un plan de proyecto. Un IT-BC , debe ser: 1) Exhaustivo en detalles de todos los posibles impactos, beneficios, costos. 2) Claro y Lgico en el impacto del costo / beneficio de cada alternativa 3) Objetivo, a travs de toda la informacin pertinente

Conceptualizacin e Inicializacin de un proyecto TIC - Business Case

C ONTENIDO 1. Que es un Businesss Case (BC)? 2. El propsito de un BC 3. El proceso de desarrollo de un BC

2.- Cual es el propsito de un BC? El propsito de un business case es mostrar como una solucin de IT puede generar valor al negocio. Por lo tanto, el business case debe mostrar explcitamente como una
14

inversin en IT conducir a un incremento en el valor del negocio. Adems, debe proveer a la gerencia toda la informacin necesaria para tomar la decisin si un proyecto debe o no ser financiado. El Proceso de desarrollo de un Business Case El desarrollo de un business case se desarrolla en ocho etapas, segn se muestra en la siguiente figura:

Etapas 1) Seleccione el equipo: El desarrollo del BC de ser posible debe involucrar a los patrocinadores y socios que sern beneficiados por el proyecto. El equipo debe estar conformado por: Gerentes, Especialistas de Negocios, Usuarios que conocen de los Requerimientos, y Especialistas de IT que entienden las oportunidades, limitaciones y riesgos asociados con IT. Las ventajas de involucrar a estos actores es: Credibilidad: un equipo aporta diferentes tipos de vista, Alineamiento con los objetivos de la organizacin: La gerencia de mas alto nivel puede ayudar conectando el BC con las estrategias de largo plazo de la organizacin.

Figura 3.1 Etapas de un BC

Costos reales: Algunos miembros del equipo con mayor experiencia o acceso a cierta informacin, pueden ayudar a realizar estimaciones mas realistas en reas como salarios, regulaciones, capacitacin, etc.

15

2) Definir el Valor Organizacional Medible (MOV) Para proveer un real valor a la organizacin el proyecto debe estar alineado con las metas misin y objetivos de la organizacin. Como su nombre lo indica un Valor Organizacional Medible (MOV) debe: Ser medible: Las mediciones proveen al equipo del proyecto un enfoque de trabajo en trmino de sus acciones. En lugar de la implementacin de un sistema de informacin, el equipo del proyecto se enfocaen lograr o alcanzar un rendimiento de trabajo como objetivo especfico. Provee valor a la organizacin: Tiempo y recursos solo se justifica si el proyecto va a entregar valor a la organizacin. Tenga en cuenta que las tecnologas de la informacin por si mismas no proveen valor. La tecnologa es solo un facilitador, es una herramienta, un medio para que la organizacin logre sus objetivos. Ser acordado: Es importante que este valor agregado sea consensuado y entendido por los beneficiarios del proyecto, es necesario que las expectativas estn claras. Verificable: Al final del proyecto, el MOV debe ser verificable para determinar si el proyecto fue exitoso. Si el proyecto fue exitoso es porque se logr llegar al MOV o incluso superarlo.

Como determinar el MOV? Paso 1. Identifique Area de Impacto: El primer paso es identificar el impacto deseado que el proyecto de IT provocar sobre la organizacin. A continuacin se proponen las siguientes reas que pueden ser consideradas.
AREA POTENCIAL EJEMPLOS DE IMPACTOS DESEADOS Penetracin de nuevos mercados Estratgica Transformacin de los trminos de competicin en el mercado Incrementar la participacin en el mercado Penetracin de nuevos mercados Cliente Transformacin de los trminos de competicin en el mercado Incrementar la participacin en el mercado Incrementar las Ganancias Financiera Operacionales Bajar costos de las operaciones Incrementar la efectividad operacional Mejorar la cadena de valor o produccin Social Educacin Salud Seguridad Ambiente Tributacin

Tabla 1.1 Potenciales reas de impacto para proyectos de IT (tomado de Marchewka(2003))

16

Paso 2. Identifique el valor deseado del proyecto de IT: En trminos simples, podemos identificar el valor de un proyecto de IT respondiendo a las siguientes preguntas: Mejor - Que desea hacer mejor la organizacin? (mejorar la calidad, la eficiencia) Mas Rpido - Que desea hacer la organizacin mas rpido? (Incrementar velocidad, eficiencia, reducir tiempos) Abaratar - Que se desea abaratar? (Abaratar costos?) Hacer mas - Que mas se desea hacer aparte de lo actual? (Crecer, expandirse?) Los primeros tres criterios, mejor, ms rpido y mas barato tiene que ver con un objetivo de calidad, efectividad y eficiencia, mientras que hacer mas tiene que ver con un objetivo de crecimiento. Estos objetivos son los que el proyecto de IT proveer a la organizacin.

c) proveer una forma de evaluacin para saber si el proyecto fue o no exitoso. Los criterios para la creacin de mtricas son: Proveer un significado para evaluar si el proyecto es exitoso o no. Pueden ser beneficios tangibles o intangibles Mtrica expresada en dlares ,porcentajes ,nmeros o cifras. La mtrica debe indicar si existe un incremento o decremento desde el actual estado de la organizacin.

Paso 4 : Establecer un margen de tiempo para alcanzar el MOV Es necesario establecer un margen de tiempo para alcanzar el MOV. No confundir el tiempo para completar el proyecto, que el tiempo para lograr el MOV, estos son dos tiempos distintos. El MOV solo se lograr medirlo una vez terminado el proyecto y por lo tanto para lograr medir el valor agregado requerir de un lapso de tiempo cuando el proyecto de IT est en produccin. El MOV puede ser flexible y cambiante, se lo puede replantear una vez que haya sido medido.

Paso 3 Definicin de Mtricas Apropiadas: El siguiente paso es determinar una mtrica que: a) provea al equipo del proyecto de un direccionamiento o punto de referencia b) establecer las expectativas

17

Paso 5: Verificar que el MOV sea realista y preciso. Requiere una relacin cercana entre el gerente del proyecto y sus auspiciantes. El gerente del proyecto es el que gua el proceso, mientras que el auspiciante debe identificar el valor y las mtricas objetivo.
AO 1 2 3 MOV
20% de retorno de la inversin 500 nuevos clientes 25% de retorno de la inversin 1000 nuevos clientes 30% de retorno de la inversin 1500 nuevos clientes

6) Resumir el MOV de forma clara y concisa en una sentencia o tabla: Al resumir el MOV: a) provee de una importante forma de verificacin, b) provee una calra y simple guia al equipo de trabajo, y c) se explictan claramente las expectativas.

Una asunto muy importante es manifestar que, el MOV no incluye ninguna sentencia explcita acerca de tecnologa. La tecnologa es un medio no un fin.

3) Identificar las alternativas No existe una nica solucin para los problemas organizacionales, es por eso que se requiere identificar mas alternativas antes de tratar directamente con la problemtica (oportunidad) organizacional. Todas las alternativas u opciones identificadas en el BC deben ser estrategias para alcanzar el MOV. Es importante que las alternativas listadas incluyan un amplio rango de soluciones potenciales, pero tambin es importante que conste una alternativa que muestre como funciona la organizacin si se mantiene el status quo o caso base (en algunos casos el status quo puede ser la mejor alternativa). Algunas opciones que se pueden considerar, pueden incluir:
18

Una sentencia clara puede citarse de la siguiente forma: Este proyecto sera exitoso si _____________________ tambin se puede explicitarlo a travs de una tabla como la siguiente:

Cambiar el actual proceso de negocio Adoptar o adaptar una aplicacin desarrollada por una diferente area de la organizacin Reingeniera del actual sistema Compra de una solucin informtica Construccin de una nueva aplicacin usando recursos internos o contratar el desarrollo a travs de outsourcing.

disponible? El actual personal tiene las habilidades y experiencia para soportar la solucin? Factibilidad Organizacional: Considera el impacto organizacional. Se enfoca principalmente en como la organizacin se adaptar al cambio. Como impactar a la gente y a la forma de hacer su trabajo? Afectar al desarrollo de la organizacin mientras la solucin es implementada? Otras Factibilidades: Dependiendo de la situacin de la organizacin, un business case puede incluir otros aspectos, como la factibilidad legal o tica. El riesgo debe enfocarse en: Identificacin Evaluacin / Impacto Respuesta

4) Definir la factibilidad e Identificacin de riesgos Cada opcin o alternativa debe ser analizada en trminos de su factibilidad y riesgo potencial. La factibilidad se enfoca en determinar si una particular alternativa es realizable y si vale la pena hacerlo. El riesgo, por otro lado, se enfoca en que puede ir mal y que puede ir bien. La factibilidad puede ser vista en los siguientes trminos: Factibilidad Econmica: Hacer un anlisis costo / beneficio. Algunas alternativas pueden ser muy costosas o simplemente no proveer los beneficios ambicionados por el proyecto. Factibilidad Tcnica: Se enfoca en la existencia de la infraestructura tcnica necesaria para soportar la solucin de IT. La actual infraestructura soportar la alternativa planteada? Ser necesaria nueva tecnologa? Estar

5) Definir TCO (Total Cost of Ownership): Costo total de propiedad Se refiere al Costo Total de adquisicin, desarrollo, mantenimiento y soporte de las TI de acuerdo a su vida til. Incluye: Costos Directos: HW-SW- Equipos de Telecomunicaciones -Costos de Instalacin
19

Costos Operacin: Salarios Capacitacin Mantenimiento. Costos Indirectos: Perdida inicial de produccin, Tiempo perdido cuando el sistema esta inoperativo, aseguramiento de calidad.

tangibles los cuales a la vez pueden ser enlazados a mejoras de eficiencia. Otra forma de cuantificar los beneficios intangibles es estimar el nivel de servicio (Cual es el costo actual por el nivel de servicio?).

7) Analizar Alternativas 6) Definir TBO (Total Benefits of Ownership): De forma similar, al igual que el modelo TCO, este modelo cuantifica los beneficios a nivel de beneficios directos, de operacin e indirectos asociada con cada alternativa. Los beneficios que se pueden considerar son: Incremento en el valor del trabajo. Mejora en la precisin y eficiencia Mejora en la toma de decisiones Mejora en el servicio al cliente Los beneficios tangibles asociados con un proyecto de IT son relativamente fciles de identificar y cuantificar, Estos generalmente se asocian con costos que no se han incurrido o en los cuales se ha reducido o ahorrado. Los beneficios intangibles pueden ser fciles tambin de detectar pero son ms dificiles de cuantificar. Es importante intentar cuantificar todos los beneficios identificados. Una forma de cuantificar los beneficios intangibles es enlazarlos a los beneficios 8) Proponer la Recomendacin Reconocidas y analizadas las alternativas, el ultimo paso es recomendar una de las opciones. La recomendacin debe estar debidamente soportada fundamentada y justificada segn el anlisis realizado en los pasos anteriores. El BC debe ser presentado en un documento formal. El contenido del documento puede tener las siguientes secciones mostradas a continuacin. Para el anlisis de las alternativas se pueden utilizar modelos financieros o modelos cuantitativos y cualitativos (Balance Score Card). Para modelos financieros se pueden utilizar indicadores como: Payback, Breakeven, ROI, NPV, EVA. El utilizar estos indicadores permite generar una mayor credibilidad y confianza en el anlisis por ende hay mas chances de que el proyecto pueda ser financiado y aprobado.

20

Cover Page Title and subtitle Author and address Date Executive Summary Brief description of the problem or opportunity Brief description of organization's goal and strategy Brief description of project's MOV and how it ties to the organizational goal and strategy Brief description of each option or alternative analyzed Brief explanation of which alternative is being recommended and why Introduction Background Current situation Description of the problem or opportunity Project's measurable organizational value

How achieving the project's MOV will support the organization's goal and strategy Objectives of writing this business case Alternatives Description of alternative 1 (Base Case) Description of alternative 2 ... Description of alternative N Analysis of Alternatives Methodology of how alternatives will be analyzed * Data collection methods * Metrics used and explanation why they are relevant Presentation of results that compares each alternative * Metrics Sensitivity analysis * Risks Assumptions Proposed recommendation Required funding and support
21

Referencias Information Technology Project Management Providing Measurable Organizational Value, Jack T. Marchewka. 2003

22