Gestión de Proyectos TIC

FACULTAD DE INGENIERÍA DE SISTEMAS - EPN

APUNTES GPTIC - AGOSTO 2012

Fase 1: Conceptualización e Inicialización de un proyecto TIC

TITO ROLANDO ARMAS A rolandoarmas@gmail.com

Agosto 2012

Apuntes

Prefacio

Este texto es una recopilación de los temas tratados en el curso de Gestión de Proyectos TIC de la Maestría de Gestión en TICs de la Facultad de Ingeniería de Sistemas de la Escuela Politécnica Nacional de Quito, a lo largo de algunos semestres previos. La mayoría de los temas y su contenido son referencias directas tomadas desde algunos sitios y obras de las cuales constan al final de cada sección.

Algunas de las imágenes 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 escríbame a rolandoarmas@gmail.com

Agosto 2012

“Apuntes Gestión de Proyectos TIC” por Rolando Armas se encuentra bajo una Licencia

Creative Commons Atribución-NoComercial-CompartirIgual 3.0 Ecuador

CAPÍTULO 1

E l Caso de N e g o c i o o Business Case

En este capítulo se responderá a la p r e g u n t a : ¿ C o m o s e j u s t i f i c a objetivamente el desarrollo de un proyecto TIC?. Se revisarán los conceptos preliminares sobre gestión de proyectos y se planteará la metodología para responder a la pregunta a través del desarrollo de un caso de negocio o business case

CONTENIDO

1. Introducción

2. Ciclo de vida de un proyecto TIC

3. Ciclo de vida de un producto TIC

4. Relación entre los ciclos de vida

5. Exito y fracaso de los proyectos TIC

SECCIÓN 1

La naturaleza y característica de un

proyecto TIC

1.- Introducción

En primera instancia es necesario entender y revisar las características propias de los proyectos de tecnología de la información: ¿Que los distingue del resto de proyectos? ¿Cuales son sus características propias?

Primero, requerimos contestar la pregunta: ¿Que es un proyecto?

“La aplicación de conocimiento, habilidades, herramientas y técnicas 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 función comercial que brinda apoyo a la producción o distribución), o

un resultado tal como un producto o un documento (por ej., un proyecto de investigación 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 características?. En las siguientes secciones responderemos a esta pregunta.

3

2. Ciclo de vida de un proyecto TIC

Un ciclo de vida de un proyecto es una colección de etapas o fases lógicas que guían 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 diseño, etc.)

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

A continuación se da un breve rasgo de las fases:

Definición del Objetivo: El objetivo debe estar enfocado en proveer el valor agregado a la organización.

Planificación del Proyecto: Una planificación de proyectos debe responder las siguientes preguntas:

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

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

¿Como conoceremos si llegamos a cumplir exitosamente?

herramienta para medir el comportamiento o rendimiento del proyecto a lo largo del ciclo de vida.

Ejecución del Plan: La ejecución del plan es poner en acción 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 organización.

Cierre del Proyecto: La fase de cierre del proyecto asegura que todo el trabajo es completado según lo planeado y acordado con el equipo del proyecto y el auspiciante (cliente).

Evaluación 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 producción y se le ha dado el plazo respectivo para que cumpla con el valor agregado acordado.

La otra forma de evaluación es documentar la experiencia en términos de lecciones aprendidas, aquellas cosas que se harían igual y aquellas que se deben cambiar en el siguiente proyecto, basados en la experiencia actual del proyecto. Estas experiencias se convertirán luego en las mejores prácticas que serán tomadas en cuenta en los siguientes proyectos.

Adicionalmente, tanto el equipo del proyecto y el proyecto en si deben ser evaluados. Una auditoría externa es recomendable también 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 estándares 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 información siguen un ciclo de vida de producción. El mas común ciclo de producción en IT es el ciclo de vida de desarrollo de sistemas, que representa las fases o etapas secuenciales que un sistema de información sigue a través de su ciclo de vida útil. En general este ciclo de vida se lo puede representar a través de las siguientes etapas: p lani f i cac ión, aná l i s i s , d i seño, implementac ión, mantenimiento y soporte.

Planificación: La pregunta a responder en esta etapa es: ¿Cual proceso de desarrollo y que actividades a considerar?. Aquí el proceso formal de planificación asegura que estén correctamente especificados: el objetivo, el presupuesto, el plazo, la tecnología, el proceso de desarrollo, métodos y herramientas.

Análisis: Etapa en la que se realiza una investigación técnica sobre la problemática. 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

Diseño: Usando los requerimientos y los modelos lógicos como entradas, se diseña la arquitectura del nuevo sistema. La arquitectura incluye el diseño de la red, la configuración del hardware, bases de datos, interfaces de usuario, y aplicaciones.

Implementación: Desarrollo y construcción del sistema, pruebas, instalación. Adicionalmente: capacitación, soporte y documentación.

Mantenimiento y soporte: Fase en la que una vez puesto en producción, se corrigen errores que podrían aparecer durante la operación del sistema.

4. La relación 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 gestión del proyecto, mientras que el segundo se enfoca en en la creación e implementación del producto.

figura 1.2 Integración 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 creación del producto ocurren durante la fase de ejecución del proyecto. Esta integración 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 características de las TI es que en última instancia son intangibles.

¿Que implicaciones tienen que las TI sean intangibles?

6

Falta de comunicación eficiente y eficaz.

Planificación irracional.

Utilización irracional de los recursos

Diseño inadecuado a las necesidades y realidades de la organización.

Requerimientos incompletos,mal definidos o poco estables.

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. Según el reporte, factores como el involucramiento del usuario, el soporte en la gestión y una clara definición 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, estén 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:

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

Guía de los fundamentos para la dirección de proyectos (Guía del PMBOK) Cuarta Edición

7

CONTENIDO

1. Introducción

2. PMBOK

3. ITPM

SECCIÓN 2

Visión general de la metodología

1. Introducción

En esta sección se hará referencia a la metodología ITPM (Information Technology Project Management) propuesto en Marchewka J.T.(2003). De acuerdo al autor, la metodología ITPM se la debe ver como una plantilla para la inicialización, planificación y desarrollo de sistemas de información. La metodología recomienda las fases, entregables, procesos, herramientas y áreas de conocimiento para soportar proyectos TIC. Se recalca en que la metodología sugiere, debido a las características propias de cada uno de los proyectos TIC, por ejemplo, no es lo mismo un proyecto de comercio electrónico que uno de migración de infraestructura.

En este curso también se usará la guía PMBOK mostrando aquellas consideraciones a tomar en cuenta en cada una de las áreas de gestión que se integran con la metodología ITPM.

2. PMBOK

Propósito del PMBOK:

La Guía del PMBOK® identifica ese subconjunto de fundamentos de la dirección de proyectos generalmente reconocido como buenas prácticas. “Generalmente reconocido” significa que los conocimientos y prácticas descritos se aplican a la mayoría de los proyectos, la mayor parte del tiempo, y que existe consenso sobre su valor y utilidad. (PMBOK)

8

Que ES y NO ES el PMBOK:

El PMBOK es una guía que describe los procesos de la dirección 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 técnicas involucradas en la aplicación de las habilidades y capacidades que se describen en las Áreas de conocimiento.

El PMBOK NO ES una guía que describa los procesos orientados al producto, es decir aquellos que especifican y crean el producto. Esos procesos varían según el área de aplicación. El alcance del proyecto no puede definirse si no se cuenta con una comprensión básica acerca de cómo generar el producto especificado.

Portafolio, programas y oficina de proyectos

Portafolio de proyectos: Conjunto de proyectos agrupados de acuerdo a un criterio unificador común para cumplir con los objetivos estratégicos de la organización, por ejemplo: portafolio energético, hídrico, de desarrollo de software, e infraestructura de comunicaciones, etc. Referentes comunes pueden ser por ejemplo: un cliente, vendedor, tecnología o recurso en común.

Programas: Un programa se define como un grupo de proyectos relacionados administrados de forma coordinada para obtener beneficios y control, que no se obtendrían si se gestionaran en forma individual.

Oficina: Una oficina de dirección de proyectos es un cuerpo o entidad dentro de una organización que tiene varias responsabilidades asignadas con relación a la dirección centralizada y coordinada de aquellos proyectos que se encuentran bajo su jurisdicción. Las responsabilidades de una oficina de gestión de proyectos pueden abarcar desde proveer funciones de apoyo para la dirección de proyectos hasta la responsabilidad de dirigir proyectos directamente.

¿Cual es el papel del PMBOK en la gestión de proyectos TIC?

PMBOK es una guía que provee una base para identificar y describir principios y practicas generalmente aceptadas en la gestión de proyectos. Sin embargo la determinación de esas practicas dependen del equipo de trabajo y de su experiencia. El PMBOK, dentro del campo de gestión 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 Gestión

La Guía del PMBOK® es una colección de procesos (5) y áreas de conocimiento (9) generalmente aceptadas como las mejores prácticas dentro de la gestión de proyectos.

La Guía del PMBOK® reconoce 5 grupos de procesos básicos (Iniciación, Planeación, Ejecución, Monitorio y Control, y Cierre) y 9 áreas de conocimiento comunes a casi todos los proyectos:

9

1. Gestión de la Integración

2. Gestión del Alcance

3. Gestión del Tiempo

4. Gestión de la Calidad

5. Gestión de los Costos

6. Gestión de los Riesgos

7. Gestión de Recursos Humanos

8. Gestión de las Comunicaciones

9. Gestión de las Adquisiciones

Se traslapan e interactúan a través de un proyecto o fase. Los procesos son descritos en términos de: Entradas (documentos, planes, diseños, etc.), Herramientas y Técnicas (mecanismos aplicados a las entradas) y Salidas (documentos, productos, etc.).

Los procesos de dirección de proyectos se agrupan en cinco categorías conocidas como Grupos de Procesos de la Dirección de Proyectos (o grupos de procesos):

Grupo del Proceso de Iniciación. Aquellos procesos realizados para definir un nuevo proyecto o una nueva fase de un proyecto ya existente, mediante la obtención de la autorización para comenzar dicho proyecto o fase.

Grupo del Proceso de Planificación. Aquellos procesos requeridos para establecer el alcance del proyecto, refinar los objetivos y definir el curso de acción necesario para alcanzar los objetivos para cuyo logro se emprendió el proyecto.

Grupo del Proceso de Ejecución. Aquellos procesos realizados para completar el trabajo definido en el plan para la dirección 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 desempeño 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 través de todos los grupos de procesos, a fin de cerrar formalmente el proyecto o una fase del mismo.

10

3. ITPM

La metodología ITPM propone las siguientes fases y entregables .

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

Fundamentos ITPM

Fase 1: Conceptualización e Inicialización

El primer paso de la metodología se enfoca en definir la META, el objetivo final del proyecto. Un proyecto es llevado a cabo para un propósito específico, y ese propósito específico debe ser brindar un valor agregado a la organización.

La definición de la meta del proyecto es un paso importante en la metodología 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.

Fase 2: Desarrollo del plan del proyecto

El project charter (constitución 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 términos de alcance, plazos, presupuesto y estándares de calidad.

11

ProcesosInicialización, planificación, ejecución, control, cierre.

Objetivos Alcance, tiempo, presupuesto, calidad.

HerramientasGestión de proyectos, Desarrollo de sistemas de información

Infraestructura Organizacional, de proyectos, técnicos

Áreas PMBOKIntegración, alcance, tiempo, costo, calidad, recursos humanos, comunicación, riesgo y adquisiciones.

El project chart debe responder a las siguientes preguntas:

1. ¿Quien es el administrador del proyecto?

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 tecnología será requerido?

9. ¿Que enfoque, herramientas y técnicas será usado para desarrollar la solución tecnológica?

10. ¿Que tareas y actividades se requerirán 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 organización 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

Fase 3: Ejecutar y controlar el proyecto

Esta fase se refiere a como se lleva a cabo el proyecto para la entrega de la solución tecnológica y la gestión 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 análisis y diseño para llegar a implementar la solución tecnológica (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 técnica para el desarrollo

Métodos 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 gestión de la calidad.

Un plan de gestión de cambios.

Un plan de comunicaciones.

12

Un plan de pruebas.

Un plan de implementación.

Un plan de evaluación, incentivos y reconocimiento al equipo de trabajo.

Fase 4: Cierre

Después de que la solución tecnológica ha sido desarrollada, probada, instalada, una aceptación 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 verificación de que todos los entregables cumplen con el alcance del proyecto.

Fase 5: Evaluación del proyecto

Esta fase se enfoca en la evaluación de las cuatro fases del proyecto. La revisión la hace el administrador del proyecto conjuntamente con el equipo de trabajo. La revisión 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 organización. Adicionalmente, el administrador del proyecto y el equipo debe identificar las mejores practicas que pueden ser institucionalizadas e incorporadas en la metodología.

Una parte externa al proyecto debe evaluar al proyecto, al administrador del proyecto y al equipo de trabajo. El enfoque de esta revisión debe responder las siguientes preguntas:

¿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 desafíos 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 organización.

Referencias

Guía de los fundamentos para la dirección de proyectos (Guía del PMBOK) Cuarta Edición

Marchewka J.T.(2003), Information Technology Project Management

13

CONTENIDO

1. ¿Que es un Businesss Case (BC)?

2. El propósito de un BC

3. El proceso de desarrollo de un BC

SECCIÓN 3

Conceptualización e Inicialización de un

proyecto TIC - Business Case

Business Case (BC)

En esta fase se determinará el valor agregado que el proyecto brindará a la organización y se propondrán mas de una alternativa, de las cuales bajo un análisis objetivo se escogerá la mejor. Esto se lo realiza a través del método 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 análisis 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 Lógico en el impacto del costo / beneficio de cada alternativa

3) Objetivo, a través de toda la información pertinente

2.- ¿Cual es el propósito de un BC?

El propósito de un business case es mostrar como una solución de IT puede generar valor al negocio. Por lo tanto, el business case debe mostrar explícitamente como una

14

inversión en IT conducirá a un incremento en el valor del negocio.

Además, debe proveer a la gerencia toda la información necesaria para tomar la decisión 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, según se muestra en la siguiente figura:

Figura 3.1 Etapas de un BC

Etapas

1) Seleccione el equipo:

El desarrollo del BC de ser posible debe involucrar a los patrocinadores y socios que serán 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 organización: La gerencia de mas alto nivel puede ayudar conectando el BC con las estrategias de largo plazo de la organización.

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

15

2) Definir el Valor Organizacional Medible (MOV)

Para proveer un real valor a la organización el proyecto debe estar alineado con las metas misión y objetivos de la organización.

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 término de sus acciones. En lugar de la implementación de un sistema de información, el equipo del proyecto se enfocaen lograr o alcanzar un rendimiento de trabajo como objetivo específico.

Provee valor a la organización: Tiempo y recursos solo se justifica si el proyecto va a entregar valor a la organización. Tenga en cuenta que las tecnologías de la información por si mismas no proveen valor. La tecnología es solo un facilitador, es una herramienta, un medio para que la organización 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 estén 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 organización. A continuación se proponen las siguientes áreas que pueden ser consideradas.

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

16

AREA POTENCIAL EJEMPLOS DE IMPACTOS DESEADOS

Estratégica

Penetración de nuevos mercados

Transformación de los términos de competición en el mercado

Incrementar la participación en el mercado

Cliente

Penetración de nuevos mercados

Transformación de los términos de competición en el mercado

Incrementar la participación en el mercado

Financiera

Operacionales

Incrementar las Ganancias

Bajar costos de las operaciones

Incrementar la efectividad operacional

Mejorar la cadena de valor o producción

SocialEducación Salud Seguridad Ambiente Tributación

Paso 2. Identifique el valor deseado del proyecto de IT: En términos simples, podemos identificar el valor de un proyecto de IT respondiendo a las siguientes preguntas:

Mejor - ¿Que desea hacer mejor la organización? (mejorar la calidad, la eficiencia)

Mas Rápido - ¿Que desea hacer la organización mas rápido? (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, más rápido 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 organización.

Paso 3 Definición de Métricas Apropiadas:

El siguiente paso es determinar una métrica que:

a) provea al equipo del proyecto de un direccionamiento o punto de referencia

b) establecer las expectativas

c) proveer una forma de evaluación para saber si el proyecto fue o no exitoso.

Los criterios para la creación de métricas son:

Proveer un significado para evaluar si el proyecto es exitoso o no.

Pueden ser beneficios tangibles o intangibles

Métrica expresada en dólares ,porcentajes ,números o cifras.

La métrica debe indicar si existe un incremento o decremento desde el actual estado de la organización.

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 producción. El MOV puede ser flexible y cambiante, se lo puede replantear una vez que haya sido medido.

17

Paso 5: Verificar que el MOV sea realista y preciso.

Requiere una relación cercana entre el gerente del proyecto y sus auspiciantes. El gerente del proyecto es el que guía el proceso, mientras que el auspiciante debe identificar el valor y las métricas objetivo.

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 verificación,

b) provee una calra y simple guia al equipo de trabajo, y

c) se explictan claramente las expectativas.

Una sentencia clara puede citarse de la siguiente forma:

“Este proyecto sera exitoso si _____________________”

Ó también se puede explicitarlo a través de una tabla como la siguiente:

Una asunto muy importante es manifestar que, el MOV no incluye ninguna sentencia explícita acerca de tecnología. La tecnología es un medio no un fin.

3) Identificar las alternativas

No existe una única solución para los problemas organizacionales, es por eso que se requiere identificar mas alternativas antes de tratar directamente con la problemática (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 también es importante que conste una alternativa que muestre como funciona la organización 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

AÑO MOV

1 20% de retorno de la inversión500 nuevos clientes

2 25% de retorno de la inversión1000 nuevos clientes

3 30% de retorno de la inversión1500 nuevos clientes

Cambiar el actual proceso de negocio

Adoptar o adaptar una aplicación desarrollada por una diferente area de la organización

Reingeniería del actual sistema

Compra de una solución informática

Construcción de una nueva aplicación usando recursos internos o contratar el desarrollo a través de outsourcing.

4) Definir la factibilidad e Identificación de riesgos

Cada opción o alternativa debe ser analizada en términos 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 términos:

Factibilidad Económica: Hacer un análisis costo / beneficio. Algunas alternativas pueden ser muy costosas o simplemente no proveer los beneficios ambicionados por el proyecto.

Factibilidad Técnica: Se enfoca en la existencia de la infraestructura técnica necesaria para soportar la solución de IT. ¿La actual infraestructura soportará la alternativa planteada? ¿Será necesaria nueva tecnología? ¿Estará

disponible? ¿El actual personal tiene las habilidades y experiencia para soportar la solución?

Factibilidad Organizacional: Considera el impacto organizacional. Se enfoca principalmente en como la organización se adaptará al cambio. ¿Como impactará a la gente y a la forma de hacer su trabajo? ¿Afectará al desarrollo de la organización mientras la solución es implementada?

Otras Factibilidades: Dependiendo de la situación de la organización, un business case puede incluir otros aspectos, como la factibilidad legal o ética.

El riesgo debe enfocarse en:

Identificación

Evaluación / Impacto

Respuesta

5) Definir TCO (Total Cost of Ownership): Costo total de propiedad

Se refiere al Costo Total de adquisición, desarrollo, mantenimiento y soporte de las TI de acuerdo a su vida útil.

Incluye:

Costos Directos: HW-SW- Equipos de Telecomunicaciones -Costos de Instalación

19

C o s t o s O p e r a c i ó n : S a l a r i o s – C a p a c i t a c i ó n - Mantenimiento.

Costos Indirectos: Perdida inicial de producción, Tiempo perdido cuando el sistema esta inoperativo, aseguramiento de calidad.

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 operación e indirectos asociada con cada alternativa. Los beneficios que se pueden considerar son:

Incremento en el valor del trabajo.

Mejora en la precisión 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 fáciles 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 fáciles también de detectar pero son más dificiles de cuantificar. Es importante intentar cuantificar todos los beneficios identificados. Una forma de cuantificar los beneficios intangibles es enlazarlos a los beneficios

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

Para el análisis 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 análisis por ende hay mas chances de que el proyecto pueda ser financiado y aprobado.

8) Proponer la Recomendación

Reconocidas y analizadas las alternativas, el ultimo paso es recomendar una de las opciones. La recomendación debe estar debidamente soportada – fundamentada y justificada según el análisis 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 continuación.

20

• 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

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

Referencias

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

22