modelo de gestiÓn para los proyectos de … · trabajo de grado para optar al título ... 2.6...
TRANSCRIPT
MODELO DE GESTIÓN PARA LOS PROYECTOS DE TECNOLOGÍA
INFORMÁTICA (TI)
JAMES TORRES OBANDO
Trabajo de grado para optar al título
de Master en Administración de Empresas (MBA)
Presidente de Trabajo de Grado
MAURICIO BOTERO JARAMILLO
Ingeniero Electrónico
UNIVERSIDAD EAFIT
ESCUELA DE POSTGRADO
MAESTRIA EN ADMINISTRACIÓN DE EMPRESAS
MEDELLÍN
2005
Nota de aceptación:
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________ Firma del presidente del jurado
______________________________________
Firma del jurado
______________________________________ Firma del jurado
Medellín, 28 de Febrero de 2006
ii
Dedico este Trabajo de Grado a mis padres, quienes con su apoyo incondicional
me han acompañado y ayudado a alcanzar las metas que he obtenido en mi vida.
iii
RESUMEN
Desde finales de los 90s, el mundo se ha vuelto más complejo. Hoy las nuevas
tecnologías se han convertido en un factor crítico para los negocios,
computadores, hardware, software y las redes como Internet, así como la
creación de equipos de trabajo interdisciplinarios han cambiado radicalmente el
ambiente de trabajo. Estos cambios han creado la necesidad de realizar una mejor
y más sofisticada gestión de proyectos. Hoy en día las empresas están
reconociendo, que para ser exitosas, necesitan aprender, desarrollar y usar
técnicas modernas de gerencias de proyectos. (Information Technolgy Project
Management, kathy Schwalbe).
Los continuos avances en la tecnología permiten que los sistemas informáticos
sean desarrollados con mayor rapidez y con mayor complejidad para satisfacer las
necesidades del entorno de negocios de hoy, los cuales se mueven con celeridad
y sofisticación. Esto inevitablemente produce riesgos en los proyectos de TI y
requiere acciones oportunas para evitar demoras o perjuicios económicos. Sin
embargo, a pesar de conocerse los riesgos, los proyectos de tecnología
informática (TI), especialmente la implementación de nuevos sistemas, continúan
siendo terminados con demora, exceden el presupuesto y no satisfacen las
necesidades de los usuarios y del negocio. (Fuente: www.kpmg.com.ar).Esto nos
lleva a darle una importancia superior a los motivos que generan estos fracasos y
desarrollar lineamientos para corregirlos.
La gestión de proyectos es un ámbito del conocimiento aun en proceso de
elaboración tanto en la academia como en la empresa, lejos de contar aún con un
modelo de excelencia que garantice la óptima asignación de los recursos, cumplir
con los tiempos de ejecución, no sobrepasar los costos establecidos y cumplir con
los requerimientos de calidad y confiabilidad.
iv
En el presente trabajo concreta el proyecto de investigación de la Maestría en
Administración (MBA) de la Universidad EAFIT y aborda la problemática presentada
en la gestión de proyectos de TI como una gran oportunidad de proponer nuevas
formas, incorporar experiencias y mejores prácticas de operar los proyectos de TI
que le permitan a la empresa estudiada incrementar la sinergia, reducir los
esfuerzos e incrementar la efectividad en el desarrollo de los proyectos
permitiendo con esto una mayor probabilidad de culminación exitosa de los
proyectos emprendidos y la validación de sus resultados.
Cumpliendo con el objetivo general propuesto para este trabajo se creo un Modelo
de Gestión para los Proyectos de Tecnología Informática (TI), incorporando una
metodología y las mejores prácticas a nivel mundial que permita mejorar la gestión
de este tipo de proyectos en la empresa objeto de este estudio y posiblemente
pueda ser adaptado en otras. El enfoque del modelo de Gestión de proyectos de TI
tiene las siguientes características.
• Es práctico y flexible
• Se apoya en una metodologías reconocida a nivel mundial como es el PMI y
MSF de Microsoft
• Tiene en cuenta las características organizacionales, lo cual es un elemento de
gran importancia para el éxito de los proyectos en general.
• Tiene en cuenta los resultados de la investigación sobre la problemática en la
gestión de proyectos de TI, con el firme propósito de ayudar a mitigarlos o
mejorarlos.
• Se apoyo en las experiencias encontradas en 3 empresas del GEA (Grupo
Empresarial Antioqueño), mediante encuestas y entrevistas a profundidad con
personas responsables de este tipo de proyectos e involucradas en este tema.
v
vi
CONTENIDO CONTENIDO .........................................................................................................vii LISTA DE TABLAS...............................................................................................xii LISTA DE FIGURAS ............................................................................................xiii
CAPITULO I ............................................................................................................1 1. INTRODUCCIÓN..............................................................................................2
1.1 INTRODUCCIÓN.......................................................................................2 1.2 DESCRIPCIÓN DE LA COMPOSICIÓN DEL TRABAJO ..........................3
CAPITULO II ...........................................................................................................5 CONCEPTOS BÁSICOS DE LA GERENCIA DE PROYECTOS DE TI................5 2. CONCEPTOS BÁSICOS DE LA GERENCIA DE PROYECTOS DE TI..........6
2.1 ¿QUÉ ES UN PROYECTO?......................................................................6 2.2 DEFINICIÓN DE PROYECTO...................................................................7 2.3 LOS PROYECTOS DE TI.........................................................................7 2.4 FACTORES CRÍTICOS DE ÉXITO DE LOS PROYECTOS......................8 2.5 PROGRAMA..............................................................................................9 2.6 PORTAFOLIO DE PROYECTOS ..............................................................9 2.7 GERENCIA DE PORTAFOLIO..................................................................9 2.8 GERENCIA DE PROYECTOS ..................................................................9 2.9 EXCELENCIA EN GERENCIA DE PROYECTOS...................................10 2.10 OBJETIVOS DEL PROYECTO ...............................................................10 2.11 El CONTEXTO DE LA GERENCIA DE PROYECTOS ............................11
2.11.1 Fases y ciclo de vida de los proyectos. .........................................11 2.11.2 Agentes interesadas con el proyecto (stakeholders del proyecto). 13
2.12 CLASIFICACIÓN DE LOS PROYECTOS DE TI. ....................................13 CAPITULO III ........................................................................................................15 ANTECEDENTES DE LA GERENCIA DE PROYECTOS.....................................15 3. ANTECEDENTES DE LA GERENCIA DE PROYECTOS .............................16
3.1 HISTORIA................................................................................................16 3.2 EL PRESENTE........................................................................................18 3.3 ALGUNAS ESTADÍSTICAS.....................................................................19 3.4 ¿PORQUÉ FALLAN LOS PROYECTOS DE TI?.....................................22 3.5 ALGUNAS CAUSAS DEL PROBLEMA...................................................22 3.6 LAS METODOLOGÍAS............................................................................23 3.7 IMPORTANCIA DE LOS MOTIVOS QUE GENERAN FRACASOS EN LOS PROYECTOS DE TI...................................................................................25
CAPITULO IV ........................................................................................................34 INVESTIGACIÓN...................................................................................................34 4. INVESTIGACIÓN ...........................................................................................35
4.1 INTRODUCCIÓN.....................................................................................35
vii
4.2 LA INVESTIGACIÓN SOBRE EL FRACASO DE LOS PROYECTOS DE TI 35 4.3 METODOLOGÍA......................................................................................38
4.3.1 Tipo de estudio o investigación. . ....................................................38 4.3.2 Diseño de la investigación. .............................................................38 4.3.3 Método de investigación. ...............................................................39 4.3.4 Instrumentos y técnicas para la recolección de la información. ......40 4.3.5 Procesamiento o análisis de la Información. . ................................41
4.4 DESARROLLO DE LA INVESTIGACIÓN................................................42 4.5 CARACTERÍSTICAS ORGANIZACIONALES DE LAS EMPRESAS ESTUDIADAS ....................................................................................................43 4.6 HALLAZGOS DE LA INVESTIGACIÓN...................................................45 4.7 ALGUNAS INTERPRETACIONES CONCLUSIONES.............................62
5. MARCO GENERAL PARA EL DESARROLLO DE LA METODOLOGÍA......69 5.1 INTRODUCCIÓN.....................................................................................69 5.2 EL ENFOQUE PARA EL DESARROLLO DE LA METODOLOGÍA DE PROYECTOS.....................................................................................................70 5.3 MARCO GENERAL .................................................................................73
5.3.1 Metodología de gestión de proyectos – pmbok® Guide. ...............73 5.3.2 Resumen de pmbok® guide. . .........................................................73 5.3.3 Aspectos fundamentales del libro PMBOK® Guide .........................75 5.3.4 Implicaciones sobre los procesos de gestión de proyectos. … . ......86 5.3.5 Desde el punto de vista académico..................................................87 5.3.6 Formación integral. ........................................................................87 5.3.7 Desde el punto de vista metodológico. :.........................................88 5.3.8 Desde el punto de vista empresaria. . .............................................90 5.3.9 Propuesta de gestión de proyectos adaptada a las características de las organizaciones. . .....................................................................................98
6. PROPUESTA DE LA METODOLOGÍA BÁSICA PARA EL MODELO DE GESTION DE PROYECTOS DE TI ....................................................................104
6.1 INTRODUCCIÓN...................................................................................104 6.2 DEFINICIÓN DEL MODELO .................................................................106 6.3 COMPONENTES DEL MODELO ..........................................................107 6.4 DESCRIPCIÓN GENERAL....................................................................111 Tomado de ......................................................................................................111 6.5 FASE DE FORMULACION....................................................................118 6.6 FASE DE VISIONAMIENTO..................................................................119 6.7 FASE DE PLANEACION .......................................................................121 6.8 FASE DE DESARROLLO (EJECUCIÓN)..............................................126 6.9 FASE DE CONTROL.............................................................................127 6.10 FASE DE CIERRE.................................................................................128
7. FASES DEL MODELO DE GESTION DE PROYECTOS DE TI PROPUESTO ......................................................................................................132
7.1 FASE DE FORMULACION (Factibilidad) ..............................................132
viii
7.1.1 Objetivo. Crear el documento, que se denomina documento de requerimientos del proyecto, el cual permite formalizar de manera preliminar los siguientes aspectos:................................................................................132 7.1.2 Actividades a desarrollar. ...............................................................133 7.1.3 Entradas. ........................................................................................133 7.1.4 Salidas............................................................................................134 7.1.5 Métricas..........................................................................................135 7.1.6 Participantes involucrados..............................................................135 7.1.7 Mejores prácticas en la elaboración de esta fase...........................136 7.1.8 Técnicas y herramientas recomendadas........................................137
7.2 FASE DE VISIONAMIENTO..................................................................138 7.2.1 Objetivo. . ......................................................................................138 7.2.2 Actividades a desarrollar. ...............................................................138 7.2.3 Entradas. ........................................................................................139 7.2.4 Salidas............................................................................................139 7.2.5 Métricas..........................................................................................140 7.2.6 Participantes involucrados..............................................................140 7.2.7 Mejores prácticas en la elaboración de esta fase...........................141 7.2.8 Técnicas y herramientas recomendadas........................................142
7.3 FASE DE PLANEACIÓN .......................................................................143 7.3.1 Objetivo. .........................................................................................143 7.3.2 Actividades a desarrollar. ...............................................................143 7.3.3 Entradas. ........................................................................................144 7.3.4 Salidas............................................................................................144 7.3.5 Métricas..........................................................................................146 7.3.6 Participantes involucrados..............................................................146 7.3.7 Mejores prácticas en la elaboración de esta fase...........................147 7.3.8 Técnicas y herramientas recomendadas........................................148
7.4 FASE DE DESARROLLO......................................................................150 7.4.1 Objetivo. . .....................................................................................150 7.4.2 Actividades a desarrollar. ...............................................................150 7.4.3 Entradas. ........................................................................................151 7.4.4 Salidas............................................................................................152 7.4.5 Métricas..........................................................................................152 7.4.6 Participantes involucrados..............................................................153 7.4.7 Mejores prácticas en la elaboración de esta fase...........................153 7.4.8 Técnicas y herramientas recomendadas........................................154
7.5 FASE DE ESTABILIZACION .................................................................154 7.5.1 Objetivo. .........................................................................................155 7.5.2 Actividades a desarrollar. ...............................................................155 7.5.3 Entradas. ........................................................................................156 7.5.4 Salidas............................................................................................157 7.5.5 Métricas..........................................................................................158 7.5.6 Participantes involucrados..............................................................158 7.5.7 Mejores prácticas en la elaboración de esta fase...........................159
ix
7.5.8 Técnicas y herramientas recomendadas........................................159 7.6 FASE DE IMPLEMENTACION ..............................................................160
7.6.1 Objetivo. .........................................................................................160 7.6.2 Actividades a desarrollar. ...............................................................161 7.6.3 Entradas. ........................................................................................162 7.6.4 Salidas............................................................................................163 7.6.5 Métricas..........................................................................................163 7.6.6 Participantes involucrados..............................................................164 7.6.7 Mejores prácticas en la elaboración de esta fase...........................164 7.6.8 Técnicas y herramientas recomendadas........................................166
CAPITULO VIII ....................................................................................................167 DISCIPLINA DE ADMINISTRACIÓN DE RIESGOS...........................................167 8. DISCIPLINA DE ADMINISTRACIÓN DE RIESGOS....................................168
8.1 INTRODUCCIÓN...................................................................................170 8.2 CONCEPTOS BÁSICOS DE LOS RIESGOS........................................171 8.3 PRINCIPIOS BÁSICOS.........................................................................173
8.3.1 Agilidad. .......................................................................................173 8.3.2 Potenciar la comunicación. ..........................................................173 8.3.3 Aprenda de todas las experiencias.................................................174 8.3.4 Responsabilidad compartida.. ........................................................174
8.4 CONCEPTOS CLAVE ...........................................................................175 8.4.1 La administración de riesgos proactiva es más eficaz....................175 8.4.2 La identificación de un riesgo es algo positivo. .............................177 8.4.3 Valoración continúa. .......................................................................178 8.4.4 Mantener una comunicación abierta...............................................179 8.4.5 Primero especificar y luego administrar..........................................179 8.4.6 Las situaciones no deben juzgarse sólo por el número de riesgos 180
8.5 PLANEAMIENTO DE LA ADMINISTRACIÓN DE RIESGOS................181 8.6 PROCESO DE ADMINISTRACIÓN DE RIESGOS................................182 8.7 IDENTIFICACIÓN DE RIESGOS ..........................................................185
8.7.1 Objetivos.. ......................................................................................187 8.7.2 Entradas. . .....................................................................................187 8.7.3 Actividades para la identificación de riesgos.. ................................188 8.7.4 Enfoque estructurado. . .................................................................189 8.7.5 Clasificación de los riesgos.. ..........................................................190 8.7.6 Declaraciones de riesgo. ................................................................193 8.7.7 Resultados. ..................................................................................196
8.8 ANÁLISIS Y PRIORIDAD DE LOS RIESGOS.......................................198 8.8.1 Objetivos.. ......................................................................................200 8.8.2 Entradas. . ....................................................................................200 8.8.3 Actividades del análisis de riesgos.. ...............................................200 8.8.4 Resultados. . .................................................................................207 8.8.5 Desactivación de los riesgos.. ........................................................212
8.9 PLANEAMIENTO Y PROGRAMACIÓN DE RIESGOS .........................213 8.9.1 Objetivos. . ...................................................................................214
x
8.9.2 Entradas. . .....................................................................................214 8.9.3 Actividades de planeamiento. .......................................................214 8.9.4 Actividades de programación. . .....................................................219 8.9.5 Resultados. . ................................................................................219
8.10 SEGUIMIENTO E INFORMES DE LOS RIESGOS...............................221 8.10.1 Objetivos.. ......................................................................................223 8.10.2 Entradas. ......................................................................................223 8.10.3 Actividades de seguimiento. . ........................................................223 8.10.4 Elaboración de informes de estado del riesgo................................224 8.10.5 Resultados. ....................................................................................225
8.11 CONTROL DE RIESGOS......................................................................226 8.11.1 Objetivos.. ......................................................................................227 8.11.2 Entradas.. .......................................................................................227 8.11.3 Actividades de control.. ..................................................................228 8.11.4 Resultados.. ...................................................................................228
8.12 APRENDER DE LOS RIESGOS ...........................................................228 8.12.1 Captar el aprendizaje de los riesgos. .............................................230 8.12.2 Administrar el aprendizaje de los riesgos. ....................................231 8.12.3 Clasificaciones de riesgos según el contexto. . .............................232 8.12.4 Base de conocimientos de riesgos.. ...............................................232 8.12.5 Madurez para administrar los conocimientos acerca de un riesgo. 233
8.13 ADMINISTRACIÓN DE RIESGOS INTEGRADA EN EL CICLO DE VIDA DEL PROYECTO .............................................................................................234 8.14 ADMINISTRACIÓN DE RIESGOS EN LA EMPRESA...........................236
8.14.1 Creación de una cultura de administración de riesgos.. .................236 8.15 ADMINISTRAR UNA CARTERA DE PROYECTOS..............................238
9. CONCLUSIONES.........................................................................................241 9.1 RESPECTO A LA INVESTIGACIÓN REALIZADA ................................243 9.2 RESPECTO AL CONOCIMIENTO ........................................................252 9.3 RESPECTO A LA GERENCIA DE PROYECTOS DE TI .......................253 9.4 RESPECTO AL MODELO DE GESTIÓN PARA LOS PROYECTOS DE TECNOLOGÍA INFORMÁTICA (TI)..................................................................255
BIBLIOGRAFIA...................................................................................................257 Otras Fuentes de consulta................................................................................259 Anexo A. .............................................................................................................262 Anexo B. .............................................................................................................293 Anexo C. .............................................................................................................299
xi
LISTA DE TABLAS Tabla 1. Desempeño de los Proyectos de TI .........................................................21
Tabla 2. Desempeño de los Proyectos de TI .........................................................45
Tabla 3. Resultados encuesta................................................................................57
Tabla 4. ..................................................................................................................96
Estado de madurez de las grupos de trabajo en las organizaciones .....................96
Tabla 5. Ejemplo Lista maestra de riesgos ..........................................................197
Tabla 6. División de siete valores para las probabilidades ..................................201
Tabla 7. Puntuación riesgos ...............................................................................203
Tabla 8. Sistemas de puntuación para calcular impacto (Hall 1998) ...................203
Tabla 9. Valor de clasificación .............................................................................206
Tabla 10. Ejemplo de lista maestra de riesgos que utiliza un enfoque de cálculo de
dos factores .........................................................................................................207
Tabla 11. Lista de los elementos que se mantienen en la lista maestra de riesgos
.............................................................................................................................208
Tabla 12. Información formulario de declaración de riesgos................................210
xii
LISTA DE FIGURAS Figura 1. Aspecto triangular de los objetivos .........................................................11
Figura 2. Fases de un proyecto .............................................................................12
Figura 3. Datos de la Standish Group....................................................................20
Figura 4. Representación de la historia de resultado de los proyectos de TI.........38
Figura 5. Resultados encuesta .............................................................................56
Figura 6. Resultados de criterios de éxito en los proyectos. Según encuesta. ......65
Figura 7. Proyectos -Estrategias corporativas .......................................................69
Figura 8. Secuencia de procesos para enlace con las estrategias. .......................70
Figura 9. Áreas de conocimiento de la gestión de proyectos y los procesos de
gestión de proyectos. PMBOK® Guide..................................................................76
Figura 10. Grupo de Procesos de la Gerencia de Proyectos................................80
Figura 11. Proceso de Iniciación............................................................................81
Figura 12. Procesos de Planeación. ......................................................................82
Figura 13. Procesos de Ejecución. ........................................................................83
Figura 14. Procesos de Control. ............................................................................84
Figura 15. Procesos de Cierre. ..............................................................................85
Figura 16. Modelo general Gonzalo Montes ..........................................................86
Figura 17. Gestión de Caracterización de la Organización....................................99
Figura 18. Visión general de los procesos de gestión de caracterización...........101
Figura 19. Ciclo de vida proyectos de TI..............................................................108
Figura 21. Proceso de gerenciamiento de un proyecto en General .....................111
Figura 22. Modelo de gestión de proyectos de TI (MGPTI) ................................117
Figura 23. Proceso de administración de riesgos de MSF..................................183
Figura 24. Identificación de riesgos .....................................................................186
Figura 25. Declaración del riesgo ........................................................................193
Figura 26. Análisis y prioridades de los riesgos...................................................199
Figura 27. Planeamiento y programación de riesgos...........................................213
Figura 28. Seguimiento e informes de los riesgos ...............................................222
xiii
Figura 29. Control de riesgos...............................................................................226
Figura 30. Aprendizaje de los riesgos..................................................................230
xiv
CAPITULO I INTRODUCCIÓN
1
1. INTRODUCCIÓN
1.1 INTRODUCCIÓN
El desafío para lograr organizaciones eficientes y gerentes exitosos en el mundo,
demanda que se tome en serio la culminación de los proyectos emprendidos y la
validación de sus resultados.
Aumentar al máximo el valor de la tecnología y la información para la empresa de tal
forma que le permita agregar valor a los clientes debería ser el objetivo principal de
los proyectos en el área de tecnología informática. Pero por lo general se ha
encontrado que los proyectos de tecnología informática siempre se demoran y
cuestan mucho más de lo que originalmente se tenia presupuestado, y sin obtener
todos los resultados fijados desde el principio (según estudios de
www.standishgroup.com/chaos,2000).
Para enfrentar con éxito este desafió y lograr un manejo eficaz de los proyectos
se propone el uso de las nuevas técnicas y prácticas metodológícas en gestión
de proyectos.
En particular, en este trabajo se desarrollo un modelo de gestión de proyectos de
tecnología informática práctico y flexible, en el que se incorporó una metodología
y las mejores prácticas modernas a nivel mundial para el manejo eficaz de los
proyectos de TI, los conocimientos académicos, la experiencia de la empresa y
dos empresas mas del Grupo Empresarial Antioqueño (GEA) en este tipo de
proyectos, pero contextualizados perfectamente dentro de las características
organizacionales particulares de la empresa. Dado que las metodologías que
existen en este ámbito tienen un carácter genérico y estándar, éstas no
2
contemplan dichas características y este aspecto es muy importante para lograr
mayor éxito en la implementación de estas metodologías y de los proyectos.
En este trabajo se partió de un estudio e investigación sobre las metodologías
más importantes relacionadas con el tema de gestión de proyectos, se revisó la
problemática en torno a proyectos de TI, especialmente en la respuesta a la
pregunta ¿Por qué terminan con demoras, exceden el presupuesto y no satisfacen
las necesidades de los usuarios y del negocio (no son exitosos) los proyectos de
TI?. Se estudio e investigo sobre las diferentes propuestas de mejoramiento a esta
problemática como también toda la bibliografía y estudios más importantes sobre
el tema. Se analizó todo el proceso de gestión de proyectos de TI que se lleva
actualmente en la empresa, se analizaron las características organizacionales, se
realizó un estudio de los modelos de gestión de proyectos de dos de las empresas
que pertenecen al denominado Grupo Empresarial Antioqueño (GEA) y teniendo
en cuenta todos estos elementos, se planteó un modelo de gestión de proyectos
practico, flexible y especifico a las necesidades de la empresa.
1.2 DESCRIPCIÓN DE LA COMPOSICIÓN DEL TRABAJO En el capítulo II se establecen los Conceptos Básicos, describiendo brevemente
los conceptos de la de Gerencia de proyectos de TI y el alcance de la gerencia de
proyectos en la organización.
En el capítulo III se presentan los antecedentes de la gerencia de proyectos,
particularmente su historia, el presente, y algunas estadísticas importantes sobre
la problemática en este campo.
En el capitulo IV se detallan el proceso y los resultados de la investigación sobre
las causas del fracaso de los proyectos de Tecnología e Información (TI).
3
En el capítulo V se presenta el Marco General para el desarrollo del Modelo de
Gestión de proyectos de Tecnología e Información (TI). Se presenta el enfoque de
los proyectos en las organizaciones y después se aborda una breve descripción
de la metodología del PMI (Project Management Institute) y el MSF (Microsoft
Solution Framework), las cuales son la base del desarrollo del Modelo de Gestión
de proyectos que se propone.
En el capítulo VI se presenta el Modelo de Gestión de proyectos de Tecnología e
Información (TI) propuesto.
En el capítulo VII se describe el Modelo de Gestión de proyectos de Tecnología e
Información (TI) y su práctica en términos de lo procesos que la componen. Para
que sirva como una guía se realiza una descripción del objetivo, las actividades a
desarrollar, las entradas y las salidas. Métricas, participantes involucrados,
mejores prácticas en la elaboración de de cada una de las fases y las técnicas y
herramientas recomendadas.
En el capitulo VIII se presenta la información básica de la disciplina de
administración de riesgos que describe los principios, conceptos, consejos, así
como un proceso dividido en seis etapas para conseguir administrar con éxito los
riesgos de los proyectos de TI. Se utilizo la disciplina de administración de riesgos
de MSF que se basa en el conocido modelo de proceso ininterrumpido de
administración de riesgos de Software Engineering Institute (SEI) para evaluar el
riesgo de los proyectos técnicos.
En el capitulo IX se presentan las conclusiones y algunas recomendaciones
derivadas del trabajo realizado.
4
CAPITULO II CONCEPTOS BÁSICOS DE LA
GERENCIA DE PROYECTOS DE TI
5
2. CONCEPTOS BÁSICOS DE LA GERENCIA DE PROYECTOS DE TI
En el presente capítulo se establecen los Conceptos Básicos, describiendo
brevemente los conceptos de los proyectos en general, los proyectos de TI y de
la Gerencia de Proyectos, presentando además el alcance de la gerencia de
proyectos en la organización.
Es importante establecer estos Conceptos Básicos porque permitirán una mejor
comprensión de los diferentes planteamientos y resultados de esta investigación.
2.1 ¿QUÉ ES UN PROYECTO? Según el PMI: “Las organizaciones ejecutan trabajos. El trabajo generalmente
involucra tanto operaciones como proyectos, aun cuando ambos puedan
superponerse. Las operaciones y los proyectos comparten muchas características;
por ejemplo, son:
• Realizados por personas
• Restringidos por recursos limitados
• Planificados, ejecutados y controlados
Operaciones y proyectos difieren primordialmente en que las operaciones son
continuas y repetitivas, mientras que los proyectos son Temporario (temporales) y
únicos.
Temporario significa que cada proyecto tiene un comienzo definido y un final
definido. ”
6
2.2 DEFINICIÓN DE PROYECTO Existen diferentes definiciones y alcance de lo que un proyecto representa. En
este documento se hace referencia a proyectos que se enmarcan dentro de las
siguientes características1 :
o Los proyectos son actividades dirigidas a alcanzar un resultado específico.
o Los proyectos implican un empeño coordinado de actividades
interrelacionadas.
o Tienen una duración limitada – un comienzo y un final.
o Cada proyecto es único (Algo que no ha sido hecho antes).
Considerado dentro del marco de un proceso de planificación, se entiende por
proyecto toda “unidad de actividad que permite materializar un plan de desarrollo”.
Caben en este concepto tanto aquellas acciones en que prevalece la importancia
de la inversión fija (industria, carreteras, puertos, etc.), como aquella en que lo
fundamental son aspectos de organización y tecnología (crédito agrícola, centros
de extensión e investigación agrícola, campañas sanitarias, investigación de
recursos naturales)
2.3 LOS PROYECTOS DE TI Los proyectos son críticos para el éxito de cualquier organización, el
reconocimiento de esta criticidad esta haciendo que la gerencia de proyectos se
convierta en el punto focal de mejoramiento en las empresas. Los proyectos de TI
corresponden a una categoría más dentro del gran abanico de proyectos diversos
que se pueden llevar a cabo y para los cuales aplican las mismas disciplinas y
áreas de conocimiento que se aplican a los otros tipos de proyectos.
1 MONTES, Gonzalo, Metodología PMI® complementada para gestionar proyectos de desarrollo de software y de implantación de aplicaciones de alto impacto en las organizaciones, ACIS, Bogota, Noviembre de 2002; p. 1-29
7
Para los proyectos de tecnología se tienen los aspectos definidos en la sección 2.2
y además:
o Son proyectos cuyo producto o servicio final es tecnología de información (TI).
o Tienen asociado un mayor riesgo.
2.4 FACTORES CRÍTICOS DE ÉXITO DE LOS PROYECTOS
Lo que hoy en día se conoce como Factores Críticos de Éxito (FCE), están
expresados en términos de alcance, tiempo y costo.
El alcance se refiere a hacer aquello a lo que nos hemos comprometido, y que
debe estar ratificado en los documentos dispuestos para ello desde el inicio del
proyecto mismo (Project Charter, Project Plan, Project Definition).
El factor tiempo tiene que ver con todos los procesos requeridos para asegurar la
terminación del proyecto, dentro del cronograma inicialmente estimado.
Y, por último el factor costo, dentro del cual se contemplan los procesos
necesarios para que el proyecto logre sus objetivos dentro del presupuesto
estimado.
Sin embargo, hay un elemento adicional que cada vez toma más fuerza y que se
debe observar si se quiere tener éxito no sólo en el proyecto actual, sino pensando
en proyectos y relaciones de negocios a largo plazo. Este elemento tiene que ver
con el Manejo de Expectativas (ME).
En la actualidad, las decisiones de tecnología dentro de la organización, ocupan
un espectro más amplio dentro del negocio y por lo tanto hay más individuos
involucrados.
8
Al intervenir más personas en la decisión se deben manejar más expectativas y
esto resulta complejo, dadas las diferentes necesidades y objetivos que cada uno
espera satisfacer con los resultados del proyecto.
2.5 PROGRAMA Es un grupo de proyectos dirigidos de manera coordinada para obtener unos
beneficios que no se podrían obtener dirigiéndolos individualmente
2.6 PORTAFOLIO DE PROYECTOS Agregado de proyectos, que en su conjunto constituye la estrategia de inversión
de la organización
2.7 GERENCIA DE PORTAFOLIO Es la forma consistente de evaluar, seleccionar, priorizar, presupuestar y planificar
los proyectos que ofrecen mayor valor y contribución a los intereses estratégicos
de la organización
2.8 GERENCIA DE PROYECTOS Aunque existen muchas definiciones tomaremos las siguientes:
• “La Gerencia de Proyectos es la aplicación de conocimientos, habilidades,
herramientas y técnicas a una serie de actividades de un proyecto para
cumplir con los requerimientos del proyecto. La gerencia de proyectos se
9
alcanza a través del uso de procesos tales como: Creación, planeación,
ejecución, control y cierre.” 2
• “La Gerencia de proyectos es la aplicación de los principios de la
administración para planear, organizar, asignar, controlar y dirigir recursos de
una organización en pro de un objetivo temporal.” Thomas C Belanger,
Successfull Project Management, 1988
• “La gerencia de Proyectos es el arte y la ciencia de administrar esfuerzos de
corto tiempo, con un inicio y un final definidos, un presupuesto especifico y con
unos criterios de desempeño definidos.” James Taylor, A Survival Guide for
Project Managers
2.9 EXCELENCIA EN GERENCIA DE PROYECTOS
Organizaciones excelentes en gerencia de proyectos crean un ambiente en el cual
existe un flujo continuo de proyectos gerenciandos exitosamente, donde el éxito se
mide a través del logro del desempeño que representa el mejor beneficio para la
empresa como un todo así como para un proyecto específico. H. Kerzner
2.10 OBJETIVOS DEL PROYECTO Los Objetivos de un proyecto son el logro de los resultados planteados para el
proyecto y la culminación o cierre del mismo. Los objetivos están siempre
enmarcados en una relación triangular de las variables Plazo, Costo, Calidad.
Estas variables estarán presionadas por cada uno de los interesados en el
proyecto. Por lo tanto el objetivo del proyecto es siempre triple.
2 (PMBOK Guide 2000 Edition)
10
Figura 1. Aspecto triangular de los objetivos
Fuente: PMBOK Guide. 2000.
2.11 El CONTEXTO DE LA GERENCIA DE PROYECTOS
Los proyectos y la gerencia de proyectos operan dentro de un contexto más
grande que el proyecto en sí. Los administradores de proyectos deben entender
este contexto más amplio, porque si bien la administración del día a día del
proyecto es necesaria para lograr llevarlo a feliz término, esto no es suficiente para
lograrlo.
Según el PMI, los proyectos y la gerencia de proyectos de mueve en el siguiente
contexto:
2.11.1 Fases y ciclo de vida de los proyectos. Dado que los proyectos son
tareas únicas, estos envuelven un grado de incertidumbre, por lo tanto en la
11
ejecución de los proyectos en las empresas, estas dividen los proyectos en fases
para mejorar el control y su ejecución. En conjunto las fases de un proyecto son
consideradas como el ciclo de vida del proyecto.
El término Ciclo de vida del proyecto señala las diferentes etapas que recorre el
proyecto desde que se concibe la idea hasta que se materializa en una obra o
acción concreta.
Cada fase de un proyecto esta delimitada por unos entregables, estos son
productos verificables y tangibles, tales como el estudio de factibilidad, el diseño
detallado, el prototipo. La culminación de una fase de un proyecto, esta
generalmente marcada por una revisión de los entregables claves y las fechas de
culminación para:
a) Determinar si el proyecto debe continuar a su fase siguiente
b) Detectar y corregir costosos errores
El ciclo de vida del proyecto sirve para definir el comienzo y el final del mismo.
Ejemplo: Figura 2. Fases de un proyecto
12
Fuente: De la Teoría a la Práctica: Un enfoque de Gerencia de Proyectos que
Funciona. Rodolfo Ambriz, PMP.
2.11.2 Agentes interesadas con el proyecto (stakeholders del proyecto). Los
stakeholders son personas y organizaciones que están activamente envueltas o
interesadas en el proyecto o cuyos intereses pueden ser positivamente o
negativamente afectados como consecuencia de la ejecución o culminación del
proyecto.
El equipo administrador de un proyecto debe identificar los StakeHolders,
determinar sus requerimientos y entonces administrar e influenciar estos
requerimientos para asegurar un proyecto exitoso.
2.12 CLASIFICACIÓN DE LOS PROYECTOS DE TI.
Para agrupar los proyectos de tecnología de información se utilizará la siguiente
clasificación: o Incorporación de infraestructura. Están relacionados con equipos de
cómputo, redes, centros de cómputo, cableados, sistemas operaciones, bases
de datos y en general software operativo.
o Incorporación de paquetes de software. Están relacionados con
aplicaciones predefinidas y preconstruidas para mejorar la productividad de
áreas de la empresa.
o Incorporación de aplicaciones complejas y ajustadas. Están relacionados
con aplicaciones de alta dificultad en su implementación, que tienen un alcance
corporativo y que por lo general requieren configurarlas de acuerdo con las
necesidades propias de la empresa. El ejemplo son las denominadas
13
aplicaciones de misión crítica tales como software para manejar el sistema
bancario en todas las sucursales de un banco, aplicaciones ERP (enterprise
resource planning) para manejar todos los procesos administrativos y
financieros de una empresa, aplicaciones para facturación masiva en
empresas particulares o públicas, etc. Este tipo de proyectos tienen dificultades
inmensas desde las ópticas de administración del cambio, impacto
organizacional, cambio de la manera como se hacen las actividades en la
empresa, etc., retos que los gerentes y el equipo de proyectos deben afrontar
decididamente mediante una efectiva gestión.
o Desarrollos de software. Relacionados con desarrollo de aplicaciones
hechas a la medida específica de las necesidades de la empresa. Requieren
de desarrollo de código en algún lenguaje de programación. Este tipo de
desarrollos pueden ser sencillos en el sentido que impactan a pequeñas áreas
o grupos dentro de las organizaciones, pero también pueden ser altamente
complejos en el sentido del impacto descrito en el punto anterior. (Nota: esta
última clasificación no hace parte del alcance de esta
investigación)
14
CAPITULO III ANTECEDENTES DE LA GERENCIA
DE PROYECTOS
15
3. ANTECEDENTES DE LA GERENCIA DE PROYECTOS
3.1 HISTORIA Tomado de la tesis doctoral “Modelo estratégico para la gestión de proyectos de carácter único.” 3 Buscando lo antecedentes históricos de la gerencia de proyectos se encuentra
que los egipcios, 3000 años a.c. fueron capaces de colocar 2.300.000 bloques de
piedras de entre 2 a 70 tn. cada una, construyendo pirámides, moviendo varios
cientos de miles de personas, etc., con lo cual ya se supone se estaban
gestionando proyectos y de gran envergadura. En realidad se puede seguir
extrapolando esta consideración en otras muchas fases de la historia en diferentes
países y civilizaciones; pero no se sabe con certeza de que esa “gestión” pudiera
llevar involucrados aspectos que en la terminología de hoy en día se consideran
claves para hablar de gestión como es el de la minimización de recursos, el control
del plazo, etc.
De hecho, se debe reconocer que la “gestión de proyectos” siempre ha
contemplado diferentes formas de resolución a lo largo de la historia; pero
probablemente, el hecho de analizar el objeto del problema, la situación existente
o los métodos ha seguir; estos conceptos, empezaron a plantearse en esos
términos, justo después de la II Guerra Mundial (Morris and Hough 1987)4, pero
fue ya en la década de los 50 cuando, según indica Harvey Maylon (1996), se
3 SERER FIGUEROA, Marcos. Modelo estratégico (sm) para la gestión de proyectos de carácter único. Tesis Doctoral,Barcelona. pp 538, Junio 2004. 4 Morris, P. W. G. (2001). Updating the project management bodies of knowledge. Project management journal. V 32, 3. 23 a 29.
16
empieza a elaborar alguna metodología que podríamos reconocer como “gestión
de proyectos”.
Un poco antes, durante la I Guerra Mundial apareció el diagrama Gantt como
antesala de los instrumentos de planificación que recibieron un soporte
metodológico con la utilización, 30 años más tarde, de los “diagramas de proceso”.
Fue en esos años, cuando las técnicas que se estaban utilizando para “gestionar”
obras de edificación o construcción en general” – proyectos de carácter único, se
empezaron a utilizar en las fábricas con elementos no constructivos o producidos
en serie –proyectos de carácter continuo. Ese hecho permitió un mayor desarrollo
de las técnicas de gestión.
Siguiendo el hilo de los antecedentes históricos, en la referida década de los 50, el
tamaño y complejidad de los proyectos fundamentalmente en los sectores de
armamento y naval que producían enormes desfases de presupuesto y plazo de
entrega forzaron al desarrollo de dos herramientas de control: por un lado el
Departamento Naval de los Estados Unidos en 1958 desarrollo el PERT5. Y por
otro lado la Dupont Corporation, el método del camino crítico (CPM)6. Ambos
instrumentos permitían programar, planificar y controlar grandes proyectos. Diez
años más tarde (John M. Nicholas), estos métodos fueron completados con
introducción del GERT método que utilizaba la simulación por computador.
Y ya a partir de 1960 y sobre todo en la década de los 70, en el seno de las
industrias de proceso, de construcción y sobre todo en el comentado
Departamento de Defensa de los Estados Unidos de América, y en especial en los
sectores aerospaciales, fue donde empezó a desarrollarse el concepto de la
gestión, aunque rápidamente, se extendió a otras organizaciones oficiales tales
como el World Bank o la CIDA (Canadian Internacional Development Agency),
5 Ver PMBOK Guide y Anexo1, para su definición y detalle 6 Es CPM de un proyecto es la sucesión de actividades que dan lugar al máximo tiempo acumulativo.
17
englobando el conjunto de técnicas utilizadas con el nombre de “Project
Management”, y que en esta tesis se define en su traducción, a nuestro entender,
como “gerencia de proyectos o gestión integrada de proyectos”. Las primeras
formulaciones consistían en un conjunto de políticas, procedimientos y prácticas
útiles para conseguir mayores rendimientos en el cumplimiento de determinados
objetivos.
En especial se distinguía el análisis inicial costo-beneficio durante las primeras
fases del proyecto cuando se estudiaba el alcance socio-económico del conflicto.
Esta visión, sin embargo fue superada cuando con el transcurso del tiempo,
diferentes profesionales, desde diversos sectores llegaron a la edición del PMBOK
Guide, estandarte del Project Management Institute, autentica base para el
desarrollo de la Gestión Integrada de Proyectos, y que se organizaba alrededor
del célebre trío: costo-plazo-calidad.
En los últimos años, sin embargo, han ido apareciendo otros conceptos que tratan
de llenar vacíos de investigación y de acción, alrededor del planteamiento,
fundamentalmente económico de la operación de un proyecto (Hastings, 1992;
Fiedler, Rabl &Weidinger, 1994;Giard & Midler, 1993; Turner, McLaughlin,
Thomas& Hastings, 1994 Jolivet, 1995), estableciéndose conceptos tales como
ingeniería concurrente, ingeniería inversa, cronocompetición, costo-objetivo. etc.
3.2 EL PRESENTE Muchas personas y empresas tienen hoy un renovado interés en la gerencia o
gestión integrada de proyectos. Hasta 1980, la gerencia de proyectos estaba
principalmente enfocada en proveer datos sobre el plan de trabajo y la asignación
de recursos para el gerente del proyecto. Esta información de seguimiento aun
18
sigue siendo un punto clave en la gerencia de proyectos, pero hoy en día esta
involucra muchos más aspectos.
Desde finales de los 90s, el mundo se ha vuelto más complejo. Hoy las nuevas
tecnologías se han convertido en un factor crítico para los negocios,
computadores, hardware, software y las redes como Internet, así como la
creación de equipos de trabajo interdisciplinarios han cambiado radicalmente el
ambiente de trabajo. Estos cambios han creado la necesidad de realizar una mejor
y más sofisticada gestión de los proyectos. Hoy en día las empresas están
reconociendo, que para ser exitosas, necesitan aprender, desarrollar y usar
técnicas modernas de gerencia de proyectos. (Information Technolgy Project
Management, kathy Schwalbe). (el término gerencia o gestión se usa en este
documento indistintamente).
Los continuos avances en la tecnología permiten que los sistemas informáticos
sean desarrollados con mayor rapidez y con mayor complejidad para satisfacer las
necesidades del entorno de negocios de hoy, los cuales se mueven con celeridad
y sofisticación. Esto inevitablemente produce riesgos en los proyectos de TI y
requiere acciones oportunas para evitar demoras o perjuicios económicos. Sin
embargo, a pesar de conocerse los riesgos, los proyectos de tecnología
informática (TI), especialmente la implementación de nuevos sistemas, continúan
siendo terminados con demora, exceden el presupuesto y no satisfacen las
necesidades de los usuarios y del negocio7.
3.3 ALGUNAS ESTADÍSTICAS Según datos de la Standish Group8 sobre el Desempeño de los Proyectos de TI
Iberoamérica, el 23% de los proyectos son cancelados antes de ser completados,
7 (Fuente: www.kpmg.com.ar) 8 The Chaos Report 1994 y 1999
19
el 62% de los proyectos tienen desviaciones de tiempo, costo y/o funcionalidad y
solo el 15% de los proyectos son completados según el plan. La desviación
promedio de tiempo es de 143% y La desviación promedio de presupuesto es de
117%.
Otros datos de la Standish Group9, muestran que sólo en el orden del 28% de los
proyectos finalizan obteniendo el objetivo planteado, en el tiempo y con los
recursos estimados. Esta problemática se da en todo tipo de proyectos, y está
particularmente acentuada en proyectos tecnológicos.
Figura 3. Datos de la Standish Group.
9 The Chaos Report 1994,1999
Completados Con Problemas Fracasados
31%
53%
16%
20
Fuente: The Chaos Report
A nivel mundial si tienen los siguientes datos comparativos entre 1995 y el 2001.
Tabla 1. Desempeño de los Proyectos de TI
1995 2001
Proyectos cancelados antes de ser completados 31% 23%
Tienen desviaciones 53% 49%
Son terminados según plan 16% 28%
Con Desviación de Tiempo 222% 63%
Con Desviación de Presupuesto. 189% 45%
Fuente: Standish Group10
Como se puede observar en este cuadro comparativo, en los últimos años se ha
mejorado el desempeño del los proyectos de TI, y si bien aun falta mucho para
lograr niveles de excelencia, lo importante de esta información es que muestra una
tendencia positiva en la superación o mejora de las deficiencias en la gestión de
proyectos. Estas mejoras son atribuibles11 en gran medida a los avances en el
tema y a las mejoras en las metodologías, así como a la conciencia creada en las
empresas sobre la incorporación de estas técnicas y metodologías y también a 10 Chaos Report 1994 , 1999 y 2001 11 Piorun, Daniel, experto en el tema de proyectos, consultor del Banco Mundial, BID, PNUD y autor del libro LIDERANDO PROYECTOS, Argentina,Ediciones Macchi.
21
la creación de una cultura de proyectos y al desarrollo de competencias sobre
este tema en las empresas.
3.4 ¿PORQUÉ FALLAN LOS PROYECTOS DE TI? En varios estudios del Grupo Standish estableció las siguientes causas mayores
para el fracaso de los proyectos12:
1. Planificación deficiente
2. Definición escasa de especificaciones
3. Falta de participación de usuarios
4. Cambios del alcance
5. Falta de apoyo ejecutivo
6. Expectativas irreales
7. Objetivos poco claros
8. Plazos de tiempo irreales
9. “Deadlines”(Tiempos de entrega) innecesarios
10. Problemas de comunicación
3.5 ALGUNAS CAUSAS DEL PROBLEMA
• Escasa cultura de Gerencia de Proyectos
• “La dinámica del negocio no admite planificación y control”
• Resistencia a la adopción de nuevas metodologías
• Se suele ignorar el contexto del proyecto
• No se analizan los proyectos fallidos
• Selección inadecuada del Gerente de proyecto
12 Piorun, Daniel, experto en el tema de proyectos, consultor del Banco Mundial, BID, PNUD y autor del libro LIDERANDO PROYECTOS, Argentina, Ediciones Macchi.
22
3.6 LAS METODOLOGÍAS
Teniendo como base la información consultada hasta el momento sobre las
metodologías de gerencia de proyectos se puede percibir que estas son un
elemento importante dentro de esta disciplina. Se identifica que estas han
avanzado y están ayudando a incrementar el desempeño exitoso de los proyectos,
sin embargo se encuentra también su utilización no es tan rigurosa ni tan común y
que por lo tanto aun falta mucho para convertirse en una practica generalizada
dentro de los proyectos de TI objeto de esta estudio. Precisamente uno de los
motivos que originan fracasos en el cumplimiento de los proyectos se encuentra
en la No utilización, o mala utilización de metodologías de trabajo13. Esto tiene
además una complejidad mayor y es que aun en el caso de adoptar alguna de las
metodologías, así esta sea una de las mas aceptadas a nivel internacional para la
gestión de proyectos en una empresa como lo es el PMI o PRINCE, el proceso no
es tan sencillo, puesto que se ha encuentra que por el carácter general y
estándar de estas guías, las características organizacionales no son contempladas
y este aspecto es muy importante para lograr mayor éxito en los proyectos y en la
implementación de la metodología14.Como analogía y para colocarlo en términos
mas censillos lo que sugiere esta anotación es que debemos localizar o adecuar
estas metodologías (cualquiera que sea) a la forma de trabajo de nuestras
empresas, pues si bien estas metodologías son unos modelos guía muy
generales, sobre el qué se debe hacer en el desarrollo y gerencia de los
proyectos, estas no desarrollan el cómo en un gran detalle y menos aun en los
13 Piorun, Daniel, experto en el tema de proyectos, consultor del Banco Mundial, BID, PNUD y autor del libro LIDERANDO PROYECTOS, Argentina, Ediciones Macchi. 14 MONTES, Gonzalo, Metodología PMI® complementada para gestionar proyectos de desarrollo de software y de implantación de aplicaciones de alto impacto en las organizaciones, ACIS, Bogota, Noviembre de 2002; p. 1-29
23
proyectos tan específicos como los de TI. Es muy claro que la cultura Americana
y la Colombiana ,por citar sólo un caso , no son iguales en cuanto a la forma de
trabajar e interactuar, claramente los latinos no tenemos la rigurosidad o la
disciplina de los Americanos. Es por esto que para el autor de esta tesis es
importante y le parece pertinente el planteamiento y aporte de Gonzalo Montes
en su documento15sobre la importancia de tener en cuenta las características
organizacionales en los proyectos , buscando con esto tener más éxito en el
desarrollo de estos. Los aspectos que se propone por lo tanto tener muy
presentes en los proyectos de TI son:
1. Los proyectos de tecnología de información de alta complejidad impactan en
forma directa los procesos vigentes y por tanto la manera como los grupos
humanos hacen las tareas dentro de la empresa.
2. La cultura organizacional de las empresas tiene una influencia directa en el
desarrollo y los resultados del proyecto de tecnología de información.
3. El equipo de proyecto y su líder formal, el gerente de proyecto, juegan un papel
decisivo en el desarrollo de cada una de las fases del proyecto.
4. La formación académica, la experiencia de los miembros del equipo de
proyecto y sus interrelaciones influyen notablemente en el éxito relativo del
proyecto.
Adicionalmente se encuentran los siguientes datos que ayudan a sustentar y
entender la importancia de las metodologías en el éxito de los proyectos y de sus
deficiencias.
Los tres factores que más contribuyen al éxito de un proyecto (según The Standish
Group Internacional 1998) son:
15 MONTES, Gonzalo, Metodología PMI® complementada para gestionar proyectos de desarrollo de software y de implantación de aplicaciones de alto impacto en las organizaciones, ACIS, Bogota, Noviembre de 2002; p. 1-29
24
• Involucramiento del usuario
• Soporte ejecutivo
• Claro establecimiento de los objetivos del negocio y del proyecto
Según el articulo: “¿Por qué fracasan los proyectos?” escrito por Daniel Piorun16,
estos 3 factores representan el 50% de oportunidades de éxito. La incorporación
de un gerente de proyectos experimentado eleva la probabilidad de éxito al 65%.
El no contar por parte de la las metodologías con las aproximaciones, los
métodos y las estrategias que se deberían emplear para adaptarlas teniendo
presente las características organizaciones particulares de cada empresa, aspecto
que afecta el éxito de los proyectos (entendido el éxito como la terminación en
los tiempos estipulados sin exceder el presupuesto, bajo los parámetros de
calidad definidos y satisfaciendo las necesidades de los usuarios y del negocio),
se crea la necesidad desarrollar un modelo de gestión de proyectos de TI
adaptado las características de la empresa, que permita mejorar estas deficiencias
y en este mismo orden conducir a proyectos mas exitosos.
3.7 IMPORTANCIA DE LOS MOTIVOS QUE GENERAN FRACASOS EN LOS PROYECTOS DE TI
El 72% de proyectos no se logran terminar como se planeo (Según el dato de la
Standish Group) - por diferentes motivos - Esto genera un aumento de costos
directos (en los casos que los proyectos finalicen con mayores recursos que los
previstos) e indirectos por la NO disponibilidad de los beneficios o servicios
previstos que brindaría dicho proyecto si hubiera finalizado en tiempo y forma.
Esto fundamentalmente impacta en una baja de productividad de algún área de la
organización y en un costo de oportunidad al no disponer de un resultado que 16 PIORUN, Daniel,¿Por qué fracasan los proyectos? , http://www.degerencia.com/ , Argentina ,17 de abril-07-2003.
25
seguramente será un eslabón importante para la cadena de factores críticos de
éxito previstos en la estrategia global de la empresa.
Esto nos lleva a darle una importancia superior a los motivos que generan estos
fracasos y desarrollar lineamientos para corregirlos. Particularmente, en la
compañía objeto de este estudio17 y dada la situación de los últimos años,
muchos proyectos de TI han seguido la misma suerte que la estadística general.
Según el Licenciado Daniel Piorun18, en un estudio realizado hacia finales del
2001 con unos 50 responsables de proyectos, permitió detectar diversos factores
que entorpecen el camino de un proyecto y que se analizan en el libro "Liderando
Proyectos", a continuación se describen:
Motivos que originan fracasos en el cumplimiento de los proyectos:
• 21 % cambios en los objetivos definidos a nivel estratégico 19
• 31 % no utilización, o mala utilización de metodologías de trabajo
• 48 % problemas humanos, de conducción, comunicación y conflictos entre
la gente
Esta información además nos complementa y apoya el tema de las metodologías
al cual nos referimos en el ítem anterior (sobre las metodologías). También se
puede agregar basado en la experiencia del investigador y la información
encontrada, que en nuestro país y especialmente en las empresas objeto de esta
investigación , organizaciones pequeñas y medianas, la utilización de
metodologías brilla por su ausencia, y en las organizaciones grandes es muy
17 Por razones de confidencialidad se omite el nombre de la compañía 18 Piorun, Daniel, experto en el tema de proyectos, consultor del Banco Mundial, BID, PNUD y autor del libro LIDERANDO PROYECTOS, Argentina, Ediciones Macchi.
19 Con relación al ítem de cambios en los objetivos, el mismo es responsabilidad de las máximas autoridades
de la organización. Por lo que no se profundizará sobre este aspecto.
26
frecuente que exista y en general se trabaje con estas, pero son muchos los
casos en los cuales - en general por falta de tiempo la metodología termina
siendo utilizada como una disimulo formal para el cumplimiento de normas y
etapas y no como lo que verdaderamente es, el eje del proyecto tomando el
contenido de la metodología y no solo la forma. Aunque existen también otros
inconvenientes por la falta de flexibilidad de las metodologías y porque son muy
complejas e imprácticas en muchos ámbitos.
Se encuentra y reafirma en esta investigación que uno de los puntos en los
cuales es muy poca la utilización de metodologías y técnicas, es en el diseño de la
estructura de trabajo un proyecto (WBS) y en la estimación de los esfuerzos y
tiempos requeridos en un proyecto. Si bien esta temática es muy clara en algunas
especialidades tales como los proyectos de construcción, donde el tamaño de una
casa se mide en metros cuadrados cubiertos, a partir de los cuales existen tablas
donde para un estándar de calidad determinado se establece el costo de
construcción, tiempos y esfuerzos asociados, particularmente en los proyectos de
TI esta temática es difícil y mas compleja debido a que la creatividad y la
productividad de las personas que desarrollan este tipo de proyectos varia entre
los diferentes equipos de trabajo y en cada organización, además cada proyecto
es único. Por lo que es sumamente importante que se desarrollen métodos en
cada organización que ayuden a medir el tamaño del proyecto y también el
disponer de estándares propios sobre la productividad, los esfuerzos y tiempos de
actividades similares y comparables, que permitan tener puntos de referencia y
comparación para realizar estimaciones mas ajustadas y realistas. Esta es una
problemática no solo de las empresas objeto de este estudio, sino que es objeto
de trabajo e investigación de organismos internacionales como la IEEE (Institute
of Electrical and Electronics Engineers), el SEI (The Software Engineering
Institute), por mencionar algunos. Es importante resaltar que este es un tema
fundamental y de mucha mas relevancia para proyectos de desarrollo de
27
software, aunque este tipo de proyectos no esta dentro del alcance de este
trabajo.
Respecto a los problemas humanos, el tema es muy crítico según se indica en el
porcentaje obtenido, un 48%. Es por esto que adicional a la incorporación de
metodologías en la gerencia de proyectos, el aspecto humano juega un papel
preponderante para el logro de los objetivos del proyecto, lo que sitúa al líder o
gerente del proyecto en una posición muy compleja, pues debe negociar y
balancear las presiones de las personas que le asignaron el proyecto con las
presiones de su equipo de trabajo que no puede acortar los tiempos que la
realidad les impone. Lo que le implica un desarrollo de habilidades muy especiales
y necesarias en este campo.
Las Naciones Unidas, particularmente la CEPAL, el ILPES, la ONUDI y el Banco
Mundial, han sido las entidades que desde el decenio de 1950 se han preocupado
por llevar al ámbito de los proyectos principios y metodologías para su mejor
gestión.
También existen varios libros con aportes muy grandes en cuanto a conceptos,
metodología, mejores prácticas y herramientas sobre gestión de proyectos,
escritos por expertos internacionales como por expertos en el tema en nuestro
país, como es el caso del libro escrito por Juan José Miranda Miranda, “Gestión de
proyectos” 20Identificación, Formulación, Evaluación Financiera, Económica, Social,
Ambiental.
En este libro se plantean nuevos conceptos y metodologías sobre el manejo
eficiente de los proyectos en general y recoge una gran experiencia, con el fin de
que los proyectos sean evaluados e implementados dentro de los parámetros de
tiempo, costo y calidad, también pretende mejorar la cultura de proyectos en el
20 MIRANDA MIRANDA, Juan José, Gestión de Proyectos, Bogota, MM Editores, 2000
28
país y en las organizaciones. Los conceptos y metodologías se trabajan bajo lo
que se denomina el “CICLO DEL PROYECTO“, que señala las diferentes etapas
que recorre un proyecto desde que se concibe la idea hasta que se materializa en
una obra o acción completa, esta etapas son a la luz de este libro: la pre-
inversión, la inversión o ejecución ,la etapa de funcionamiento u operación y
la evaluación ex-post. Aunque las tres primeras etapas son muy comunes y de
una conocimiento, aceptación y aplicación de manera generalizada, encuentro
que la evaluación ex -post , la cual es una evaluación posterior a la entrega en
funcionamiento u operación del proyecto , no es muy usada por así decirlo, en
especial en los proyectos de TI. Porque si bien se logran culminar los entregables
del proyecto y dejarlos en operación para el beneficio de la empresa, en la
experiencia del investigador, casi nunca de evalúa un tiempo después si los
planteamientos iniciales de sustentación y beneficios con los que se diseño y
vendió el proyecto, realmente fueron alcanzados. Es por esto que me parece de
gran importancia este libro, que si bien tiene un enfoque para proyectos de
carácter social, no deja de se válido y un punto importante en los proyectos de TI,
que de desarrollan en las empresas.
Igualmente existen varias metodologías creadas por organizaciones dedicadas a
la investigación y desarrollo en este tema, como la metodología de gestión de
proyectos (GP) PMI (Project Managment Institute). La propuesta metodológica del
PMI cubre 9 áreas del conocimiento asociadas a la gestión de proyectos:
Integración, Alcance, Tiempo, Costos, Calidad, Recursos Humanos,
Comunicación, Riesgo, Adquisiciones.
Esta metodología goza de gran aceptación por parte de toda la comunidad
internacional dedicada a este tema ya que por su profundidad y coherencia se ha
convertido en un estándar ampliamente utilizado en todo el mundo. Actualmente
esta guía es reconocida por ANSI e ISO como un estándar para la gestión de
29
proyectos siendo utilizada por más de 100,000 profesionales certificados por PMI
en todo el mundo.
Otra metodología estructurada para todo tipo de proyectos ampliamente difundida
y de gran aceptación es la llama PRINCE (Proyects IN Controlled Environments),
que actualmente se encuentra en su versión 2 PRINCE2, esta metodología
nació del gobierno británico y ha sido adoptada principalmente en los países
europeos, muy poco en América. Al igual que el PMI, es una guía genérica para la
gerencia efectiva de los proyectos, que genera un marco de referencia sobre el
que se debe hacer pero poco concreto sobre el como realizarlo. Al igual que el
PMI, define claramente áreas de conocimiento, procesos y herramientas
asociadas, que son en muchos aspectos muy parecidas y en otros casos hasta
complementarias para cada una de las fases en el ciclo de vida de los proyectos.
Como un punto muy valioso para esta investigación es el hecho de que el manejo
de los riesgos en el proyectos en la metodología PRINCE tiene un valor
preponderante y una atención especial y es de resaltar como aporte ya que los
proyectos de TI objeto de esta investigación tienen esta gran característica o
diferencia con los de otro tipo. Esto se debe principalmente a que el componente
tecnológico hace que estos tengan unos mayores niveles de riesgo de no culminar
con éxito.
Es importante también mencionar que existen un gran número de metodologías, la
mayoría propias de grandes empresas, como IBM, Oracle, NCR, Getronics,
Microsoft, por mencionar algunas, que son muy válidas y que incorporan grandes
experiencias y mejores prácticas. Lamentablemente estas no son de dominio
público, sino que son de carácter confidencial porque incorporan muchos de los
conocimientos que hacen competitivas a esta empresas y por el cual cobran.
Durante el desarrollo de este trabajo el investigador tuvo acceso a algunos de
ejemplos de estas metodologías y lo que se puede resaltar sobre estas es lo
siguiente:
30
o Tienen e incorporan continuamente las experiencias que tienen dichas
empresas en todo el mundo.
o Son muy ágiles y prácticas, ya que tienen todos los formatos y ejemplos,
guías de cómo se deben emplear y como se ha empleado, casos de éxito.
o Son claramente diferenciadas y muy especificas por tipos de proyectos, y
dentro de estos por casos muy concretos, como por ejemplo proyectos de
implementación de centros de computo con tecnología RISC o la
implementación de un sistema de minería de datos para empresas de
telecomunicaciones. De tal forma que la reutilización sea muy alta y no se
este inventando la rueda cada vez que se aborda un proyecto de este tipo.
o Toda la documentación, las lecciones aprendidas en los diferentes
proyectos son frecuentemente actualizadas.
o Aunque muchas se basan en metodologías como el PMI, van mas lejos
puesto que desarrollan detalladamente el como realizar las cosas , como
aplicar las técnicas y las herramientas, y todo lo adaptan a la forma de
operación de cada una de sus empresas en los diferentes países.
Existen otras metodologías de gerencia de proyectos muy especificas para
proyectos de desarrollo de software (tipo de proyectos que no están dentro del
alcance de esta investigación) tales como RUP (The Rational Unified Process),
XP (Programación Extrema), CMM (Capability Maturity Model), SCRUM, MSF
(Microsoft Solutions Framework), todas utilizadas a nivel mundial y local, las
cuales de igual forma fueron revisadas con el objetivo de mirar su posible aporte
en la mejora de las deficiencias encontradas durante esta investigación y en
particular para el tipo de proyectos de TI objeto de este trabajo. Se encontró que a
excepción del MSF las demás tienen un foco muy definido y es el de mejorar la
31
eficiencia y la calidad específicamente en los proyectos de desarrollo de software,
para los cuales generan sin lugar a duda grandes aportes y mejoras. Pero dan
poca atención y elementos, desde el punto de vista del investigador, que permitan
ser usados de manera consistente y práctica en proyectos diferentes al desarrollo
de software.
Para complementar es importante mencionar la existencia de las organizaciones
que trabajan a nivel mundial en la investigación y desarrollo en el tema de gerencia
de proyectos y también involucran particularmente los de TI, entre las cuales
tenemos:
ISO 9000-2000 /1006 (Guidelines for Quality in Project Management)
CMM (Capability Maturity Model)
SEI (Software Engineering Institue)
IPMA (International Project Management Association)
APM (Association for Project Management)
Microsoft Solution Framework (MSF)
En Colombia existe un grupo de interés denominado GEPROYINFO que
pertenece la Asociación Colombiana de Ingeniería de Sistemas (ACIS) la cual ha
venido trabajando en el tema específico de gerencia proyectos de tecnología
informática y adicionalmente, al proceso de concientización y profesionalización
que le han venido dando las empresas a este tema.
Este grupo de investigación trata diferentes temas relacionados con la gerencia
de proyectos de TI, tales como:
Los procesos de gerencia de riesgos
Control de calidad
Control de Cambios
El perfil del gerente de proyectos (habilidades y conocimientos)
32
Costo total de propiedad
Flexibilización de las metodologías y su simplificación. No trabajar para la
metodología
Características de los proyectos exitosos y de los proyectos fracasados
(casos de éxito)
PMI & CMM (Como se complementan para adoptar las mejores prácticas
enfocadas al desarrollo de Sw)
Mecanismos de certificación
Evaluación y recuperación de proyectos en problemas
Gestión con Proveedores, subcontratistas y responsabilidades legales al
momento de contratar
Acuerdos de Niveles de servicio en los contratos (SLAs)
Adicionalmente, este grupo de la ACIS llevo acabo la primera encuesta sobre
gerencia de proyectos de TI en Colombia, en los meses de febrero y marzo de
2004 y cuyos resultados se publicaron en mayo del 200421.
Aunque es un área en el cual se esta trabajando mucho dada la gran importancia
que tiene el tema hoy en día, la gestión de proyectos es un ámbito del
conocimiento aun en proceso de elaboración tanto en la academia como en la
empresa, pues los modelos hasta hoy planteados aun están lejos de lograr la
excelencia que garantice la óptima asignación de los recursos, el cumplimiento
con los tiempos de ejecución, no sobrepasar los costos establecidos y cumplir con
los requerimientos de calidad y confiabilidad tan necesitados en todos los
proyectos, y especialmente en los de TI.
21 Resultados Publicados en www.acis.org
33
CAPITULO IV INVESTIGACIÓN
34
4. INVESTIGACIÓN
4.1 INTRODUCCIÓN La importancia de las Tecnologías de Información (TI) es tal que hoy
prácticamente todas las organizaciones dependen en mayor o menor medida de
estas para operar.
El impacto que tienen las TI es muy alto. La información, la comunicación, la
coordinación y el software son los componentes importantes de la llamada “nueva
economía”. Algunas organizaciones consideran a sus proyectos de TI como
estratégicos y están alterando su estructura y operación, intentando adaptarse a la
turbulencia del mercado y aprovechando las ventajas en la coordinación, el
registro y análisis de información y el apoyo para la toma de decisiones que
brindan los sistemas de información, logrando una ventaja competitiva. Otras
organizaciones, sencillamente están utilizando las TI de manera colateral,
aprovechando parcialmente las posibilidades de automatización en el flujo de
información y procesos productivos; esencialmente operando como antes y no
aprovechan la oportunidad para re-definir sus procesos de producción.
4.2 LA INVESTIGACIÓN SOBRE EL FRACASO DE LOS PROYECTOS DE TI Los proyectos de Tecnologías de Información (TI) son proyectos que tienen
características muy particulares: sus entregables son digitales (programas de
cómputo, archivos con código fuente de programas, diagramas, modelos,
manuales e implementación de infraestructura etc.) requieren mucha creatividad
35
en la mayoría de sus fases, con tasas de fracaso de más del 70% (según el
Standish Group). Los proyectos representan el modelado parcial de la
organización, son de gran complejidad, son muy costosos, son manejados con
poca experiencia administrativa y son de gran importancia para las organizaciones
en la sociedad postindustrial. Los proyectos de TI intentan modelar y automatizar
parcialmente la operación de la organización y son tan complejos como lo es la
propia organización y la tecnología, por lo que tienen un mayor nivel de riesgo.
La investigación sobre el fracaso de los proyectos de TI es bastante limitada tanto
a nivel local como mundial, y la mayoría de las que se han realizado se
concentran en considerar los fracasos de manera genérica como “fallas en la
gestión de los proyectos”
En esta investigación se explora el panorama de los proyectos de TI, su
importancia en la sociedad y en la organización. Se abordan los conceptos
mínimos para aquellos lectores que no son conocedores del tema y se desarrolla
una propuesta teórica sobre el fracaso de los proyectos de TI en las
organizaciones en donde se llevo acabo esta investigación. Se hace un análisis de
los factores que determinan el éxito o fracaso de los proyectos de TI. Finalmente
se analizan las causas de la falla de este tipo de proyectos desde la perspectiva
de los estudios organizacionales y se propone un enfoque para reducir esa tasa
de fracaso mediante un modelo de gestión de proyectos de TI y el aprendizaje
organizacional.
Los fundamentos sobre gerencia de proyectos se han desarrollado o iniciado en
USA. Y a partir de ahí, numerosos profesionales en gestión de proyectos y
profesores de universidades o escuelas especializadas de todo el mundo han
desarrollado aspectos concretos sobre como se deben “hacer las cosas” para
tener éxito en la gestión de un proyecto.
36
Se puede decir, que en el ámbito mundial hay un incontable número de artículos,
libros, publicaciones, investigaciones y se imparten numerosos seminarios,
conferencias y cursos en general sobre el tema.
Sin embargo basado en la experiencia en gerencia de proyectos de TI del autor de
estas tesis y a mucha de la información consultada sobre el tema, se puede
afirmar que el esquema de planteamiento de la gerencia de proyectos y la
problemática alrededor de estos es muy general y el modelo genérico que mas
aceptación mundial tiene es el que el Project Management Institute (PMI)
promueve, no con esto queriendo decir que sean el mejor, pues sin ninguna duada
los demás enfoques y metodologías igualmente son válidas y por lo mismo son
utilizadas por gobiernos y compañías como es el caso de la Metodología PRINCE.
La utilización de estos modelos y metodologías en culturas como la nuestra
(Colombia) y en especial en las empresas donde se realizo esta investigación, se
ha hecho sin la apropiada de adaptación y en algunos caso se puede decir que sin
ninguna adaptación. Lo que trae como consecuencia el que o se obvie este
esquema de gestión de proyectos de una forma completa, lo que conlleva a una
pérdida de experiencia, o se cometen errores en su utilización al hacerlo de una
manera genérica.
Es por esto que investigar la posibilidad de establecer las causas o factores que
impiden el éxito de los proyectos de TI en nuestro entorno, presenta una
oportunidad de hacer un aporte al respecto, proponiendo un modelo para
gestionar proyectos que partiendo de lo que en estos momentos se conoce y logre
conocer, marque nuevos caminos a través de un nuevo esquema que lo
enriquezca, aprovechando la experiencia acumulada, lo que ya existe en el ámbito
local y lo mejore.
37
Figura 4. Representación de la historia de resultado de los proyectos de TI.
4.3 METODOLOGÍA Este trabajo se ajusta al cumplimiento del planteamiento metodológico planteado
en el proyecto de investigación.
4.3.1
4.3.2
Tipo de estudio o investigación. El tipo de investigación que se realizó en
este trabajo es de tipo descriptiva, ya que con esta investigación se busca
especificar y evaluar características importantes sobre los proyectos de TI.
Diseño de la investigación. El diseño de esta investigación es no
experimental transaccional, pues se recopilarán datos e información disponibles
en el momento sobre el problema planteado.
38
4.3.3 Método de investigación. Se realizará un estudio detallado sobre la
problemática en la gestión de proyectos de TI y sobre las diferentes alternativas de
solución que se proponen en los diferentes medios, para esto se recogerá
información de organizaciones, la academia, las metodologías, libros, las mejores
prácticas y casos de estudio, investigaciones y experiencias en el ámbito local,
además se realizaran entrevistas estructuradas a las personas responsables del
tema en las empresas del GEA y en la academia.
A partir de esta información se sintetizarán los conceptos fundamentales y se
definirán criterios para seleccionar los aspectos de las metodologías y propuestas
que mas aportan a la solución de la problemática bajo el contexto esbozado, con
esto se crearan propuestas que permitan desarrollar un modelo de gestión de
proyectos acorde a las necesidades planteadas. Se desarrollarán todas las
labores de creación del modelo y se realizarán las verificaciones de su validez,
(mas no manera practica dado que no esta dentro del alcance de este trabajo),
para su posterior entrega.
Para lograr los objetivos planteado en esta investigación, se llevaron acabo los
siguientes pasos:
1. Investigación sobre documentos, metodologías y mejores prácticas y la
problemática en la gestión de proyectos de TI. Esta fue una de las fases
más dispendiosas, por la multiplicidad y dispersión de las fuentes, la calidad
de la información y selección de aquella mas relevante.
2. Análisis y entendimiento de las metodologías más importantes y las
mejores prácticas en la gestión de proyectos. Las siguientes fueron las
principales fuentes de información:
39
• Análisis Documental.
o De fuentes de Metodologías. Documentos primarios
o De Gerencia de proyectos y mejores prácticas: Informes,
investigaciones, libros, memorias de eventos.
o De artículos e información contenida en libros, revistas generales o
especializadas y artículos cuya relación se presenta en la
bibliografía.
3. Síntesis de los conceptos, metodologías y criterios
4. Esquematizar un modelo según las mejores estrategias expuestas en las
metodologías y seleccionadas de estas
5. Analizar el proceso de gestión de proyectos y la cultura de proyectos en la
empresa. Apoyado en el modelo presentado por Gonzalo Montes.22
6. Realizar entrevistas estructuradas
7. Buscar experiencias y conocimientos en gestión de proyectos y sus
modelos en otras empresas del GEA.
8. Realizar entrevistas estructuradas en las empresas escogidas del GEA.
9. Recopilar, analizar e interpretar toda la información recogida
10. Diseñar un modelo que incorpore este conocimiento y refinarlo.
11. Presentar y sustentar el modelo definitivo.
12. Entregar el modelo definitivo y el trabajo final
4.3.4
Instrumentos y técnicas para la recolección de la información. En esta
investigación se utilizaron los siguientes instrumentos y técnicas para la
recolección de información:
22MONTES, Gonzalo, Metodología PMI® complementada para gestionar proyectos de desarrollo de software y de implantación de aplicaciones de alto impacto en las organizaciones, ACIS, Bogota, Noviembre de 2002; p. 1-29
40
1. Recoger datos sobre investigaciones realizadas sobre el tema.
2. La entrevista estructurada, la cual se realizó a personas de las compañías
que pertenecen al Grupo Empresarial Antioqueño, de la compañía
Suramericana y expertos académicos en el tema.
En las entrevistas se tuvieron en cuenta las siguientes consideraciones:
• Tipo de entrevista: Estructurada con preguntas abiertas, para seguir
de guía como una conversación, y focalizada, es decir, que las
cuestiones por investigar se derivan del problema general que se va
a estudiar.
• Tipo de preguntas: Generales y específicas, con el fin de buscar,
fundamentalmente, aspectos cualitativos que describa los
fenómenos organizacionales que son objeto del estudio.
• Planeación de la entrevista: Se contemplo como mínimo los
siguientes aspectos:
a. La determinación de los objetivos de la información buscados.
b. La escogencia de las personas apropiadas para la entrevista
c. La metodología de entrevista propiamente dicha
• Selección de los métodos de registro de la información obtenida:
Grabación previo consentimiento del entrevistado y anotación por
parte del entrevistador de las ideas más relevantes.
• Manejo y uso de la información confidencial: Respeto a la
confidencialidad en los aspectos solicitados por los entrevistados.
4.3.5 Procesamiento o análisis de la Información. La información recolectada se
analiza mediante cuadros estadísticos, gráficos y cuadros sinópticos. El análisis
41
consiste en el estudio de la información recopilada para hallar la relación entre las
diversas fuentes y establecer la forma en que responden al problema planteado en
la investigación, acorde a las preguntas planteadas sobre la problemática del éxito
de los proyectos de TI.
4.4 DESARROLLO DE LA INVESTIGACIÓN Durante el desarrollo de esta investigación el autor realizo un estudio sobre la
problemática de la gestión de proyectos de TI, en el ámbito global y
posteriormente en el local (Colombia y las Empresas de GEA), para lo cual se
revisaron gran cantidad de artículos, numerosas investigaciones realizadas por
diferentes organizaciones interesadas en el tema, como el PMI, Standish Group,
Meta Group, Universidades, y libros especializados en gerencia de proyectos y en
especial de gerencia de proyectos de TI. (Ver Bibliografia)
La información base se tomo de algunos artículos publicados por el PMI, pero
fundamentalmente se utilizaron los reportes de la The Standish Group
internacional, INC; en los que se encuentran los resultados de las diferentes
investigaciones que ha realizado esta organización alrededor del tema de gestión
de proyectos, y en particular de los proyectos de TI. The Standish Group
internacional, INC es un organismo internacional dedicado al estudio de las
causas o problemática del fracaso de los proyectos de TI. Dentro de estas
investigaciones la que más se cita sobre el estado de los proyectos de TI es el
famoso “Reporte Caos” del Standish Group [Standish 1995] que prácticamente
todos los investigadores asumen como la referencia obligada. Esta información ha
sido de un gran valor como punto de partida para esta investigación,
adicionalmente de ser una fuente de gran credibilidad y prestigio a nivel mundial
en esta materia.
42
Para el ámbito local se utilizo información de la Asociación Colombiana de
Ingenieros de Sistemas (ACIS), especialmente de las memorias de sus eventos e
investigaciones realizados sobre el tema; estas aportaron una gran información de
la situación de la gestión de proyectos en Colombia, especialmente de las
investigaciones y eventos realizado entre los años 2003 y 2004.
Otras fuentes se lograron adquirir a través de entrevistas estructuras a
profundidad con académicos, consultores, directores de proyectos, gerentes de
informática y profesionales relevantes en el ámbito de gerencia de proyectos de
TI, pertenecientes a las empresas de GEA y a proveedores de tecnología de
estas (son omitidos los nombres de estas empresas para mantener su reserva);
Estas entrevistas permitieron obtener la información cualitativa de gran
importancia y relevancia para los objetivos de esta investigación.
Los criterios, hallazgos y conclusiones se fundamentan en todo el análisis de la
información encontrada y se complementan con los análisis, el punto de vista y la
experiencia que el autor a lo largo de más de 14 años ha adquirido en el
desarrollo de proyectos de TI en diferentes empresas y en los estudios
realizados en la academia, lo que permitió detectar diversos factores que
entorpecen el camino de un proyecto y que se analizan a continuación.
4.5 CARACTERÍSTICAS ORGANIZACIONALES DE LAS EMPRESAS ESTUDIADAS
Como parte fundamental para entender los datos encontrados en esta
investigación y como un pilar de los planteamientos realizados sobre la
importancia la las características organizaciones en el éxito de los proyectos de TI,
se describirán las características organizaciones relevantes respecto a la gerencia
de proyectos en las empresas estudiadas.
43
Encontramos que las empresas tienen una estructura funcional en la que los
proyectos se desarrollan en equipos conformados por personas de diferentes
áreas que tienen que trabajar simultáneamente en las labores propias del cargo
como en las del proyecto asignado. Estas personas deben responder al mismo
tiempo por sus obligaciones ante su jefe inmediato o Gerente a la par con las del
proyecto, pero es en definitiva el jefe inmediato el que maneja sus prioridades de
tiempo. Por lo tanto el líder de proyecto tiene que realizar un escalamiento
jerárquico o al mismo nivel, al jefe inmediato de las personas que integran el
equipo del proyecto cuando debe solicitar mayor disponibilidad del tiempo o
mayores compromisos con las actividades acordadas con cada uno de los
integrantes de su equipo de proyecto, esto claramente evidencia una gran
dificultad en el manejo de los recursos humano dentro del proyecto, pues siempre
esta supeditado a las decisiones y compromisos los jefes de las personas de su
grupo. Existe un clara y marcada centralización para la toma de decisiones a
todo nivel de la empresa, y existe una competencia clara en la demanda por los
recursos de las diferentes áreas para cada uno de los proyectos que se llevan o
planeen ejecutar.
No existe un nivel de formalidad en las políticas, procedimientos y directrices para
la gestión de proyectos a nivel general de la empresa , aunque ya se están
empezando a desarrollar algunas políticas, directrices y estándares al respecto,
estos aun son muy incipientes. Existe un mayor grado formalidad para lo
proyectos catalogados como corporativos y de alto impacto, pero mas respecto a
realizar una clara definición del proyecto, a cuantificar los costos y a tener unos
cronogramas y realizar rigurosamente los seguimientos en la alta gerencia.
Los líderes de proyectos son nombrados más por su conocimiento técnico y
disponibilidad de tiempo que por las habilidades, conocimientos y experiencia en
la gerencia de proyectos. Adicionalmente el conocimiento de las metodologías y
disciplinas de la gestión de proyectos es muy bajo y por lo tanto la improvisación
44
es mucha. Esto también dado por el hecho de no existir metodologías, guías
estándar para la gestión de proyectos, especialmente para los proyectos de TI.
La mayoría de las comunicaciones entre los equipos y miembros de los equipos
son muy informales y poco estructuradas.
En términos generales se puede decir que la empresa es muy jerárquica para la
toma de decisiones, su estructura es funcional, poco formal tanto en los procesos
como en la comunicación y en la documentación. Los proyectos compiten por los
recursos claves dentro de cada una de las áreas de la empresa.
4.6 HALLAZGOS DE LA INVESTIGACIÓN
Como punto de referencia encontramos que según datos The Standish Group
internacional, INC 23 sobre el desempeño de los Proyectos de TI en Iberoamérica,
el 23% de los proyectos son cancelados antes de ser completados, el 62% de los
proyectos tienen desviaciones de tiempo, costo y/o funcionalidad y solo el 15% de
los proyectos son completados según el plan acordado inicialmente. La desviación
promedio de tiempo es de 143% y la desviación promedio de presupuesto es de
117%. A nivel mundial se tienen los siguientes datos comparativos entre 1995 y el
2001.
Tabla 2. Desempeño de los Proyectos de TI
1995 2001
Proyectos cancelados antes de ser completados 31% 23%
Tienen desviaciones 53% 49%
Son terminados según plan 16% 28%
Con Desviación de Tiempo 222% 63%
Con Desviación de Presupuesto. 189% 45%
23 The Chaos Report 1994 y 1999
45
Fuente: The Standish Group internacional, INC
Aunque a nivel local no se cuenta con la suficiente información estadística que
nos permita realizar una comparación respecto a los datos mundiales del
desempeño de los proyectos de TI, los conceptos y las apreciaciones de las
diferentes personas entrevistadas y encuestadas, nos indican y dejan apreciar
que estos datos no distan mucho de la realidad en el ámbito local (Colombia) y
especialmente en las empresas donde se realiza esta investigación.
Adicionalmente esta percepción se sustenta según el dato en el que, el 31% de
los proyectos colombianos se encuentran terminados dentro del tiempo
presupuestado. En cuanto al cumplimiento del presupuesto, el 48% de los
proyectos son terminados dentro del presupuesto según el reporte de la segunda
encuesta de gerencia de proyectos de TI en Colombia, realizada por ACIS, 2004,
la cual se baso en la recolección de datos de 53 gerentes de proyectos de
tecnología informática y 9 miembros de la comunidad de Tecnología Informática
en Colombia. 24
Es importante resaltar que en el ámbito local es difícil contar con este tipo de
información principalmente por dos motivos: No se guarda información sobre el
desempeño de los proyectos y en los casos que se tiene este tipo de información
es confidencial, estratégica o no se puede divulgar porque puede tener
repercusiones en la imagen de las compañías.
Más allá de que las estadísticas presentadas representan un buen punto de
partida, lo primordial para esta investigación no es el dato en si, sino el hallazgo y
la sustentación de la problemática de desempeño alrededor de los proyectos de
TI, como también el poder sintetizar los conceptos fundamentales sobre ¿Por qué 24 III Encuesta de Gerencia de Proyectos de TI en Colombia, ACIS, 2004-2005, Ing. Rafael J. Barros
46
terminan con demoras, exceden el presupuesto y no satisfacen las necesidades
de los usuarios y del negocio (No son exitosos) los proyectos de TI? En las
empresas del GEA donde se realizó esta investigación.
Después de investigar y revisar la gran cantidad de fuentes de información sobre
esta problemática, se puede decir que es difícil encontrar una única respuesta a
la pregunta planteada, debido a que cada proyecto tiene características propias,
diferentes factores de riesgo, causas diferentes de fracaso y los entornos
culturales en cada organización son particulares en cada caso. Sin embargo, dado
que este estudio se nutrió de experiencias personales, más allá de los números,
permitió detectar diversos factores que entorpecen el éxito de un proyecto y se
han logrado identificar y analizar, creando un grupo de referencia de las causas
más comunes de fracaso en los proyectos de TI, que permiten dar una respuesta
a la pregunta planteada. Según esto podemos decir en términos generales que a
nivel mundial los proyectos de TI fallan principalmente por:
Principales Causas: 1. Planificación deficiente
2. Definición escasa de especificaciones
3. Falta de participación de usuarios claves
4. Cambios de alcance
5. Falta de apoyo ejecutivo
6. Expectativas irreales
7. Objetivos poco claros
8. Plazos de tiempo irreales
9. “Deadlines” innecesarios
10. Problemas de comunicación
Fuente: Standish Group internacional, INC
47
Con esta información como punto de partida y gracias a la información obtenida
durante las entrevistas realizadas a personas responsables e interesadas en este
tema en el ámbito local, y también a la información extractada de diferentes
artículos sobre el tema, como el de Administración de proyectos de tecnologías
de información, Yessika Rodríguez B., Asesor de Proyectos y el reporte de The
Standish Group internacional, INC se creo una lista personalizada al ámbito local
y particularmente en las empresas donde se realizo la investigación, sobre las
principales causas por las que fallan los proyectos de TI.
Es importante aclarar que aunque esta lista de causas puede atribuirse a todo
tipo de proyectos de TI, en el caso particular de este trabajo el alcance y los
resultados están claramente acotados a la definición hecha de proyectos de TI en
el capitulo 225.
Entendiendo que las causas o factores que impiden el éxito de los proyectos se
encuentran dentro de diferentes aspectos o elementos relacionados con la
gestión de proyectos, tales como: aspectos humanos, organizacionales,
culturales, técnicos y metodológicos, de planeación, información y control; se
definió por parte del autor una agrupación en cuatro aspectos macros que sirven
como marco de referencia para esta investigación en particular y que nos sirven
para entender que la problemática alrededor de los proyectos de TI, esta
enmarcada en varias dimensiones o aspectos relacionados con la gerencia de
estos.
Las causas encontradas se abordaron dentro de los siguientes aspectos:
ASPECTOS HUMANOS
• Recurso humano incompetente
• Falta de trabajo en equipo y sentido de pertenencia
• Problemas de conducción, comunicación y conflicto
25 Capitulo 2 sección 2.12 CLASIFICACIÓN DE LOS PROYECTOS DE TI.
48
• Falta de conocimientos y habilidades para gerenciar proyectos
ASPECTOS ORGANIZACIONALES
• Falta de compromiso y sentido de pertenencia del usuario líder del
proyecto. (Por usuario líder se entiende la persona del negocio que
representa el área o áreas que directamente serán impactadas con
los resultados del proyecto)
• La falta de cultura de trabajo por proyectos en la organización
• No participación de áreas claves del negocio desde el inicio del
proyecto
• Cambios en los objetivos
ASPECTOS PROPIOS DE TI O DE LOS PROYECTOS DE TI
• Problemas de administración de tecnología
• Desconocimiento de la tecnología
• Problemas de Integración de TI
ASPECTOS METODOLÓGICOS
• Inadecuado manejo de los Riesgos del proyecto
• Proyectos demasiado ambiciosos
• Falta de un plan de aseguramiento de la calidad del proyecto
• Poca claridad e inadecuada asignación de las responsabilidades en
el equipo de trabajo
• No utilización, o mala utilización de metodologías de Gerencia de
Proyectos
• Falta de claridad y unidad alrededor de los objetivos del proyecto
• Especificación de requerimientos incompleta, ambigua,
inconsistente, variante.
• Inadecuado manejo de control de Cambios
49
• Errores en la planeación del Proyecto (Poca precisión para estimar
el tiempo y los recursos)
ASPECTOS HUMANOS: Tienen que ver básicamente con problemas de
habilidades, competencias y conocimientos de las personas que en un
momento dado son seleccionadas para participar en un proyecto. Los
proyectos son desarrollados por personas, esto quiere decir, que están
influenciados por aspectos subjetivos asociados a la naturaleza de los
individuos que trabajan en ellos. Factores como el compromiso de sus
miembros, la afinidad con las actividades que el equipo desarrolla, el grado de
empatia y en general la emoción que se genera alrededor del proyecto, se
convierten en el combustible que hace que los resultados esperados puedan o
no lograrse.
• Recurso humano incompetente: Esta causa hace referencia, a
problemas relacionados con falta de conocimiento o experiencia para
cumplir con los compromisos o actividades asignadas dentro de un
proyecto.
• Falta de trabajo en equipo y sentido de pertenencia: Esta hace
referencia a problemas de capacidad para interactuar con otras
personas compartiendo funciones y responsabilidades para el logro de
objetivos comunes.
• Problemas de conducción, comunicación y conflicto. Estos tienen
que ver con problemas de capacidad para dirigir personas, para
comunicar con claridad y para manejar situaciones conflictivas.
• Falta de conocimientos y habilidades para gerenciar proyectos. Básicamente tiene que ver con la falta de conocimientos y experiencia
50
en la gestión de proyectos, así como el no tener desarrolladas las
habilidades necesarias para realizar el rol de un gerente de proyectos.
ASPECTOS ORGANIZACIONALES Y CULTURALES: Están relacionados
problemas de estructura y cultura organizacional
• Falta de compromiso y sentido de pertenencia del usuario líder del proyecto. (Por usuario líder se entiende la persona del negocio que
representa el área o áreas que directamente serán impactadas con los
resultados del proyecto). Tiene que ver básicamente con problemas de
asignación del usuario líder del proyecto y con el tiempo que la
organización le asigna para cumplir con las labores o compromisos
dentro del proyecto.
• La falta de cultura de trabajo por proyectos en la organización: Este
problema se relaciona con el grado de madurez de la organización en el
trabajo por proyectos en particular con la estructura organizacional que
tenga la empresa para facilitar el trabajo por proyectos. Los proyectos
se desarrollan al interior de las organizaciones, en ellos participan
personas que presentan comportamientos influenciados por el estilo y
las costumbres de dichas organizaciones. Por consiguiente, los
resultados y la dinámica del proyecto esta constantemente afectada por
la cultura organizacional. Las decisiones tomadas alrededor del mismo
pueden ser vistas de diversas formas por los miembros de la
organización y dependiendo de ello, asumirán posiciones contributivas,
detractoras o imparciales sobre el proyecto o sobre sus miembros.
• No participación de áreas claves del negocio desde el inicio del proyecto. También esta relacionada con la madurez de la organización
en el trabajo por proyectos y la asignación o disponibilidad de recursos
51
para involucrarse dentro de los proyectos en los que pueden brindar un
gran apoyo para el logro de los objetivos planteados.
• Cambios en los objetivos. Tiene relación con la forma de gobierno de
la organización y el entorno en el que se desenvuelve. Los cambios de
rumbo, frecuentes en algunos proyectos y ocasionados por la reacción
ante un cambio del mercado o del entorno del proyecto, afectan
negativamente el mismo, al no permitir la culminación de tareas o
finalización de entregables esperados en una determinada fase del
proyecto. Esto lleva frustraciones a los involucrados, al no suplir sus
necesidades de realización y no ver materializado su esfuerzo en
productos concretos o entregables tangibles.
ASPECTOS PROPIOS DE TI O DE LOS PROYECTOS DE TI: Tienen una
relación directa con la complejidad en la administración y conocimiento de la
tecnología misma necesaria para realizar el entregable del proyecto.
• Problemas de administración de tecnología. Son los problemas que
surgen por el desconocimiento o no aplicación de los procesos y
procedimientos para administrar la tecnología necesaria (plataformas,
herramientas etc.), para llevar el proyecto a cabo y para que el
entregable pueda ser implementado y entregado a operación final,
dentro del entorno empresarial.
• Desconocimiento de la tecnología. Algunos proyectos involucran la
utilización de nuevas tecnologías, en ellos el grado de incertidumbre
sobre su capacidad, sumado a la curva de aprendizaje necesaria para
obtener un dominio sobre los beneficios y limitaciones reales de las
nuevas tecnologías, frecuentemente constituyen factores que consumen
mayores recursos como tiempo y costo.
52
Aún cuando la curva de aprendizaje se cubra y se haya reducido el nivel
de incertidumbre sobre la nueva tecnología, se verán afectadas las
expectativas del proyecto al no conocerse si todas las cosas previstas
son soportadas o no o si deben buscarse caminos adicionales que
permitan evitar las limitaciones encontradas en el uso de la nueva
tecnología.
• Problemas de Integración de TI. Problemas especialmente
relacionados con dificultades para realizar una integración de la
infraestructura, aplicaciones (Programas de software), u otros
elementos tecnológicos que son resultado del proyecto, con los
entornos tecnológicos de la organización o incluso con las diferentes
tecnologías o plataformas que se utilizan dentro del proyecto.
ASPECTOS METODOLÓGICOS: Están directamente relacionados con
aspectos de las disciplinas o metodologías de gestión de proyectos de TI,
que son fundamentales y que de no desarrollarse bien generan inconvenientes
para el éxito del proyecto.
• Inadecuado manejo de los riesgos del proyecto. En toda actividad
realizada, existe la posibilidad de que las cosas no salgan bien. En otras
palabras, durante la realización del proyecto aparecen sucesos que
amenazan la finalización del mismo. Esto sugiere una administración
del riesgo asociado a los factores que afectan al proyecto y que
permitan anticipar las medidas necesarias para minimizar el impacto
negativo que estos factores puedan tener sobre los resultados
esperados. Esto es mar cierto y mas crítico particularmente en los
proyectos de TI, dado que una de las características que resalta en
estos es precisamente la de que tiene un alto nivel de riesgo, en parte
asociado de alguna forma a que realizan uso intensivo de la tecnología.
53
• Proyectos demasiado ambiciosos. En toda actividad realizada entre
más amplia sea o de mayor alcance dentro de unos tiempos muy
ajustados, el espacio de colchón u holgura de tiempo del proyecto se
limitan, la cantidad y el esfuerzo de los recursos se incrementa y las
probabilidades de no cumplir se aumentan, debido a que se aumenta la
complejidad en la administración o gestión del proyecto.
• Falta de un plan de aseguramiento de la calidad del proyecto. El
plan de calidad define como se efectuará el control y la mejora continua
tanto del proyecto como del producto o servicio creado por el mismo.
Este da pautas claras de cómo realizar los procesos de Aseguramiento
y Control de la Calidad.
• Poca claridad e inadecuada asignación de las responsabilidades en el equipo de trabajo. Los proyectos involucran la utilización de
recursos y su organización para producir los resultados esperados. Esto
crea la necesidad de contar con una estructuración detallada y clara de
las actividades necesarias para el logro de los objetivos, el orden en
que deben desarrollarse, los roles y responsabilidades de cada uno de
los integrantes y la organización de los demás recursos y esfuerzos
necesarios en cada una de las etapas del proyecto.
• No utilización, o mala utilización de metodologías de gerencia de proyectos. No utilización de alguna metodología estándar y
formalizada, para le gestión de los proyectos, esta metodología puede
se propia , o alguna estándar o reconocida como este el caso del PMI.
O utilización de una metodología de forma genérica sin la adecuación a
las características de la empresa sin ser utilizada como instrumento de
ayuda, sino que se trabaja para la metodología por cumplirla.
54
• Falta de claridad y unidad alrededor de los objetivos del proyecto
Los miembros del equipo e interesados en el proyecto no tienen
claridad sobre los objetivos del proyecto, porque no están bien definidos
o porque no se definieron en consenso con todos los interesado y por lo
tanto no los comparten ni los asumen como se debe.
• Especificación de requerimientos incompleta, ambigua, inconsistente. Algunos de los problemas comunes encontrados al momento de estructurar requerimientos son:
o Dificultad en las personas para expresar con claridad los requerimientos.
o La no posible generalización de los mismos. o La dificultad de interrelación con macro sistemas y subsistemas. o La dependencia de destrezas y habilidades al momento de su
definición. o Su constante variación durante el ciclo de desarrollo del
proyecto.
• Inadecuado manejo de control de cambios. Apunta a la
implementación de un proceso que permite evaluar impactos en los
requerimientos de cambios, en alcance, tiempo, costos, calidad del
proyecto, y que permita realizar solo aquellos que sean aprobados por
las personas interesadas o afectadas por el proyecto.
• Errores en la planeación del proyecto. Está básicamente relacionado
con la poca precisión para estimar el tiempo y los recursos en la etapa
de planeación del proyecto. El esfuerzo debe medir la sostenibilidad
real de un proyecto sobre la base de procesos de eficiencia. Se
acostumbra a planear sin tener en cuenta balances de carga y esfuerzo
para los recursos involucrados, sobre todo humanos.
55
Como paso posterior a la construcción y entendimiento de la lista sobre las
causas del fracaso de los proyectos de TI, se realizó una encuesta a 50
funcionarios de las empresas del GEA (Grupo Empresarial Antioqueño) y
proveedores de Tecnología de estas, directamente responsables de los proyectos
de TI, con el objetivo de corroborar que dentro de esta lista construida se
encontraban las causas más significativas y de mayor importancia en el éxito de
los proyectos de TI, además identificar el impacto, peso o la importancia atribuida
de cada una de estas causas del fracaso de los proyectos. De las 50 encuestas
enviadas fueron respondidas 30, lo que nos dio un 60% en el porcentaje de
respuestas. El cuestionario de las preguntas realizadas se encuentra en el Anexo
B.
Otro objetivo de la encuesta fue el identificar si se utilizaba alguna metodología
para la gestión de proyectos, así como las herramientas utilizadas como apoyo
para esta gestión. También se evaluó en la encuesta la percepción del grado de
importancia de la formación (capacitación) en gestión de proyectos por parte de
las organizaciones o del personal que participa en estos, así como la disposición
de recursos para el mejoramiento de estos aspectos. Los resultados que se
obtuvieron se presentan y se describen a continuación:
Figura 5. Resultados encuesta
56
9,09%9,09%
9,09%27,27%
27,27%
27,27%
27,27%27,27%
31,82%31,82%
36,36%
36,36%
36,36%
40,91%
40,91%45,45%
54,55%
54,55%59,09%
72,73%
77,27%
0,00% 10,00% 20,00% 30,00% 40,00% 50,00% 60,00% 70,00% 80,00%
Causas de Fracaso en Proyectos de TI
Errores en la planeación del Proyecto Cambios en los objetivos Inadecuado manejo de control de Cambios Especificación de requerimientos incompleta, ambigua, inconsistente Falta de claridad y unidad alrededor de los objetivos del proyecto No participación de áreas claves del negocio desde el inicio del proyecto No utilización, o mala utilización de metodologías de Gerencia de Proyectos Poca claridad e inadecuada asignación de las responsabilidades Falta de conocimientos y Habilidades para Gerenciar Proyectos La falta de cultura de trabajo por proyectos en la organización Problemas de Integración de TI Falta de Un plan de aseguramiento de la calidad del proyecto Desconocimiento de la tecnología Problemas Humanos, de conducción, comunicación y conflicto Proyectos demasiado ambiciosos Inadecuado manejo de Riesgos Problemas de administración de tecnología Trabajo en Equipo y sentido de pertenencia Otros Recurso Humano incompetente Falta de compromiso y sentido de pertenencia del usuario líder del proyecto.
|
Tabla 3. Resultados encuesta.
10. Cuáles son las causas del fracaso de los proyectos de TI (Entendiendo como fracaso en los proyectos, proyectos que finalizan no obteniendo el objetivo planteado, ni en el tiempo y con los recursos estimados)
TOTAL Resp %
(Elija todas las aplicables) [ ] Falta de compromiso y sentido de pertenencia del usuario líder del proyecto. 2 9%[ ] Recurso Humano incompetente 2 9%[ ] Otros, especifique cuales: ____________________________________________________ 2 9%[ ] Trabajo en Equipo y sentido de pertenencia 6 27%[ ] Problemas de administración de tecnología 6 27%[ ] Inadecuado manejo de Riesgos 6 27%
57
[ ] Proyectos demasiado ambiciosos 6 27%[ ] Problemas Humanos, de conducción, comunicación y conflicto 6 27%[ ] Desconocimiento de la tecnología 7 32%[ ] Falta de Un plan de aseguramiento de la calidad del proyecto 7 32%[ ] Problemas de Integración de TI 8 36%[ ] La falta de cultura de trabajo por proyectos en la organización 8 36%[ ] Falta de conocimientos y Habilidades para Gerenciar Proyectos 8 36%[ ] Poca claridad e inadecuada asignación de las responsabilidades en el equipo de trabajo 9 41%[ ] No utilización, o mala utilización de metodologías de Gerencia de Proyectos 9 41%[ ] No participación de áreas claves del negocio desde el inicio del proyecto 10 45%[ ] Falta de claridad y unidad alrededor de los objetivos del proyecto 12 55%[ ] Especificación de requerimientos incompleta, ambigua, inconsistente 12 55%[ ] Inadecuado manejo de control de Cambios 13 59%[ ] Cambios en los objetivos 16 73%[ ] Errores en la planeación del Proyecto (Poca precisión para estimar el tiempo y los recursos) 17 77%
Rol pasivo de TI respecto al Negocio, Ineficiente gestión de proyectos, inexistencia de una metodología dirigida- reutilización
falta de metodologías, malas contrataciones con terceros se le da mucho peso al precio de las ofertas
De los resultados obtenidos podemos resaltar lo siguiente:
Errores en la planeación del Proyecto (Poca precisión para estimar el
tiempo y los recursos) obtuvo un 77,27%, resultado que la posiciona como
la principal causa del fracaso de los proyectos de TI dentro de las
compañías del GEA en las que se realizo la investigación.
Parte de la problemática que ocasiona la poca precisión para estimar el
tiempo y los recursos se debe principalmente a que los proyectos de TI son
poco predecibles y con un alto nivel de riesgo inherente a la tecnología
misma. Algo adicional que contribuye a que esta precisión sea poca es el
hecho de no contar en las organizaciones con información estadística
acompañada de las lecciones aprendidas en cada uno de los proyectos que
se han desarrollado en el pasado y por lo tanto no se tienen referentes mas
precisos en los momentos de realizar este tipo de planeación.
58
Otra gran deficiencia que se tiene y que ocasiona esta falta de precisión
para estimar el tiempo y los recurso es la no utilización de técnicas o
herramientas como de WPS, el Gantt y el PERT y en general el que los
tiempos en muchos casos no son definidos por las personas que
directamente realizan las actividades, sino que estas son de alguna manera
“impuestas” o definidas por otros.
Se aprecia también el no empleo del tiempo suficiente para realizar con
rigurosidad la planeación del proyecto y además de tener como concepto
errado que la planeación del proyecto se limita a realización de un
cronograma. El cronograma en la mayoría de estas organizaciones es
símbolo de planeación, pues se tiene a confundir la etapa de planeación
de un proyecto, con la elaboración de un cronograma. Este aspecto nos da
ha entender que existen problemas de concepto en toda la disciplina y el
manejo de lo que se conoce como gerencia de proyectos.
Cambios en los objetivos obtuvo un 72,73%, ubicando a esta como la
segunda principal causa en importancia e incidencia en el fracaso de los
proyectos de TI.
A nivel mundial también se encuentra como una de las principales causas
del fracaso de los proyectos. La problemática detectada cuando ocurren
cambios en los objetivos o alcance en el proyecto se debe básicamente a
un manejo inadecuado del control de cambios y a problemas en el
gerenciamiento de los proyectos, ya que un cambio de objetivos cambia en
si el proyecto y por lo tanto este se debe replantear, realizar una nueva
planeación y las estimaciones necesarias para el nuevo alcance y el logro
de los nuevos objetos. Claramente si se cambian los objetivos del proyecto
se esta ante un nuevo proyecto. Este resultado no es de sorprender y va
59
muy alineado de la cultura organizacional y porque no decirlo de la
Colombiana. Somos muy dados a ser poco rigurosos en las definiciones de
lo que queremos y a abusar del ya que estamos haciendo esto , porque
no aprovechamos para hacer esto otro.
Inadecuado manejo de control de Cambios obtuvo un 59,09%, ubicándola
en el tercer lugar de importancia. Es muy común que en los proyectos se
presenten cambios o ajustes al mismo, y esto si es especialmente
evidenciado en proyectos de TI, debido principalmente a que conseguir las
especificaciones de lo que se desea lograr en el proyecto en las etapas de
definición con un alto grado de precisión y exactitud aun es complicado.
El entorno actual de los negocios y la velocidad con la que avanza la
tecnología hace inevitable el que se presenten cambios y ajustes en los
proyectos a lo largo de su ciclo de vida.
Esto hace indispensable contar con un proceso de manejo de cambios en
el proyecto que permita validar el impacto que tendrá sobre el alcance, los
recursos y el tiempo de tal forma que se pueda ajustar la planeación y las
estimaciones iniciales para que reflejen los cambios que surjan en los
diferentes momentos durante el ciclo de vida del proyecto. Aquí también
influye algo muy propio de la cultura en la que se realiza esta investigación
y es el “ya que”, la cual implica el que una vez se avanza en el desarrollo
del proyecto surgen nuevas alternativas o nuevas visiones u oportunidades
para adicionar otra funcionalidad o satisfacer ciertas necesidades que en
muchos casos se puede dejar para fases posteriores del proyecto, pero que
por la misma cultura se pretenda lograr mejor de una vez, sin la debida
conciencia del impacto que esto puede llegar a ocasionar en el proyecto.
Especificación de requerimientos incompleta, ambigua, inconsistente. Obtuvo un 54,55%, resultado que la ubica como la cuarta causa en
importancia o incidencia en el fracaso de los proyectos. Las deficiencias en
60
la especificación de los requerimientos, son principalmente debidas a una
falta de rigurosidad metodológica en las etapas iniciales del ciclo de vida
del proyecto y a la falta de una planeación adecuada. Esto no solo aplica
para los proyectos de TI sino en general para todo tipo de proyectos.
Otro factor que afecta esto es el que las herramientas y técnicas que se
tienen hasta este momento para definición de requerimientos aun no logran
los niveles de utilización y precisión tal que dejen poca cabida a una
insuficiente claridad en las definiciones de los requerimientos que se
realicen.
Falta de claridad y unidad alrededor de los objetivos del proyecto. Obtuvo un 54,55%. Esta causa identifica una deficiencia en la definición,
divulgación y en la conducción de los proyectos por parte de líder o
gerente del proyecto, pues una de sus principales responsabilidades es la
de mantener la unidad del equipo del proyecto alrededor de los objetivos
planteados en la definición de este, de tal forma que se puedan lograr.
No participación de áreas claves del negocio desde el inicio del proyecto. Obtuvo un 45,45%. La no participación de las áreas claves para el
proyecto, demuestra problemas en la estructura y madurez de la
organización en la gestión de proyectos y también deficiencias en el líder o
gerente de proyecto. La estructura jerárquica y funcional de las empresas
no facilita la gestión por proyectos.
No utilización, o mala utilización de metodologías de Gerencia de Proyectos. Obtuvo un 40,91%. Dado que el 68,18% de los encuestados
dicen utilizar o tener algún tipo de metodología este resultado demuestra
que si bien existe la metodología para la gerencia de proyectos en las
61
empresas estudiadas, estas no son utilizadas o bien utilizadas para ayudar
a mejorar el desempeño de los proyectos, o las metodologías no estas
adecuadas para el manejo de los proyectos de TI, que claramente tiene
sus singularidades y su ciclo de vida particular.
Poca claridad e inadecuada asignación de las responsabilidades. Obtuvo
un 40,91%. Esto demuestra problemas en la conducción de los proyectos,
así como problemas en las fases de planeación, que claramente ocasiona
problemas durante la ejecución del proyecto. El no tener claridad sobre las
responsabilidades de cada integrante del equipo durante el desarrollo del
mismo, impide el buen de desempeño del equipo y por lo tanto no genera
las eficiencias y las sinergias que se derivan del trabajo en equipo
ordenado y bien estructurado. Esta dificultad se evidencia aun mas por
hecho de que la compañía tiene una estructura funcional y no de proyectos,
no queriendo decir que se debe cambiar sino que se deben implementar
mecanismos para facilitar la labor de los integrantes de las diferentes áreas
en los proyectos.
4.7 ALGUNAS INTERPRETACIONES Y CONCLUSIONES
La primer apreciación que se encuentra según los resultados es que las
causas del fracaso de los proyectos de TI esta claramente identificadas con las
causas encontradas en el contexto internacional. Por lo tanto la problemática
alrededor del tema es muy similar en términos generales.
Tomando estos ocho factores ya ratificados, se puede concluir que existen
unas claras deficiencias en la administración o gerencia de proyectos de TI,
ocasionadas en parte por una desconocimiento de las disciplina de gerencia
62
de proyectos y en otra por la falta de una metodología, unas políticas, unos
procesos, procedimientos, técnicas y herramientas apropiadas. Además no el
tema no se queda en la falta de la metodología sino en la falta de disciplina,
cultura y conocimientos para aplicar estos conceptos en los proyectos de TI.
Claramente la cultura organizacional tiene un gran impacto en la forma de
gerenciar los proyectos y en la falta de esta disciplina para aplicar las pocas
metodologías o directrices que se tiene al respecto. Pues si bien al responder
la encuesta y en las entrevistas a profundidad se identifican estas como las
causas de los problemas que se presentan en los proyectos, las excusas
comunes son la falta de tiempo y el poco entrenamiento que tienen las
personas en gerencia de proyectos.
Aprovechando la experiencia y conocimientos que tiene el investigador, se
puede decir que existe un bajo nivel de rigurosidad en la planeación de los
proyectos y en general de las actividades realizadas, la improvisación es
mucha y la disciplina es poca. Los resultados en los proyectos se logran mas
por las presiones y el gran esfuerzo en tiempo para hacer que las cosas se
logren, que por un proceso organizado, coordinado y eficiente.
Al no contar con documentación sobre proyectos anteriores y estadísticas de
proyectos pasados, se tienen grandes dificultades para las estimaciones, las
estimaciones se hacen mas tratando de cumplir con las fechas impuestas, que
de una forma realista basada en datos verdaderos o de referencia de
proyectos o actividades similares, además se ignora en muchos casos la
opinión sobre rendimiento de la persona o grupo de personas que ejecuta
directamente cada una de esta actividades del proyecto. Esto claramente
genera un riesgo mayor de incumplimiento en los tiempos comprometidos
desde inicio de los proyectos. De nuevo aquí se evidencia, según la
información obtenida, el impacto que tiene la cultura de la organización en la
forma y en el desempeño de los proyectos y mas particularmente en los
proyectos objeto de este estudio, los proyectos de TI. La poca disciplina y
rigurosidad para realizar la planeación de estos es también un aspecto
63
evidenciado en muchas otras actividades de gestión de la empresa. La
urgencia en las actividades diarias, el asumir compromisos con fechas poco
realistas, el desborde en la capacidad de trabajo de los recursos no permite
que aun con el conocimiento y la disposición de llevar a cabo los proyectos
con metodología, buenas practicas y técnicas, esto se logre. Generando con
esto un ciclo de no acabar y es de no tener tiempo para realizar de una
manera mas estructurada y con las técnicas apropiadas la gerencia de los
proyectos, pero de igual forma los proyectos no terminan en los tiempos y con
la calidad acordados en parte porque la manera poco planeada y organizada
con la que son realizados, generando perdida de tiempo, reprocesos,
inconformidades y costos de oportunidad para la compañía.
Aspectos como la planeación a todo nivel, la formalización de los procesos y
la comunicación, la documentación y la coordinación de los proyectos entre
otros, no se encuentran aun en grado de madurez que permita de una manera
rápida implementar una metodología rigurosa para la gerencia de proyectos.
Por lo tanto el modelo de gerencia de proyectos que se pretenda proponer en
esta investigación debe estar enfocado en facilitar una implementación gradual
y muy practica, de retroalimentación y aprendizaje constante y claramente
adecuado a la cultura de la empresa. Que no solo diga que se debe hacer en
los casos específicos de los proyectos de TI de forma genérica sino que
induzca de forma sutil y a manera de guía la forma como se deben llevar a
capo cada una de las etapas del ciclo de vida del proyecto.
En los resultados obtenidos se encuentra que las fases donde se generan más
errores en los proyectos son las fases de Formulación, Visión y Planeación,
que al hacerse con vaguedad, poca rigurosidad e imprecisiones, provoca
muchos de los problemas ya enunciados. Pero es precisamente la
metodología de gerencia de proyectos la que permite mitigar estos factores y
64
de esta forma disminuir los riesgo de fracaso, con lo cual se incrementa la
probabilidad éxito de estos.
Si bien el desarrollo e implementación de proyectos de TI puede ser
extremadamente complejo, lo que contribuye a que sean mas difíciles y de
mayores riesgos, con los datos obtenidos podemos decir firmemente que la
tecnología en sí no es el único ni el principal factor en el fracaso de los
proyectos de TI en este caso. De las investigaciones realizadas se encuentra
que el existo o fracaso de los proyectos de TI esta mas relacionado con las
personas y los procesos que se realizan que con las tecnología en si.
Figura 6. Resultados de criterios de éxito en los proyectos. Según encuesta.
Causas de Exito de los proyectos de TI
02468
1012141618
Otros,
Proyectos Cortos
Adecuado manejo de Riesgos
Utilización de m
etodologías de Gerencia de Pro...
Cultura de trabajo por p
royectos en la organiza
ción
Buenos conocim
ientos y Habilidades p
ara Gere...
Buenas estra
tegias de conducció
n, seguimient..
Adecuado manejo de contro
l de Cambios
Gran compromiso
y sentido de pertenencia del ...
Buena planeación del Proyecto
(Precisió
n para ...
Un plan de aseguramiento de la calidad del proy...
Especificación de re
querimientos c
ompleta, clara..
Participació
n y compromiso de áreas claves des..
Claridad y unidad alrededor de los objetivo
s del..
Claridad y una adecuada asignación de las re
...
Recurso Humano co
mpetente
Conocimiento de la tecnología
Trabajo en Equipo y sentido de pertenencia
Causas
Num
ero
Rpt
as y
%
TOTAL Resp
%
65
11. Cuáles son las causas del Éxito de los proyectos de TI
TOTAL
Resp %
Otros, 1 5%
Proyectos Cortos 7 32%
Adecuado manejo de Riesgos 8 36%
Utilización de metodologías de Gerencia de Proyectos 8 36%
Cultura de trabajo por proyectos en la organización 9 41%
Buenos conocimientos y Habilidades para Gerenciar Proyectos 9 41%
Buenas estrategias de conducción, seguimiento, control, comunicación y manejo del
conflicto 10 45%
Adecuado manejo de control de Cambios 11 50%
Gran compromiso y sentido de pertenencia del usuario líder del proyecto 12 55%
Buena planeación del Proyecto (Precisión para estimar el tiempo y los recursos) 12 55%
Un plan de aseguramiento de la calidad del proyecto 12 55%
Especificación de requerimientos completa, clara y consistente 12 55%
Participación y compromiso de áreas claves desde el inicio del proyecto 13 59%
Claridad y unidad alrededor de los objetivos del proyecto 14 64%
Claridad y una adecuada asignación de las responsabilidades en el equipo de trabajo 14 64%
Recurso Humano competente 15 68%
Conocimiento de la tecnología 16 73%
Trabajo en Equipo y sentido de pertenencia 17 77%
Lo anterior corrobora aun mas y posibilita el espacio para plantear un modelo
de gestión de proyectos que permita, disminuir la probabilidad de ocurrencia
de las causas o los factores de fracaso anteriormente identificados, mediante
una practica de administración de proyectos formal y de esta forma iniciar un
mejora en el desempeño de los proyectos de TI.
66
El modelo que se desarrolle, se debe mantener sobre un premisa ya
planteada, y es que debe ser de fácil aplicación en cuanto a la metodología, lo
que implica que esta no debe ser genérica sino muy particularizada al tipo de
proyectos estudiado, y que las características organizacionales de las
empresa(s) estudiada(s), deben ser contempladas por el modelo como un
aspecto muy importante para lograr mayor éxito en la implementación de la
metodología de gestión de proyectos de TI.
67
CAPITULO V MARCO GENERAL PARA EL
DESARROLLO DE LA METODOLOGÍA DE PROYECTOS
68
5. MARCO GENERAL PARA EL DESARROLLO DE LA METODOLOGÍA DE PROYECTOS
Para desarrollar la guía metodológica en la gestión de proyectos de TI, primero
revisaremos el enfoque de los proyectos en las organizaciones y después
abordaremos una breve descripción de la metodología del PMI (Project
Management Institute) y el MSF (Microsoft Solution Framework), las cuales son la
base del desarrollo de la metodología que se plantea.
5.1 INTRODUCCIÓN Como pilar de la transformación de las estrategias corporativas en acciones
concretas tenemos que los proyectos enlazan las estrategias corporativas con los
resultados operativos de la siguiente manera:
Figura 7. Proyectos -Estrategias corporativas
Fuente: Una metodología básica para la dirección de proyectos. Alberto López, PMP.
69
La secuencia de procesos para lograr este enlace entre las estrategias y los
resultados operativos las podemos ver de la siguiente manera:
Figura 8. Secuencia de procesos para enlace con las estrategias.
Fuente: Una metodología básica para la dirección de proyectos. Alberto López, PMP. Aunque estas 5 fases: planificación, análisis de alternativas, definición de la
alternativa, implementación y posterior evaluación y retroalimentación, son
regularmente ejecutadas en los proyectos que se abordan en las empresas, el
factor diferenciador y el que ayuda a resolver muchos de los problemas que no
permiten lograr el éxito en los proyectos, es la forma en la que se realizan estas
etapas, pues con regularidad estas no son elaboradas correctamente y
eficientemente.
5.2 EL ENFOQUE PARA EL DESARROLLO DE LA METODOLOGÍA DE PROYECTOS
70
El enfoque que se abordara en este trabajo esta orientado a desarrollar un
metodología práctica y flexible a partir de la mejores practicas a nivel mundial,
basados en el modelo de gestión de proyectos del PMI, que permita gestionar los
proyectos de TI en cada una de estas etapas de la forma correcta y bien
elaboradas, con un aspecto muy importante como lo es el de aprendizaje y
retroalimentación de la misma metodología que permita seguirse adaptando y
perfeccionando.
Después de estudiar varias de las metodologías de gerencia de proyectos, se
decide utilizar como base del modelo de gestionar proyectos de TI la metodología
promovida por el PMI llamada método PMI® o PMBOK® Guide, Se ha
seleccionado la metodología de gestión de proyectos del PMI® (Program
Management Institute), ya que por su profundidad y coherencia se ha convertido
en un estándar ampliamente utilizado en todo el mundo y en nuestro medio,
actualmente esta guía es reconocida por ANSI e ISO como un estándar para la
gestión de proyectos siendo utilizada por más de 100,000 profesionales
certificados por PMI® en todo el mundo. Siendo por lo tanto base de muchas de
las metodologías de los distintos proveedores de las empresas estudiadas.
Además de reconocer su gran valor y aporte que sobre el tema ha hecho en el
mundo de la academia. Adicionalmente porque aunque esta metodología tiene un
carácter genérico, para este caso específico permite complementarla con el MSF
(Microsoft Solutions Framework), metodología en la que el investigador encuentra
aportes metodológicos específicos a la problemática encontrada y muy prácticos
para su implementación en el tipo de proyectos de TI objeto de esta investigación.
También se incorporaran suplementos y técnicas para que el modelo tenga en
cuenta las principales características organizacionales de las empresas que como
ya se ha expuesto, es uno de los puntos débiles al emplear las metodologías
genéricas como es el caso del PMI, ya que dentro de los temas encontrados en
las investigaciones realizadas sobre el fracaso de los proyectos, esta el no
71
emplear metodologías adecuadas y en los casos en los que se usan las
metodologías, se encuentra que por su carácter genérico su implementación se
hace difícil y su utilización también, debido a que la cultura y las características
organizacionales influyen significativamente en la forma de realizar las
actividades en cada empresa. Para esto se aprovechara la información y los
aportes de GONZALO MONTES en su documento “ METODOLOGÍA PMI®
COMPLEMENTADA PARA GESTIONAR PROYECTOS DE DESARROLLO DE
SOFTWARE Y DE IMPLANTACIÓN DE APLICACIONES DE ALTO IMPACTO EN
LAS ORGANIZACIONES“26. (Se utilizaran textualmente capítulos de su
documento). Las características organizacionales que se proponen tener en cuenta en el
documento de Gonzalo Montes, con lo cual se busca tener más éxito en el
desarrollo de los proyectos, son: • Los proyectos de tecnología de información de alta complejidad impactan en
forma directa los procesos vigentes y por tanto la manera como los grupos
humanos hacen las tareas dentro de la empresa. • La cultura organizacional de las empresas tiene una influencia directa en el
desarrollo y los resultados del proyecto de tecnología de información. • El equipo de proyecto y su líder formal, el gerente de proyecto, juegan un papel
decisivo en el desarrollo de cada una de las fases del proyecto.
• La formación académica, la experiencia de los miembros del equipo de proyecto y
sus interrelaciones influyen notablemente en el éxito relativo del proyecto.
26 MONTES, Gonzalo, Metodología PMI® complementada para gestionar proyectos de desarrollo de software y de implantación de aplicaciones de alto impacto en las organizaciones, ACIS, Bogota, Noviembre de 2002; p. 1-29
72
5.3 MARCO GENERAL Tomado del documento de GONZALO MONTES “METODOLOGÍA PMI®
COMPLEMENTADA PARA GESTIONAR PROYECTOS DE DESARROLLO DE
SOFTWARE Y DE IMPLANTACIÓN DE APLICACIONES DE ALTO IMPACTO EN
LAS ORGANIZACIONES“. Porque su propuesta y aporte son de gran relevancia y
valor en el tema de esta investigación.
5.3.1
5.3.2
Metodología de gestión de proyectos – pmbok® Guide. Dado que la
metodología del PMBOK® será la base para el desarrollo del modelo de gestión
de proyectos propuesto de TI, se hará en esta sección un breve resumen de las
componentes y estructura del libro PMBOK® Guide versión de 2000, creando de
esta forma un marco general de esta metodología, que permita el entendimiento
de la misma par su aplicación tanto de los conceptos como de las guías
recomendadas por esta.
Se incluye solamente un resumen de este libro ya que el presente documento no
pretende reemplazarlo sino complementarlo, para lo cual es necesario que el
lector tenga una idea muy clara de lo que es y representa el PMBOK® Guide en la
comunidad internacional de gestión de proyectos.
Resumen de pmbok® guide. En varios apartes se emplean traducciones
literales de PMBOK® Guide para mantener la interpretación objetiva de los
conceptos explicados allí.
5.3.2.1 Introducción del libro PMBOK® Guide 27. El término Project Management
Body of Knowledge, en adelante PMBOK, describe la suma (acumulación) del
27 MONTES, Gonzalo, Metodología PMI® complementada para gestionar proyectos de desarrollo de software y de implantación de aplicaciones de alto impacto en las organizaciones, ACIS, Bogota, Noviembre de 2002; p. 1-29
73
conocimiento dentro de la profesión de Gestión de Proyectos. Como sucede con
otras profesiones el cuerpo de conocimiento se apoya y crece con los practicantes
y académicos que lo aplican y que avanzan con éste. PMBOK incluye
conocimiento probado y prácticas tradicionales las cuales son ampliamente
aplicadas así como conocimiento de prácticas innovadoras y avanzadas en
proyectos.
El principal propósito de la guía es identificar y describir el subconjunto de PMBOK
el cual es generalmente aceptado. Esto significa que el conocimiento y las
prácticas son aplicables a muchos proyectos la mayoría de las veces y que existe
un amplio consenso acerca de su valor y su utilidad. “Generalmente aceptado” no
significa que el conocimiento y las prácticas son o deberían ser aplicadas
uniformemente en todos los proyectos; el equipo de gestión de proyectos siempre
es el responsable en determinar lo qué es apropiado para un proyecto dado.
La guía también intenta dar una terminología común dentro de la profesión cuando
se hable acerca de gestión de proyectos.
El documento suministra una referencia básica para cualquier persona interesada
en la profesión de gestión de proyectos. Está dirigida a:
• Gerentes de proyectos y otros miembros de los equipos de proyectos.
• Gerentes de gerentes de proyectos.
• Clientes de proyectos y otros posibles usuarios.
• Gerentes funcionales con responsabilidades asignadas en equipos de proyectos.
• Personas que enseñen gestión de proyectos.
• Consultores y otros especialistas en gestión de proyectos y campos afines.
• Entrenadores que desarrollan programas de educación de gestión de proyectos.
74
Este documento también es usado por el Project Management Institute para
brindar una estructura consistente para sus profesionales que desarrollan
programas que incluyen:
• Certificación a Profesionales de Gestión de Proyectos (PMPs).
• Acreditación en graduación de programas de educación en gestión de proyectos.
5.3.3 Aspectos fundamentales del libro PMBOK® Guide .
Aspecto 1: Definición de Gerencia de Proyectos de acuerdo con PMBOK® Guide: “Gerencia de proyectos es la aplicación de conocimiento, habilidades,
herramientas y técnicas a las actividades de un proyecto para alcanzar los
requerimientos del mismo. Alcanzar o exceder necesidades o expectativas de
todos los involucrados invariablemente involucra balancear las demandas a través
de:
• Alcance, tiempo, costo y calidad.
• Grupo de personas involucradas con diferentes expectativas y necesidades.
• Requerimientos identificados (necesidades) y requerimientos no identificados
(expectativas).”
Aspecto 2: Áreas de Conocimiento de Gestión de Proyectos
La guía PMBOK® está dividida en dos partes. La primera parte es llamada “El
Marco de Gestión de Proyectos”. Provee una estructura básica de entendimiento
de la gestión de proyectos. La segunda parte son las Áreas de Conocimiento de
Gestión de Proyectos. Describe el conocimiento de la gestión de proyectos y su
75
práctica en términos de sus procesos que la componen. Estos procesos han sido
organizados en nueve áreas de conocimiento (Véase el siguiente Cuadro).
Figura 9. Áreas de conocimiento de la gestión de proyectos y los procesos de gestión de proyectos. PMBOK® Guide.
Gestión del Proyecto
Gestión de Integraión
76
Gestión de la Integración del Proyecto: Describe los procesos requeridos para
asegurar que todas las componentes del proyecto son coordinados en forma
apropiada. Consiste del desarrollo del plan del proyecto, ejecución del plan del
proyecto y control general del cambio.
Gestión del Alcance del Proyecto: Describe los procesos requeridos para
asegurar que el proyecto incluye todo el trabajo requerido y únicamente el trabajo
requerido, para finalizar el proyecto satisfactoriamente. Consiste de la iniciación, la
planeación del alcance, la definición del alcance, la verificación del alcance y el
control del cambio del alcance.
Gestión del Tiempo del Proyecto: Describe los procesos requeridos para
asegurar la finalización a tiempo del proyecto. Consiste de las actividades de
77
definición, secuencia de actividades, estimación de la duración de las actividades,
desarrollo del cronograma y control del cronograma.
Gestión de Costos del Proyecto: Describe los procesos requeridos para
asegurar que el proyecto es finalizado dentro del presupuesto aprobado. Consiste
de la planeación de recursos, estimación de costos, presupuesto de costos y
control de costos.
Gestión de Calidad del Proyecto: Describe los procesos requeridos para
asegurar que el proyecto cumplirá con las necesidades para las cuales éste fue
emprendido. Consiste de la planeación de la calidad, aseguramiento de la calidad
y control de la calidad.
Gestión de Recursos Humanos del Proyecto: Describe los procesos requeridos
para hacer más efectiva la participación de la gente involucrada con el proyecto.
Consiste de la planeación organizacional, conformación del equipo humano y
desarrollo del equipo.
Gestión de Comunicaciones del Proyecto: Describe los procesos requeridos
para asegurar a tiempo y apropiadamente la generación, recolección,
diseminación, almacenamiento y disposiciones de la información del proyecto.
Consiste en el plan de comunicaciones, distribución de la información, reportes de
ejecución y cierre administrativo.
Gestión de Riesgo del Proyecto: Describe los procesos relacionados con
identificación, análisis y respuesta a los riesgos del proyecto. Consiste en la
identificación del riesgo, cuantificación del riesgo, desarrollo de respuesta al riesgo
y control de respuesta al riesgo.
78
Gestión de Adquisición del Proyecto: Describe los procesos requeridos para
adquirir bienes y servicios a partir de proveedores. Consiste en la planeación de la
adquisición, planeación de la solicitud, solicitud, selección de la fuente,
administración del contrato y cierre del contrato.
Aspecto 3: Agrupamiento de Procesos de Gestión de Proyectos
“Los proyectos están compuestos de procesos. Un proceso es una serie de
acciones que conducen a un resultado. Los procesos de los proyectos son
ejecutados por personas y generalmente se presentan en dos categorías:
• Procesos de gestión del proyecto. Se relacionan con describir y organizar el
trabajo del proyecto.
• Procesos orientados al producto. Se relacionan con especificar y crear el
producto del proyecto. Son típicamente definidos por el ciclo de vida del proyecto y
varían según el área de aplicación donde se desenvuelve el proyecto.
Estos dos tipos de procesos interactúan permanentemente a lo largo del desarrollo
del proyecto.
Los procesos de gestión del proyecto pueden ser organizados en cinco grupos de
uno o más procesos cada uno:
• Procesos de iniciación: Donde se reconoce que un proyecto o una fase
debe comenzar y se establece el compromiso para hacerlo.
79
• Procesos de planeación: Proyecta y mantiene un esquema trabajable
para lograr que las necesidades del negocio, en las que está empeñado el
proyecto, se cumplan.
• Procesos de ejecución: Coordina a las personas y a otros recursos para
llevar a cabo el plan.
• Procesos de control: Asegura que los objetivos del proyecto son
alcanzados a través de monitoreo y medición del progreso del proyecto,
tomando acciones correctivas cuando sea necesario.
• Procesos de cierre: Formaliza la aceptación del proyecto o de una fase y
lo conduce hacia un final ordenado.
Estos grupos de procesos se relacionan entre sí, como se aprecia en el siguiente
gráfico:
Figura 10. Grupo de Procesos de la Gerencia de Proyectos
80
Aspecto 4: Interrelación entre los procesos de gestión de proyectos y las áreas de conocimiento. Cada una de las 37 áreas de conocimiento descritas en el PMBOK® Guide se
utilizan durante el desarrollo de un proyecto, en las cinco fases descritas
anteriormente.
“Dentro de cada grupo de procesos, los procesos individuales están enlazados por
sus entradas y sus salidas. Con el enfoque de estos enlaces se puede describir
cada proceso en términos de:
• Entradas: Documentos o “ítems documentables“ que serán realizados.
• Herramientas y técnicas: Mecanismos aplicados a las entradas para crear las
salidas.
• Salidas: Documentos o “ítems documentables“ que son el resultado de un
proceso.”
A continuación se representan gráficamente los procesos de gestión de proyectos
y sus interrelaciones. Los números en cada gráfico identifican el capítulo y la
sección donde está descrito el proceso respectivo dentro del libro original
PMBOK® Guide.
Figura 11. Proceso de Iniciación
81
Figura 12. Procesos de Planeación.
82
Figura 13. Procesos de Ejecución.
83
Figura 14. Procesos de Control.
84
Figura 15. Procesos de Cierre.
85
5.3.4 Implicaciones sobre los procesos de gestión de proyectos. En esta
sección se explica el conjunto de implicaciones sobre las componentes de gestión
organizacionales que influyen decididamente en los proyectos, con el fin de
estructurarlas en el aporte al método de gestión de proyectos PMI® que realiza
Gonzalo Montes en su documento.
El modelo general al que se ha llegado es el que se ilustra con el siguiente gráfico: Figura 16. Modelo general Gonzalo Montes
Se han deducido cuatro implicaciones: • Implicaciones a nivel de equipos de proyecto. Orientadas al recurso humano
que participa en el proyecto en forma directa.
• Implicaciones a nivel de la metodología del PMBOK® Guide. Orientadas a
los espacios que no cubre la metodología estándar.
86
• Implicaciones a nivel de la organización. Orientadas al recurso humano y sus
interrelaciones dentro de las organizaciones.
• Implicaciones a nivel de la globalización. Orientadas hacia la armonía que
debe existir entre los tres aspectos anteriores.
En las siguientes secciones se describen estas implicaciones y sus relaciones con
la gestión de proyectos.
5.3.5
5.3.6
Desde el punto de vista académico. Se describen las implicaciones
académicas desde las ópticas de formación integral y profesional.
Formación integral. En términos generales las universidades saben que
el mundo esta cambiando y para esto la formación de sus profesionales debe ser
más integral y conforme con las expectativas y dinámica de las empresas en
materia de proyectos.
La incorporación de materias asociadas con proyectos se considera como un
punto importante para la formación integral, porque le permiten al estudiante
conocer y acercarse más a todos los aspectos de la realidad laboral.
Otras posibles áreas de conocimiento como administración de riesgo, tendencias y
metodologías de calidad, entendimiento del entorno empresarial, comunicaciones,
negociación y resolución de problemas hará de los profesionales personas más
integrales y por tanto más efectivos en el entorno de proyectos de tecnología de
información de alto impacto.
Una complementación ideal para que los estudiantes ganen experiencia en
proyectos, durante las etapas de formación académica, es que participen en
87
proyectos asignados a las Universidades por la empresa pública o privada.
También a través de las vivencias profesionales del profesorado.
Como conclusión de este aparte los aspectos de la formación académica que
potencian los aportes de un profesional que integra equipos de proyectos son los
siguientes:
5.3.6.1 Aspectos de formación académica.
Aspectos de Formación Académica Ética, valores y humanística Materias preferiblemente asociadas con: Gestión de Proyectos (varios semestres) Formación Empresarial Enfoque Organizacional Tecnología de Información Economía Sistemas de Información Recursos Humanos Tecnología y Sociedad Trabajo en equipo Manejo de buenas relaciones personales Entendimiento del entorno empresarial Comunicaciones Negociación y resolución de problemas Talleres de gestión de proyectos basados en vivencias en proyectos del profesorado
5.3.7 Desde el punto de vista metodológico. Una vez revisado la estructura
y contenido del libro “A Guide to the Project Management Body of Knowledge”,
PMBOK® Guide, se pueden mencionar las siguientes conclusiones:
88
• La guía dedica los capítulos II y III (The Project Management Context y Project
Management Processes respectivamente) para ambientar a los lectores en los
procesos generales de gestión de proyectos los cuales son, en algunos aspectos,
muy similares a los procesos de gestión de otras disciplinas.
• El capítulo III especialmente menciona las variables que, desde la perspectiva
que nos interesa (idiosincracia, cultura organizacional y formación académica),
inciden marcadamente en los proyectos tecnológicos.
• La guía no profundiza sobre las aproximaciones, los métodos y las estrategias
que se deberían emplear en estos casos para lograr mayor éxito en los proyectos
porque perdería la generalidad que se busca al estar constituida. La guía particularmente indica que los aspectos claves de gestión a ser
considerados dentro del contexto de gestión de proyectos y que a su vez son
esenciales considerar para lograr los objetivos del presente estudio, son:
- Agentes interesadas con el proyecto o involucrados en el proyecto
(stakeholders).
- Influencia organizacional (Cultura y Estructura).
- Principales destrezas generales de gestión en los líderes y miembro del
proyecto.
- Influencias socioeconómicas.
Como ya se menciono, al no profundizar el PMBOK® Guide sobre los aspectos
socioculturales que a nivel región, país y empresa pueden afectar el éxito de los
proyectos, Gonzalo Montes en su documento “Metodología PMI® complementada
para gestionar proyectos de desarrollo de software y de implantación de
aplicaciones de alto impacto en las organizaciones”, propone complementar el
método de gestión de proyectos descrito en el libro PMBOK® Guide, haciendo
énfasis en las destrezas no técnicas del recurso humano y en las características
89
organizacionales. En las siguientes secciones se encuentra el aporte sobre este
tema, el cual es de vital importancia y relevancia para esta investigación y para el
modelo de gestión reproyectos de TI que se propone como resultado de trabajo
realizado.
5.3.8
Desde el punto de vista empresaria. En esta sección se encuentran los
aspectos más esenciales que en una organización se deben tener en cuenta,
cuando los proyectos de tecnología de información, en nuestro medio, fallan por
causas que obedecen exclusivamente a las características de la organización.
• Diagnóstico desde la perspectiva de antecedentes de proyectos. El estudio de
KPMG Peat Marwick28 concluye con el siguiente conjunto de preguntas que
permiten diagnosticar el grado de complejidad que trae consigo un proyecto de
transformación en una empresa, tal como lo son los proyectos de tecnología de
información de alto impacto.
a) Conoce usted el nivel de “compromiso real”, que el proyecto tiene, de todos los
miembros de la alta dirección?
b) Existe total claridad de la visión, misión y valores de la organización y su
relación con el proyecto?
c) El personal de la organización ha entendido y dimensionado la importancia que
tiene el cambio para la empresa?
d) Ha identificado los principales factores de riesgo que podrían afectar el
compromiso y apoyo en el proyecto, por parte de los diferentes niveles de la
organización?
28 KPMG Peat Marwick. Benchmarking sobre Procesos de Transformación en Colombia. Santafé de Bogotá: 1997
90
e) Ha considerado estrategias y mecanismos que le aseguren controlar y
minimizar el impacto de estos factores?
f) Qué tan capacitados están los equipos de implantación para desarrollar
exitosamente el plan de implementación? Cuentan con la formación y experiencia
que requiere de ellos el cambio, como para direccionar los aspectos humanos del
proyecto?
g) Qué tanto nivel de resistencia percibe usted que se presentará en los usuarios
del cambio, como consecuencia de la adopción del nuevo esquema de trabajo?
h) Ha considerado las manifestaciones resistentes que podrían aparecer en mayor
proporción por cada área impactada?
i) Ha establecido cuál es el nivel de consistencia o inconsistencia que tiene el
cambio con la cultura existente en la organización?
j) Está usted en capacidad para administrar las variables técnicas y humanas de la
transformación?
Por otro lado los estudios de la Universidad de los Andes29 relacionados con los
procesos de desarrollo de software resaltan los siguientes aspectos, no técnicos, que influyen en la calidad de los proyectos. a) Administración de Requerimientos.
b) Planeación del Proyecto.
c) Seguimiento del Proyecto.
d) Administración Subcontratación.
29 CIFUENTES C, Iván Fernando. Estado del proceso de desarrollo de software en Colombia. Memos de Investigación; No. 233 Centro de Documentación de Ingeniería, Facultad de Ingeniería, Universidad de los Andes. Santafé de Bogotá: 1996
91
e) Aseguramiento de la Calidad.
f) Enfoque en la Organización del Proceso.
g) Definición de la Organización del Proceso.
h) Coordinación Intergrupal.
i) Revisión de Colegas.
j) Administración del Cambio del Proceso.
El resultado de estos estudios en el medio colombiano se puede comparar con el
resultado de proyectos exitosos y deficientes a nivel mundial, tal como lo reflejan
las causas del informe Chaos30 relacionadas con razones no técnicas.
a) Razones de éxito en proyectos exitosos (Informe Chaos).
b) Participación de los Usuarios.
c) Apoyo de la Alta Gerencia.
d) Expectativas Reales.
e) Recurso Humano Competente.
f) Sentido de Pertenencia.
g) Claridad en la visión y objetivos.
h) Trabajo en Equipo.
Razones de fracaso en proyectos con inconvenientes o cancelados (Informe Chaos). a) Falta de Participación de los Usuarios.
b) Cambios en las Especificaciones y Requerimientos.
c) Escaso Apoyo de la Alta Gerencia.
d) Expectativas no Alcanzables.
e) No claridad en los objetivos.
f) Deficiente Gestión de IT.
30 http://standishgroup.com/visitor/chaos.html
92
Con base en los informes de la Universidad de los Andes y del Informe Chaos, se
pueden sintetizar las razones organizacionales de éxito y de fracaso de proyectos
así:
Razones organizacionales que influyen en el éxito de los proyectos de tecnología de información
Administración de Requerimientos Planeación del Proyecto Seguimiento del Proyecto Administración Subcontratación Aseguramiento de la Calidad Enfoque en la Organización del Proceso Definición de la Organización del Proceso Coordinación Intergrupal Revisión de Colegas Administración del Cambio del Proceso Involucramiento de los Usuarios Apoyo de la Alta Gerencia Expectativas Reales Recurso Humano Competente Sentido de Pertenencia Claridad en la visión y objetivos Trabajo en Equipo Falta de capacitación de los líderes o los miembros o los consultores Falta definición roles y responsabilidades de los actores
• Diagnóstico desde la perspectiva empresarial. Como síntesis de las
características de las organizaciones que influencian el éxito relativo de los
proyectos se tiene las siguientes.
93
Características de las organizaciones
Característica Descripción Estructura a. Formalización Documentación escrita, políticas,
procedimientos, regulaciones b. Especialización Grado de tareas organizacionales por
persona c. Estandarización Desempeño uniforme de tareas d. Complejidad vertical Cantidad de niveles existentes en la
jerarquía e. Centralización Nivel jerárquico que se tiene para
tomar decisiones f. Profesionalismo Nivel de educación formal del equipo
de proyecto Cultura Corporativa
a. Valores Organizacionales • Ingresos / Misión-Cliente
Orientación de los resultados corporativos
• Control / Empoderamiento
Delegación y autoridad
• Departamentalizada / Integrada
Relaciones entre los empleados
• Control de Calidad / Mejoramiento Continuo
Actitud corporativa para superar expectativas
b. Valores de Liderazgo • Desconfianza / Confianza
Relación líder con sus colaboradores
• Cerrada / Abierta
Calidad de la comunicación
• Juicio / Apoyo-Soporte
Objetividad de las relaciones
• Independencia / Trabajo en Equipo
Sentido de cooperación
• Crédito personal / Crédito compartido
Reconocimiento
• Servir al jefe / Servir al cliente
Relación colaborador superior inmediato
Ciclo de Madurez Etapas que caracterizan el desarrollo de una organización
94
• Diagnóstico desde la perspectiva de líder de proyectos y su equipo de trabajo. El líder de proyectos en Colombia tiene muchas características importantes que
son definidas muy bien por Ogliastri y por Miranda31, donde ambos autores
presentan un diagnóstico bien preconcebido de los estados actuales y deseados
de estos líderes.
Desde este punto de vista podemos presentar un diagnóstico para éste trabajo con base en estos estudios, así: Diferencia entre líder y gerente
LIDER GERENTE • Estratégico, ve el conjunto • Visión de largo plazo • Trabaja con la gente • Es flexible • Ambicioso • Anticipa • Tiene poder personal
• Operativo • Visión de corto plazo • Individualista • Es inflexible • Metas normales • Vive en urgencias • El puesto le da poder
Adicionalmente son interesantes las conclusiones de estos dos autores que
aunque no reflejan el estado de todas las empresas en Colombia, sí reflejan el
estado actual de las empresas más destacadas en el área de liderazgo gerencial,
que a su vez aplican para los líderes de los proyectos de tecnología de
información.
31 OGLIASTRI, Enrique. El liderazgo organizacional en Colombia, un estudio cualitativo. Revista Universidad EAFIT.. Enero - Marzo, 1997. MIRANDA MIRANDA, Juan José Gestión de Proyectos. Identificación, Formulación, Evaluación Financiera, Económica, Social, Ambiental. MM Editores, 2000.
95
Factores claves como las relaciones humanas, la visión de futuro, el estilo
gerencial administrativo (trabajo en equipo), la capacidad para realizar cambios de
fondo dentro de las organizaciones, y algunos otros aspectos como la integridad
personal, la capacidad innovadora y el trabajo por objetivos son determinantes
para el buen desarrollo de los proyectos de tecnología.
Podemos deducir que en las empresas donde no halla un perfil de gerentes de
proyectos como el descrito anteriormente, es muy probable que cualquier
desarrollo de proyecto no sea llevado tan eficaz ni eficientemente como se
esperaba.
Otro factor fundamental es el estado de desarrollo de los equipos de proyectos, de
cómo están calificados de acuerdo con su madurez en las empresas. Este factor
es muy bien tratado por la Stackhouse Garber & Associates, del cual podemos
extraer el siguiente cuadro para tener un punto de referencia de medición de los
estados de madurez de los equipos de proyectos:
Tabla 4. Estado de madurez de las grupos de trabajo en las organizaciones
96
97
5.3.9 Propuesta de gestión de proyectos adaptada a las características de las organizaciones. Después de hacer un amplio análisis de los factores que
influyen en el éxito de los proyectos de tecnología de información, de la
metodología de gestión de proyectos descrita en PMBOK® Guide y de las
características de las organizaciones en donde se desenvuelven los proyectos, se
puede plantear la modificación al método de gestión de proyectos.
Teniendo en cuenta la estructura del método PMIBOK® Guide la
complementación que se propone es la siguiente:
a) Agregar el área de conocimiento número diez que cubra el conjunto de
procesos de gestión que permitan identificar la caracterización de la organización
en donde se desenvuelve el proyecto. El nombre de esta área de conocimiento es:
“Capítulo 13. Proceso de Gestión de Caracterización de la Organización”.
b) Los procesos de gestión de caracterización de la organización tienen la misma
estructura descriptiva de entradas, herramientas y salidas de los demás capítulos
de PMBOK® Guide.
c) Las salidas de los procesos de gestión de caracterización de la organización
son entradas a varios de los subprocesos de las áreas de conocimiento estándar
de PMBOK® Guide.
Con base en el diagnóstico de la influencia particular de las características de
cada organización sobre los proyectos, se proponen los siguientes subprocesos,
del Proceso de Gestión de Caracterización de la Organización, los cuales se
describen en el siguiente numeral:
98
• Subproceso Identificación Caracterización de la Organización
• Subproceso Identificación Preparación para el Cambio
• Subproceso Identificación Factibilidad de Éxito de los Proyectos dentro de la
Organización
• Subproceso Identificación Formación y Experiencia de Integrantes del Equipo de
Proyecto
• Subproceso Identificación Capacidades del Equipo de Proyecto
• Subproceso Identificación Tendencia de la Organización hacia la Globalización
En el siguiente gráfico se ilustra el proceso de gestión de caracterización de la
organización siguiendo el estándar empleado en PMBOK® Guide que, dentro de
esta metodología, corresponde al capítulo 13.
Figura 17. Gestión de Caracterización de la Organización
La gestión de caracterización de la organización incluye los procesos requeridos
para asegurar que el proyecto se contextualiza perfectamente dentro de las
características organizaciones particulares de cada empresa. La figura muestra
una visión general de los siguientes procesos:
99
13.1 Identificación Caracterización de la Organización – identifica el grado
de madurez de tres componentes claves de la organización: estructura,
cultura corporativa y ciclo de madurez de la organización, para situar
efectivamente el proyecto dentro de la dimensión específica de la
empresa como organización.
13.2 Identificación Preparación para el Cambio – identifica qué tan
preparada está la organización para asimilar fluidamente el cambio
originado por la tecnología que se incorporará con el proyecto.
13.3 Identificación Factibilidad de Éxito de los Proyectos dentro de la Organización – identifica el grado de proyectización que tiene la
organización donde se desarrollará el proyecto, para hacer un juicio
objetivo de los riesgos y retos que tendrá el desarrollo del mismo.
13.4 Identificación Formación y Experiencia de Integrantes del Equipo de Proyecto – identifica los rasgos de posibles candidatos, desde el punto
de vista de su formación académica orientada a proyectos, para tener
más efectividad en la conformación del equipo de proyecto.
13.5 Identificación Capacidades del Equipo de Proyecto – identifica el
grado de madurez del liderazgo del gerente de proyecto y del equipo
humano del proyecto, para asegurar un adecuado desarrollo de los
mismos durante la implementación del proyecto.
13.6 Evaluación Tendencia de la Organización hacia la Globalización – identifica el grado de internacionalización de la organización para
desarrollar estrategias de gestión adecuadas durante el proyecto.
Esta área de conocimiento interactúa con los procesos de facilitación o de soporte
de cada una de las 5 fases de gestión de un proyecto, especialmente con las
100
fases de planeación y ejecución. La importancia de esta área de conocimiento
está en lograr identificar las dificultades propias de un proyecto con las
características específicas y únicas de la organización en donde se implementará,
con el fin de establecer planes de acción acordes en los procesos de gestión de
comunicaciones, recurso humano, calidad y riesgo especialmente.
La figura se muestra una visión general de los siguientes procesos:
Figura 18. Visión general de los procesos de gestión de caracterización
101
Todos los procesos mostrados en la figura anterior tienen una componente de
herramientas y técnicas.
102
CAPITULO VI PROPUESTA DE LA
METODOLOGÍA BÁSICA PARA EL MODELO DE GESTIÓN DE
PROYECTOS DE TI
103
6. PROPUESTA DE LA METODOLOGÍA BÁSICA PARA EL MODELO DE GESTION DE PROYECTOS DE TI
6.1 INTRODUCCIÓN
De las investigaciones realizadas por The standish Group International32, ACIS33,
diferentes expertos el tema, los estudios revisados y realizados durante este
trabajo, se infiere que las principales causas del fracaso de los proyectos de TI se
encuentran básicamente enmarcadas en los siguientes aspectos:
• Cambios en los objetivos
• Falta de claridad y unidad alrededor de los objetivos del proyecto
• Problemas de Integración de TI
• Trabajo en Equipo y sentido de pertenencia
• Poca claridad e inadecuada asignación de las responsabilidades en el
equipo de trabajo
• Problemas de administración de tecnología
• No participación de áreas claves del negocio desde el inicio del proyecto
• Falta de compromiso y sentido de pertenencia del usuario líder del
proyecto.
• Desconocimiento de la tecnología
• La falta de cultura de trabajo por proyectos en la organización
• Errores en la planeación del Proyecto (Poca precisión para estimar el
tiempo y los recursos)
32 Reporte Chaos 1999 33 Asociación Colombiana de Ingenieros de Sistemas.
104
• Inadecuado manejo de control de Cambios
• Inadecuado manejo de Riesgos
• Proyectos demasiado ambiciosos
• Falta de un plan de aseguramiento de la calidad del proyecto
• Especificación de requerimientos incompleta, ambigua, inconsistente
• No utilización, o mala utilización de metodologías de Gerencia de Proyectos
• Problemas Humanos, de conducción, comunicación y conflicto
• Recurso Humano incompetente
• Falta de conocimientos y Habilidades para Gerenciar Proyectos
Si bien durante la investigación realizada se encontró que el desarrollo e
implementación de proyectos de TI puede ser extremadamente complejo, de un
alto grado de dificultad y con un alto nivel de riesgo, también se puede evidenciar
con base en la información consultada y en la investigación en campo realizada,
que la tecnología en sí no es el único ni el principal factor en el fracaso de los
proyectos de TI. Las investigaciones realizadas indican que el existo o fracaso de
los proyectos de TI esta mas relacionado con las personas y los procesos que se
realizan que con las tecnología en si, sin con esto decir que la tecnología no
genera también un mayor nivel del riesgo a este tipo de proyectos.
Partiendo de esta premisa, derivada las investigaciones realizadas, se propone un
modelo de gestión de proyectos de TI, que ayude a disminuir los riesgos de
fracaso identificados en este trabajo para el tipo de proyectos definidos.
Para desarrollar esta metodología se ha tomando como fuente de información al
PMBOK34 Guide y a Microsoft Solutions FrameWork (MSF)35. El PMI será la base
de todo el modelo y la metodología, pero dado su carácter de disciplina general
aplicable a todo tipo de proyectos, esta será complementada y apoyada también
34 PMI, Inc, A Guide to the Project Managemente Body Of Knowledge, 2000 Edition 35 Microsoft, Microsoft Solutions Framework Versión 3.0, Junio 2003
105
en el marco de referencia (Framework) MSF desarrollado por Microsoft
especialmente para proyectos de TI, tipo de proyectos objeto de estudio en este
trabajo. (Un resumen sobre MSF se encuentra en el Anexo 1)
La descripción del modelo esta dividida en dos partes. La primera parte es llamada
El Marco de Gestión de Proyectos (metodología básica). Esta provee una
estructura básica de entendimiento de la gestión de proyectos. La segunda parte
describe la gestión de proyectos y su práctica en términos de los procesos que la
componen.
6.2 DEFINICIÓN DEL MODELO El modelo de gestión de proyectos de TI (MGPTI) es un conjunto de procesos que
parten de las principales áreas claves dentro del marco de referencia de gerencia
de proyectos (PMBOK36 Guide) y Microsoft Solutions FrameWork (MSF) con el fin
de generar estándares, guías metodológicas y mejores practicas que como
mínimo, proporcione a los líderes de proyectos de TI, las directrices que debe
seguir durante el ciclo de vida “típico” de un proyecto de TI. Con este modelo el
líder de proyecto, su equipo y todos los grupos de interés del proyecto tendrían un
método estándar con el que iniciar, planificar, ejecutar, controlar y cerrar el
proyecto. Además, el modelo identifica los roles y las responsabilidades, los
estándares y los procedimientos, las plantillas y las herramientas, las propuestas
importantes y los “puntos de comprobación” (Hitos) de la revisión del proyecto que
necesitaría el equipo directivo durante todo el ciclo de vida del proyecto.
Pretendiendo con esto mejorar los procesos para la gestión y suministrando a las
personas que los ejecutan un marco de referencia y unas herramientas
focalizadas para la gestión de los proyectos de TI. Evitando de esta forma que se 36 PMI, Inc, A Guide to the Project Managemente Body Of Knowledge, 2000 Edition
106
adopte por parte de los líderes de proyectos un método “instintivo” o “intuitivo”
para gestionar los proyectos de TI y como resultado de esto, se corra un serio
riesgo de no controlar o mitigar las principales causas que impiden el éxito del
proyecto y por el contrario lo lleven a ser un fracaso.
El modelo tiene como pilar el mejoramiento continuo y la recolección de datos y
experiencias, soportado en una base de datos en la que quedan recogidos los
hechos más relevantes ocurridos en cada uno de los proyectos y las lecciones
aprendidas que se extraen de los mismos. Se trata de hacer que todas las
personas susceptibles de gestionar proyectos, independientemente de su
experiencia y bagaje profesional, utilicen la base de datos a modo de consulta
previa antes de acometer proyectos de características similares y que, así mismo,
la realimenten durante el transcurso de los proyectos en los que están inmersos.
En modelo incorpora de la metodología MSF:
o Modelos avanzados de Administración de Riesgos.
o Procesos optimizados para la ejecución de etapas para el desarrollo e
implementación de soluciones tecnológicas.
o Un modelo de trabajo en equipo que supera las barreras que se
encuentran en los equipos de trabajo
6.3 COMPONENTES DEL MODELO
El modelo de gestión de proyectos de TI se estructura de acuerdo a los siguientes
procesos o fases de un proyecto de TI, Lo que se denomina ciclo de vida.
107
Figura 19. Ciclo de vida proyectos de TI
CICLO DE VIDA PROYECTOS DE TI
108
Los componentes del modelo se muestran la siguiente grafica.
109
Figura 20. Componentes del modelo de gestión de proyectos de TI
Lecciones aprendidas y
retroalimentación del modelo
HERRAMIENTAS Y
TECNICAS
MSF MODELO DE EQUIPOS MANEJO DEL RIESGO LIDER DEL PROYECTO
CARACTERÍSTICAS ORGANIZACIONALES Cultura, estructura, Valores, Formas de toma de
decisiones, Trabajo en equipo
METODOLOGÍA DE GESTION DE PROYECTOS PMBOK Guide.
MEJORES PRÁCTICAS
PROYECTOS DE TI
CICLO DE VIDA DE PROYECTOS TI
COMPONENTES DEL MODELO DE GESTIÓN DE PROYECTOS DE TI (MGPTI)
110
6.4 DESCRIPCIÓN GENERAL
Tomado de 37 Figura 21. Proceso de gerenciamiento de un proyecto en General
Fuente: Una metodología básica para la dirección de proyectos. Alberto López, PMP.
37 LÓPEZ, Alberto J, PMP,Miembro fundador del Capítulo Argentino del PMI, Una Metodología básica para la dirección de proyectos. PMI capitulo Buenos Aires. (Documento base de esta descripción)
111
Según se muestra en la gráfica, mediante el proceso de gerenciamiento de un
proyecto a través de su ciclo de vida, se desarrollan una serie de procesos
(Fases), procedimientos, documentos y buenas practicas, los cuales en su
conjunto conforman una metodología.
Las metodologías en general comienzan con una etapa conceptual donde se
analiza la factibilidad del proyecto (interno o externo), a encarar. Se realizan
estudios económicos, de riesgos, de oportunidades y estratégicos. Estos
resultados sirven como elementos importantes para tomar la decisión de
proseguir o no con el proyecto. Una decisión positiva implica comprometer
recursos humanos, materiales y económicos para el planeamiento del proyecto.
La autorización para construir el plan, da lugar a un documento denominado
Estatuto del Proyecto "Project Charter". Este define la autoridad y responsabilidad
del director del proyecto, alcance del mismo, costos, tiempos, proveedores de
recursos, etc.
En la etapa de planeamiento se realiza la consolidación de los requerimientos.
Inicialmente requerimientos funcionales, luego los técnicos los que finalmente se
materializan en una estructura de trabajo detallada (WBS), (Work Breakdown
Structure, es una técnica de planeación para definir objetivos de una forma
detallada, (Ver Anexo 1. Estructura de división del trabajo). Este documento es
fundamental para el proyecto ya que define el alcance del mismo.
Sumando todos los costos de las tareas y recursos asociados del WBS obtenemos
el presupuesto del todo el esfuerzo a realizar (Equipos, Software, mantenimiento,
recursos etc). Tomando las tareas del WBS y teniendo en cuenta, dependencias,
recursos y restricciones, se relacionan lógicamente y se obtiene el cronograma, y
de él la duración total del proyecto.
112
En el momento en el que se logra el conocimiento del alcance, del tiempo y del
costo del proyecto, se tienen las condiciones para realizar el análisis de riesgo del
mismo y planear las posibles respuestas a dichos riesgos.
Existen una serie de documentos que complementan a los hasta ahora
enunciados y que conforman con aquellos el plan total del proyecto.
• Plan de calidad: atiende al control y la mejora continua en los procesos de
ejecución del proyecto.
• Plan de comunicaciones: dedicado a responder a: ¿qué comunicar? ¿a
quién? ¿cómo?, ¿cuándo?
Finalmente los tres últimos documentos apuntan al control durante las etapas de
implementación y cierre del proyecto.
• El primero es el de control de cambios. Apunta a la implementación de
un proceso que permita evaluar los impactos de los cambios y realizar solo
aquellos que sean aprobados. Evaluando su impacto en costos, tiempo y
cumplimiento de especificaciones.
• El segundo es el de control del avance mediante la aplicación de un
proceso definido y estandarizado.
• El tercero y último es el que establece los criterios de aceptación del
entregable final del proyecto.
La documentación hasta ahora mencionada forma parte del plan del proyecto el
cual debe ser aprobado, ya sea por el cliente (aprobación de la propuesta) o por el
patrocinante (aprobación del documento de entendimiento). En las etapas de
113
ejecución y control, que se basan en el plan del proyecto, se realizan el desarrollo
e implementación de este. Ya en la etapa de cierre surgen como documentos
importantes, las lecciones aprendidas, el análisis de desempeño de los miembros
del equipo y la documentación actualizada del proyecto.
Utilizar una metodología como la esquematizada aumenta significativamente el
logro del éxito en la ejecución de los proyectos en general y particularmente se
plantea como un buen esquema para la mejora en la ejecución de los proyectos
de TI.
Partiendo del ciclo de vida de los proyectos en general, como el descrito
anteriormente, se propone el siguiente modelo de gestión de proyectos de TI
(MGPTI), el cual tiene como base la identificación de las características
organizacionales de la empresa. Sobre esta base se soportan la implementación
de la Metodología de Gerencia de proyectos del PMI PMIBook Guide, la cual por
su carácter general será complementada con las mejores prácticas de gestión
específicas para los proyectos de TI objeto de este trabajo, el Microsoft Solución
Framework (MSF). Inicialmente se propone hacer énfasis en la utilización de la
disciplina del manejo del riesgo proactivo de este modelo (MSF), la cual a juicio
del investigador es una disciplina completa y práctica, y por lo tanto una gran
herramienta para la gestión del riesgos en el modelo de gestión de los proyectos
de TI propuesto, recordando que la administración de riesgos es crucial para
obtener el éxito en los proyectos de TI. En el capitulo 8 se presenta un descripción
completa de la disciplina de administración de riesgos de MSF.
Otro gran modelo que se propone utilizar del MSF como complemento al PMI, es
el Modelo de equipo MSF (Ver anexo A), que se basa en la premisa de que cada
función presenta una perspectiva única en el proyecto y que ninguna persona por
sí misma puede representar de una manera satisfactoria todos los objetivos de
calidad de todas las funciones. En concreto, las funciones del equipo MSF
114
comparten responsabilidad en muchos aspectos de la administración del proyecto,
por ejemplo, la administración del riesgo, la administración del tiempo, la
administración de la calidad, el planeamiento, la programación, la selección de los
miembros del equipo y la administración de los recursos humanos. Con esto se
gana una mayor flexibilidad y un mayor trabajo en equipo en los proyectos de esta
naturaleza.
Sobre estas tres capas del modelo cubiertas en lo que podemos llamar como la
capa metodológica, se implementan las herramientas y técnicas para el desarrollo
de cada una de las fases del ciclo de vida de esta tipo de proyectos, y se aplican
los procesos de gerencia de proyectos de PMI.
El modelo aquí presentado esta de forma conceptual, como se propuso en el
proyecto de investigación planteado. Por lo tanto el desarrollo e implementación
del modelo, así como su evaluación y retroalimentación, puede ser el tema de
otro proyecto de investigación.
Sin embargo se entregan en el capitulo 6 y 7 una descripción de cada una de las
fases del ciclo de vida de los proyectos de TI propuesto, con las actividades, los
documentos, las herramientas y las mejores prácticas para el desarrollo de cada
una de estas fases.
En la figura 22 se presenta el Modelo de gestión de proyectos de TI (MGPTI).
115
116
Figura 22. Modelo de gestión de proyectos de TI (MGPTI)
Modelo de gestión de proyectos de TI (MGPTI)
|
FFaassee ddeeIImmpplleemmeennttaacciióónn
FFaassee ddeeEEssttaabbiilliizzaacciióónn
FFaassee ddeeDDeessaarrrroolllloo
FFaassee ddeePPllaanneeaacciióónn
FFaassee ddee VViissiióónn
FFaassee ddeeFFoorrmmuullaacciióónn
Ciclo de vida de proyectos de TI
PPrroocceessooss ddee:: oo IInniicciiaacciióónn oo PPllaanneeaacciióónn oo CCoonnttrrooll oo EEjjeeccuucciióónn oo CCiieerrrree
PPrroocceessooss ddee:: oo IInniicciiaacciióónn oo PPllaanneeaacciióónn oo CCoonnttrrooll oo EEjjeeccuucciióónn oo CCiieerrrree
PPrroocceessooss ddee:: oo IInniicciiaacciióónn oo PPllaanneeaacciióónn oo CCoonnttrrooll oo EEjjeeccuucciióónn oo CCiieerrrree
PPrroocceessooss ddee:: oo IInniicciiaacciióónn oo PPllaanneeaacciióónn oo CCoonnttrrooll oo EEjjeeccuucciióónn oo CCiieerrrree
PPrroocceessooss ddee:: oo IInniicciiaacciióónn oo PPllaanneeaacciióónn oo CCoonnttrrooll oo EEjjeeccuucciióónn oo CCiieerrrree
PPrroocceessooss ddee:: oo IInniicciiaacciióónn oo PPllaanneeaacciióónn oo CCoonnttrrooll oo EEjjeeccuucciióónn oo CCiieerrrree
METODOLOGÍA DE GESTION DE PROYECTOS
PMBOK Guide
--EEnnffooqquuee ddee EEqquuiippoo ddiissttrriibbuuiiddoo -- DDiisscciipplliinnaa ddee aaddmmiinniissttrraacciióónn ddee RRiieessggooss PPrrooaaccttiivvaa
--EEnnffooqquuee ddee EEqquuiippoo ddiissttrriibbuuiiddoo -- DDiisscciipplliinnaa ddee aaddmmiinniissttrraacciióónn ddee RRiieessggooss PPrrooaaccttiivvaa
--EEnnffooqquuee ddee EEqquuiippoo ddiissttrriibbuuiiddoo -- DDiisscciipplliinnaa ddee aaddmmiinniissttrraacciióónn ddee RRiieessggooss PPrrooaaccttiivvaa
--EEnnffooqquuee ddee EEqquuiippoo ddiissttrriibbuuiiddoo -- DDiisscciipplliinnaa ddee aaddmmiinniissttrraacciióónn ddee RRiieessggooss PPrrooaaccttiivvaa
--EEnnffooqquuee ddee EEqquuiippoo ddiissttrriibbuuiiddoo -- DDiisscciipplliinnaa ddee aaddmmiinniissttrraacciióónn ddee RRiieessggooss PPrrooaaccttiivvaa
-- aa
aa
DDiisscciipplliinnaa ddee ddmmiinniissttrraacciióónn ddee
RRiieessggooss PPrrooaaccttiivv
MSF (Microsoft Solutions Framework)
CCAARRAACCTTEERRÍÍSSTTIICCAASS OORRGGAANNIIZZAACCIIOONNAALLEESS CCuullttuurraa,, eessttrruuccttuurraa,, VVaalloorreess,, FFoorrmmaass ddee ttoommaa ddee ddeecciissiioonneess,, TTrraabbaajjoo eenn eeqquuiippoo
CCaappííttuulloo 1133 ((PPMMII)).. PPrroocceessoo ddee GGeessttiióónn ddee CCaarraacctteerriizzaacciióónn ddee llaa OOrrggaanniizzaacciióónn (Gonzalo Montes)
TÉCNICAS Y HERRAMIENTAS DE CADA FASE
117
En las siguientes secciones se encuentra una descripción general de cada uno de
las fases del ciclo de vida de los proyectos de TI del modelo propuesto.
6.5 FASE DE FORMULACION
Se comienza con una etapa conceptual donde se analiza la factibilidad del
proyecto (interno o externo), a encarar.
Se realizan estudios económicos, de riesgos, de oportunidades y estratégicos. Sus
resultados sirven como elementos importantes para decidir proseguir o no el
proyecto.
Una decisión positiva en el proceso de selección, implica comprometer recursos
humanos y materiales para el planeamiento del proyecto.
La autorización para construir el plan, da lugar a un documento de relevante
importancia denominado Documento de Requerimientos del Proyecto (DRP). Este
define directamente o por referencia a otros documentos:
• La necesidad de negocio que dio origen al proyecto
• La descripción del producto o servicio
• El responsable del proyecto, y su autoridad y responsabilidad para el uso
de recursos organizacionales en el proyecto etc.
• Información Histórica
• Criterios de selección del producto o servicio
La creación de este documento la debe realizar una persona externa al proyecto
con autoridad organizacional reconocida de poder hacer dicho documento. Para
118
proyectos de incorporación de paquetes de software o aplicaciones complejas y
ajustadas la debe realizar una persona del área de tecnología en conjunto con la
persona del área del negocio conocedora de la necesidad. Si el proyecto es de
incorporación de infraestructura, este debe ser realizado por una persona del área
de tecnología.
En la metodología del PMI se conoce este documento como al "enunciado del
alcance", que se denominará Documento de Requerimientos del Proyecto (DRP).
Estos presentan información como nivel de riesgo, criterio de éxito y/o aceptación,
medidas de costo, tiempo, alcance y calidad, niveles de comunicación, etc.
El DRP es un documento preliminar con información no muy detallada pero con la
claridad de lo que se quiere obtener como producto final del desarrollo del
proyecto.
Está información consignada sirve de base o insumo para comenzar a planear el
proyecto y no permanece inalterable, sino que es enriquecida y refinada a medida
que se avanza en dicho planeamiento.
6.6 FASE DE VISIONAMIENTO
En esta fase se busca lograr uno de los requerimientos fundamentales para el
éxito del proyecto, la unidad del grupo o equipo alrededor de una visión
compartida. Se trata de tener una visión clara de lo que se quiere obtener con la
ejecución del proyecto. Una visión de alto nivel de los objetivos y las restricciones.
Las principales actividades que se realizan en esta fase son:
119
• Conformación del Equipo base del proyecto (Core team)
• Identificación y análisis de los requerimientos del negocio, se utiliza el
Documento de Requerimientos del Proyecto (DRP)
• Preparación , entrega y aprobación del documento de visión y alcance del
proyecto
• Preparar el documento de riesgos asociados con la visión y alcance
definidos
En esta fase el equipo del proyecto y el cliente llegan a un acuerdo sobre la visión
y alcance de proyecto, las características que se incluirán y las que no, y un
estimativo del tiempo para la entrega o culminación.
Los entregables de esta etapa son:
• Documento de visión y alcance
• Documento de Evaluación de Riesgo
• Documento de estructura del proyecto
• Restricciones
• Supuestos
El documento de estructura del proyecto contiene la información de cómo se
encuentra organizado el equipo de trabajo, que rol o roles cumple cada
integrante, y las responsabilidades especificas de cada uno.
Un ejemplo de Formato y Guía para realizar la documentación de esta etapa se
encuentra en el Anexo 3.
120
6.7 FASE DE PLANEACION
La etapa de planeamiento es una de las de mayor importancia, la mayor parte de
la planeación del proyecto es terminada en esta etapa. La cantidad de esfuerzo
en la planeación debe ser proporcional a la magnitud y alcance del proyecto.
En esta etapa de planeamiento se debe realizar un avance en la consolidación de
los requerimientos. Inicialmente los funcionales, basados en lo descrito en el
Documento de Requerimientos del Proyecto (DRP). Estos requerimientos se van
afinando para servir como base de los requerimientos técnicos los que finalmente
se materializan en lo que se denomina una estructura de trabajo detallada (WBS),
donde se desagrega el trabajo hasta llegar a elementos que se puedan asignar a
organizaciones o individuos (definiendo su responsabilidad en la ejecución de las
tareas). A este nivel de detalle del WBS se da respuesta a preguntas tales como:
¿Qué hay que hacer?,¿Quién es responsable?,¿Cómo o con qué recursos?,
¿Cuándo hay que entregarlo?, ¿Cuánto costará?, etc.
Este documento (WBS) es fundamental para el proyecto ya que define el alcance
del mismo y sirve como base para obtener el cronograma, realizar el presupuesto
y obtener el flujo de caja. Es importante también para comenzar con la
identificación de los riesgos dentro del proceso de gerenciamiento de estos.
Tomando las tareas del WBS y teniendo en cuenta, dependencias, recursos y
restricciones, se relacionan lógicamente para obtener el cronograma, del mismo
se obtiene la duración total del proyecto medida por su camino crítico(CPM)38.
38 El camino crítico es la sucesión de actividades que dan lugar al máximo tiempo acumulativo. Ver Anexo1 y PMBOK Guide para las detalle
121
El tiempo que se obtiene de terminación del proyecto puede no ser compatible
con las necesidades del cliente o patrocinante, por lo que es común realizar
ajustes que puedan modificar la lógica del cronograma y por supuesto el WBS,
para ello se utilizan técnicas como variar la cantidad de recursos tratando de
lograr la duración deseada (si es posible).
Para realizar el presupuesto del proyecto con el mayor grado de exactitud se
procede a sumar todos los costos de las tareas del WBS (mas costos de software,
equipos, mantenimiento, recursos humanos) obteniendo un presupuesto. La
unión de los costos por tarea y el momento de efectuarse la erogación (obtenido
del cronograma), permite conocer el flujo de caja necesario para el proyecto.
Una vez logrado el conocimiento del alcance, del tiempo y del costo del proyecto,
se tienen las condiciones para un proceso muy crítico en los proyectos y es el
gerenciamiento de los riesgos del mismo, en especial para los proyectos de TI, el
cual comienza con la identificación, sigue con la cuantificación y priorización y
culmina en esta etapa del proyecto con el planeamiento de las posibles respuestas
a dichos riesgos.39
En este punto parece que todo está listo para comenzar el proyecto, sin embargo
una actividad importante es la firma de un documento en el que se acepte el plan
por parte del cliente o patrocinador del proyecto, aprobándolo y proporcionándole
los fondos necesarios para su ejecución.
39 Ver mas detalle sobre administración de riesgos en el capitulo 8 de este documento
122
El proceso de aceptación implica en casi todos los casos modificaciones a la triple
restricción de los objetivos de los proyectos (costo, tiempo y alcance), y por lo
tanto también al plan de riesgos y otros planes conexos.
En el caso de proyectos externos es el cliente, el que mediante la firma del
contrato, acepta la propuesta mientras que en los proyectos internos el
patrocinante (sponsor) en este caso área del negocio que solicito los entregables
del proyecto, es el que por medio de su firma aprueba su ejecución. En este último
caso el documento de compromiso mutuo se denomina documento de
entendimiento interno y se asemeja al contrato que firma el cliente.
Es muy importante tener presente que El WBS en esta etapa ya está completo y
un gran nivel de detalle, tanto en tareas como en costo y duración de las mismas.
Pero es lo normal y sobretodo en proyectos externos que cuando se realiza la
firma del contrato se inicie una fase de planeamiento post-propuesta para hallar
más detalle de las tareas que se ha estimado basándose en algún proceso de
analogía. La razón de esta falta de precisión es costo y tiempo. Se puede planear
hasta el último detalle pero el costo puede ser enorme y la ventana de oportunidad
se puede perder. El nivel de detalle del WBS se completa en realidad cuando se
comienza a implementar el proyecto y cada responsable detalla sus tareas.
Existen otros documentos que complementan a los hasta ahora enunciados y que
conforman con aquellos el plan total del proyecto.
Plan de Calidad
Este define como se efectuará el control y la mejora continua tanto del proyecto
como del producto o servicio creado por el mismo. Aquí existen claras pautas de
123
cómo realizar los procesos de Aseguramiento y Control de la Calidad. Como parte
del primero existen una serie de auditorias y revisiones pactadas a lo largo del
ciclo de vida del proyecto.
Plan de Comunicaciones
El tamaño del mismo varía dependiendo del tamaño del proyecto.
Fundamentalmente establece: Quien necesita que información, Que comunicar, A
quien, Cómo, Cuándo comunicar, Porque medios, los formatos de actas, reporte
etc.
Plan de Recursos Humanos
Este presenta una clara definición de los roles y responsabilidades de los
participantes del proyecto, quienes son y como se desarrollara y fortalecerá el
trabajo en equipo (team building).
Los siguientes documentos apoyan la realización del control durante las etapas de
implementación y cierre del proyecto.
El primero es el de control de cambios.
Apoya la implementación de un procedimiento que permita evaluar impactos de
los cambios y la realización de solo aquellos que sean aprobados por el equipo del
proyecto. El control de cambios debe tener una consideración especial, ya que en
todas las fuentes de información consultadas, se considerada el manejo de los
cambios que surgen en el desarrollo del proyecto tienen un gran impacto en el
desvío de estos.
124
Un procedimiento recomendado por el PMI y MSF establece que todos los pedidos
deben ser realizados en forma escrita, en formulario preestablecido y con la firma
del solicitante, además se deben realizar los estudios del impacto y la
reprogramación de tiempo, costos y calidad del proyecto.
Esta información es presentada a un equipo de trabajo (formado normalmente por
un representante del cliente, por el gerente del proyecto y por una autoridad
superior a este último), el cual evalúa el impacto de los cambios (tiempo, costo,
alcance, riesgos, etc.), y decide su implementación. Cualquiera sea la decisión
está debe ser registrada en un documento de control (por Ej. Acta, o control de
cambios). Si el cambio fue aceptado, debemos modificar el proyecto actual,
cambiando el WBS, el cronograma, el presupuesto, la identificación de riesgos,
etc. Dicho de otra manera estamos en presencia de un nuevo proyecto.
El segundo es el de control del avance
Mediante la aplicación de un proceso que dado los estándares establecidos (plan
de alcance, costo, tiempos), y los resultados obtenidos en la ejecución del
proyecto (performance), analiza los desvíos (Lo Planeado - Lo real = Variación)
y toma las medidas correctivas que sean necesarias.
El tercero y último es el que establece los criterios de aceptación del
entregable final del proyecto. Este documento realmente es parte del alcance
del proyecto y está relacionado con tareas en el WBS. También las métricas
establecidas forman parte del plan de calidad del proyecto.
La documentación hasta ahora mencionada forma parte del plan del proyecto el
cual al ser aprobado, ya sea por el cliente o por el patrocinante. Esta
125
documentación se transforma, respectivamente, en el contrato para proyectos
externos o en el documento de entendimiento cuando se trata de proyectos
internos.
6.8 FASE DE DESARROLLO (EJECUCIÓN)
En esta etapa se emprende con el "kickoff" o primera reunión conjunta del equipo
que ejecutará el proyecto. Aquí se terminan de definir los roles y
responsabilidades de sus miembros con el nivel de información necesario para la
ejecución del proyecto.
En el comienzo de la ejecución se completan los grupos de actividades y
actividades al nivel de detalle que permitan realizar su control y verificar su
cumplimiento. También se comienza a realizar, dentro del plan de Recursos
Humanos, el desarrollo del equipo, las acciones y entrenamiento necesario.
El aseguramiento de la calidad es realizado por un comité (integrado
generalmente por el gerente del proyecto, cliente y algunos miembros del equipo o
área de calidad de TI de la empresa). Sus decisiones de cambio deben ser
sometidas al comité de control de cambios del proyecto para su evaluación y
aprobación o rechazo.
En definitiva todos los componentes del plan de gerenciamiento del proyecto
deben ser llevados a cabo en forma simultánea (Comunicaciones,
Gerenciamiento de Riesgos, etc.)
126
6.9 FASE DE CONTROL
En este se realiza el gerenciamiento de los cambios, documentando las
solicitudes, análisis y decisiones. Dependiendo del proyecto y su dimensión puede
existir el rol de gerente de configuración, este actúa como fiel guardián del alcance
del proyecto permitiendo solo incorporar al mismo los cambios aprobados.
Durante este proceso ocurren las revisiones programadas y las auditorias de
ejecución, las cuales tienen como objetivo verificar la marcha real del proyecto
contra el plan y en el caso de desvíos tomar las acciones correctivas
correspondientes.
En las revisiones ejecutivas, se debe presentar de un gráfico de Gantt y un cuadro
resumen con los avances y aspectos más importantes en el desarrollo del
proyecto. Normalmente existen tres áreas de reporte claramente definidas:
• Periodo de revisión que va desde la última revisión hasta la fecha
• El estado del proyecto desde su comienzo hasta la fecha
• El pronóstico actualizado del resultado total del proyecto
• El grado de avance de un proyecto tanto en tiempo como en costo y resultados
comparando la cantidad de trabajo planeada versus la realmente realizada.
En esta etapa se ejecuta el proceso de control de calidad, el cuál verifica el
cumplimiento de los estándares de calidad previamente establecidos, e identifica
formas de eliminar las causas de resultados insatisfactorios.
127
El gerenciamiento de riesgos es llevado a cabo, implementado las estrategias
preestablecidas para hacer frente a los riesgos que se materializan, identificando
nuevos riesgos y revaluando continuamente los riesgos vigentes.
Una de las lecciones aprendidas y recomendada respecto a la documentación del
proyecto es: “Normalmente se piensa que gran parte de la documentación se
elaborará durante el cierre del proyecto”, La realidad es que lo que no se
documenta durante la ejecución y control del proyecto rara vez llega a plasmarse
en algo que pueda ser usado para futuros proyectos. Por lo tanto lo mejor es
realizar la documentación del proyecto durante el desarrollo del mismo como parte
de las actividades de este.
6.10 FASE DE CIERRE
En está etapa existen dos áreas claramente marcadas.
1. La que atiende a la aceptación del producto o servicio por parte del cliente (y
su grado de satisfacción con lo realizado), y que posibilita entre otros la
facturación del trabajo y el cierre administrativo del proyecto.
2. La que atiende a la organización ejecutora del proyecto en lo que hace a la
evaluación del proyecto realizado, a los beneficios que le dejo la ejecución del
mismo:
• Equipo experimentado listo para realizar eficazmente proyectos
similares
• Gente con nuevas aptitudes adquiridas durante la ejecución del mismo
128
• Lecciones aprendidas basadas en el análisis de la documentación
actualizada del proyecto, muy importante para futuros proyectos y para
el proceso de mejoramiento en la gestión de proyectos de TI.
Un tema importante es el de la documentación, tanto la que se entrega al cliente
como la que permanece en la empresa proveedora. Se debe asegurar que la
documentación existente corresponde y contiene la última versión del producto o
servicio entregado y esta completa.
129
CAPITULO VII FASES DEL MODELO DE
GESTION DE PROYECTOS DE TI PROPUESTO
130
Ciclo de vida o de Procesos del Modelo Gestión de los Proyectos de TI propuesto. (MGPTI)
131
7. FASES DEL MODELO DE GESTION DE PROYECTOS DE TI PROPUESTO
En este capitulo de describen cada una de las fases del modelo propuesto, con las
actividades, las entradas, las salidas, las métricas, personas involucradas,
herramientas y mejores prácticas recomendadas para cada una de las fases del
modelo propuesto.
7.1 FASE DE FORMULACION (Factibilidad)
7.1.1 Objetivo. Crear el documento, que se denomina documento de
requerimientos del proyecto, el cual permite formalizar de manera preliminar los
siguientes aspectos:
• Propósito del proyecto
• Acuerdos entre los clientes y patrocinadores del proyecto y el líder del
proyecto
• Objetivos del negocio y del proyecto
• Alcance del proyecto y expectativas
• Roles y responsabilidades
• Premisas y restricciones
• Análisis de factibilidad del proyecto
• Estudios económicos
• Estudios de riesgos
• Estudio de oportunidades y estratégicos
132
• Breve aproximación de la administración de la calidad del proyecto
• Reglas y políticas que se deben seguir en el proyecto
7.1.2
7.1.3 Entradas.
Actividades a desarrollar.
• Definir las necesidades del negocio para el proyecto
• Definir los objetivos del proyecto enmarcados en los Objetivos del negocio
• Definir el patrocinador del proyecto dentro de la empresa
• Definir el líder o lideres del proyecto
• Realizar el análisis de factibilidad técnica del proyecto
• Realizar el análisis de factibilidad financiera del proyecto
• Estudios Financieros
• Estudios de Riesgos
• Estudios de oportunidades y estratégicos
• Reglas y políticas que se deben seguir en el proyecto
Todas estas actividades se deben desarrollar en el formato del Anexo B.
• Necesidades del negocio, ideal un documento de requerimientos.
• Investigaciones sobres las tecnologías y propuestas de soluciones
• Reglas y políticas de la compañía
• Documentación técnica y económica de la solución provista por el
proveedor o terceros.
• Restricciones
• Supuestos
133
• Propuestas de proveedores
• Información sobre las tecnologías o aplicaciones a implementar
• Análisis de ROI (retorno sobre la inversión) de las tecnologías o soluciones
propuestas
• Referencias de proyectos similares en la compañía y en otras compañías
7.1.4 Salidas. 1. Documento que contenga:
• Propósito del proyecto
• Acuerdos entre los clientes y patrocinadores del proyecto y el líder del
proyecto
• Objetivos del negocio y del proyecto
• Alcance del proyecto y expectativas
• Entregables a nivel general del proyecto
• Roles y responsabilidades
• Premisas y restricciones
• Análisis de factibilidad del proyecto
• Estudios Financieros (Presupuesto de inversión vs. beneficios)
• Estudios de riesgos
• Estudio de oportunidades
• Breve aproximación de la administración de la calidad del proyecto
• Reglas y políticas que se deben seguir en el proyecto
2. Y un documento con los requerimientos del proyecto refinado y estructurado de
tal forma que facilite la solicitud de propuestas específicas a los proveedores
y la posterior negociación y elaboración de los contratos.
134
7.1.5 Métricas.
7.1.6
Las principales métricas que se deben manejar en esta fase son las siguientes: • Costo aproximado del proyecto
• Costo / Beneficio del proyecto
• ROI ( Retorno de inversión del proyecto)
• Impacto de los riesgos identificados
Participantes involucrados. Los proyectos de TI nacen principalmente por dos fuentes:
• Requerimientos del negocio
• Requerimientos de la Gerencia de Desarrollo y/o Técnica , para el
mantenimiento, mejoramiento o ampliación de las infraestructura
tecnológica
Por lo anterior, los participantes involucrados en esta fase del proyecto deben ser:
• Líder del área de negocio que requiere de los entregables del proyecto y
que será el encargado de sustentarlo a la compañía para su aprobación y
asignación de recursos.
• Líder del proyecto por parte del área técnica
• Líder del proyecto por parte del área de desarrollo, si aplica para el
proyecto.
• Usuarios de la solución.
135
• Personal técnico que realizará la administración de la solución que se
implemente.
• Fabricante o proveedor de la solución si es del caso.
• Líder del proyecto por parte del área de aseguramiento de la calidad
(SQA).
• Personas de apoyo por parte del área de contraloría y planeación , si es
necesario
7.1.7 Mejores prácticas en la elaboración de esta fase. Algunas de las mejores prácticas que se pueden aplicar para realizar esta fase son:
• Asegurar que el proyecto tiene un líder y el adecuado soporte por parte del
negocio.
• Reuniones con el líder del negocio que requiere la solución para entender
las necesidades en términos del negocio y poderlos interpretar en los
términos de TI.
• Realizar acuerdos con los líderes del negocio sobre las necesidades y el
alcance que se espera tenga la solución, antes de pasar a una etapa de
planeación.
• Identificar los riesgos para el negocio, como para las áreas de TI.
• Identificar el impacto tecnológico del proyecto.
• Obtener los criterios necesarios, tanto del negocio, como tecnológicos para
la justificación del proyecto.
• Obtener los criterios de éxito del proyecto.
• Diseñar un documento de requerimientos claros y conciso (Términos de
referencia o solicitud de propuesta en ingles RFP: Request for Proposal).
136
7.1.8 Técnicas y herramientas recomendadas.
• Formato de definición de plan de proyecto
• Reuniones de grupo con todos los involucrados
• Análisis de factibilidad de proyecto
• Matriz de riesgos ( Esta se describe en el capitulo 8)
• Realizar actas de las reuniones y aprobarlas
• Reuniones específicas con los proveedores de tecnología
• Realizar referencias en el medio con proyectos similares
• Realizar investigaciones sobre los temas técnicos en Internet
• MFS y PMBOOK
• Consultar las mejores prácticas en la implementación del tipo de soluciones
planteadas o requeridas
• Ser claro y conciso en la redacción de los documentos
• Manejar un lenguajes de bajo nivel, que sea entendible por todos los
involucrados en el proyecto
• Crear un documento (RFP: Request for Proposal) detallado.
• Evitar la máximo el uso de términos técnicos y en caso dado definir un
glosario de términos
• Los objetivos que se definan deben cumplir lo siguiente:
o Debe ser específico. Precisar claramente lo que necesita ser
realizado
o Medible o cuantificable, no necesariamente cuantificables en
números, pueden incorporar estándares aceptados de desempeño
que sean claros para todos los involucrados
o Acordado, entre todos los interesados (stakeholders) en el proyecto.
o Realista (Alcanzable)
137
o Tiene una franja específica de tiempo para su logro, lo que es
base para los planes de acción. Los objetivos pueden ser a corto,
mediano y largo plazo.
7.2 FASE DE VISIONAMIENTO
Si se llega a la ejecución de esta etapa, es porque el proyecto fue aprobado por la
compañía para su ejecución y según los análisis previos de factibilidad económica
y técnica, también se debió haber realizado la negociación con el proveedor de la
solución y estar en el perfeccionamiento del contrato y su firma. En esta etapa se
produce el acercamiento con el proveedor y se comienza el diseño definitivo del
proyecto.
7.2.1
7.2.2
Objetivo. Lograr uno de los requerimientos fundamentales para el éxito
del proyecto, y es de conseguir la unidad del grupo o equipo alrededor de una
visión compartida. Se trata de lograr que todo el equipo de trabajo obtenga una
visión clara y compartida de lo que se quiere lograr con la ejecución del proyecto.
Esta visión es a un alto nivel de los objetivos y las restricciones.
Actividades a desarrollar.
• Conformación definitiva del equipo base del proyecto (Core team)
138
• Validación de los requerimientos del negocio, para esto se utiliza el
Documento de Requerimientos del Proyecto elaborado en la fase de
Formulación, el FRP y el contrato
• Elaborar un acuerdo entre el equipo del proyecto y el proveedor sobre la
visión y alcance del proyecto aprobada
• Definir las características que se incluirán en la solución y las que no, y un
estimativo del tiempo para la entrega o culminación según el alcance
acordado
• Preparación, entrega y aprobación del documento de visión y alcance
definitivo del proyecto
• El equipo debe identificar los tipos de tareas y técnicas que se necesitan
para crear cada característica y los elementos a entregar. Esto se
documenta en una estructura de división de trabajo (WBS) que se describe
posteriormente en este documento
• Preparar el documento de riesgos asociados con la visión y alcance
definidos
7.2.3 Entradas.
7.2.4 Salidas.
• Documento de Requerimientos del proyecto elaborado en la fase de
Formulación
• RFP
• Contrato
• Documento de visión y alcance del proyecto definitivo
139
• Documento de evaluación del riesgo
• Documento de estructura del proyecto, este documento contiene la
información de cómo se encuentra organizado el equipo de trabajo, que rol
o roles cumple cada integrante y las responsabilidades especificas de cada
uno
• Restricciones
• Supuestos
7.2.5 Métricas.
7.2.6
• Costo del proyecto
• Costo / Beneficio del proyecto
• ROI ( Retorno de inversión del proyecto)
• Impacto de los riesgos identificados
• Tiempo estimado de entrega
• Disponibilidad de tiempo de los integrantes
• Aportes a los indicadores del negocio , como disminución de costos,
incremento en ventas, aumento de flexibilidad, mayor calidad en procesos y
productos, mayor cobertura
Participantes involucrados.
• Líder del área de negocio que requiere de los entregables del proyecto
• Líder del proyecto por parte del área técnica
• Líder del proyecto por parte del área de desarrollo, si aplica para el
proyecto
140
• Usuarios de la solución
• Personal técnico que realizará la administración de la solución que se
implemente
• Representantes del fabricante o proveedor de la solución si es del caso
• Líder del proyecto por parte del área de aseguramiento de la calidad (SQA)
de la gerencia Técnica
• Personas de apoyo por parte del área de contraloría, Jurídico y planeación,
si es necesario
Estas personas se deben de seleccionar de acuerdo a las necesidades del
proyecto y se debe tener todo el cuidado de involucrar a todas las personas a las
que afecta el resultado del proyecto como tal y a los que se encargaran de llevarlo
a cabo. Pues este es un factor clave para el éxito del proyecto.
7.2.7 Mejores prácticas en la elaboración de esta fase.
• Asegurar que el proyecto tiene un líder y el adecuado soporte por parte del
negocio y que comparte la visión y el alcance del mismo
• Reuniones con todos los interesados en el proyecto para acordar la visión y
alcance
• Dejar en el documento de visión y alcance las características que se
incluirán en la solución y las que no, y un estimativo del tiempo para la
entrega o culminación según el alcance acordado
• Identificar nuevos riesgos para el negocio, como para las áreas de TI.
• Validar el impacto tecnológico del proyecto
• Validar los criterios de éxito del proyecto
141
• Realizar una matriz de rol responsabilidad que facilite la identificaciones de
roles-participantes dentro del equipo del proyecto
• Definir claramente las responsabilidades de cada rol dentro del proyecto
• Enviar el documento de visión y alcance a todos los integrantes del equipo
para revisión, corrección y aprobación definitiva.
• Realizar Actas de todas las reuniones y hacerlas aprobar por los
integrantes del equipo del proyecto.
• Crear un ambiente de trabajo en grupo cordial, ordenado y comprometido.
• Solicitar la asignación del espacio de trabajo requerido por cada uno de los
integrantes del equipo.
• Reuniones bien organizadas, con un buen manejo de tiempo y objetivos
concretos.
• Nivelación de todos los integrantes del equipo en los aspectos básicos del
proyecto.
7.2.8 Técnicas y herramientas recomendadas.
• Reuniones de grupo
• Generación de lluvias de ideas
• Consultar las mejores prácticas en la implementación del tipo de soluciones
planteadas o requeridas.
• Ser claro y conciso en la redacción de los documentos
• Desarrollar un documento de visión y alcance aprobado por el grupo que
contenga las características que se incluirán en la solución y las que no, y
un estimativo del tiempo para la entrega o culminación según el alcance
acordado.
• Matriz de riesgos
142
• Hojas de calculo
• Acordar cronograma para esta etapa, con fechas y entregables concretos
• Presentaciones, diagramas etc.
7.3 FASE DE PLANEACIÓN
La planeación es la disposición sistemática de tareas para el logro de un objetivo.
En esencia el plan es un mapa que muestra cómo ir desde donde se encuentra
en la actualidad hasta donde se quiere estar.
7.3.1 Objetivo.
7.3.2
Determinar de manera detallada (punto por punto) qué se necesita hacer, quién lo
hará, qué recursos se necesitan, cuando se debe entregar, cuanto tiempo se
necesitará y cuánto costará.
Para esto de se deben armonizar los múltiples, exigentes y difíciles objetivos del
proyecto con los recursos que son limitados, costosos y rígidos.
Actividades a desarrollar.
• Validar el objetivo inicial del proyecto. • Validar el alcance del trabajo, para esto se deben validar y consolidar los
requerimientos funcionales y técnicos.
• Definir las actividades específicas necesarias para realizar el proyecto y
asignar las responsabilidad para cada una de ellas
143
• Crear una estructura de división de trabajos (WBS) de máximo 3 niveles.
(Mirar conceptos), esto define el orden de las actividades.
• Determinar el orden en que se tiene que llevar a cabo esas actividades
• Estimar el tiempo y los recursos que se necesitan para cada actividad
• Preparar una programación y un presupuesto para el proyecto
• Definir los hitos o puntos de control de proyecto, que permitan el monitoreo
del cumplimiento de los objetivos del proyecto.
• Gerenciamiento de los riesgos (la identificación, la cuantificación y
priorización de los riesgos y el plan con las posibles respuestas a los
riesgos identificados)
7.3.3 Entradas.
7.3.4
• Documento de visión y alcance del proyecto definitivo
• Documento de evaluación del riesgo
• Documento de estructura del proyecto, este documento contiene la
información de cómo se encuentra organizado el equipo de trabajo, que rol
o roles cumple cada integrante y las responsabilidades especificas de cada
uno.
• Documento con los términos de referencia (RFP)
• Modelos de contratos de proyectos similares
• Otros planes de proyecto desarrollados en proyectos anteriores
• Restricciones
• Supuestos
Salidas.
144
• Documento de visión y alcance del proyecto definitivo
• Documento de evaluación del riesgo
• Documento de estructura del proyecto
• Restricciones
• Supuestos
• Estructura de división de trabajos (WBS) de máximo 3 niveles, completo y
con un gran nivel de detalle.
• Cronograma del Proyecto
• Duración total del proyecto medida por su camino crítico.
• Programación y un presupuesto actualizado del proyecto
• Hitos o puntos de control de proyecto, que permitan el monitoreo del
cumplimiento de los objetivos del proyecto.
• Plan de riesgos, que contenga los riesgos identificados, la cuantificación y
priorización y el planeamiento de las posibles respuestas a dichos riesgos.
• Plan de desarrollo
• Plan de capacitación a los usuarios
• Plan de seguridad
• Plan de Calidad (Contiene el plan de pruebas y el plan de implementación
piloto)
• Plan de Implementación
• Plan de Comunicaciones
• Plan de Recursos Humanos
• Plan de Compras e instalaciones
• Procedimiento de control de cambios (Ver formulario ejemplo)
• Procedimiento de control del avance
• Criterios de aceptación del entregable final del proyecto
145
• Firma y aprobación del plan Total del proyecto, lo que se denomina
documento de entendimiento. El cual contiene todos los puntos o
documentos anteriores.
7.3.5 Métricas.
7.3.6
• Costo del proyecto
• Costo / Beneficio del proyecto
• ROI ( Retorno de inversión del proyecto)
• Impacto de los riesgos identificados
• Tiempo estimado de entrega
• Ruta crítica del proyecto (Con el análisis PERT40)
Participantes involucrados.
• Líder del área de negocio que requiere de los entregables del proyecto
• Líder del proyecto por parte del área técnica
• Líder del proyecto por parte del área de desarrollo, si aplica para el
proyecto.
• Usuarios de la solución
• Personal técnico que realizará la administración de la solución que se
implemente.
• Representantes del Fabricante o proveedor de la solución si es del caso.
• Líder del proyecto por parte del proveedor
40 Ver el PMBOK Guide 2000, para mayor información y detalle sobre este análisis
146
• Líder del proyecto por parte del área de aseguramiento de la calidad (SQA)
de la gerencia Técnica
• Personas de apoyo por parte del área de contraloría, Jurídico y planeación,
si es necesario
7.3.7 Mejores prácticas en la elaboración de esta fase.
• Detenerse y pensar antes de iniciar realmente el proyecto, con el fin de
estudiar cómo se puede hacer mejor.
• Priorizar los entregables para mantener el grupo enfocado en temas
específicos.
• Discutir cada objetivo del proyecto con todos los involucrados, revisando los
riesgos y los beneficios para el proyecto.
• Ser lo mas realista posible en el plan.
• Concentrarse en el trabajo, no en si hará que uno quede bien o no.
• Al enfrentarse a un problema, siempre preguntar cómo lo manejó antes la
compañía, con el fin de obtener algunos conocimientos.
• Evite la tendencia a ser exageradamente optimista, en especial en la fase
inicial del proyecto. Si se piensa que el proyecto necesita determinado
tiempo más, planéelo así.
• Es importante que las personas que participarán en la realización del
trabajo colaboren también en la planeación. Ellas son las que conocen
mejor cuáles son las actividades y el detalle de estas actividades que se
necesitan llevar a cabo y cuánto debe durar cada una. La participación crea
compromiso.
• Confirme la validez del plan del proyecto con aquellos que participan en el
mismo, si hay algún desacuerdo, resuélvalo antes de seguir adelante.
147
• Conviértase en un experto en convocar reuniones sobre el proyecto para el
proceso de planeación.
• No establezca el plan hasta que cuente con la información requerida y
exacta. No improvisar mucho.
• Sea efectivo en la distribución, oportunidad, comprensión, brevedad, forma
y consistencia de los planes.
• No sobrecargar el trabajo, pues esto puede implicar no poder ejecutarlo
como se debe.
• Tener muy presente la metodología de trabajo que se empleara.
• Definir claramente como se realizará el proceso de control de cambios.
• Dejar por escrito los criterios de aceptación del producto y/o servicio creado
por el Proyecto.
• La revisión conjunta (proveedor-cliente/patrocinante) de los requerimientos
y de la solución propuesta como paso previo a la ejecución del contrato.
• La razonabilidad de estos contenidos está basada en la certeza de que su
ausencia o mala aplicación contribuyen significativamente a los desvíos en
los proyectos.
• Recoger y volver a usar de una manera inteligente los documentos del
planeamiento de proyectos anteriores.
7.3.8 Técnicas y herramientas recomendadas.
• Reuniones de grupo.
• Generación de lluvias de ideas.
• Consultar las mejores prácticas en la implementación del tipo de soluciones
planteadas o requeridas.
• Ser claro y conciso en la redacción de los documentos
148
• Desarrollar un documento de visión y alcance aprobado por el grupo que
contenga las características que se incluirán en la solución y las que no, y
un estimativo del tiempo para la entrega o culminación según el alcance
acordado.
• Desarrollar cada uno de los temas de la documentación descrita en las
salidas de esta fase.
• Recoger y volver a usar los documentos del planeamiento de proyectos
anteriores
• Distribuciones de probabilidad para estimaciones de tiempo y esfuerzo.
• Estadísticas sobre los tiempos, actividades y duraciones de proyectos
similares. Ejemplo: Distribución triangular para estimar duraciones, con
Estimación pesimista, estimación promedio y estimación optimista.
• Estructura de división de trabajos (WBS)41.
• Análisis PERT y Ruta Crítica.42
• Gantt.43
• Matriz de riesgos44.
• Hojas de cálculo.
• MS Project o programas similares.
• Cronograma y entregables concretos.
• Presentaciones, diagramas etc.
41 Ver el PMBOK Guide 2000 y Anexo 1, para mayor información y detalle 42 Ver el PMBOK Guide 2000, para mayor información y detalle 43 Ver el PMBOK Guide 2000, para mayor información y detalle 44 Ver Capitulo 8 de este documento.
149
7.4 FASE DE DESARROLLO
Durante esta fase se realiza la construcción los componentes de la solución
planteada como alcance en el proyecto
7.4.1
7.4.2
Objetivo. Construir o acoplar la mayor parte los componentes que
conforman la solución planteada según el alcance definido para el proyecto.
Actividades a desarrollar.
• Realizar el montaje de los elementos de infraestructura de la solución en un
ambiente de desarrollo
• Realizar los ajustes y configuraciones necesarias, según los requerimientos
y el diseño planteado
• Crear los documentos de configuración para la solución.
• Realizar pruebas de concepto de los elementos claves de la solución, en un
ambiente de laboratorio
• Realizar las pruebas funcionales
• Identificar problemas
• Documentar las pruebas
• Actualizar el plan de pruebas
• Administrar las especificaciones funcionales
• Actualizar el plan de trabajo
• Seguimiento al proyecto
• Revisar los hitos o puntos de control de proyecto, que permitan el monitoreo
del cumplimiento de los objetivos del proyecto.
150
• Gerenciamiento de los riesgos (la identificación, la cuantificación y
priorización de los riesgos y el plan con las posibles respuestas a los
riesgos identificados)
• Crear las listas de verificación (checklist) para la implementación piloto y la
final
• Actualizar y ajustar el plan para la implementación piloto
7.4.3 Entradas.
• Documento de visión y alcance del proyecto versión definitiva
• Documento de evaluación del riesgo
• Documento de estructura del proyecto
• Restricciones
• Supuestos
• Estructura de división de trabajos (WBS) de máximo 3 niveles, completo y
con un gran nivel de detalle.
• Cronograma del Proyecto
• Duración total del proyecto medida por su camino crítico.
• Programación y un presupuesto actualizado del el proyecto
• Hitos o puntos de control de proyecto, que permitan el monitoreo del
cumplimiento de los objetivos del proyecto.
• Plan de riesgos, que contenga los riesgos identificados, la cuantificación y
priorización y el planeamiento de las posibles respuestas a dichos riesgos.
• Plan de Calidad
• Plan de Comunicaciones
• Plan de Recursos Humanos
• Procedimiento de control de cambios
151
• Procedimiento de control del avance
• Criterios de aceptación del entregable final del proyecto
7.4.4 Salidas.
7.4.5 Métricas.
• Documento de evaluación del riesgo actualizado
• Cronograma del Proyecto actualizado
• Plan de riesgos actualizado, que contenga los riesgos identificados, la
cuantificación y priorización y el planeamiento de las posibles respuestas a
dichos riesgos
• Especificaciones funcionales definitivas
• Especificaciones de las pruebas y los casos de pruebas
• Crear los documentos de configuración para la solución
• Plan actualizado para le piloto y la implementación definitiva
• Listas de verificación
• Costo del proyecto actualizado
• Costo / Beneficio del proyecto
• ROI ( Retorno de inversión del proyecto), actualizado
• Impacto de los riesgos identificados
• Tiempo estimado de entrega, actualizado
• Resultados de pruebas funcionales
• Resultados de desempeño
152
7.4.6
7.4.7
Participantes involucrados.
• Líder del área de negocio que requiere de los entregables del proyecto
• Líder del proyecto por parte del área técnica
• Líder del proyecto por parte del área de desarrollo, si aplica para el
proyecto.
• Usuarios de la solución
• Personal técnico que realizará la administración de la solución que se
implemente.
• Representantes del Fabricante o proveedor de la solución si es del caso.
• Líder del proyecto por parte del proveedor
• Líder del proyecto por parte del área de aseguramiento de la calidad
(SQA).
• Personas de apoyo por parte del área de contraloría, Jurídico y planeación ,
si es necesario
Mejores prácticas en la elaboración de esta fase.
• Realizar pruebas de concepto en un ambiente de laboratorio que simule de
la mejor manera posible el ambiente de producción
• Conocer detalladamente el ambiente donde se implementara la solución.
• Comunicación permanente del equipo técnico del proyecto.
• Realizar reuniones de avance y discusión de problemas o nuevos temas
referentes al éxito del proyecto.
• Medir el progreso y el avance
• Priorizar los entregables para mantener el grupo enfocado en temas
específicos.
• Verificar cada objetivo del proyecto con todos los involucrados, revisando
los riesgos y los beneficios para el proyecto.
153
• Al enfrentarse a un problema, siempre preguntar cómo lo manejó antes la
compañía, con el fin de obtener algunos conocimientos.
7.4.8
Técnicas y herramientas recomendadas.
• Realizar pruebas de concepto de los componentes claves de la solución.
• Reuniones de grupo
• Generación de lluvias de ideas
• Consultar las mejores prácticas en la implementación del tipo de soluciones
planteadas o requeridas.
• Ser claro y conciso en la redacción de los documentos
• Desarrollar cada uno de los temas de la documentación descrita en las
salidas de esta fase.
• Matriz de riesgos.45
• Diagrama de Gantt46
• Hojas de cálculo.
• MS Project o programas similares.
• Presentaciones, diagramas etc.
7.5 FASE DE ESTABILIZACION Durante esta fase se realizan las pruebas a los componentes listos de la solución
45 Ver capitulo 8 de este documento, para mayor información y detalle 46 Ver el PMBOK Guide 2000, para mayor información y detalle
154
7.5.1 Objetivo.
7.5.2
Realizar las pruebas de los componentes que conforman la solución planteada
que se encuentran listos y con las características según el alcance definido para el
proyecto.
Actividades a desarrollar.
• Realizar los ajustes y configuraciones necesarias, según los requerimientos
y el diseño planteado
• Actualizar los documentos de configuración para la solución.
• Realizar pruebas tanto técnicas como funcionales de los elementos claves
de la solución, en un ambiente de laboratorio
• Identificar problemas
• Documentar las pruebas
• Actualizar el plan de pruebas
• Reportar los Bugs(errores) encontrados
• Corregir los errores encontrados
• Administrar las especificaciones funcionales.
• Actualizar el plan de trabajo
• Seguimiento al proyecto
• Revisar los hitos o puntos de control de proyecto, que permitan el monitoreo
del cumplimiento de los objetivos del proyecto.
• Gerenciamiento de los riesgos (la identificación, la cuantificación y
priorización de los riesgos y el plan con las posibles respuestas a los
riesgos identificados)
155
• Crear las listas de verificación (checklist) para la implementación piloto y la
final
• Actualizar y ajustar el plan para la implementación piloto
• Realizar la Implementación del piloto
• Evaluar la implementación piloto
7.5.3 Entradas.
• Documento de visión y alcance del proyecto definitivo
• Documento de evaluación del riesgo
• Documento de estructura del proyecto
• Restricciones
• Supuestos
• Estructura de división de trabajos (WBS) de máximo 3 niveles, completo y
con un gran nivel de detalle
• Cronograma del Proyecto
• Duración total del proyecto medida por su camino crítico.
• Programación y presupuesto
• Hitos o puntos de control de proyecto, que permitan el monitoreo del
cumplimiento de los objetivos del proyecto
• Plan de riesgos, que contenga los riesgos identificados, la cuantificación y
priorización y el planeamiento de las posibles respuestas a dichos riesgos47
• Plan de Calidad
• Plan de Comunicaciones
• Plan de Recursos Humanos
47 Ver capitulo 8 de este documento para mayor detalle, de administración de riesgos
156
• Procedimiento de control de cambios
• Procedimiento de control del avance
• Criterios de aceptación del entregable final del proyecto
• Crear los documentos de configuración para la solución.
• Plan actualizado para el piloto y la implementación definitiva
• Listas de verificación de actividades
• Especificaciones funcionales definitivas
• Especificaciones de las pruebas y los casos de prueba
7.5.4 Salidas.
• Documento de evaluación del riesgo actualizado
• Cronograma del Proyecto
• Plan de riesgos actualizado, que contenga los riesgos identificados, la
cuantificación y priorización y el planeamiento de las posibles respuestas a
dichos riesgos.
• Resultados de las pruebas funcionales
• Mediciones de desempeño y seguridad.
• Crear los documentos de configuración para la solución.
• Plan actualizado para el piloto y la implementación definitiva
• Listas de verificación, procedimientos y scripts de implementación
• Plan de reversa para la implementación piloto
• Documentación del proyecto actualizada
• Hitos revisados
• Manuales para la implementación
• Manuales para los administradores y usuarios
157
7.5.5 Métricas.
7.5.6
• Costo del proyecto
• Costo / Beneficio del proyecto
• ROI ( Retorno de inversión del proyecto)
• Impacto de los riesgos identificados
• Tiempo estimado de entrega
• Resultados de pruebas funcionales
• Resultados de desempeño
• Resultados del piloto
Participantes involucrados.
• Líder del área de negocio que requiere de los entregables del proyecto
• Líder del proyecto por parte del área técnica
• Líder del proyecto por parte del área de desarrollo, si aplica para el
proyecto.
• Usuarios de la solución
• Personal técnico que realizará la administración de la solución que se
implemente.
• Representantes del Fabricante o proveedor de la solución si es del caso.
• Líder del proyecto por parte del proveedor
• Líder del proyecto por parte del área de aseguramiento de la calidad
(SQA).
• Personas de apoyo por parte del área de contraloría y planeación , si es
necesario
158
7.5.7
7.5.8
Mejores prácticas en la elaboración de esta fase.
• Realizar prueba piloto con un grupo pequeño de personas en un ambiente
de producción
• Definir claramente los criterios de éxito del piloto
• El grupo participante del piloto debe conocer y esta de acuerdo con los
criterios de éxito del mismo
• Los problemas encontrados durante el piloto deben ser documentados y las
soluciones documentadas, esto servirá como fuente de información para los
grupos que realizaran la instalación y el soporte
• Conocer detalladamente el ambiente donde se implementara la solución
• Comunicación permanente del equipo técnico del proyecto y los usuarios
finales
• Realizar reuniones de avance y discusión de problemas o nuevos temas
referentes al éxito del proyecto
• Medir el progreso y el avance
• Verificar cada objetivo del proyecto con todos los involucrados, revisando
los riesgos y los beneficios para el proyecto
• Al enfrentarse a un problema, siempre preguntar cómo lo manejó antes la
compañía, con el fin de obtener algunos conocimientos
Técnicas y herramientas recomendadas.
• Realizar pruebas de concepto de los componentes claves de la solución.
• Reuniones de grupo
• Generación de lluvias de ideas
159
• Consultar las mejores prácticas en la implementación del tipo de soluciones
planteadas o requeridas.
• Ser claro y conciso en la redacción de los documentos
• Desarrollar cada uno de los temas de la documentación descrita en las
salidas de esta fase.
• Matriz de riesgos
• Diagrama de Gantt del proyecto
• Hojas de calculo
• MS Project o programas similares.
• Presentaciones, diagramas etc.
• Realizar prueba piloto en ambiente de producción
7.6 FASE DE IMPLEMENTACION
Durante esta fase se realiza la implementación en el ambiente de producción de
los componentes que conforman la solución.
7.6.1 Objetivo.
• Realizar la implementación y posterior estabilización de los componentes
que conforman la solución planteada con las características según el
alcance definido para el proyecto.
• Realizar la transición del proyecto a los responsables de la operación y
soporte
• Obtener la aprobación final del proyecto
160
7.6.2 Actividades a desarrollar.
• Realizar los ajustes y configuraciones necesarias, según los requerimientos
y el diseño planteado
• Actualizar los documentos de configuración para la solución.
• Implementar y estabilizar los componentes de la solución
• Identificar problemas
• Documentar los procesos y los procedimientos de soporte y operación
• Reportar los errores(Bugs) encontrados
• Corregir los errores encontrados
• Actualizar el plan de trabajo
• Seguimiento al proyecto
• Revisar los hitos o puntos de control de proyecto, que permitan el monitoreo
del cumplimiento de los objetivos del proyecto.
• Gerenciamiento de los riesgos (la identificación, la cuantificación y
priorización de los riesgos y el plan con las posibles respuestas a los
riesgos identificados)
• Actualizar las listas de verificación (checklist) para la implementación
• Actualizar y ajustar el plan para la implementación
• Actualizar y entregar las bases de conocimientos y reportes
• Crear la documentación del repositorio de todas versiones de documentos
generadas en el proyecto
• Generar el reporte de cierre
• Generar la versión final de todos los documentos del proyecto
• Documentar todas las lecciones aprendidas
161
7.6.3 Entradas.
• Documento de visión y alcance del proyecto definitivo
• Documento de evaluación del riesgo
• Documento de estructura del proyecto
• Restricciones
• Supuestos
• Estructura de división de trabajos (WBS) de máximo 3 niveles, completo y
con un gran nivel de detalle
• Cronograma del Proyecto
• Duración total del proyecto medida por su camino crítico
• Programación y presupuesto
• Hitos o puntos de control de proyecto, que permitan el monitoreo del
cumplimiento de los objetivos del proyecto
• Plan de riesgos, que contenga los riesgos identificados, la cuantificación y
priorización y el planeamiento de las posibles respuestas a dichos riesgos
• Plan de Calidad
• Plan de Comunicaciones
• Plan de Recursos Humanos
• Procedimiento de control de cambios
• Procedimiento de control del avance
• Criterios de aceptación del entregable final del proyecto
• Crear los documentos de configuración para la solución
• Plan actualizado para el piloto y la implementación definitiva
• Listas de verificación
• Especificaciones funcionales definitivas
• Especificaciones de las pruebas y los casos de prueba
162
7.6.4 Salidas.
7.6.5 Métricas.
• Documento de evaluación del riesgo actualizado
• Cronograma del Proyecto actualizado
• Plan de riesgos actualizado, que contenga los riesgos identificados, la
cuantificación y priorización y el planeamiento de las posibles respuestas a
dichos riesgos.
• Documentos de configuración definitiva para la solución actualizado
• Plan actualizado para la implementación definitiva
• Listas de verificación, procedimientos y scripts de implementación
• Documentación del proyecto actualizados
• Hitos revisados
• Manuales, procesos y procedimientos para la operación y soporte
• Manuales para los administradores y usuarios
• Versión final de todos los documentos generados en el proyecto
• Reporte de cierre del proyecto
• Datos de satisfacción del cliente y usuarios de la solución
• Definición de los siguientes pasos a seguir
• Costo del proyecto
• Costo / Beneficio del proyecto
• ROI ( Retorno de inversión del proyecto)
• Impacto de los riesgos identificados
163
• Performance (Desempeño) del proyecto (tiempo planeado vs. real)
• Resultados de la implementación
• Grado de satisfacción de clientes y usuarios
• Mediciones de operación de la solución (como líneas base de la
implementación)
7.6.6
7.6.7
Participantes involucrados.
• Líder del área de negocio que requiere de los entregables del proyecto
• Líder del proyecto por parte del área técnica
• Líder del proyecto por parte del área de desarrollo, si aplica para el
proyecto.
• Usuarios de la solución
• Personal técnico que realizará la administración y operación de la solución
que se implemente.
• Representantes del fabricante o proveedor de la solución si es del caso.
• Líder del proyecto por parte del proveedor
• Líder del proyecto por parte del área de aseguramiento de la calidad
(SQA).
• Personas de apoyo por parte del área de contraloría y planeación , si es
necesario
Mejores prácticas en la elaboración de esta fase.
• Implementar los componentes bases de la solución y lograr su
estabilización, antes de implementar los demás componentes.
164
• Los problemas encontrados durante la implementación deben ser
documentados y las soluciones documentadas, esto servirá como fuente de
información para los grupos que realizaran la operación y el soporte.
• Conocer detalladamente el ambiente donde se implementara la solución.
• Comunicación permanente del equipo técnico del proyecto y los usuarios
finales.
• Recoger permanentemente la retroalimentación de los usuarios del sistema
• Organizar bien todo la logística y seguir el plan de comunicaciones
• Realizar reuniones de avance y discusión de problemas o nuevos temas
referentes al éxito del proyecto.
• Medir el progreso y el avance
• Verificar cada objetivo del proyecto con todos los involucrados, revisando
los riesgos y los beneficios para el proyecto.
• Al enfrentarse a un problema, siempre preguntar cómo lo manejó antes la
compañía, con el fin de obtener algunos conocimientos.
• Asegurar el plan de transición del proyecto a la operación y soporte de la
solución implementada, para esto puede ser necesario en algunos casos
desarrollar un proyecto para esta transición.
• Contemplar el periodo de implementación estable a la implementación
completa, durante el cual aunque el equipo del proyecto no este activo en
actividades del proyecto, si es necesario que este atento a responder a
temas que le sean escalados, este periodo típicamente dura entre 15 a 30
días
• Durante el periodo de implementación estable e implementación completa
realizar las mediciones de que también esta operando la solución, estas
mediciones servirán con la línea base de la solución
• Definir un punto claro de cierre de la etapa de implementación
• Documentar las lecciones aprendidas
165
7.6.8 Técnicas y herramientas recomendadas.
• Mediciones de desempeño de la solución
• Reuniones de grupo
• Generación de lluvias de ideas
• Consultar las mejores prácticas en la implementación del tipo de soluciones
• Ser claro y conciso en la redacción de los documentos
• Desarrollar cada uno de los temas de la documentación descrita en las
salidas de esta fase
• Matriz de riesgos
• Diagrama Gantt
• Hojas de calculo
• MS Project o programas similares.
• Presentaciones, diagramas etc.
• Realizar un plan detallado de la implementación
• Evaluación posterior a la implementación y seguimiento
• Medir aportes del proyecto en el negocio
166
CAPITULO VIII DISCIPLINA DE ADMINISTRACIÓN
DE RIESGOS
167
8. DISCIPLINA DE ADMINISTRACIÓN DE RIESGOS
El manejo de riesgos exitoso está relacionado con estar preparado para los
problemas que puedan aparecer, y manejarlos antes de que impacten. La clave
del éxito en la Gerencia de Proyectos es la habilidad para identificar y manejar
riesgos. No hay proyectos sin riesgo y no se trata de evitar los riesgos. Tomar
riesgos es lo que produce resultados. Los Riesgos no gerenciados son pronóstico
de desastre. Esta es una disciplina que el investigador considera muy importante gracias a la
experiencia obtenida a lo largo de la vida profesional y específicamente en el
desarrollo de los proyectos de TI. Los riesgos entendidos como cualquier evento o
condición que puede influir de forma positiva o negativa en el resultado de un
proyecto tienen definitivamente un gran impacto y una gran cuota en el éxito o
fracaso de los proyectos de TI. Un adecuado manejo de los riesgos es sin lugar a
dudas una de las causas del éxito en los proyectos. Por lo tanto esta disciplina
hace parte fundamental del modelo de Gestión de Proyectos propuesto. Si bien
puede considerarse que esta información pudiera estar en un anexo, considero
que para resaltar su importancia se debe presentar en esta capitulo aprovechando
la gran información y el poder contar con una documentación amplia y bien
desarrollada, pero a la ves muy pragmática que permitirá un fácil entendimiento y
la aplicación dentro del modelo propuesto.
Si bien existen en la mayoría de libros de gerencia de proyectos, capítulos
destinados al tratamiento del tema en la mayoría de estos el tratamiento de este
168
es muy matemático y con una gran rigurosidad académica, que no esta mal de
ninguna manera, pero que claramente no estaría acorde ni seria consecuente con
el modelo de gerencia de proyectos propuesto. El tratamiento dado en la
metodología del MSF es por lo tanto a criterio del investigador el que se ajusta a
las pretensiones del modelo desarrollado, sin perder en ningún momento la
rigurosidad en el tratamiento de este tema. Por esto es importante resaltar que el
desarrollo de esta disciplina dentro del la metodología MSF se basa en el
conocido modelo de proceso ininterrumpido de administración de riesgos de
Software Engineering Institute (SEI)48 49. Lo cual respalda la rigurosidad
académica de la disciplina de administración de riegos escogida.
Por lo anterior a continuación se expone esta disciplina, tomando el texto
completo que al respecto nos presenta dicha metodología. La administración de riesgos es una disciplina básica dentro de Microsoft®
Solutions Framework (MSF). Esta reconoce que los cambios y la incertidumbre
que éstos generan son aspectos inherentes del ciclo de vida de TI. Esta disciplina
de administración de riesgos prefiere tratar la incertidumbre desde una perspectiva
proactiva, realizando ininterrumpidamente valoraciones de riesgos que incidan en
la toma de decisiones durante un ciclo de vida. Esta disciplina describe principios,
conceptos y consejos, así como un proceso de cinco fases para realizar con éxito
la administración continuada de riesgos:
• Identificación de riesgos
• Análisis de riesgos
48 Audrey J. Dorofee, Julie A. Walker, Christopher J Alberts et al, Continuous Risk Management Guidebook (Universidad Carnegie-Mellon, 1996). 49 Ronald P. Higuera, “Team Risk Management: A New Model for Customer-Supplier Relationships”, SEI Technical Report CMU/ SEI-94-SR-5, (Pittsburgh, PA: Software Engineering Institute—Universidad Carnegie Mellon), 1994.
169
• Planeamiento de estrategias de contingencia y mitigación
• Control del estado de riesgos
• y aprendizaje de los resultados.
8.1 INTRODUCCIÓN
Microsoft Solutions Framework (MSF) ha desarrollado un proceso para identificar y
valorar ininterrumpidamente los riesgos de un proyecto, dar prioridad a estos
riesgos e implementar las estrategias para tratar estos riesgos de forma proactiva
a lo largo del ciclo de vida del proyecto.
A continuación se presenta la información básica de la disciplina de
administración de riesgos que describe los principios, conceptos, consejos, así
como un proceso dividido en seis etapas para conseguir administrar con éxito los
riesgos de los proyectos de TI. La información de este documento debería servir
de ayuda para que un equipo de proyectos pueda implementar un proceso
proactivo de administración de riesgos para un proyecto de TI. Las personas sin
experiencia en la administración de riesgos de proyectos de TI deberían ser
capaces de comprender los conceptos básicos, la terminología y los principios
necesarios para participar y contribuir activamente en la administración de riesgos
durante el ciclo de vida de un proyecto de TI.
La administración de riesgos es el proceso que permite identificar, analizar y
solucionar los riesgos para que no se conviertan en un problema y deriven en
daños o pérdidas.
170
Las principales características de la disciplina de administración de riesgos son las
siguientes:
• Carácter global que incluye todos los elementos de un proyecto: personas,
procesos y elementos de tecnología.
• Incorpora un proceso intuitivo, sistemático y reproducible para la
administración de riesgos de los proyectos.
• Se aplica ininterrumpidamente durante el ciclo de vida de los proyectos.
• Su tendencia es proactiva en lugar de reactiva.
• Fomenta el aprendizaje individual y colectivo.
• Es muy flexible y puede adaptarse a una gran variedad de análisis de
riesgos cuantitativos y cualitativos.
8.2 CONCEPTOS BÁSICOS DE LOS RIESGOS
Un aspecto fundamental en la administración de riesgos es el control de los
riesgos inherentes de un proyecto. Los riesgos surgen de la incertidumbre que
rodea a las decisiones y a los resultados de los proyectos. La mayoría de
individuos asocian el concepto de riesgo a la pérdida potencial de un valor, control,
función, calidad o a la falta de puntualidad en el plazo de entrega de un proyecto.
También es posible que los resultados de un proyecto no hayan alcanzado las
expectativas, por lo que la incertidumbre en la toma de decisiones que han
derivado en este resultado también puede considerarse un elemento de riesgo.
Por riesgo se entiende cualquier evento o condición que puede influir de forma
positiva o negativa en el resultado de un proyecto. Este concepto más amplio de
171
riesgo especulativo se utiliza en el sector de las finanzas, donde las decisiones
tomadas en momentos de incertidumbre pueden estar asociadas con la posibilidad
de beneficios o pérdidas, en contraposición al concepto de riesgo puro empleado
en el mundo de las aseguradoras, en el que las incertidumbres sólo se asocian
con las potenciales pérdidas futuras.
Los riesgos se diferencian de los problemas en que un riesgo es la posibilidad
futura de que se produzca un resultado adverso o una pérdida. En cambio, los
problemas son las condiciones o las situaciones que ya están presentes en un
proyecto. Los riesgos pueden, además, convertirse en problemas si no se tratan
con eficacia. La administración de riesgos es el proceso que permite identificar,
analizar y resolver proactivamente los riesgos de un proyecto. El objetivo de la
administración de riesgos no es otro que maximizar las repercusiones positivas
(oportunidades) y minimizar las negativas (pérdidas) asociadas a un riesgo del
proyecto. Sólo una política efectiva de administración de riesgos puede asegurar
un equilibrio entre riesgo y oportunidades. Para los proyectos de Tecnología de la información (TI) la administración de
riesgos es crucial para obtener el éxito. Las presiones de la competencia, los
cambios normativos y la evolución de las técnicas pueden obligar a los equipos de
proyectos de TI a alterar los planes y estrategias en mitad de un proyecto. Los
cambios en los requisitos de los usuarios, las nuevas herramientas y tecnologías,
las constantes amenazas de seguridad y los cambios de empleados añaden más
presión al equipo de proyectos de TI y perjudican la toma de decisiones.
172
8.3 PRINCIPIOS BÁSICOS
La disciplina de administración de riesgos de MSF se basa en la noción de que los
riesgos deben tratarse de forma proactiva, que la administración de riesgos forma
parte de un proceso formal y sistemático que debe considerarse como una
iniciativa positiva. Esta disciplina está basada en los principios básicos, los
conceptos y la metodología más importantes de MSF. Los principios básicos de
MSF pueden mejorar la administración de los riesgos de los proyectos. Sin
embargo, los siguientes principios son especialmente importantes para la
disciplina de administración de riesgos de MSF.
8.3.1
8.3.2
Agilidad. La perspectiva de cambios es una de las principales
incertidumbres a la que deberá hacer frente el equipo del proyecto. Las
actividades relacionadas con la administración de riesgos no deberían limitarse a
una única fase del ciclo de vida de un proyecto. Con demasiada frecuencia, los
equipos inician un proyecto con la sana intención de aplicar los principios básicos
de la administración de riesgos, pero no logran sus objetivos debido a los
ajustados tiempos de entrega. La agilidad exige que el equipo valore
ininterrumpidamente y administre proactivamente los riesgos durante todas las
fases del ciclo de vida de un proyecto porque los continuos cambios en todas las
facetas del proyecto significan que los riesgos también están cambiando. Un
enfoque proactivo permite que el equipo acepte el cambio y lo convierta en una
oportunidad, evitando así que se vuelva en su contra.
Potenciar la comunicación. Se recomienda que los riesgos se discutan
de forma abierta, tanto dentro del equipo como con los accionistas externos al
equipo. Todos los integrantes del equipo deben participar en la identificación y
173
análisis de los riesgos. Los líderes del equipo y los responsables ejecutivos deben
evitar que los riesgos se perciban como algo negativo y animar a los integrantes
del equipo a que sigan este comportamiento. Los miembros de un equipo no
deben tener reservas para comunicar sus opiniones con libertad para, de esta
forma, evaluar con más precisión el estado del proyecto y tomar decisiones
consensuadas entre los miembros del equipo y los patrocinadores.
8.3.3
8.3.4
Aprenda de todas las experiencias. MSF da por hecho que el
aprendizaje sólo puede ayudar a mejorar los resultados. El conocimiento obtenido
en un proyecto puede reducir la incertidumbre de la toma de decisiones en otros
proyectos cuando la información es poco fiable. Aquí se resalta la importancia que
el aprendizaje de los resultados de otros proyectos tiene dentro de una
organización. Por este motivo, en el proceso de administración de riesgos ha
incorporado un paso relacionado con el aprendizaje. El análisis directo de los
resultados de proyectos anteriores fomenta el aprendizaje dentro del equipo
mediante el intercambio de opiniones entre los miembros del equipo.
Responsabilidad compartida. No hay ninguna persona que sea
“propietaria” de la administración de riesgos dentro de MSF. La participación activa
en el proceso de administración de riesgos es responsabilidad de todos los
integrantes del equipo. Los miembros del equipo tienen asignadas tareas
específicas para analizar los riesgos en el marco de planeamiento general del
proyecto, y cada uno de ellos se responsabiliza de llevarlas a cabo. Las
actividades pueden afectar a todas las áreas del proyecto durante todas las fases
de los ciclos del proyecto y del proceso de administración de riesgos.
174
Estas actividades van desde la identificación de riesgos en áreas de experiencia o
responsabilidad personal hasta el análisis de riesgos, el planeamiento de riesgos y
la ejecución de tareas de control de riesgos durante el proyecto.
8.4 CONCEPTOS CLAVE
En esta sección se describen los conceptos más importantes acerca de los riesgos
y la administración de riesgos imprescindibles para comprender el funcionamiento
de la disciplina de administración de riesgos de MSF.
El riesgo es inherente en cualquier proyecto o proceso. Aunque un proyecto puede
tener más o menos riesgos que otro, no existe ningún proyecto que no se vea
amenazado por algún riesgo. Los proyectos se desarrollan para que una
organización alcance un objetivo que le proporcione unos beneficios. Pero siempre
existen algunas dudas en torno al proyecto que pueden incidir negativamente en la
consecución del objetivo. Siempre se debe tener presente que los riesgos son
inherentes y que están presentes en todas partes, por lo tanto se debe trabajar sin
descanso para tomar decisiones equilibradas entre riesgos y oportunidades sin
obsesionarse únicamente en eliminar el riesgo, dejando de lado el resto de
elementos.
8.4.1 La administración de riesgos proactiva es más eficaz. Según MSF se
debe adoptar una tendencia proactiva para identificar, analizar y resolver los
riesgos de la siguiente manera:
• Anticipación a los problemas en lugar de reaccionar a ellos cuando ya se
han producido.
175
• Tratamiento de la raíz del problema en lugar de tratar los síntomas.
• Planes para la resolución de problemas preparados con antelación antes de
que se produzcan los problemas.
• Uso de un proceso conocido, estructurado y repetible para resolver el
problema.
• Uso de medidas preventivas siempre que sea posible.
La administración de riesgos efectiva no se consigue simplemente reaccionando
ante los problemas. El equipo debe trabajar para identificar los riesgos
anticipadamente y elaborar estrategias y planes para administrarlos. Los planes
deben elaborarse para corregir los problemas, si llegan a producirse. La
anticipación a los problemas potenciales, así como los planes bien estructurados,
reducen los tiempos de respuesta en los momentos de crisis y pueden minimizar o
incluso revertir el daño ocasionado por un problema.
Las características que definen una administración de riesgos proactiva son la
mitigación de riesgos y la reducción del impacto producido por los riesgos. La
mitigación puede ponerse en práctica cuando el riesgo ya existe para intentar
resolver la causa inmediatamente subyacente, o bien puede centrarse en la causa
raíz del problema (o en cualquier nivel de la cadena causal).
Las medidas de mitigación se aplican mejor durante la fase preliminar de un
proyecto porque el equipo todavía puede intervenir a tiempo para lograr el objetivo
del proyecto.
La identificación y corrección del origen de un problema es vital para la empresa,
ya que las medidas correctivas pueden tener efectos muy positivos que van más
allá del ámbito de un proyecto individual. Por ejemplo, la ausencia de estándares
176
de codificación o convenciones de nomenclatura en equipos puede dar como
resultado consecuencias adversas dentro de un proyecto de desarrollo y, por ello,
convertirse en un factor de riesgo importante para el proyecto. Sin embargo, la
creación de estándares y directrices puede tener un efecto positivo en todos los
proyectos realizados en una empresa cuando se implementan en toda la
organización.
8.4.2 La identificación de un riesgo es algo positivo. Para entender
correctamente y en toda su amplitud qué es la administración de riesgos efectiva
es preciso comprender los riesgos a los que se enfrenta el equipo del proyecto.
Cuando la diversidad de los retos y la magnitud de las pérdidas potenciales son
muy evidentes, las actividades relacionadas con la solución de riesgos pueden
minar la moral de los miembros del equipo. Algunos de ellos pueden incluso tener
la impresión que la identificación de riesgos sólo pone más trabas a la
consecución final del proyecto. Sin embargo, se debe actuar desde la perspectiva
de que el proceso de identificación de riesgos permite al equipo administrar los
riesgos de forma más eficaz porque los pone al descubierto y, de esta manera, las
posibilidades de éxito del equipo aumentan. Expresando de forma abierta sus
opiniones acerca de los riesgos, los integrantes del equipo pueden centrarse en su
trabajo. Para ello es muy importante clarificar las funciones, las responsabilidades
y los planes para las actividades preventivas y las medidas correctivas ante los
problemas.
El equipo, en especial sus líderes, debe considerar la identificación de un riesgo
como algo positivo para que los integrantes aporten toda la información posible
acerca del riesgo con el que se enfrentan. Cuando los riesgos se perciben como
algo negativo, los integrantes de un equipo se sienten reacios a informar sobre
177
ellos. El proceso de identificar los riesgos debe estar rodeado por un ambiente en
el que las personas sientan la libertad de expresar puntos de vista especulativos o
controvertidos. Son muchos los ejemplos de situaciones negativas provocadas por
la identificación de riesgos. Por ejemplo, en algunos proyectos, el mencionar los
riesgos nuevos se toma como una queja. En ciertas situaciones, una persona que
habla de los riesgos recibe el calificativo de conflictiva, y las reacciones se
concentran en la persona, antes que en los riesgos. Bajo estas circunstancias, los
miembros de un equipo tienen reservas para comunicar sus opiniones con
libertad. Seleccionan y suavizan la información de riesgos que deciden compartir
para que no resulte demasiado negativa en relación con las expectativas de los
demás integrantes. Los equipos que crean un entorno de administración de
riesgos positivo felicitando, por ejemplo, a los miembros que sacan los riesgos a la
luz, tienen más posibilidades de identificar y solucionar los riesgos antes que los
equipos que trabajan en un ambiente negativo.
Para maximizar la parte positiva de los proyectos, el equipo debe estar ansioso
por aceptar riesgos. Esto implica ver los riesgos y la incertidumbre como la única
forma de crear la oportunidad adecuada que el equipo está esperando para
conseguir los objetivos.
8.4.3 Valoración continúa. Muchos profesionales en tecnología de la
información (TI) poseen un concepto erróneo de la administración de riesgos y, en
el mejor de los casos, la consideran una actividad necesaria pero aburrida que se
debe efectuar al comienzo de un proyecto o en los preliminares de un nuevo
proceso.
Los cambios continuos en el proyecto y en el entorno operativo obligan a los
equipos a realizar valoraciones frecuentes del estado de los riesgos existentes y a
178
valorar o actualizar de nuevo los planes para prevenir o actuar ante los problemas
asociados a estos riesgos. Los equipos de proyectos también deben buscar
constantemente la posible aparición de nuevos riesgos. Las actividades de
administración de riesgos deben integrarse en el ciclo de vida general del proyecto
proporcionando la actualización de los planes y actividades del control de riesgo
apropiadas sin llegar a crear una infraestructura de informes y seguimiento
separada.
8.4.4
8.4.5
Mantener una comunicación abierta. Es importante tener presente que
en muchas ocasiones los integrantes de un equipo conocen los riesgos, pero no
los comunican en la forma adecuada. Por lo general, es fácil informar de los
riesgos hacia abajo en la cadena de mando, pero es difícil hacerlo en sentido
contrario. En todos los niveles, las personas pretenden conocer los riesgos de los
niveles inferiores, pero muchas veces no los comunican abiertamente a quienes
están a un nivel más alto. El flujo de información restringido relacionado con los
riesgos es un factor que puede aumentar la aparición de riesgos porque las
decisiones acerca de estos riesgos deben tomarse con menos información. En la
jerarquía de la organización, los responsables deben ser los primeros en
mostrarse abiertos y comunicativos en lo relacionado con los riesgos y asegurarse
de que todo el mundo comprende perfectamente los riesgos y los planes de
riesgos.
Primero especificar y luego administrar. El punto de unión entre la
administración de riesgos y la toma de decisiones es la incertidumbre. Las
definiciones genéricas de un riesgo no hacen desaparecer la incertidumbre y dan
179
lugar a distintas interpretaciones del riesgo. Las definiciones que no dejan lugar a
dudas permiten a los equipos:
• Asegurarse de que todos los miembros del equipo comprenden el riesgo de
la misma forma.
• Comprender la causa o causas del riesgo y la relación con los problemas
que puedan surgir.
• Disponer de una base para realizar un análisis formal y cuantitativo y
planear los esfuerzos.
• Aumentar la confianza que los accionistas y los patrocinadores tienen
depositada en la capacidad del equipo para administrar el riesgo.
El planeamiento de la administración de riesgos debe enfocarse con especial
atención a la información específica para minimizar los errores de ejecución en el
plan de riesgos que pueden inutilizar los esfuerzos preventivos o interferir en los
esfuerzos de recuperación y corrección.
8.4.6 Las situaciones no deben juzgarse sólo por el número de riesgos. A
pesar de que los miembros del equipo y los accionistas suelen percibir los
elementos de riesgo como algo negativo, los proyectos o los procesos operativos
nunca deben juzgarse por el número de riesgos detectados. A fin de cuentas, un
riesgo es sólo una posibilidad, no la certeza de una pérdida ni un resultado por
debajo de lo esperado. El proceso de administración de riesgos de MSF
recomienda el uso de una identificación de riesgos y un proceso de análisis
estructurados para proporcionar a los responsables de la toma de decisiones no
sólo la información de la existencia de riesgos sino también la importancia de
dichos riesgos.
180
8.5 PLANEAMIENTO DE LA ADMINISTRACIÓN DE RIESGOS
Durante la fase de planeamiento preliminar del modelo de proceso de MSF, el
equipo debe desarrollar y documentar un plan para implementar el proceso de
administración de riesgos en el contexto del proyecto. Algunas cuestiones que
deben solucionarse con este plan son las siguientes:
• ¿Cuáles son las presunciones y las restricciones para la administración de
riesgos?
• ¿Cómo se implementará el proceso de administración de riesgos?
• ¿Cuáles son los pasos involucrados en el proceso?
• ¿Cuáles son las actividades, las funciones, las responsabilidades y los
productos finales en cada paso?
• ¿Quién llevará a cabo las actividades de riesgo?
• ¿Qué conocimientos se requieren?
• ¿Se necesita algún tipo de formación adicional?
• ¿Cómo se relaciona la administración de riesgos en el proyecto con los
esfuerzos empresariales?
• ¿Qué tipo de herramientas o métodos se utilizarán?
• ¿Qué definiciones se utilizan para clasificar y calcular el riesgo?
• ¿Qué prioridad se otorga a los riesgos?
• ¿Cómo se crearán y ejecutarán los planes de riesgos y de contingencia?
• ¿Cómo se integrarán las actividades de control de riesgos en el plan
general del proyecto?
• ¿Qué actividades realizarán los miembros del equipo para administrar los
riesgos?
181
• ¿Cómo se comunicará el estado entre el equipo y los accionistas del
proyecto?
• ¿Cómo se supervisará el progreso?
• ¿Qué tipo de infraestructura se empleará (bases de datos, herramientas,
depósitos) para permitir el proceso de administración de riesgos?
• ¿Qué peligros entraña la administración de riesgos?
• ¿Qué recursos están disponibles para la administración de riesgos?
• ¿Cuáles son las fechas críticas del planeamiento para implementar la
administración de riesgos?
• ¿Quién es el patrocinador y quiénes son los accionistas?
Las actividades para el planeamiento de la administración de riesgos no deben
considerarse como un proceso separado de las actividades de planeamiento del
proyecto, de igual forma que las tareas de administración de riesgos no deben
considerarse como un proceso adicional de las tareas que los integrantes del
equipo realizan para completar un proyecto. Puesto que los riesgos son inherentes
desde la primera hasta la última fase de todos los proyectos, los recursos deben
asignarse y planearse para administrar los riesgos de forma activa. El
planeamiento de la administración de riesgos que se lleva a cabo durante la fase
preliminar y el plan de riesgos que documenta dichos planes, debe aportar
elementos de acción definidos para determinados miembros del equipo dentro de
la estructura de distribución de trabajo. Estos elementos de acción deben constar
en el plan del proyecto y en el planeamiento del proyecto principal.
8.6 PROCESO DE ADMINISTRACIÓN DE RIESGOS
182
Información general acerca del proceso de administración de riesgos
La disciplina de administración de riesgos de MSF recomienda una administración
de riesgos proactiva, una valoración continua de los riesgos y la integración en la
toma de decisiones a lo largo del proyecto o ciclo de vida operativo. Los riesgos se
valoran, supervisan y administran ininterrumpidamente hasta que se resuelven o
se convierten en problemas que deben solucionarse. Figura 23. Proceso de administración de riesgos de MSF
Los seis pasos que conforman el proceso administración de riesgos de MSF son:
• Identificación
• Análisis y asignación de prioridades
• Planeamiento y programación
• Seguimiento y elaboración de informes
• Control
• Aprendizaje
183
Durante la fase de identificación de riesgos, los riesgos se identifican y ponen al
descubierto para que todo el equipo sea consciente de que existe un problema en
potencia. La identificación de riesgos debe realizarse lo antes posible y repetirse
con frecuencia a lo largo de todo el ciclo de vida del proyecto porque aporta
información al proceso de administración de riesgos.
El análisis de los riesgos transforma las cifras y los datos de los riesgos
detectados durante la fase de identificación en información que el equipo puede
utilizar para tomar decisiones relacionadas con la asignación de prioridades. Al
establecer la prioridad de los riesgos el equipo puede confirmar los recursos del
proyecto para administrar los riesgos más importantes.
El planeamiento de riesgos toma la información obtenida tras el análisis de
riesgos y la utiliza para trazar estrategias, planes y acciones. La programación de
riesgos garantiza que estos planes se aprueban y se incorporan en la
infraestructura y el proceso de administración diario del proyecto para confirmar
que la administración de riesgos forma parte de las actividades diarias del equipo.
La programación de riesgos es el punto de conexión explícito entre el
planeamiento de riesgos y el planeamiento del proyecto.
El seguimiento de riesgos supervisa el estado de los riesgos y el progreso de
sus planes de acción. El seguimiento de riesgos también incluye la supervisión de
probabilidades, impactos, exposiciones y otras medidas de riesgo para los
cambios que pudiesen alterar los planes de prioridades o de riesgos y las
características, los recursos o la programación del proyecto. El seguimiento de
riesgos hace posible la visibilidad del proceso de administración de riesgos dentro
del proyecto desde la perspectiva de los niveles de riesgo, a diferencia de la
perspectiva de finalización de tareas del proceso de administración de proyectos
operativos estándar. El informe de los riesgos garantiza que el equipo, los
184
patrocinadores y los accionistas están al corriente del estado de los riesgos del
proyecto y de los planes para administrarlos.
El control de riesgos es el proceso que ejecuta los planes de acción de riesgos y
sus informes de estado asociados. El control de riesgos también incluye la
iniciación de las solicitudes de control de cambios del proyecto si los cambios en el
estado o los planes de los riesgos pueden alterar las características, los recursos
o la programación del proyecto.
El aprendizaje de riesgos formaliza las lecciones aprendidas y los elementos y
herramientas relevantes del proyecto y plasma todo esta información en un
formato reutilizable para el equipo o la empresa.
Se debe tener en cuenta que se trata de pasos lógicos que no es preciso seguir en
estricto orden cronológico. Los equipos irán repitiendo cíclicamente los pasos de
identificación, análisis y planeamiento para una clase de riesgo a medida que
aumente su experiencia en el proyecto y deben acudir, sólo de vez en cuando, a
la fase de aprendizaje a fin de recopilar información para la empresa.
Sería erróneo deducir por el diagrama que todos los riesgos del proyecto deben
pasar indefectiblemente por esta secuencia de pasos. La disciplina de
administración de riesgos de MSF recomienda que cada proyecto defina, durante
la fase de planeamiento del proyecto, el momento y la forma en que el proceso de
administración de riesgos se iniciará y las circunstancias bajo las que se
producirán las transiciones entre los pasos para cada riesgo o grupo de riesgos.
8.7 IDENTIFICACIÓN DE RIESGOS
185
La identificación de riesgos es el primer paso en el proceso de la administración
de riesgos de MSF. Los riesgos deben identificarse y expresarse de forma clara e
inequívoca para que el equipo pueda llegar a un consenso y continuar hacia la
fase de análisis y planeamiento. La mentalidad del equipo debe ser
deliberadamente abierta durante la identificación de los riesgos.
Debe prestarse especial atención a la actividad de aprendizaje y centrarse en la
búsqueda de los vacíos de conocimiento del proyecto y su entorno que podrían
incidir negativamente en el proyecto o limitar sus posibilidades de éxito. La Figura
2 representa de forma gráfica las entradas, las salidas y las actividades para la
identificación de riesgos.
Figura 24. Identificación de riesgos
186
8.7.1
8.7.2
Objetivos. La meta en la identificación de riesgos es la elaboración de una
lista de los riesgos con los que el equipo deberá enfrentarse. Esta lista debe ser lo
más extensa posible y deberá cubrir todas las áreas del proyecto.
Entradas. Las entradas en la identificación de riesgos son toda la
información disponible acerca de riesgos generales y específicos del proyecto en
las áreas de negocios, técnicas, organizativas y de entorno importantes. Otros
aspectos adicionales son la experiencia del equipo, el enfoque organizativo actual
ante los riesgos en forma de políticas, directrices, plantillas e información acerca
187
del proyecto, incluido su estado actual y su historial. El equipo es libre de elegir
otras fuentes de información. Debe tenerse en cuenta todo aquello que el equipo
considere de ayuda para identificar el riesgo. Al iniciar el proyecto es muy útil
poner en común los conocimientos, realizar sesiones dirigidas o incluso talleres
para obtener información sobre las percepciones que el equipo del proyecto y los
accionistas tienen acerca de los riesgos y las oportunidades. Para identificar los
riesgos relevantes de los proyectos, el equipo puede recurrir a los esquemas de
clasificación de la industria, como la taxonomía de riesgos de SEI Software, las
listas de control de proyectos, los informes de resumen de proyectos anteriores,
así como cualquier fuente de información publicada.
8.7.3 Actividades para la identificación de riesgos. Durante la identificación
de riesgos, el equipo crea una declaración ambigua o una lista de riesgos que dan
forma a los riesgos que se encontrará. Al inicio del proyecto, es fácil organizar un
seminario o una sesión de confrontación de ideas para identificar los riesgos
asociados a una nueva situación. Lamentablemente, muchas organizaciones
consideran que esta actividad sólo es necesaria una vez y no la vuelven a repetir
durante el ciclo de vida del proyecto o de la operación. La disciplina de
administración de riesgos de MSF opina que la identificación de riesgos debe
llevarse a cabo periódicamente durante un proyecto. La identificación de riesgos
puede realizarse según un horario establecido (cada día, semana o mes), por
objetivos (asociado a un plan de acontecimientos del proyecto) o activado por
sucesos (forzado por sucesos destructivos en la empresa, la tecnología, la
organización o el entorno). Las actividades de identificación de riesgos deben
realizarse a intervalos y con una finalidad establecida por cada equipo del
proyecto. Por ejemplo, puede que un equipo haya completado la identificación de
riesgos global por etapas dentro de un proyecto de desarrollo extenso. A pesar de
ello, puede contar con pequeños equipos o incluso desarrolladores individuales
188
que repitan la identificación de riesgos en sus áreas de responsabilidad para lograr
un objetivo interno o para completar una programación semanal.
Durante la identificación inicial de los riesgos en un proyecto, la interacción entre
los miembros del equipo y los participantes es crucial porque es la forma más
directa de exponer suposiciones y expresar distintos puntos de vista. Por este
motivo, la disciplina de administración de riesgos de MSF recomienda la
participación activa de todos los integrantes del equipo durante la identificación de
riesgos.
Durante la identificación de riesgos puede que el equipo deba realizar
investigaciones adicionales o que solicite ayuda a expertos en la materia para
obtener más información acerca de los riesgos del proyecto.
8.7.4 Enfoque estructurado. En la medida de lo posible, MSF recomienda un
enfoque estructurado para la administración de riesgos. Para los proyectos de
desarrollo de software y de implementación, la clasificación de los riesgos durante
la fase de identificación puede servir de ayuda para elaborar un enfoque
coherente, reproducible y medible. La clasificación de riesgos establece una base
para la terminología de riesgos estándar en los informes y el seguimiento y es muy
importante para crear y mantener las bases de conocimiento de riesgos de las
empresas o industrias.
Dentro de la identificación de riesgos, las listas de clasificación permiten que el
equipo pueda pensar con mayor amplitud sobre los riesgos del proyecto porque ya
dispone de una lista de áreas del proyecto susceptibles de esconder riesgos
procedentes de proyectos parecidos. La formulación de la declaración de riesgo es
189
la principal técnica que se dispone en MSF para evaluar un proyecto específico y
para establecer la prioridad y el desarrollo de los planes de riesgo específicos.
8.7.5 Clasificación de los riesgos. El equipo del proyecto puede utilizar las
clasificaciones o categorías de los riesgos, denominadas también taxonomías de
riesgos, para varios propósitos.
Durante la identificación de riesgos, pueden utilizarse para estimular el
pensamiento sobre los riesgos que pueden producirse en las distintas áreas del
proyecto. Durante la puesta en común de ideas, las clasificaciones de riesgos
también aligeran la complejidad de trabajar con muchas cantidades de riesgos
porque los riesgos parecidos pueden incluirse en un mismo grupo. También
pueden emplearse para proporcionar una terminología unificada que el equipo
puede utilizar para supervisar y notificar el estado de los riesgos a lo largo del
proyecto. Por último, las clasificaciones de los riesgos son muy útiles para
establecer las bases de conocimiento de riesgo para empresas e industrias porque
proporcionan la base para indexar nuevas contribuciones y buscar y recuperar
información existente. La tabla siguiente muestra una clasificación de alto nivel de
las fuentes de riesgo de los proyectos.
Personas Clientes Usuarios finales Patrocinadores Participantes Personal Organización Conocimientos Políticas Moral
Proceso Misión y metas
190
Toma de decisiones Características del proyecto Presupuesto, costo, programación Requisitos Diseño Creación Pruebas
Tecnología Seguridad Entorno de desarrollo y prueba Herramientas Implementación Soporte técnico Entorno operativo Disponibilidad
Entorno Legal Normativo Competencia Económico Tecnología Empresa
Existen muchas taxonomías o clasificaciones para los riesgos de proyectos
generales de desarrollo de software. Entre las clasificaciones conocidas y más
mencionadas que describen las fuentes de riesgo de proyectos de desarrollo de
software se incluyen las realizadas por Barry Boehm 50, Caper Jones 51, y SEI
Software Risk Taxonomy.52
También hay disponibles listas de áreas de riesgo que cubren con mayor detalle
áreas limitadas de los proyectos. El planeamiento de riesgos es un área común
para equipos de proyectos. Por ello, Steve McConnell53 ha compilado una lista
completa y detallada para ayudar a los equipos de proyectos de desarrollo de
software a identificar los riesgos según lo programado. Distintos tipos de proyectos
(infraestructura o distribución de aplicaciones empaquetadas), proyectos 50 arry W. Boehm, Software Risk Management, (Nueva York, NY: IEEE Press), 1989. B51 Capers Jones, Assessment and Control of Software Risks. (Englewood, NJ: Prentice-Hall, 1994). ISBN 0-13-741406-4 52 Ronald P. Higuera y Yacov Y. Haimes, “Software Risk Management”, SEI Technical Report,1996. 53 Steve McConnell, Rapid Development, (Redmond, Microsoft Press), 1996, pp 87-91.
191
realizados con tecnologías especializadas (como la seguridad, los sistemas
embebidos, EDI), sectores verticales (sanidad, fabricación, etc.) o proyectos de
productos específicos pueden incluir riesgos conocidos exclusivos del sector.
Dentro de la seguridad de la información, los riesgos relacionados con el robo, la
pérdida o la degradación de la información a causa de accidentes o por actos
deliberados, se suelen considerar como amenazas. Los proyectos en estas áreas
se beneficiarán de la revisión de las extensiones o clasificaciones de riesgo
alternativo (amenaza) que se incluyen dentro de las clasificaciones de riesgo
general para que el equipo del proyecto pueda pensar ampliamente durante la
identificación de riesgos.
Otras fuentes de información de riesgos se encuentran en las bases de datos de
los proyectos del sector, como pueda ser Software Engineering Information
Repository (SEIR) o las bases de datos internas de conocimiento de riesgos de las
empresas.
192
8.7.6 Declaraciones de riesgo. Una declaración de riesgo es una expresión de
lenguaje natural que describe la relación entre una situación o atributo real de un
proyecto y una segunda situación o atributo de proyecto no realizado. La primera
parte de la declaración de riesgo se denomina condición e incluye y describe una
situación o atributo del proyecto existente que el equipo prevé que puede resultar
en una pérdida en el proyecto o en una reducción de beneficios. La segunda parte
de la declaración de riesgo se denomina consecuencia y describe el atributo o
situación no deseable del proyecto. Las dos declaraciones están unidas por un
“por lo tanto” o “como consecuencia” que implica una relación incierta (en otras
palabras, inferior al 100%) pero causal. Esta información se representa de forma
esquemática en la figura 25.
Figura 25. Declaración del riesgo
193
El proceso de declaración en dos partes ofrece la ventaja de unir las
consecuencias de riesgo con las condiciones de riesgo visibles (y controlables en
potencia) dentro del proyecto en la fase preliminar de la identificación de riesgos.
El uso de enfoques alternativos en los que el equipo se centra únicamente en la
identificación de las condiciones de riesgo dentro de la fase de identificación suele
requerir que el equipo realice una copia de seguridad para recordar más adelante
la condición del riesgo en el proceso de administración para desarrollar estrategias
de administración.
Se debe tener en cuenta que las declaraciones de riesgo no son declaraciones “if-
then”, sino declaraciones de hechos que exploran las posibles pero no realizadas
consecuencias. Durante los pasos de análisis y planeamiento, la posibilidad de
utilizar declaraciones “if-then” hipotéticas puede servir de ayuda para sopesar las
alternativas y elaborar planes mediante árboles de decisiones. Sin embargo, la
meta en la identificación de riesgos consiste en identificar la mayor cantidad
posible de riesgos y es preferible dejar los análisis what-if (qué pasaría) para la
fase de planeamiento. En la fase preliminar del proyecto deberían existir muchas
declaraciones de riesgo con condiciones que indiquen la falta de conocimiento del
equipo como, por ejemplo, “todavía no sabemos nada acerca de X, por lo tanto.”
Cuando se formule una declaración de riesgo, el equipo deberá tener en cuenta
tanto la causa del resultado potencial menos deseado así como el propio
resultado. La declaración de riesgo debe incluir el estado visible de la situación
(condición) dentro del proyecto así como el estado visible de las situaciones que
puedan producirse (consecuencia). Como parte de una análisis de riesgos
exhaustivo, los miembros del equipo deberían buscar coincidencias y
agrupaciones naturales de las condiciones de las declaraciones de riesgo del
proyecto y retroceder por la cadena causal de condición en busca de una causa
194
raíz subyacente común.54 También puede resultar práctico seguir la cadena causal
hacia adelante desde el binomio condición— consecuencia de la declaración de
riesgo para examinar los efectos en la organización y el entorno fuera del proyecto
para obtener una mejor perspectiva de las pérdidas totales u oportunidades
perdidas asociadas con una condición determinada del proyecto.55
Durante la identificación del proyecto es habitual que el equipo identifique varias
consecuencias para la misma condición. Algunas veces, las consecuencias de
riesgo identificadas en un área del proyecto pueden convertirse en una condición
de riesgo en otra área. Los equipos deben registrar estas situaciones para poder
tomar las decisiones adecuadas durante el análisis y el planeamiento de riesgos
teniendo en cuenta las dependencias e interacciones causales entre los riesgos.
Dependiendo de las relaciones entre los riesgos, el cierre de un riesgo puede
cerrar un grupo entero de riesgos dependientes y cambiar el perfil de todo el
proyecto. La documentación de estas relaciones en la fase preliminar de
identificación de riesgos puede proporcionar información muy útil para crear un
planeamiento de riesgos flexible, completo y que utilice de forma eficaz los
recursos disponibles del proyecto resolviendo la causa original. Las ventajas de
capturar este tipo de información en la fase de identificación deben compararse
rápidamente con los análisis y las prioridades subsiguientes y, a continuación,
volver a examinar las dependencias y la causa raíz durante la fase de
planeamiento para los riesgos más importantes.
54 Una técnica de puesta de ideas en común muy efectiva para la identificación de causas raíz se llama “Five Whys” (Las cinco razones). En esta técnica, el grupo debe formularse la pregunta “¿por qué ocurre esto?” a propósito de la condición del riesgo, responder y repetir la pregunta “¿por qué ocurre esto? – debido a…” hasta cinco veces. 55 Se consigue mediante una variante de la técnica “Las cinco razones”, en la que el equipo repite cinco veces la secuencia de pregunta y respuestas “¿por qué ocurre esto?..Porque entonces…”.
195
8.7.7
Resultados. El resultado mínimo de las actividades de identificación de
riesgos es una declaración clara, sin ambigüedades y consensuada registrada en
forma de lista de riesgos con los que debe enfrentarse el equipo. Si el enfoque
condición-consecuencia de los riesgos se utiliza tal y como se describe en las
publicaciones de SEI56, NASA57 y las versiones anteriores de MSF58,59 el resultado
será un conjunto de declaraciones de riesgo que dan forma a los riesgos que el
equipo ha identificado en el proyecto. La lista de riesgos en forma de tabla
constituye la entrada principal para la siguiente etapa del análisis del proceso de
administración de riesgos. La identificación de riesgos suele generar una gran
cantidad de información útil, incluida la identificación de las causas raíz y los
efectos que provocan, las partes afectadas, el propietario, etc. La disciplina de
administración de riesgos de MSF recomienda que los equipos elaboren un
registro en forma de tabla con las declaraciones de riesgo y la información
relacionada con la causa raíz y sus efectos. Cualquier información adicional
relacionada con la clasificación de riesgos (por área de proyecto o atributo)
también puede ser útil cuando se utilice la información de riesgo del proyecto para
crear o utilizar una base de conocimientos de riesgo empresarial, si existe una
taxonomía bien definida. El resto de información útil puede registrarse en la lista
para definir el contexto del riesgo para que otros miembros del equipo, revisores
externos o accionistas entiendan la voluntad de un equipo por poner un riesgo al
descubierto60 61 62. Entre la información de contexto acerca de un riesgo que los
equipos de proyecto pueden registrar durante la identificación de riesgos para
demostrar la voluntad del equipo se incluye:
56 Audrey J Dorofee, Julie A Walker, Christopher J Alberts, et al., Continuous Risk Management Guidebook. (Pittsburgh, PA: Universidad Carnegie Mellon, 1996). 57 Linda H Rosenberg , Theodore Hammer , Albert Gallo, Continuous Risk Management atNASA, 1999 (http://satc.gsfc.nasa.gov/support/ASM_FEB99/crm_at_nasa.html) 58 MSF Risk Management Process Documento, 2001. 59 Principles of Application Development- Curso 593 y Curso 1517. 60 Rosenberg LH, et al., 1999. 61 Elaine Hall, Managing Risk. Methods for Software Systems Development, SEI Series in Software Engineering, (Reading, MA: Addison-Wesley, 1998), Capítulo. 4, “Identify Risk”. 62 Dorfee AJ, et al, 1996.
196
• Condiciones
• Restricciones
• Circunstancias
• Suposiciones
• Factores contributivos
• Dependencias entre los riesgos
• Temas relacionados
• Propietario de activos de negocio
• Preocupaciones del equipo
La lista de riesgos en forma tabular (con o sin condiciones, causas raíz, los efectos
de dichas causas o información de contexto) se convertirá en la lista maestra de
riesgos durante los siguientes pasos del proceso de administración de riesgos. La
siguiente tabla muestra un ejemplo de una lista maestra de riesgos.
Tabla 5. Ejemplo Lista maestra de riesgos Causa raíz Estado Consecuencia Efecto de la causa Personal inadecuado Las funciones de
desarrollo y prueba se han combinado
Es posible que el producto se comercialice con más defectos
Insatisfacción del cliente
Tecnología nueva Nuestro desarrolladores están trabajando con un lenguaje de programación nuevo
Mayor tiempo de desarrollo
Nuestros productos se comercializan tarde y perdemos cuota de mercado
Organización El equipo de desarrollo está repartido entre Bogota y Medellín
La comunicación entre el equipo será difícil
Retrasos en la comercialización del producto con retoques adicionales
197
8.8 ANÁLISIS Y PRIORIDAD DE LOS RIESGOS
El análisis y prioridad de los riesgos es el segundo paso en el proceso de
administración de riesgos de MSF. El análisis de riesgos implica la conversión de
los datos de riesgo en un formato que facilite la toma de decisiones. La asignación
de prioridades a los riesgos permite a los integrantes del equipo tratar en primer
lugar los riesgos más importantes del proyecto. Durante esta etapa, el equipo
examina la lista de elementos obtenidos en la identificación de riesgos y les asigna
una prioridad, registrando el orden final en la lista maestra de riesgos.
Desde esta lista, el equipo puede determinar los riesgos que son más importantes
y reservar recursos para planear y ejecutar una estrategia específica. El equipo
también puede identificar los riesgos que, por su poca prioridad, pueden quitarse
de la lista. A medida que el proyecto se acerca al final y las circunstancias del
mismo van cambiando, la identificación y el análisis de riesgos se repetirán y la
lista maestra de riesgos se modificará. Puede que surjan nuevos riesgos y puede
que los riesgos más antiguos que han bajado de prioridad se eliminen o
“desactiven”.
Las entradas y las salidas de esta fase están representadas en la Figura 26.
198
Figura 26. Análisis y prioridades de los riesgos
199
8.8.1
8.8.2
8.8.3
Objetivos. La meta principal del análisis de riesgos consiste en establecer
las prioridades de los elementos de la lista de riesgos y determinar cuál de ellos
justifica la reserva de recursos para el planeamiento.
Entradas. Durante el análisis de riesgos el equipo recurrirá a la
experiencia e información conseguida de otras fuentes con relación a las
declaraciones de riesgo obtenidas durante la identificación de riesgos. La
información necesaria para transformar las declaraciones de riesgos en bruto en
una lista maestra de riesgos con prioridades puede obtenerse de las políticas y
directrices de riesgos de la organización, las bases de datos de riesgos del sector,
las simulaciones, los modelos analíticos, los administradores de unidades
empresariales, así como expertos de dominio, entre otras fuentes.
Actividades del análisis de riesgos. Existen varias técnicas cuantitativas
y cualitativas para asignar las prioridades a una lista de riesgos. Una de las más
fáciles para el análisis de riesgos consiste en tomar las decisiones consensuadas
por el equipo en dos de los componentes de riesgo más universales: probabilidad
e impacto. Estas cantidades pueden multiplicarse juntas para calcular una métrica
denominada exposición al riesgo.
• Probabilidad de riesgo. La probabilidad de riesgo es una medida que
calcula la probabilidad de que la situación descrita en el apartado de
consecuencias de los riesgos de la declaración de riesgos llegue a producirse de
verdad. Para clasificar los riesgos es recomendable la asignación de un valor
numérico a la probabilidad. La probabilidad de un riesgo debe ser mayor que cero
o el riesgo no representa una amenaza para el proyecto. Asimismo, la probabilidad
debe ser menor que 100% o el riesgo es una certeza, en otras palabras, es un
200
problema identificado. Las probabilidades son claramente difíciles de calcular y
aplicar, a pesar de contar con la ayuda de las bases de datos de riesgo de
empresas e industrias, cuyos datos muestran los cálculos basados en infinidad de
proyectos. Sin embargo, la mayoría de equipos de proyecto pueden expresar con
palabras sus experiencias, interpretar los informes y proporcionar una amplia
gama de expresiones de lenguaje natural para indicar rangos de probabilidad
numéricos. Por ejemplo, las simples expresiones “bajo, medio, alto” pueden
expresar valores de probabilidad claros (17%, 50%, 84%), aunque también
pueden emplearse términos más complejos como, por ejemplo, “muy poco
probable,” “improbable,” “probable,” “casi con total seguridad”, que expresan
incertidumbre frente a probabilidades. La primera tabla muestra un ejemplo de una
división de tres valores para las probabilidades. La segunda tabla muestra una
división de siete valores para las probabilidades.
Tabla 6. División de siete valores para las probabilidades
Rango de probabilidad
Valor de probabilidad empleado para los
cálculos
Expresión de lenguaje natural
Valor numérico
de 1% a 33% 17% Baja 1 de 34% a 67% 50% Media 2 de 68% a 99% 84% Alta 3
Rango de probabilidad
Valor de probabilidad empleado para los
cálculos
Expresión de lenguaje natural
Valor numérico
de 1% a 14% 7% Muy poco probable 1 de 15% a 28% 21% Baja 2 de 28% a 42% 35% Probablemente no 3 de 43% a 57% 50% 50-50 4 de 58% a 72% 65% Probable 5 de 73% a 86% 79% Altamente probable 6 de 87% a 99% 93% Casi seguro 7
Tenga en cuenta que el valor de probabilidad empleado para el cálculo representa
el punto medio de un intervalo. Con la ayuda de estas tablas de asignación, un
201
método alternativo para cuantificar la probabilidad consiste en asignar una
puntuación numérica al rango de probabilidad o la expresión de lenguaje natural
consensuada por el equipo. Si se utiliza una puntuación numérica para representar
un riesgo, será preciso asignar el mismo valor a todos los riesgos para que el
proceso de prioridades funcione.
Independientemente de la técnica empleada para cuantificar la incertidumbre, el
equipo también deberá desarrollar un enfoque para deducir un único valor para la
probabilidad de riesgo que represente su consenso en relación con cada riesgo.
• Impacto del riesgo. El impacto del riesgo calcula la gravedad de los
efectos adversos, la magnitud de una pérdida o el costo potencial de la
oportunidad si el riesgo llega a producirse dentro del proyecto. Debe tratarse de
una medida directa de la consecuencia del riesgo tal y como se define en la
declaración de riesgo. Puede calcularse en términos financieros o con una escala
de medición subjetiva. La ventaja de expresar todos los impactos del riesgo en
términos financieros es que los patrocinadores del proyecto se familiarizarán antes
con la información. El impacto financiero puede traducirse en costos a largo plazo
de operaciones y soporte técnico, la pérdida de cuota de mercado, costos a corto
plazo por trabajos adicionales o los costos de las oportunidades.
En el resto de situaciones, el uso de una escala de valores subjetiva de 1 a 5 o de
1 a 10 es más adecuada para calcular el impacto. Si todos los riesgos de una lista
maestra de riesgos utilizan las mismas unidades de medida, las técnicas de
asignación de prioridades simples funcionarán. También sirve de ayuda elaborar
tablas de conversión que relacionen el tiempo o el dinero con valores que pueden
compararse con las unidades subjetivas utilizadas en otra parte del análisis, tal
como se muestra en la siguiente tabla. Este enfoque proporciona una unidad de
202
medición altamente adaptable para comparar los impactos de los distintos riesgos
a través de varios proyectos a un nivel empresarial. Esta particular asignación es
una transformación logarítmica. Los valores altos indican pérdidas muy elevadas.
Los valores medios indican una pérdida parcial o una efectividad reducida. Los
valores bajos indican una pérdida pequeña o irrelevante.
Tabla 7. Puntuación riesgos
Puntuación Pérdida monetaria 1 Menos de 100 dólares 2 Entre 100 y 1.000 dólares 3 Entre 1.000 y 10.000 dólares 4 Entre 10.000 y 100.000 dólares 5 Entre 100.000 y 1.000.000 de dólares 6 Entre 1.000.000 y 10 millones de dólares 7 Entre 10 y 100 millones de dólares 8 Entre 100 y 1.000 millones de dólares 9 Entre 1.000 millones y 10.000 millones de dólares 10 Más de 10.000 millones de dólares Cuando las pérdidas monetarias no se pueden calcular con facilidad, el equipo
puede desarrollar un sistema de puntuación de impacto alternativo que abarque
las áreas de proyecto adecuadas. Hall (1998) proporciona los ejemplos63 en la
siguiente tabla.
Tabla 8. Sistemas de puntuación para calcular impacto (Hall 1998)
Criterio Exceso de gastos Programación Técnica Baja Menos de 1% Salta 1 semana Efecto leve en el rendimiento Media Menos de 5% Salta 2 semanas Efecto moderado en el rendimiento Alta Menos de 10% Salta 1 mes Efecto grave en el rendimiento Crítico 10% o más Salta más de 1 mes El objetivo no se puede cumplir El sistema de puntuación para calcular el impacto debería reflejar los valores y
políticas del equipo y de la organización. Una pérdida monetaria de 10.000 dólares 63 Elaine Hall, Managing Risk, p. 101.
203
que pueda ser aceptable para un equipo u organización puede ser inadmisible
para otro. El uso de una puntuación de impacto catastrófica en la que se asigna un
valor artificialmente alto de 100 garantizará que un riesgo con una probabilidad
muy baja ocupe la primera posición de la lista de riesgos y se mantenga en ella.
• Exposición al riesgo. La exposición al riesgo calcula la amenaza general
que supone el riesgo combinando la información que expresa la probabilidad de
una pérdida real con información que indica la magnitud de la pérdida potencial en
un único valor numérico. El equipo puede usar la magnitud de la exposición al
riesgo para clasificar los riesgos. En el caso más simple de análisis de riesgo
cuantitativo, la exposición al riesgo se calcula multiplicando la probabilidad de
riesgo por el impacto.
Cuando las puntuaciones se utilizan para cuantificar la probabilidad y el impacto,
es muy práctico crear una matriz que tenga en cuenta las posibles combinaciones
de las puntuaciones y las asigne a las categorías de riesgo bajo, medio o alto.
Para utilizar la puntuación de probabilidad tripartita, en la que 1 es bajo y 3 alto,
los resultados pueden expresarse en una tabla, donde cada casilla es un valor
posible para la exposición al riesgo. En esta disposición es muy fácil clasificar los
riesgos en la categoría de bajo, medio y alto dependiendo de su posición en las
bandas diagonales de la puntuación ascendente.
Impacto de probabilidad Baja = 1 Media = 2 Alta = 3 Alta = 3 3 6 9
Media = 2 2 4 6 Baja = 1 1 2 3
Exposición baja = 1 o 2 Exposición media = 3 o 4 Exposición alta = 6 o 9
204
La ventaja de este formato tabular es que permite incluir niveles de riesgo en los
informes de estado con colores (rojo indica zona de alto riesgo en la parte superior
derecha, verde zona de riesgo bajo en la esquina inferior izquierda y amarillo para
los niveles de riesgo medio a lo largo de la diagonal) para que los patrocinadores y
los accionistas los puedan comprender fácilmente.
También permite utilizar una terminología bien definida (“alto riesgo” es más fácil
de comprender que “exposición elevada”).
• Técnicas cuantitativas adicionales. Puesto que el objetivo del análisis de
riesgos consiste en asignar una prioridad a los riesgos dentro de la lista de riesgos
y orientar la toma de decisiones hacia el control de riesgos para la reserva de
recursos de los proyectos, hay que tener presente que cada equipo de proyecto
debe seleccionar un método para asignar prioridades que sea adecuado para el
equipo, los accionistas y la infraestructura de administración de riesgos
(herramientas y procesos). Algunos proyectos pueden beneficiarse del uso de
técnicas equilibradas de múltiples atributos para tener en cuenta otros
componentes que el equipo tiene previsto incluir en el proceso de clasificación,
como pueda ser el marco de tiempo necesario, la magnitud de un beneficio de una
oportunidad potencial, la confiabilidad de los cálculos de probabilidades y la
valoración de los activos físicos o de información. En la siguiente tabla se muestra
un ejemplo de matriz de prioridades equilibrada que no tiene en cuenta
únicamente la probabilidad y el impacto, sino también la franja horaria crítica y los
costos necesarios para implementar un control efectivo, donde la fórmula para
obtener el valor de clasificación se calcula de la siguiente manera:
Valor de clasificación = 0,5(probabilidad x impacto) – 0,2(cuándo se necesita) +
0,3 (costo control x probabilidad que el control funcione).
205
Tabla 9. Valor de clasificación
Valor de clasificación Probabilidad
Impacto (en miles de dólares)
Cuándo se necesita
(semanas)
Costo de la implementación
(en miles de dólares)
Probabilidad que el control
funcione 125,025 0,5 500 1 2 0,5 83,596 0,84 200 4 4 0,33 37,64 0,33 200 2 20 0,84 4,9816 0,33 30 4 3 0,84 Con este método, los equipos pueden contabilizar la exposición al riesgo,
programar la criticidad (es decir, cuándo debe realizarse un control de riesgo o
plan de mitigación para que sea efectivo) e incorporar el costo y la eficacia del
plan dentro del proceso de toma de decisiones. Este enfoque general permite a los
equipos clasificar los riesgos por su contribución en la obtención de los objetivos
del proyecto y sirve de base para evaluar los riesgos desde la perspectiva de las
pérdidas (impacto) y desde las oportunidades (beneficios positivos).
La selección del método o combinación de métodos de análisis de riesgo
“correcto” depende de si se toma la decisión correcta entre dedicar esfuerzos en el
análisis de riesgos o en tomar una opción de prioridad incorrecta o insostenible
(para los participantes). Los análisis de riesgos deben llevarse a cabo como apoyo
para la asignación de prioridades empleada para la toma de decisiones y nunca
debe realizarse pensando únicamente en el análisis. Los resultados de los
enfoques cuantitativos o semicuantitativos para la asignación de prioridades de los
riesgos deben evaluarse en el contexto de las metas empresariales, oportunidades
y prácticas de administración lógicas y no deben considerarse sólo como una
forma mecanizada de tomar decisiones.
206
8.8.4 Resultados. El análisis de riesgos proporciona al equipo una lista de
prioridades de riesgos muy útil para planear las actividades de riesgos. En la
disciplina de administración de riesgos de MSF, esta lista recibe el nombre de lista
maestra de riesgos. La información detallada de los riesgos, como el estado del
proyecto, el contexto, la causa original y la unidad de medición utilizada para la
asignación de prioridades (probabilidad, impacto, exposición) se registran a
menudo para cada riesgo en el formulario de declaración de riesgos.
• Lista maestra de riesgos. En la disciplina de riesgos de MSF la lista de
riesgos recibe el nombre de lista maestra de riesgos. Esta lista en forma de tabla
identifica el estado del proyecto que ha originado el riesgo, los potenciales efectos
adversos (consecuencia) y el criterio o información utilizados para la clasificación,
como pueda ser la probabilidad, el impacto y la exposición. Si se ordena por el
nivel de clasificación (alto a bajo), la lista maestra de riesgos proporciona una base
para asignar prioridades en el proceso de planeamiento. En la siguiente tabla se
muestra un ejemplo de lista maestra de riesgos que utiliza un enfoque de cálculo
de dos factores (probabilidad e impacto).
Tabla 10. Ejemplo de lista maestra de riesgos que utiliza un enfoque de cálculo de dos factores Prioridad Estado Consecuencia Probabilidad Impacto Exposición
1 Programación de proyecto largo
Pérdida de fondos al cabo
del año
80% 3 2.4
2 Ningún estándar de codificación para
un lenguaje de programación nuevo
Comercialización con más defectos
45% 2 0.9
3 Ninguna especificación por
escrito de los requisitos
Algunas características del producto no
se implementarán
30% 2 0.6
Impacto bajo = 1, impacto medio = 2, impacto alto = 3
207
Exposición = Probabilidad x Impacto
La lista maestra de riesgos es una compilación de toda la información de
valoración de los riesgos detallada de forma individual. Se trata de un documento
que sirve de punto de partida del proceso de administración de riesgos
subsiguiente y, por ello, debe actualizarse a lo largo de todo el ciclo de análisis,
planeamiento y supervisión de los riesgos.
La lista maestra de riesgos es un documento fundamental para la administración
de riesgos activa o proactiva. Permite la toma de decisiones porque proporciona la
información básica para:
• Asignar prioridades de esfuerzo
• Identificar las acciones críticas
• Acentuar las dependencias La siguiente tabla muestra una lista de los elementos que se mantienen en la lista
maestra de riesgos. El método utilizado para calcular la exposición provocada por
un riesgo debe documentarse con detalle en el plan de administración de riesgos y
hacer lo posible para que los cálculos plasmen con exactitud las intenciones del
equipo al calcular la importancia de los distintos factores.
Tabla 11. Lista de los elementos que se mantienen en la lista maestra de riesgos
Elemento Función Estado Declaración de riesgo Estructurar claramente un
riesgo Necesario
Probabilidad Cuantificar la probabilidad de que suceda
Necesario
Impacto Cuantificar la gravedad o magnitud del costo de la oportunidad
Necesario
208
Criterio de clasificación Única medición de importancia Necesario Prioridad (rango) Asignar prioridades a las
acciones Necesario
Propietario Asegurar continuidad de los planes de acción de riesgo
Necesario
Plan de mitigación Describir las medidas preventivas
Necesario
Plan de contingencia y activadores
Describir las medidas correctoras
Necesario
Causa raíz Orientar el planeamiento de intervención efectiva
Opcional
Efecto de la causa Asegurar las cifras de impacto adecuadas
Opcional
Contexto Documentar los antecedentes para captar el intento de un equipo por poner un riesgo al descubierto
Opcional
Tiempo hasta la implementación
Captar la importancia de implementar los controles de riesgo en un espacio de tiempo determinado
Opcional
• Métodos de análisis adicionales. Algunos equipos pueden realizar niveles
adicionales de análisis para clarificar su comprensión del riesgo de un proyecto.
Estas técnicas adicionales se describen en manuales convencionales de
administración de proyectos y administración de riesgos64 65. Técnicas como el
análisis del árbol de decisiones, el análisis causal, el análisis Pareto, la simulación
y el análisis sensitivo se han utilizado para conseguir una comprensión cuantitativa
más amplia de los riesgos de los proyectos. Estas herramientas deben utilizarse si
el equipo cree que pueden aportar algo positivo a la asignación de prioridades o al
proceso de planeamiento para compensar los costos de recursos.
64 Project Management Institute, A Guide to the Project Management Body of Knowledge 2000 Edition, (Newtown Square, PA: Project Management Institute, Inc. 2000), Capítulo 11. 65 Elaine Hall, Managing Risk.
209
• Formularios de declaración de riesgos. Al analizar cada riesgo de proyecto
de forma individual o durante las actividades de planeamiento relacionadas con un
riesgo determinado, es preciso poder consultar toda la información relacionada
con el riesgo en un documento o formulario de declaración de riesgos.
Normalmente, el formulario de declaración de riesgos contiene los mismos
campos que la lista maestra de riesgos creada durante la identificación y
valoración, aunque puede incluir información adicional que el equipo necesita
durante el proceso de administración de riesgos.
Cuando otro equipo o individuo asigna a los riesgos una acción de continuidad, a
veces es más cómodo tratarlos como un documento separado de la lista maestra
de riesgos. En la siguiente tabla se indica la información que el equipo debe tener
presente al desarrollar un formulario de declaración de riesgos.
Tabla 12. Información formulario de declaración de riesgos
Elemento Función Identificador del riesgo El nombre que emplea el equipo para identificar
inequívocamente una declaración de riesgo, con el propósito de elaborar informes y realizar un seguimiento.
Fuente del riesgo Una amplia clasificación del área subyacente desde la que se originó el riesgo empleada para identificar las áreas en las que deben buscarse las fuentes del riesgo
Condición del riesgo Una frase que describe una condición existente que pudiera conducir a una pérdida para el proyecto. Constituye la primera parte de una declaración de riesgo
Consecuencia del riesgo
Una frase que describa la pérdida que ocurriría en el proyecto si se materializara el riesgo. Constituye la segunda parte de una declaración de riesgo.
Probabilidad del Riesgo
Una probabilidad mayor que cero y menor que el 100 por ciento que representa la probabilidad de que la condición ocurra en realidad, provocando una pérdida.
Clasificación del impacto del riesgo
Amplia clasificación del tipo de impacto que el riesgo puede provocar.
210
Impacto del riesgo La magnitud del impacto en caso de que el riesgo ocurra en realidad. Este número debe ser el valor monetario de la pérdida o simplemente un número entre 1 y 10 que represente una magnitud relativa.
Exposición al riesgo La amenaza completa que significa el riesgo para el proyecto, compensando la probabilidad de una pérdida real con la magnitud de la pérdida posible. El equipo emplea la exposición al riesgo para valorar y clasificar los riesgos. La exposición se calcula multiplicando el impacto por la probabilidad del riesgo.
Contexto del riesgo Un párrafo con antecedentes adicionales que sirvan para aclarar la situación del riesgo.
Riesgos relacionados Una lista de identificaciones que emplea el equipo para dar seguimiento a los riesgos que dependen entre sí.
• Lista de los riesgos más importantes. El análisis de riesgos pondera la
amenaza de cada riesgo como una ayuda para decidir en qué riesgos es
conveniente aplicar una acción. La administración de riesgos toma el tiempo y los
recursos de otras partes del proyecto, por lo que es importante que el equipo sólo
haga lo absolutamente necesario para administrarlos.
Una técnica sencilla pero eficaz para vigilar el riesgo consiste en una lista de los
riesgos más importantes para el proyecto. Todos los patrocinadores del proyecto
deben contar con esta lista que puede incluirse en el documento que establece el
objetivo (la visión) o el ámbito del plan del proyecto.
Lo fundamental es identificar una cantidad limitada de los riesgos importantes que
deben administrarse (por lo general 10 o menos). Aunque el equipo desee
administrar más de 10 riesgos, es más efectivo centrarse en primer lugar en un
número reducido de riesgos importantes y luego administrar los menos
importantes cuando el primer grupo ya está controlado.
211
Tras clasificar los riesgos, el equipo deberá centrarse en elaborar una estrategia
de administración de riesgos y en cómo incorporar los planes de acción al plan
general.
8.8.5 Desactivación de los riesgos. Los riesgos pueden desactivarse o
clasificarse como inactivos para que el equipo pueda centrarse en los riesgos que
precisan de una administración activa. La clasificación de un riesgo como inactivo
significa que el equipo ha decidido que no vale la pena destinar esfuerzos en
realizar un seguimiento de dicho riesgo.
La decisión de desactivar un riesgo debe tomarse durante el análisis de los
riesgos.
Algunos riesgos se desactivan porque su probabilidad es cero y no se prevé que
esta situación cambie, es decir, tienen poquísimas probabilidades de producirse.
Otros riesgos se desactivan porque sus consecuencias, en caso de producirse, se
encuentran por debajo del límite de impacto según el cual un riesgo es más
aceptable que el esfuerzo de planeamiento de una estrategia de mitigación o
contingencia. De todos modos, no es aconsejable desactivar los riesgos que se
encuentren por encima de este límite aunque el riesgo de exposición sea bajo, a
no ser que el equipo esté completamente seguro de que la probabilidad (y en
consecuencia la exposición) será baja en todas las circunstancias pronosticadas.
También hay que tener presente que la desactivación de un riesgo no equivale a
solucionar el riesgo. Los riesgos desactivados pueden volver a aparecer más
adelante en condiciones distintas y el equipo puede volver a clasificarlo como
activo e iniciar las pertinentes actividades de administración de riesgo.
212
8.9 PLANEAMIENTO Y PROGRAMACIÓN DE RIESGOS
El planeamiento de acciones para riesgos es el tercer paso en el proceso de
administración de riesgos. Las actividades de planeamiento convierten la lista de
riesgos con prioridades en planes de acción. El planeamiento implica desarrollar
acciones para cada uno de los riesgos principales, establecer prioridades para las
acciones de un riesgo, y crear un plan integrado de administración de riesgos. El
planeamiento también implica integrar las tareas necesarias para implementar las
acciones de riesgo en una programación de proyecto asignando dichas tareas a
individuos y realizando un seguimiento activo de su estado. Este paso se
representa de forma esquemática en la Figura 27
Figura 27. Planeamiento y programación de riesgos
213
La lista maestra de riesgos se actualiza con información adicional acerca de los
riesgos principales identificados durante el análisis de riesgos. A veces es
recomendable presentar la información de la lista maestra de riesgos utilizada
durante el planeamiento como un formulario de acción separado para que puedan
utilizarlos los integrantes del equipo a los que se les ha asignado los elementos de
acción de riesgo.
8.9.1
8.9.2
8.9.3
Objetivos. El principal objetivo del planeamiento y programación de
riesgos consiste en desarrollar un plan detallado para controlar los riesgos más
importantes identificados durante el análisis de riesgos e integrarlo en los
procesos de administración estándar del proyecto para garantizar su realización.
Entradas. La disciplina de administración de riesgos de MSF recomienda
integrar estrechamente el planeamiento de riesgos en la infraestructura y en los
procesos estándar de planeamiento del proyecto. Entre las entradas en el proceso
de planeamiento de riesgos no sólo se incluyen la lista maestra de riesgos, la lista
de riesgos más importantes y la información de la base de conocimientos de la
administración de riesgos, sino también los planes y programas del proyecto.
Actividades de planeamiento. Cuando desarrolle planes para reducir la
exposición al riesgo:
• Concéntrese en los riesgos de mayor exposición.
• Trate la condición para reducir la probabilidad.
• Busque el origen de la causa en lugar de los síntomas.
• Trate las consecuencias para minimizar el impacto.
214
• Determine el origen de la causa y busque situaciones similares en otras
áreas que puedan producirse por la misma causa.
• Tenga en cuenta las dependencias e interacciones existentes entre los
riesgos.
Puede utilizar varios enfoques para reducir el riesgo:
• En los riesgos que el equipo del proyecto puede controlar, se deben aplicar
los recursos necesarios para reducir el riesgo.
• En los riesgos que el equipo del proyecto no puede controlar, determine
cambios de estrategia o transfiera el riesgo a los individuos que tienen la
autoridad para intervenir.
Durante el planeamiento de la acción de riesgos, el equipo debe tener en cuenta
las seis siguientes alternativas al formular los planes de acción.
• Investigación. ¿Conocemos lo suficiente acerca de este riesgo?
¿Necesitamos estudiar más el riesgo para adquirir más información y
determinar mejor sus características antes de que podamos decidir qué
acción efectuar?
• Aceptación. ¿Podemos vivir con las consecuencias si el riesgo ocurriera
en realidad? ¿Podemos aceptar el riesgo y no aplicar más acciones?
• Prevención. ¿Podemos evitar el riesgo cambiando el campo?
• Transferencia. ¿Podemos evitar el riesgo transfiriéndolo a otro proyecto,
equipo, organización o individuo?
215
• Mitigación. ¿Puede el equipo hacer algo para atenuar el impacto del riesgo
en caso de que ocurra?
• Contingencia. ¿Puede reducirse el impacto mediante una reacción
planeada?
• Investigación. Gran parte del riesgo presente en los proyectos guarda
relación con las incertidumbres que rodean la información incompleta. Los riesgos
relacionados con la falta de conocimiento pueden a menudo resolverse o
administrarse con efectividad obteniendo información sobre el tema antes de
seguir adelante. Por ejemplo, un equipo puede realizar una investigación de
mercado para obtener más información acerca de los conocimientos o la
predisposición a utilizar una determinada tecnología antes de dar por finalizado el
plan del proyecto. Si, finalmente, el equipo desea realizar esta investigación, el
plan de riesgos debería incluir una propuesta de investigación adecuada que
incluya las hipótesis que deben probarse o las preguntas que deben contestarse,
la dotación de personal y el equipamiento necesario.
• Aceptación. En algunos riesgos ya no es posible intervenir con medidas
preventivas ni correctivas efectivas, pero aun así el equipo decide simplemente
aceptar el riesgo para materializar la oportunidad. La aceptación no significa
resignación. Así pues, el plan deberá incluir una exposición razonada con los
motivos que han empujado al equipo a aceptar el riesgo sin desarrollar ningún
plan de mitigación o contingencia. Estos riesgos se deben seguir supervisando a
lo largo del ciclo de vida del proyecto por si se produce algún cambio en las
probabilidades, en el impacto o en posibilidad de ejecutar una medida preventiva o
de contingencia. El compromiso de realizar el seguimiento de un riesgo debe
216
contar con recursos reservados y las unidades de medición de seguimiento
establecidas en el proceso de administración general del proyecto.
• Prevención. A veces puede ocurrir que un riesgo se controle más
fácilmente cambiando el ámbito del proyecto que eliminando el riesgo por
completo. Si se diera este caso, el plan debería incluir documentación que
describa el cambio de forma razonada, y el plan del proyecto deberá actualizarse
e iniciar los procesos necesarios para cambiar el diseño o el ámbito.
• Transferencia. A veces, un riesgo puede transferirse para que pueda ser
administrado por otra entidad fuera del proyecto. Entre los casos en los que un
riesgo puede transferirse destacan:
• Aseguradoras
• Utilizar asesores externos más experimentados
• Comprar un componente en lugar de desarrollarlo
• Subcontratar los servicios
La transferencia del riesgo no significa que el riesgo se haya eliminado. En
general, una estrategia de transferencia de riesgos generará riesgos que seguirán
necesitando una administración proactiva pero que reducen el grado de riesgo a
un nivel aceptable. Por ejemplo, el uso de un asesor externo puede transferir los
riesgos técnicos fuera del equipo, pero puede suponer la aparición de nuevos
riesgos en el área presupuestaria y administrativa del proyecto.
217
• Mitigación. La mitigación de riesgos implica acciones y actividades que se
realizan con anticipación para evitar que se produzca un riesgo o para reducir el
impacto o las consecuencias a un nivel aceptable. La diferencia entre mitigación
de riesgos y prevención de riesgos es que la mitigación intenta minimizar el riesgo
a niveles aceptables, mientras que la prevención cambia el ámbito de un proyecto
para eliminar las actividades que presentan un riesgo inaceptable.
El principal objetivo de la mitigación de riesgos es reducir la probabilidad de
ocurrencia. Por ejemplo, el uso de conexiones de red redundantes a Internet
reduce la probabilidad de perder el acceso porque elimina el punto de error simple.
No todos los riesgos de un proyecto cuentan con una estrategia de mitigación
razonable y rentable. En los casos donde no existe una estrategia de mitigación,
es esencial desarrollar un plan de contingencia efectivo.
• Planeamiento de contingencia. La idea detrás de una estrategia de
contingencia es contar con un plan de reserva que pueda activarse en caso de
que fracasen todos los esfuerzos para administrar el riesgo. Los planes de
contingencia son necesarios para todos los riesgos, incluidos aquellos que
cuentan con planes de mitigación. Describen cómo reaccionar cuando el riesgo se
produce y se centran en la consecuencia y en cómo minimizar su impacto. Para
que sean efectivos, el equipo debe elaborar los planes de contingencia con
antelación. El equipo puede a veces establecer puntos de activación para el plan
de contingencia según el tipo de riesgo o de impacto que se producirá.
Existen dos tipos de puntos de activación de contingencia:
218
• Los puntos de activación temporales se crean a partir de fechas, por la
general la última fecha en la que debe ocurrir un suceso.
• Los puntos de activación de umbral se basan en elementos que pueden
medirse o calcularse.
Es muy importante que exista un consenso rápido entre el equipo y los
responsables en cuanto a los puntos de activación y sus valores para que no
exista un retraso al confirmar los presupuestos o recursos necesarios para poner
en práctica el plan de contingencia.
8.9.4
8.9.5
Actividades de programación. La programación de la administración de
riesgos y actividades de control no es muy distinta de la tendencia estándar
recomendada por MSF en lo relativo a la programación general de actividades de
proyectos66. Es muy importante que el equipo comprenda que las actividades de
control de riesgos forman parte del proyecto y que no son una responsabilidad
adicional de realización voluntaria. El proceso de planeamiento del proyecto y de
informe de estado debe dar cuenta de todas las actividades de riesgo.
Resultados. La salida del plan de acción de riesgos debe incluir planes de
acción específicos que incluyan con detalle uno de los seis enfoques descritos
más arriba. Las tareas para implementar estos planes deben integrarse en las
programaciones y planeamientos estándar del proyecto. Esto incluye realizar
ajustes en los recursos reservados, la programación y las características. El
resultado debe ser un conjunto de acciones de riesgo que describen las tareas
individuales que deben llevar a cabo los integrantes del equipo. La lista maestra
66 Consulte MSF 3.0 Project Management Discipline, disponible en: http://www.microsoft.com/msf/ Documento Publicado Originalmente en : http://www.microsoft.com/latam/technet/articulos/200304/art02/ Descargado de http://www.WillyDev.NET
219
de riesgos debe actualizarse con la información adicional incluida en los planes de
mitigación y contingencia. Es aconsejable resumir los planes de administración de
riesgos en un solo documento.
• Elementos de acción de riesgos. Los elementos de acción de riesgos se
registran en el sistema de seguimiento habitual de actividades de proyecto del
equipo para que se consideren tan importantes como cualquier otra acción.
Como todas las acciones perfectamente documentadas, los elementos deben
tener asociada una fecha final y un miembro del equipo asignado para que no
existan confusiones sobre quién es el responsable de su realización.
• Formularios de acción de riesgos. El equipo debe crear información de
planeamiento adicional para cada riesgo en la lista de riesgos más importantes
para documentar con detalle los planes, los puntos de activación y las acciones de
mitigación y contingencia. Entre la información que el equipo debe tener en cuenta
al desarrollar un formulario de acción de riesgos o un documento se incluye:
o Identificador del riesgo. El nombre que emplea el equipo para identificar
inequívocamente una declaración de riesgo, con el propósito de elaborar informes y realizar un seguimiento.
o Declaración del riesgo. La declaración en lenguaje normal que describa la
condición existente que podría conducir a una pérdida para el proyecto y la descripción de la pérdida que ocurriría si el riesgo se volviera una certeza.
o Estrategia de mitigación del riesgo. Un párrafo o dos que describa la
estrategia del equipo para administrar el riesgo, en donde se incluyan las suposiciones consideradas.
220
o Unidades de medición de la estrategia de mitigación del riesgo. Las unidades de medición que usará el equipo para determinar si funcionan las acciones planeadas para la administración del riesgo.
o Elementos de acción del riesgo. Una lista de las acciones que el equipo
aplicará para administrar el riesgo, incluida la fecha de vencimiento y la persona responsable del proyecto.
o Estrategia de contingencia del riesgo. Un párrafo o dos que describa la
estrategia del equipo en caso de que no funcionen las acciones planeadas para administrar el riesgo. El equipo ejecutaría la estrategia de contingencia del riesgo si se alcanzara su punto de activación.
o Valores de activación para la contingencia. Los valores de activación
son los criterios que usará el equipo para determinar cuándo deben aplicarse los planes de contingencia
o Unidades de medición de la estrategia de contingencia del riesgo. Las
unidades de medición que usará el equipo para determinar si la estrategia de contingencia funciona.
o Responsabilidad del plan de riesgos. La función del equipo y los
individuos responsables de implementar el plan de acción de riesgos.
• Programa y plan del proyecto actualizados. El planeamiento de
documentos relacionados con los riesgos debe integrarse dentro de la
documentación del planeamiento general del proyecto y la programación maestra
debe actualizarse con las nuevas tareas generadas por los planes.
8.10 SEGUIMIENTO E INFORMES DE LOS RIESGOS
El seguimiento es el cuarto paso en el proceso de administración de riesgos de
MSF. El seguimiento de los riesgos es esencial para la implementación de un plan
221
de acciones eficaz. Permite asegurar que las tareas asignadas que implementan
medidas preventivas o planes de contingencia se realizan en el tiempo previsto
dentro de las restricciones de recursos del proyecto. La principal actividad que
realiza el equipo durante el seguimiento de los riesgos consiste en supervisar las
unidades de medición y los puntos de activación del riesgo para comprobar que
las acciones de riesgo planeadas funcionan. El seguimiento es la función de
supervisión del plan de acciones de los riesgos. El seguimiento de riesgos se
representa de forma esquemática en la Figura 28.
Figura 28. Seguimiento e informes de los riesgos
222
8.10.1
8.10.2
8.10.3
Objetivos. El objetivo del seguimiento de riesgos consiste en supervisar
los planes de acción (comprobar que los planes de contingencia y mitigación se
están realizando), supervisar las unidades de medición del proyecto asociadas al
punto de activación de un plan de contingencia e informar al equipo del proyecto
que se han excedido los puntos de activación del plan de contingencia, lo que
indica que un plan de contingencia puede iniciarse.
Entradas. Las principales entradas en el seguimiento de riesgos son las
siguientes:
• Los formularios de acción de riesgos que contienen los planes de mitigación y
contingencia y que especifican las unidades de medición y los valores de punto
de activación del proyecto que deben supervisarse.
• Los informes de estado del proyecto relevantes que se utilizan para realizar un
seguimiento del progreso dentro de la infraestructura de administración del
proyecto.
En función de las unidades de medición del proyecto de las que el equipo está
realizando un seguimiento, existen otras fuentes de información del proyecto
(bases de datos de seguimiento, depósitos de código fuente, sistemas de control o
incluso sistemas de administración de recursos humanos) que pueden
proporcionar datos de seguimiento para el equipo del proyecto.
Actividades de seguimiento. Durante el seguimiento de riesgos el
equipo ejecuta las acciones del plan de mitigación como una parte más de la
actividad general del equipo. El progreso hacia estos elementos de acción
223
relacionados con los riesgos, así como cualquier cambio relevante de los valores
de los puntos de activación, se recopilan y emplean para crear informes de estado
de cada riesgo.
A continuación se indican algunos ejemplos de unidades de medición de proyectos
a las que se pueden asignar unidades de medición para puntos de activación y
que pueden ser sometidas a un seguimiento constante:
• Problemas no resueltos (defectos abiertos) por módulo o componente.
• Promedio de horas extra registradas por semana o por desarrollador.
• Número de revisiones de requisitos (cambios) por semana.
8.10.4 Elaboración de informes de estado del riesgo. La elaboración de
informes de riesgo funciona en dos niveles. Para el propio equipo, la elaboración
de informes del estado de riesgos debe tener en cuenta cuatro situaciones
posibles en la administración de riesgos:
• Un riesgo se soluciona, con lo que termina el plan de acciones que le
corresponde.
• Las acciones para un riesgo siguen el plan de administración de riesgos, en
cuyo caso se mantienen dentro de lo planeado.
• Algunas acciones para un riesgo no siguen el plan de administración de
riesgos, en cuyo caso deben determinarse e implementarse medidas
correctoras.
• La situación ha cambiado significativamente en relación con uno o más riesgos
y por lo general requerirá una revaloración de los riesgos o volver a planear
una actividad.
224
Para los informes externos que se envían a los participantes en el proyecto, el
equipo debe presentar los riesgos importantes para el proyecto y el estado de las
acciones para la administración de riesgos. También es útil mostrar la clasificación
de riesgos anterior, por ejemplo, las veces que un riesgo ha estado en la lista de
los 10 más importantes. Conforme el equipo del proyecto adopta acciones para
administrar los riesgos, la exposición al riesgo total del proyecto debe tender a
establecerse en niveles aceptables.
8.10.5 Resultados. La finalidad de la elaboración de informes de estado de los
riesgos consiste en comunicar los cambios en el estado del riesgo y progreso de
los planes de mitigación. Los informes de estado de los riesgos incluyen la
siguiente información útil:
• Nombre del riesgo
• Clasificación del riesgo (área del proyecto)
• Probabilidad, impacto y exposición actuales
• Nivel de riesgo (bajo, medio, alto)
• Resumen de los planes de mitigación y contingencia
• Estado hacia la realización de los planes de mitigación y contingencia
(acciones completadas)
• Disponibilidad de los planes de contingencia
• Valores de los puntos de activación
• Acciones planeadas
• Propietario del riesgo
La finalidad de un informe de estado de riesgo dirigido a un ejecutivo o a un
accionista consiste en comunicar el estado de riesgos general del proyecto. Este
tipo de informes incluye la siguiente información útil:
225
• Nombre del proyecto
• Nivel de riesgo por área de proyecto
• Tendencia del riesgo
• Resumen de la actividad de los planes de mitigación y contingencia
Este informe se suele incluir dentro del informe de estado estándar del proyecto.
8.11 CONTROL DE RIESGOS
El control de riesgos es el quinto paso en el proceso de administración de riesgos
de MSF. Durante esta etapa, el equipo realiza activamente las actividades
relacionadas con los planes de contingencia porque se han alcanzado los puntos
de activación. Este paso se representa de forma esquemática en la Figura 29.
Figura 29. Control de riesgos
226
Las acciones correctoras se inician según la información obtenida por el
seguimiento de riesgos. La disciplina de administración de riesgos de MSF
depende de la infraestructura y de los procesos existentes de administración del
proyecto para:
• Controlar los planes de acciones para riesgos.
• Corregir las variaciones de los planes.
• Responder a los sucesos de activación.
Los resultados y las lecciones aprendidas de la ejecución de los planes de
contingencia se incorporan al informe de resultados y de estado del plan de
contingencia para que la información forme parte del proyecto y de la base de
conocimientos de riesgos de la empresa. Es fundamental recopilar la mayor
cantidad posible de información acerca de los problemas (en el momento en que
ocurren) o acerca de un plan de contingencia (cuando se invoca) para determinar
la efectividad de este tipo de planes o estrategias en el control de riesgos.
8.11.1
8.11.2
Objetivos. El objetivo del control de riesgos es la ejecución correcta de
los planes de contingencia que el equipo del proyecto ha desarrollado para los
riesgos más importantes.
Entradas. Las entradas del control de riesgos son los formularios de
acción de riesgo que describen con detalle las actividades que los miembros del
equipo deben llevar a cabo, así como los informes de estado de riesgos que
documentan los valores de las unidades de medición del proyecto que indican que
se ha excedido un valor de activación.
227
8.11.3
8.11.4
Actividades de control. Las actividades de control de riesgo deben
utilizar los procesos estándar de administración del proyecto para iniciar,
supervisar y valorar el progreso durante el curso de acción planeado. Los detalles
específicos de los planes de riesgo variarán en cada proyecto, pero debería
utilizarse el proceso general para la elaboración de informes de estado de las
tareas. Es básico identificar continuamente de los riesgos para detectar riesgos
secundarios que puedan aparecer o amplificarse debido a la ejecución del plan de
contingencia.
Resultados. El resultado del control de riesgos es el progreso de la
documentación del informe de estado estándar del proyecto hacia la realización
del plan de contingencia. Para el equipo del proyecto también resulta útil resumir
las lecciones aprendidas (por ejemplo, lo que ha funcionado y lo que no) del plan
de contingencia. Los cambios en el estado del riesgo que podrían modificar la
programación, los recursos o las funciones del proyecto (por ejemplo, la ejecución
de un plan de contingencia) deben propiciar la creación de una solicitud de control
de cambios en los proyectos que cuentan con procesos formales de control de
cambios.
8.12 APRENDER DE LOS RIESGOS
El aprendizaje de los riesgos es el sexto y último paso en el proceso de
administración de riesgos de MSF. Su papel en las actividades de administración
de riesgos es más bien estratégico, empresarial u organizativo. Esta fase se
conoce también como aprovechamiento de los riesgos para destacar los
conocimientos que la organización obtiene en términos de experiencia para el
equipo, el proyecto o la propia empresa, así como la propia mejora del proceso de
228
administración de riesgos. El aprendizaje de los riesgos debe constituirse como
una actividad continuada durante todo el proceso de administración de riesgos de
MSF y puede ponerse en práctica en cualquier momento. Se centra en la
consecución de tres objetivos clave:
• Proporcionar calidad a las actividades de administración de riesgos para que el
equipo pueda obtener información.
• Hacer acopio de las lecciones aprendidas, especialmente las relativas a la
identificación de riesgos y a las estrategias de mitigación, para que otros
equipos puedan hacer uso de ellas. Esta información permitirá aumentar la
base de conocimientos de los riesgos.
• Mejorar el proceso de administración de riesgos gracias a la información
proporcionada por el equipo.
Las reuniones sobre los riesgos son el lugar ideal para empezar a aprender de los
riesgos. Es preciso organizarlas periódicamente y, al igual que cualquier otra
sesión de puesta en común de MSF, deben planearse con antelación, deben
seguir un orden del día previamente estructurado, deben contar con la asistencia
de todos los participantes y éstos deben expresar sus opiniones de forma honesta
y libre en un ambiente optimista. En la Figura 30 se representa esquemáticamente
la fase de aprendizaje.
229
Figura 30. Aprendizaje de los riesgos
8.12.1 Captar el aprendizaje de los riesgos. La definición de la clasificación de
los riesgos es un mecanismo muy útil para garantizar que las lecciones aprendidas
de experiencias anteriores están al alcance de los equipos que realizarán
valoraciones de los riesgos en el futuro. Mediante las clasificaciones de los riesgos
se suelen registrar dos aspectos fundamentales del aprendizaje:
Nuevos riesgos. Si un equipo detecta un problema que previamente no ha sido
identificado como un riesgo, debería comprobar si algún síntoma (indicadores
anticipados) podría haber sido de ayuda para predecir el riesgo. Puede que la
lista de riesgos existente deba actualizarse para ayudar a identificar una
condición de riesgo futura, o puede que el equipo también haya identificado un
230
nuevo riesgo que debería incluirse en la base de conocimientos de riesgos
existentes
Estrategias de mitigación correctas. El otro aspecto clave consiste en recopilar
las experiencias de estrategias que se han utilizado con éxito (o incluso las que
no han tenido éxito) para atenuar los riesgos. El uso de una clasificación de
riesgos estándar permite agrupar con sentido los riesgos relacionados entre sí
para que los equipos encuentren con facilidad las estrategias de administración
de riesgos que se han aplicado con éxito en el pasado.
8.12.2 Administrar el aprendizaje de los riesgos. Las organizaciones que
emplean técnicas de administración de riesgos con frecuencia deben crear una
estructura para administrar los riesgos de un proyecto. A continuación se
describen las condiciones necesarias para poner en práctica este requerimiento:
• Un individuo debería ser el propietario y el responsable de un área de
clasificación de riesgos específica para aprobar los cambios.
• Las clasificaciones de los riesgos deberían equilibrar la necesidad de una
cobertura de riesgos contra la complejidad y usabilidad. A veces, la
creación de una clasificación de riesgos distinta para varios tipos de
proyectos puede mejorar la usabilidad notablemente.
• Debe crearse una base de conocimientos de los riesgos para mantener las
clasificaciones, las definiciones, los criterios de diagnóstico y los sistemas
de clasificación de los riesgos, así como para recopilar información acerca
de las experiencias del equipo.
231
• El proceso de revisión de riesgos también debe administrarse
correctamente para garantizar la recopilación de todo el conocimiento
posible. Para un equipo de proyecto las revisiones pueden llevarse a cabo
durante la revisión final del proyecto, cuando los resultados de la
administración de riesgos sean evidentes para todos los miembros del
equipo.
8.12.3
8.12.4
Clasificaciones de riesgos según el contexto. La identificación de
riesgos puede perfeccionarse mediante el desarrollo de clasificaciones de riesgo
para los contextos repetitivos de un proyecto. Por ejemplo, una organización que
se dedique a la creación de proyectos puede elaborar clasificaciones para distintos
tipos de proyecto. A medida que la experiencia aumenta en el contexto de un
proyecto, los riesgos pueden ser más específicos y asociarse con estrategias de
mitigación.
Base de conocimientos de riesgos. La base de conocimientos de
riesgos es un sistema formal o informal que la organización utiliza para recopilar
conocimientos para que puedan servir de ayuda a la administración de riesgos.
Sin una base de conocimientos, las organizaciones podrían tener problemas para
adoptar un enfoque proactivo para la administración de riesgos. La base de
conocimientos de riesgos es distinta de la base de datos de administración de
riesgos, que se utiliza para almacenar y realizar un seguimiento de elementos de
riesgo individuales, planes y estados durante el proyecto.
232
8.12.5 Madurez para administrar los conocimientos acerca de un riesgo. La
base de conocimientos de riesgos es un componente clave para la mejora
continuada de la administración de riesgos.
En los niveles más bajos de madurez, los equipos de proyectos y de procesos
carecen de base de conocimientos. Cada equipo debe empezar desde cero cada
vez que inicia una administración de riesgos. En esta situación, el enfoque hacia la
administración de riesgos suele ser reactivo, pero puede pasar a la siguiente fase
de administración de riesgos activa. Sin embargo, el equipo no administra los
riesgos de forma proactiva.
El siguiente nivel de madurez precisa de una base de conocimientos informal que
utilice los conocimientos implícitos obtenidos por los miembros con más
experiencia de la organización. Se suele lograr implementando una junta de
riesgos en la que los profesionales más experimentados pueden controlar la
evolución de cada equipo. Este sistema fomenta la administración de riesgos
activa y puede provocar una administración de riesgos limitada por la inclusión de
políticas. Un ejemplo de política de administración de riesgos proactiva podría ser
la siguiente: “todos los proyectos de más de 20 días de antigüedad necesitan una
revisión de riesgos para obtener la aprobación.”
El primer nivel de formalidad en la base de conocimientos se obtiene con un
enfoque más estructurado para la identificación de riesgos. La disciplina de
administración de riesgos de MSF recomienda el uso de las clasificaciones de
riesgos para este cometido. Con la captación formal de la experiencia, la
organización puede realizar más actividades de administración proactivas a
medida que las causas subyacentes de los riesgos se van identificando.
233
Finalmente, las organizaciones con más experiencia no sólo registran los
indicadores que pueden acabar en riesgo, sino también las estrategias adoptadas
para administrar los riesgos y su índice de éxito. Con este tipo de base de
conocimientos los pasos de identificación y planeamiento del proceso de riesgos
pueden basarse en la experiencia compartida de varios equipos y la organización
puede empezar a optimizar sus costos de administración de riesgos y a amortizar
la inversión realizada en el proyecto. Al analizar la implementación de la base de
conocimientos de riesgos, la experiencia demuestra que:
• El valor de la base de conocimientos de riesgos aumenta cuanto más repetitivo
es el trabajo (como las organizaciones que se especializan en proyectos
similares o los procesos operativos continuados).
• Si una organización se centra en tan sólo un proyecto, es más fácil mantener
una base de conocimientos menos compleja.
La administración de riesgos no es un proceso automático que evita que los
equipos piensen en los riesgos. Incluso en las situaciones repetitivas, el entorno
empresarial, las expectativas de los clientes, las aptitudes del equipo y la
tecnología siempre son diferentes. Por lo tanto, el equipo debe valorar cuáles son
las estrategias de administración de riesgos apropiadas para cada proyecto.
8.13 ADMINISTRACIÓN DE RIESGOS INTEGRADA EN EL CICLO DE VIDA DEL PROYECTO
El proceso de administración de riesgos de MSF está estrechamente integrado en
el ciclo de vida general del proyecto. La valoración de los riesgos puede empezar
desde la fase preliminar cuando el equipo del proyecto y los accionistas
234
estructuran el proyecto y determinan las primeras restricciones. Por cada
restricción y suposición que se incluya en el proyecto surgirán nuevos riesgos. El
equipo del proyecto debe iniciar las actividades de identificación de riesgos lo
antes posible. Durante la etapa de análisis y planeamiento de los riesgos, los
planes de mitigación y contingencia de riesgos necesarios deben incluirse
directamente en la programación del proyecto y en el plan principal. El proceso de
administración estándar del proyecto deberá supervisar el progreso del plan de
riesgos.
Aunque, por lo general, el proceso de administración de riesgos empieza con las
sesiones programadas de análisis e identificación de riesgos, el planeamiento, el
seguimiento y el control de los riesgos posterior se llevarán a cabo como distintos
bloques de actividad para cada riesgo identificado en la lista maestra de riesgos.
Dentro de la disciplina de riesgos de MSF, la administración de riesgos continuada
da por hecho que el equipo del proyecto “siempre” se encuentra simultáneamente
en el estado de identificación y seguimiento de riesgos. Participarán en las
actividades de control de riesgos cuando sean requeridos por los eventos de
activación y la programación y el planeamiento del proyecto. Sin embargo, durante
el ciclo de vida completo del proyecto, aparecerán nuevos riesgos que precisarán
de sesiones de análisis y planeamiento adicionales. No es necesario sincronizar
los pasos de la administración de riesgos con las etapas del ciclo de vida del
proyecto. Algunos equipos iniciarán la actividad de análisis e identificación de
riesgos en etapas más importantes como oportunidades para valorar de nuevo el
estado del proyecto. Al mismo tiempo, es importante resumir los conocimientos
obtenidos de un riesgo.
Por lo general, la identificación y el seguimiento de los riesgos son actividades
continuas. Los miembros del equipo deberían buscar constantemente los riesgos
de un proyecto y ponerlos al descubierto para que el equipo pueda analizarlos, así
235
como realizar un seguimiento ininterrumpido del progreso de acuerdo con planes
de riesgo específicos. Es más probable que el análisis de los riesgos y la
modificación de los planes de acción de la administración de riesgos sean
actividades más intermitentes, a veces programadas proactivamente (en etapas
importantes) y a veces como consecuencia de sucesos de proyectos no
programados (descubrimiento de riesgos adicionales durante el seguimiento y el
control). A menudo, el aprendizaje es más un suceso programado que sucede en
etapas importantes y al final de un proyecto.
A lo largo de un proyecto, la naturaleza de los riesgos que se analizan también
puede cambiar. En la fase inicial del proyecto, los riesgos estarán relacionados
con el proyecto, la empresa, el ámbito, los requisitos y el diseño. Pero con el paso
del tiempo, los riesgos técnicos relacionados con la implementación se hacen más
evidentes para acabar convirtiéndose en riesgos operativos. Puede servir de
ayuda utilizar listas de control o revisar las listas de clasificaciones de riesgos en
cada fase de transición importante del ciclo de vida del proyecto para reorientar la
actividad de identificación de los riesgos.
8.14 ADMINISTRACIÓN DE RIESGOS EN LA EMPRESA
Para obtener el máximo rendimiento posible de la administración de riesgos, es
muy importante mantener una perspectiva empresarial para tratar la
administración de riesgos en toda la empresa.
8.14.1 Creación de una cultura de administración de riesgos. Si bien pocas
organizaciones dedicadas a la creación de proyectos discuten la importancia de la
administración de riesgos en sus proyectos, son muchas las que tienen
dificultades por adoptar la disciplina asociada al proceso de una administración de
236
riesgos proactiva. A menudo realizan una valoración de riesgos al inicio de cada
proyecto, pero no consiguen mantener el proceso a medida que avanza el
proyecto.
Para explicar este comportamiento se emplean dos argumentos:
• Plazos de entrega demasiado ajustados.
• Preocupación de que la atención dedicada a los riesgos minará la confianza
de los clientes o mostrará una impresión negativa.
Esto suele deberse a que los responsables del proyecto no comprenden el valor
que la administración de riesgos tiene para un proyecto. En consecuencia, suelen
mostrarse reacios a destinar el tiempo necesario para la administración de riesgos
(y obviamente para otras actividades de administración del proyecto) en el
presupuesto del proyecto. En cambio, pueden sacrificar estas actividades si el
presupuesto se dispara.
Por lo tanto, es especialmente importante asegurarse de que todos los accionistas
sean conscientes de la importancia de la administración de riesgos para poder
crear un entorno en el que la administración de riesgos pueda prosperar. Se ha
comprobado que los siguientes pasos pueden ayudar a implantar la administración
de riesgos como una disciplina constante:
• Asegurar el patrocinio para la administración.
• Buscar el consejo y el tutelaje de un administrador de riesgos que pueda
aportar experiencia personal y conocimiento de los errores
• Inculcar a todos los accionistas la importancia de administrar los riesgos y los
costos que pueden derivarse de los errores.
237
• Preparar un equipo de administradores de riesgos que sirva como modelo de
ejemplo para otros; un plan de formación efectivo consiste en combinar clases
teóricas acerca de la administración de riesgos con ejercicios prácticos
basados en un proyecto real.
• Invitar a todos los participantes en el proyecto a las reuniones de revisión de
riesgos y asegurarse de que reciban un informe del estado de los riesgos.
• Incorporar un sistema de incentivos para los miembros del equipo del proyecto
que identifiquen y/o administren correctamente los riesgos.
• Asegurarse de que los equipos del proyecto tienen en cuenta los riesgos en el
planeamiento del proyecto y en la toma de decisiones clave.
• Solicitar periódicamente la opinión de los accionistas en lo referente a la
efectividad del proceso de administración de riesgos y asegurarse de que esta
información tenga resultados positivos.
• Recompensar a los miembros del equipo que pongan al descubierto nuevos
riesgos.
8.15 ADMINISTRAR UNA CARTERA DE PROYECTOS
Las organizaciones dedicadas a la creación de proyectos pueden beneficiarse de
la implantación de un proceso para administrar los riesgos entre sus carteras de
proyectos. Entre las ventajas destacan: • Los recursos y el esfuerzo pueden asignarse a todos los proyectos de la
cartera en función de los riesgos a los que deben hacer frente.
• El administrador de riesgos de cada proyecto cuenta con un segundo punto de
asignación de problemas externo para disponer de una opinión alternativa a las
valoraciones del equipo.
238
• Los equipos de proyectos pueden aprender más rápidamente de las
experiencias de otros proyectos.
• La calidad de los procesos de administración de riesgos se aplica a cada
proyecto. Es preciso destacar que la revisión de riesgos por cartera complementa las
valoraciones de riesgos realizadas por cada equipo de proyecto. El equipo de
revisión carece de los conocimientos necesarios para identificar los riesgos y del
tiempo para tomar una acción de mitigación de los riesgos, aunque puede
contribuir al análisis y planeamiento de los riesgos. Puesto que el grupo de
revisión normalmente está integrado por administradores con más experiencia,
sus miembros pueden a menudo recurrir a ellos para que adviertan al equipo del
proyecto de la posible existencia de un riesgo, contribuyendo a la asignación de
prioridades de los riesgos. También pueden recomendar estrategias de mitigación
y contingencia que han visto aplicar con éxito en el pasado.
Las siguientes prácticas se han aplicado con éxito en la administración de riesgos
de una cartera:
• Asegurar el apoyo ejecutivo para realizar el proceso de revisión de la cartera.
Mantener el apoyo mediante informes periódicos acerca de nuevos
descubrimientos.
• Programar las reuniones con mucha antelación. Reserve un día fijo para
realizar la reunión, si es posible un día en el que la mayoría de responsables
del proyecto puedan asistir. Envíe invitaciones a los miembros de la junta de
revisión con tiempo suficiente, ya que los buenos revisores seguramente ya
tienen otros compromisos.
239
• Seleccione con detenimiento los proyectos que desee revisar. Puede tener
previsto revisar los proyectos de mayor envergadura una vez al mes. Intente
revisar también el mayor número posible de proyectos menos importantes.
• Siga un orden del día estándar para cada proyecto, de modo que los
responsables sepan a qué atenerse durante la reunión. Por ejemplo, puede
dedicar 20 minutos para la presentación de la valoración del riesgo actual, 20
minutos para debatir las estrategias de mitigación y contingencia para terminar
con un repaso de 5 minutos de los conocimientos que desee compartir con los
otros equipos del proyecto.
• Utilice documentos estándar para elaborar los informes del proyecto y las
valoraciones de los riesgos.
• Asegúrese de que los documentos se actualicen y distribuyan con antelación a
todos los asistentes de la reunión; de esta forma la reunión será más breve.
• Anime a los líderes del equipo del proyecto a asistir a la reunión personalmente
o por teléfono.
• Asegúrese de que los equipos del proyecto saquen provecho de la sesión de
revisión. A tal efecto, repase el progreso de los temas que técnicamente no
puedan considerarse riesgos pero a los que la experiencia de los miembros de
los miembros de la junta de revisión pueda aportar nuevos datos al equipo del
proyecto.
• Evite buscar los culpables de la situación del proyecto.
• Permita que cualquier miembro del proyecto solicite una revisión de su
proyecto.
240
9. CONCLUSIONES
Los proyectos son comunes en el día adía de las empresas estudiadas y en
general en todas las empresas, pero es sorprendente la poca rigurosidada y
formalidad con la que se desarrollan las actividades propias de la gerencia de
proyectos en esta empresas. Se evidencia claramente mucha improvisación y
falta de preparación por parte de las personas que realizan los proyectos, ya que
desconocen en gran medida los conceptos claves para la gerencia de estos, o si
los conocen hacen caso omiso en su aplicación. El sobre esfuerzo y la sobre
carga de trabajo para cumplir los tiempos acordados es un hecho evidente en la
gran mayoría de los proyectos de TI que se llevan a cabo, debido en gran medida
a la pobre planeación y a la deficiente ejecución que se realiza cuando se
abordan estos, como también me atrevo a afirmar que al deficiente manejo de los
riesgos en los proyectos. La falta de preparación y entrenamiento en el tema por
parte de las personas encargadas de liderar los proyectos genera una dificultad
mas en la realización exitosa de los mismos, pero fundamentalmente inhibe el
tener una mejor perspectiva sobre como se pueden hacer mejor las cosas. La
implementación de una metodología puede ser de gran ayuda sea cual sea la que
se emplee , pero definitivamente esta implementación por si sola no mitigará los
diferentes problemas encontrados, para lograrlo, considero esta implementación
debe estar acompañada por una estructuración y alineación de los procesos del
área de TI y de la empresa que le permitan cumplir los compromisos y niveles de
servicio acordados en cada uno de sus servicios y en general permitan el
desarrollo estructurado y riguroso del modelo de gerencia de proyectos planteado.
De lo contrario, se corre el riesgo de que la urgencia en el día a día no permita de
241
igual forma implementar y ejecutar el modelo como se debe, al igual como sucede
con muchas otras buenas intenciones en la mayoría de las empresas.
No se debe olvidar de ninguna forma la importancia de incorporar una herramienta
de gestión de proyectos que apoye la implementación del modelo. La importancia
de la herramienta en este caso radica en que una parte fundamental en la
apropiada gestión de proyectos reside en la capacidad para controlar
adecuadamente las diversas variables y el volumen cada vez mayor de
información que se genera durante la ejecución de un proyecto. Las complejidades
asociadas a la gestión de los recursos y la necesidad de maximizar la
productividad exigen sistemas de información robustos, flexibles y a la vez fáciles
de usar.
Es fundamental para el modelo presentado que las labores de seguimiento,
reportes de avance, estadísticas, ajuste de cronogramas, planeación,
documentación y consulta, estén soportados por herramientas tecnológicas que
agilicen esta labor al contrario de aumentar la dificultad y operatividad en la
gerencia y administración de los proyectos de TI. Adicionalmente la
implementación de una herramienta facilita la adopción de una metodología,
estandariza la forma de realizar las diferentes labores, permite la reutilización de
formatos, cronogramas, estructuras de desglose de trabajo, planes, y lecciones
aprendidas.
La revisión de los datos e información reales de proyectos anteriores es uno de
los mejores modos de sentar las bases para las estimaciones, aspecto que se
encontró deficiente en la investigación realizada. Las organizaciones inteligentes
recogen y analizan estos datos. Muchas actividades del proyecto cuentan con
indicadores de la industria que pueden proporcionar buenas pruebas
comparativas, para esto es fundamental el contar con una forma estructurada de
242
recolectar toda esta información y es claramente una herramienta de gestión de
proyectos la que puede facilitar en gran parte esta labor.
Sin lugar a dudas se debe resaltar que la planeación es la función más
importante que se tiene que realizar en la gerencia de proyectos. Un hallazgo
importante de este trabajo, es el que muchos proyectos desembocan en un
fracaso por la precipitación en su inicio o por la creencia que sobre la marcha se
arreglan las cosas. Otros fracasan porque una vez realizada la planificación inicial
queda ésta, exclusivamente, como referencia lejana y formal de lo que debía
haber sido. Existe un dicho, que dice que: los planes son para no cumplirlos. Y
éste dicho es el que sin lugar a dudas se debe romper aquí, en la gerencia de
proyectos y el que se pretende romper con el modelo de gerencia de proyectos de
TI planteado. La planeación apunta directamente hacia el éxito de los proyectos,
ya que esta permite el establecimiento de unas actividades, recursos y estrategias
que debidamente priorizados, interrelacionadas y ordenadas en el tiempo hacen
que se produzcan unos acontecimientos o evitan que se produzcan otros nocivos
para la obtención de unos objetivos.
Por experiencia sabemos que errar es más fácil que acertar, así que, tomar las
precauciones para salvar las dificultades, resulta, no- solo conveniente, si no
prudente, para la gerencia de proyectos de TI y en general para muchas
actividades en la empresas y en la vida.
9.1 RESPECTO A LA INVESTIGACIÓN REALIZADA
En este trabajo se realizó un estudio e investigación sobre la problemática en la
gestión de proyectos de TI y sobre las diferentes alternativas de solución que se
243
proponen en los diferentes medios, las metodologías más importantes
relacionadas con el tema de gestión de proyectos, se revisó la problemática en
torno a proyectos de TI, especialmente en búsqueda de respuestas a la pregunta
¿Por qué terminan con demoras, exceden el presupuesto y no satisfacen las
necesidades de los usuarios y del negocio “no son exitosos” los proyectos de TI?.
La información base se tomo en un alto porcentaje de artículos publicados por el
PMI, como también se utilizaron en un alto porcentaje los reportes de la The
Standish Group internacional, INC; en los que se encuentran los resultados de las
diferentes investigaciones que ha realizado esta organización alrededor del tema
de gestión de proyectos, y en particular de los proyectos de TI.
Adicionalmente se recopilo información de organizaciones como Asociación
Colombiana de Ingenieros de Sistemas (ACIS), la academia, las metodologías
mas importantes en este tema como el PMI, PRINCE, RUP, CMM, XP, SCRUM y
el MSF de Microsoft (esta particularmente por ser una metodología muy práctica
enfocada a proyectos de TI), libros, las mejores prácticas en gestión de proyectos
de TI y casos de estudio, investigaciones y experiencias en el ámbito local,
además se realizaron entrevistas estructuradas a profundidad con académicos,
consultores, directores de proyectos, gerentes de informática y profesionales
relevantes en el ámbito de gerencia de proyectos de TI, pertenecientes a las
empresas de GEA y a proveedores de tecnología de estas (son omitidos los
nombres de estas empresas para mantener su reserva). Estas entrevistas
permitieron obtener la información cualitativa de gran importancia y relevancia
para los objetivos de la investigación realizada. Posteriormente se complemento
esta información con la realización de una encuesta a 50 profesionales (de las
cuales respondieron 30) relacionados con este tipo de proyectos entre los que se
encontraban proveedores de servicios de TI de la empresa de estudiada y de 2
empresas más del GEA, lo que permitió validar y priorizar en importancia las
244
causas de fracaso en los proyectos de TI que finalmente se seleccionaron en esta
investigación como base para el desarrollo del modelo de gestión de proyectos de
TI que ataque directamente esta causas.
Se encontró en términos generales que la información y las investigaciones sobre
el fracaso de los proyectos de TI son bastante limitadas tanto a nivel local como
mundial, y la mayoría de las investigaciones que se han realizado se concentran
en considerar los fracasos en los proyectos de manera genérica como “fallas en la
gestión de los proyectos”. Es importante resaltar que en el ámbito local es difícil
contar con este tipo de información principalmente por dos motivos: No se guarda
información sobre el desempeño de los proyectos y en los casos que se tiene este
tipo de información es confidencial, estratégica o no se puede divulgar porque
puede tener repercusiones en la imagen de las compañías.
Después de investigar y revisar la gran cantidad de fuentes de información sobre
esta problemática, se puede concluir que no existe una única respuesta a la
pregunta planteada, debido a que cada proyecto tiene características propias,
diferentes factores de riesgo, causas diferentes de fracaso y los entornos
culturales son particulares para cada organización. Sin embargo, dado que este
estudio se nutrió también de experiencias personales, se detectaron diversos
factores que entorpecen el éxito de un proyecto y se lograron identificar y
analizar, creando un grupo de referencia de las causas más comunes de fracaso
en los proyectos de TI, con lo cual se logra dar una respuesta a la pregunta
planteada en esta tesis. Por lo tanto se puede decir en términos generales que a
nivel mundial los proyectos de TI fallan principalmente por:
245
Principales Causas: 1. Planificación deficiente
2. Definición escasa de especificaciones
3. Falta de participación de usuarios claves
4. Cambios de alcance
5. Falta de apoyo ejecutivo
6. Expectativas irreales
7. Objetivos poco claros
8. Plazos de tiempo irreales
9. “Deadlines” innecesarios
10. Problemas de comunicación
Fuente: Standish Group internacional, INC
Con esta información como punto de partida y la información obtenida durante las
entrevistas realizadas a personas responsables e interesadas en este tema en el
ámbito local, y de diferentes artículos sobre el tema, se creo una lista
personalizada sobre las principales causas por las que fallan los proyectos de TI.
en ámbito local y particularmente en las empresas donde se realizo la
investigación.
Se logro identificar que causas o factores que impiden el éxito de los proyectos
se encuentran dentro de diferentes aspectos o elementos relacionados con la
gestión de proyectos, tales como: aspectos humanos, organizacionales,
culturales, técnicos y metodológicos, de planeación, información y control; por lo
cual se opto por una agrupación en cuatro aspectos macros que sirvieron como
marco de referencia para el desarrollo del modelo de gestión de proyectos de TI
que finalmente se propuso.
246
Los cuatro aspectos macro son los siguientes:
CAUSAS RELACIONADAS CON ASPECTOS HUMANOS:
• Recurso humano incompetente
• Falta de trabajo en equipo y sentido de pertenencia
• Problemas de conducción, comunicación y conflicto
• Falta de conocimientos y habilidades para gerenciar proyectos
CAUSAS RELACIONADAS CON ASPECTOS ORGANIZACIONALES
• Falta de compromiso y sentido de pertenencia del usuario líder del
proyecto. (Por usuario líder se entiende la persona del negocio que
representa el área o áreas que directamente serán impactadas con
los resultados del proyecto)
• La falta de cultura de trabajo por proyectos en la organización
• No participación de áreas claves del negocio desde el inicio del
proyecto
• Cambios en los objetivos
CAUSAS RELACIONADAS CON ASPECTOS PROPIOS DE TI O DE LOS PROYECTOS DE TI
• Problemas de administración de tecnología
• Desconocimiento de la tecnología
• Problemas de Integración de TI
CAUSAS RELACIONADAS CON ASPECTOS METODOLÓGICOS
• Inadecuado manejo de los Riesgos del proyecto
• Proyectos demasiado ambiciosos
• Falta de un plan de aseguramiento de la calidad del proyecto
247
• Poca claridad e inadecuada asignación de las responsabilidades en
el equipo de trabajo
• No utilización, o mala utilización de metodologías de Gerencia de
Proyectos
• Falta de claridad y unidad alrededor de los objetivos del proyecto
• Especificación de requerimientos incompleta, ambigua,
inconsistente, variante.
• Inadecuado manejo de control de Cambios
• Errores en la planeación del Proyecto (Poca precisión para estimar
el tiempo y los recursos)
A partir de esta información se sintetizaron los conceptos fundamentales y se
definieron unos criterios para seleccionar los aspectos de las metodologías que
mas aplicaban para el desarrollo de un modelo que permitiera la mitigación de
estas causas, para lo cual se escogió como base la metodología del PMI como
metodología genérica y complementada con el MSF como metodología
especifica para proyectos de TI objeto de esta investigación. Se escogió el PMI
por su aceptación internacional y por el conocimiento que se tiene de esta
metodología a nivel local, y el segundo por sus aportes en el campo específico de
los proyectos de TI, como también por permitir de una manera práctica
complementar el MPI. También se revisaron algunas propuestas y documentos
como el de Gonzalo Montes que aportaron según el criterio del investigador a la
solución de la problemática bajo el contexto esbozado. Esto permitió crear
propuestas para desarrollar el modelo de gestión de proyectos acorde a las
necesidades planteadas.
El enfoque que se abordó en este trabajo estuvo orientado a desarrollar un
modelo con una metodología práctica y flexible a partir de la mejores practicas a
248
nivel mundial, basados en el modelo de gestión de proyectos del PMI, que permita
gestionar los proyectos de TI de una forma correcta y bien elaborados, con un
enfoque muy importante como lo es el de aprendizaje y retroalimentación de la
misma metodología y el modelo, que permita en el tiempo seguirse adaptandose y
perfeccionando.
Una conclusión muy importante a la que se pudo llegar después de todo este
análisis e investigación, y de estudiar las causas de fracaso en este tipo de
proyectos, es que si bien el desarrollo e implementación de proyectos de TI
puede ser extremadamente complejo, hecho que contribuye a que sean mas
difíciles y de mayores riesgos, la tecnología en sí no es el único ni el principal
factor en el fracaso de los proyectos de TI. Se encontró que el éxito o fracaso de
los proyectos de TI esta a su vez también muy relacionado con las personas que
intervienen y con los procesos que se realizan para el gerenciamiento de estos.
Se puede decir que los factores encontrados como inhibidores del éxito en lo
proyectos de TI, están asociados principalmente a una deficiente administración o
gerencia de proyectos y en especial a la no aplicación de las mejores practicas de
gestión de proyectos de TI. Ya que la gerencia de proyectos esta precisamente
enfocada en la mitigación de estos factores de tal forma que se disminuyan los
riesgo de fracaso, con lo cual se incrementa la probabilidad éxito de los mismos.
De los resultados obtenidos se encuentra que las fases donde se generan más
deficiencia el la gerencia de proyectos, son las fases de Formulación, Visión y
Planeación, que al hacerse con vaguedad, poca rigurosidad e imprecisiones,
provoca muchos de los problemas de no éxito en los proyectos, encontrados y
enunciados en este trabajo.
249
Se corroboro que las causas del fracaso en los proyectos de TI en el entorno
investigado están enmarcadas dentro de las causas encontradas por organismos
internacionales aunque su nivel de importancia o de incidencia es diferente. Esto
es explicado en gran medida por las diferencias en los aspectos culturales y a las
características organizacionales de las empresas estudiadas.
La poco formalidad en los procesos con los que se desarrolla la gerencia de
proyectos en las empresas estudiadas, exige la implementación de una practica
de administración de proyectos formal y de esta forma contribuir a mejorar el
desempeño de los proyectos de TI.
Para desarrollar la metodología de gestionar proyectos de TI se propuso utilizar
como base la metodología genérica de gestión de proyectos estándar en el ámbito
internacional llamada método PMI® o PMBOK® Guide, dado su gran acogida a
nivel internacional y en especial en el entorno Colombiano , pero complementada
con el MSF (Microsoft Solutions Framework metodología desarrollada por Microsoft) la cual tiene un carácter de metodología específica para proyectos de
TI y especialmente por el aporte en los modelos avanzados de administración de
riesgos, procesos optimizados para la ejecución de etapas para la implementación
de soluciones tecnológicas y un modelo de trabajo en equipo que permite superar
las barreras que se encuentran en los equipos de trabajo y el trabajo en equipo.
Aspectos que fuero encontrados y validados como causantes de fracasos en los
proyectos de TI llevados a cabo en las empresas estudiadas.
También se utilizaron otros suplementos y técnicas con el fin de tener en cuenta
las principales características organizacionales de las empresas, el cual se
encontró es uno de los puntos débiles al emplear las metodologías genéricas
como el PMI. Se encontró que una de las casas de fracaso de los proyectos, es la
250
de no emplear metodologías adecuadas. Pero además se encontró que en los
casos en los que si se usan las metodologías, estas por su carácter genérico
hacen que su implementación sea difícil y su utilización también.
También se encontró que la cultura y las características organizacionales influyen
significativamente en la forma de realizar las actividades en cada empresa y por
lo tanto esta debe ser considerada dentro de las metodologías o modelos que se
usen para gerenciar los proyectos de TI. Como las características
organizacionales encontradas en estas empresas, mostraron poca formalización
en las comunicaciones, falta de tiempo para realizar de manera rigurosa las
actividades de gerencia de proyectos y poca disciplina para ejecutar los procesos
y procedimientos asociados a las metodologías, se considero conveniente tener
un enfoque práctico y flexible para el desarrollo del modelo de gestión de
proyectos de tecnología informática .
El modelo de gestión de proyectos de TI (MGPTI) propuesto esta conformado por
un conjunto de procesos que parten de las principales áreas claves dentro del
marco de referencia de gerencia de proyectos (PMBOK67 Guide) y Microsoft
Solutions FrameWork (MSF) con el fin de generar estándares, guías
metodológicas y mejores practicas que como mínimo, proporcione a los líderes de
proyectos de TI, las directrices que debe seguir durante el ciclo de vida “típico” de
un proyecto de TI. Con este modelo el líder de proyecto, su equipo y todos los
grupos de interés del proyecto tendrían un método estándar con el que iniciar,
planificar, ejecutar, controlar y cerrar el proyecto. Además, el modelo identifica los
roles y las responsabilidades, los estándares y los procedimientos, las plantillas y
las herramientas, las propuestas importantes y los “puntos de comprobación”
67 PMI, Inc, A Guide to the Project Managemente Body Of Knowledge, 2000 Edition
251
(Hitos) de la revisión del proyecto que necesitaría el equipo directivo durante todo
el ciclo de vida del proyecto.
EL modelo pretende mejorar los procesos para la gestión de proyectos y
suministrar a las personas que los ejecutan un marco de referencia y unas
herramientas focalizadas para la gestión de los proyectos de TI, de una manera
práctica que se adapte de la mejor manera a la cultura organizacional de las
empresas estudiadas. Evitando con esto que se adopte por parte de los líderes de
proyectos un método para gestionar los proyectos de TI “instintivo” o “intuitivo”
como el utilizado hasta hoy según la evidencia encontrada y como resultado de
esto, se corra un serio riesgo de no controlar o mitigar las principales causas que
impiden el éxito de los proyectos y por el contrario lo lleven a ser un fracaso mas
dentro de las estadísticas.
El modelo tiene como pilar del mejoramiento, la elaboración de una base de datos
en la que queden recogidos los hechos más relevantes ocurridos en cada uno de
los proyectos y las lecciones aprendidas que se extraen de los mismos. Se trata
de hacer que todas las personas susceptibles de gestionar proyectos,
independientemente de su experiencia y bagaje profesional, utilicen la base de
datos a modo de consulta previa antes de acometer proyectos de características
similares y que, así mismo, la realimenten con de los nuevos proyectos que se
desarrollen.
9.2 RESPECTO AL CONOCIMIENTO
Existe dentro de la literatura técnica, una amplísima información sobre las
diferentes características de la gestión de proyectos: el riesgo, la comunicación,
el control del coste, la planificación, etc. En ese aspecto se esta en disposición de
asegurar que existe práctica y conceptualización teórica más que suficientes. Por
252
lo tanto, se puede concluir que el conocimiento sobre los diferentes aspectos es
muy amplio, y se puede asegurar su mejoramiento y mantenimiento de cara al
futuro, tanto local como en el contexto mundial.
9.3 RESPECTO A LA GERENCIA DE PROYECTOS DE TI
• Se puede decir que factores claves como las relaciones humanas, la visión de
futuro, el estilo gerencial administrativo (trabajo en equipo), la capacidad para
realizar cambios de fondo dentro de las organizaciones, y algunos otros
aspectos como la integridad personal, la capacidad innovadora y el trabajo por
objetivos son determinantes para el buen desarrollo de los proyectos de
Tecnología Informática (TI).
• Podemos deducir que en las empresas donde no halla un perfil de “gerentes”
(líderes) de proyectos adecuado, es muy probable que cualquier desarrollo de
proyecto no sea llevado tan eficaz ni eficientemente como se esperaba.
• Se encuentra que por su carácter genérico, las metodologías de gestión de
proyectos y particularmente la del PMBOK, son de difícil implementación y su
utilización también, debido a que la cultura y las características
organizacionales influyen significativamente en la forma de realizar las
actividades en cada empresa por lo tanto estas deben ser complementadas y
adecuadas para facilitar que quien las implemente contemple las
características organizacionales y de esta forma las pueda adaptar de una
manera adecuada para la empresa. Estas metodologías dicen el que hacer
pero se quedan muy cortas en el como, por lo tanto el como debe ser
desarrollo por la empresa o personas que la van a utilizar.
253
• Los proyectos de Tecnología Informática son de alta complejidad e impactan
en forma directa los procesos vigentes en la empresa y por tanto la manera
como los grupos humanos hacen las tareas dentro de la empresa. • La cultura organizacional de las empresas tiene una influencia directa en el
desarrollo y los resultados del proyecto de Tecnología Informática. • El equipo de proyecto y su líder formal, el gerente de proyecto, juegan un papel
decisivo en el desarrollo de cada una de las fases del proyecto.
• La formación académica, la experiencia de los miembros del equipo de
proyecto y sus interrelaciones influyen notablemente en el éxito relativo del
proyecto
• El principal propósito de la guía PMBOK es identificar y describir el cuerpo del
conocimiento dentro de la profesión de Gestión de Proyectos el cual es
generalmente aceptado. Esto significa que el conocimiento y las prácticas son
aplicables a muchos proyectos la mayoría de las veces y que existe un amplio
consenso acerca de su valor y su utilidad. “Generalmente aceptado” no
significa que el conocimiento y las prácticas son o deberían ser aplicadas
uniformemente en todos los proyectos; el equipo de gestión de proyectos
siempre es el responsable en determinar lo qué es apropiado para un proyecto
dado.
• La disciplina de administración de riesgos es muy importante para el éxito de
los proyectos de TI, ya que una de las principales característica de este tipo de
proyectos es el alto nivel de riesgo en su ejecución. Para esto se encontró que
disciplina de administración de riesgos MSF es práctica, adaptada y
estructurada para el desarrollo de proyectos de TI, además recomienda el uso
254
de una administración de riesgos proactiva y no reactiva, Esta disciplina consta
de seis pasos lógicos (identificación, análisis, planeamiento, seguimiento,
control y aprendizaje) a los que un equipo de proyecto debe recurrir
continuamente durante el ciclo de vida de un proyecto.
9.4 RESPECTO AL MODELO DE GESTIÓN PARA LOS PROYECTOS DE TECNOLOGÍA INFORMÁTICA (TI)
• El modelo que se desarrollo, en ningún momento se apartó de una de las
premisas planteadas, y es la de tener muy presente las características
organizacionales de las empresa(s) estudiada(s). Esta premisa se expone
basándose en que las características organizacionales son un aspecto muy
importante para lograr mayor éxito en los proyectos y en la implementación una
de la metodología de gestión de proyectos de TI.
• El modelo presentado es una primera aproximación la cual no pudo ser
validada con una implementación practica en la realidad debido a las
limitaciones de tiempo y alcance planteada este trabajo de investigación
• El modelo tiene como pilar del mejoramiento la elaboración de una base de
datos en la que quedan recogidas las incidencias más relevantes acaecidas en
cada uno de los proyectos y las lecciones aprendidas que se extraen de las
mismas. Se trata de hacer que todas las personas susceptibles de gestionar
proyectos, independientemente de su experiencia y bagaje profesional, utilicen
la base de datos a modo de consulta previa antes de acometer proyectos de
características similares y que, así mismo, la realimenten durante el transcurso
de los proyectos en los que están inmersos. Se pretende con todo ello
adelantarse a los problemas o al menos saber que hacer o que no hacer en
255
caso de que aparezcan. Su uso también es apropiado para la estimación de las
contingencias por imprevistos a la hora de presupuestar un proyecto. La
metodología que se plantea aplicar para el aprovechamiento de la citada base
de datos de experiencias es muy simple en cuanto a su concepto y complicada
en su aplicación práctica ya que requiere de una gran disciplina, coordinación y
formalización en la empresa.
• En modelo incorpora de la metodología de MSF :
o Modelos avanzados de Administración de Riesgos.
o Procesos optimizados para la ejecución de etapas para el desarrollo e
implementación de soluciones tecnológicas.
o Un modelo de trabajo en equipo que supera las barreras que se
encuentran en los equipos de trabajo.
Todos estos son aspectos claves para superar las causas de fracaso de los
proyectos de TI, según los hallazgos encontradas en la investigación realizada
durante el presente trabajo de grado.
256
BIBLIOGRAFIA
ANDREU, Rafael, RICART Joan E., VALOR Josep. Estrategia y Sistemas de Información, Segunda Edición. Ed. McGRAW-HILL. Bogotá. 1996.
AMERICAN MANAGEMENT ASSOCIATION INTERNATIONAL, Information Systems Project Management, 1999
CORTADA, James W., Best Practices in Information Technology. Ed. Prentice-Hall, Inc. New Jersey. 1998. 250 Pags.
DANIEL PIORUN, Liderando Proyectos, Ed. Macchi. 2002.
GIDO, Jack. CLEMENTS, James P., Administración exitosa de proyectos. Ed.
International Thomson Editores, 1999. 405 Pags.
HARVARD BUSINESS REVIEW, On the Business Value of IT. Ed. HBS. 1999.
LAUDON, Kenneth C, LAUDON, Jane P, Administración de los Sistemas de Información Organización y Tecnología. Tercera Edición, Ed. Prentice-Hall. 1996. KERZNER, Harold, Project Management. A Systems Approach to Planning, Scheduling, and Controlling, SIXTH EDITION. JONN WILEY & SONS INC. New York .1998. LÓPEZ, Alberto J, PMP,Miembro fundador del Capítulo Argentino del PMI, Una Metodología básica para la dirección de proyectos. PMI capitulo Buenos Aires. (Documento base de esta descripción)
LYNDA M. APPLEGATE, ROBERT D. AUSTIN, F. WARREN MCFARLAN. Creating Business Advantage in the Information Age, Modulo 4 “Managing Information Age Projects and Programs”. Ed. McGRAW-HILL. 2002.
NASSIR SAPAG CHAIN, Criterios de Evaluación de Proyectos. Ed. McGRAW-HILL. Bogotá. Edición 2000.
257
MIRANDA MIRANDA, Juan José Gestión de Proyectos. Identificación, Formulación, Evaluación Financiera, Económica, Social, Ambiental. MB Editores. Bogotá. 1997. 366 Pags.
MICROSOFT, Microsoft Solutions Framework Versión 3.0, Junio 2003
MONTES GONZALO, Metodología PMI® complementada para gestionar proyectos de desarrollo de software y de implantación de aplicaciones de alto impacto en las organizaciones. ACIS. Bogota. Noviembre de 2002.
MURCH, Richard, Project Management Best Practices for IT Professionals. Ed.
Prentice Hall PTR. 2001. 240 Pags.
PROJECT MANAGEMENT INSTITUTE, Una Guía a los Fundamentos de la Dirección de proyectos (PMBOK Guide). Edición 2000. Ed. PMI. Traducción Argentina al español. 219 Pags.
PMI, Inc, A Guide to the Project Managemente Body Of Knowledge, 2000 Edition
SENN, James A. Análisis y Diseño de Sistemas de Información. Segunda Edición, Ed. McGRAW-HILL. Bogotá.1992.
SISTEMAS EXPERTOS, Gerencia de Proyectos Apoyada en Tecnologías Informáticas, Material de Clase. Ed. SE. Medellín.400 Pags.
SCHWALBE, Kathy. Information Technology Project Management. Segunda
Edición. Ed.. Course Technology. Canada 2002. 547 Pags.
W. BEHERENS Y P.M. HAWRANEK, Manual para la preparación de estudios de viabilidad industrial, Edición corregida y aumentada, ONUDI, 1994.
http://www.pmi.org
258
http://www.pmi.org/publictn/download/pmboktoc1.htm
http://standishgroup.com/visitor/chaos.htm
http://www.aeipro.org
http://www.ipma.ch/
http://www.pmforum.org/warindex.htm
http://www.4pm.com/
http://www.microsoft.com/office/project/default.htm
http://dfca.larc.nasa.gov
http://www.cioinsight.com/sections/executivebriefs
http://eweek.bitpipe.co
http://www.degerencia.com/
OTRAS FUENTES DE CONSULTA MSF (Microsoft solutions framework) Process Model v. 3.0, 2002 (disponible en http://www.microsoft.com/msf/) (en inglés).
259
Audrey J. Dorofee, Julie A. Walker, Christopher J Alberts et al, Continuous Risk Management Guidebook (Universidad Carnegie-Mellon, 1996). Ronald P. Higuera, “Team Risk Management: A New Model for Customer-Supplier Relationships”, SEI Technical Report CMU/ SEI-94-SR-5, (Pittsburgh, PA: Software Engineering Institute—Universidad Carnegie Mellon), 1994. Encarta 2002, Article “Insurance. II. Reasons for Insurance”. Jim McCarthy, Dynamics of Software Development (Redmond, Washington: Microsoft Press, 1995), página 99. MSF Team Model 3.0 Whitepaper (http://www.microsoft.com/msf/) (en inglés). MSF 3.0 Process Model Whitepaper disponible en http://www.microsoft.com/msf/ (en inglés) para obtener más información. Ronald P. Higuera y Yacov Y. Haimes, “Software Risk Management”, SEI Technical Repor CMU/SEI-96-TR-012 ESC-96-012 (Pittsburgh, PA: Software Engineering Institute—Universidad Carnegie Mellon, 1996). Steve McConnell, Software Project Survival Guide, (Redmond, WA: Microsoft Press), 1998. Barry W. Boehm, Software Risk Management, (Nueva York, NY: IEEE Press), 1989. Capers Jones, Assessment and Control of Software Risks. (Englewood, NJ: Prentice-Hall, 1994). ISBN 0-13-741406-4. Ronald P. Higuera y Yacov Y. Haimes, “Software Risk Management”, SEI Technical Report,1996. Steve McConnell, Rapid Development, (Redmond, Microsoft Press), 1996, pp 87-91. Thomas R. Peltier, Information Security Risk Analysis, (Boca Ratón: Auerbach Publications, 2001). Donald L Pipkin, Information Security: Protecting the Global Enterprise, (Newark, NJ: Prentice Hall, 2000). http://seir.sei.cmu.edu/
260
Audrey J Dorofee, Julie A Walker, Christopher J Alberts, et al., Continuous Risk Management Guidebook. (Pittsburgh, PA: Universidad Carnegie Mellon, 1996). Linda H Rosenberg , Theodore Hammer , Albert Gallo, Continuous Risk Management at NASA, 1999 (http://satc.gsfc.nasa.gov/support/ASM_FEB99/crm_at_nasa.html) MSF Risk Management Process Documento, 2001. Principles of Application Development- Curso 593 y Curso 1517. Rosenberg LH, et al., 1999. Elaine Hall, Managing Risk. Methods for Software Systems Development, SEI Series in Software Engineering, (Reading, MA: Addison-Wesley, 1998), Capítulo. 4, “Identify Risk”. Dorfee AJ, et al, 1996. Elaine Hall, Managing Risk, p. 101. Project Management Institute, A Guide to the Project Management Body of Knowledge 2000 Edition, (Newtown Square, PA: Project Management Institute, Inc. 2000), Capítulo 11. Elaine Hall, Managing Risk. MSF 3.0 Project Management Discipline, disponible en: http://www.microsoft.com/msf/ Documento Publicado Originalmente en http://www.microsoft.com/latam/technet/articulos/200304/art02/ Descargado de http://www.WillyDev.NET
261
Anexo A.
Resumen de Microsoft solutions framework (MSF) 68
Para maximizar el éxito de los proyectos relacionados con la tecnología de la información (TI), Microsoft ha puesto a disposición guías en forma de paquetes que ayudan a diseñar, desarrollar, implementar, operar y mantener de una manera efectiva soluciones creadas a partir de la tecnología de Microsoft. Estos conocimientos se han reunido a partir de la experiencia obtenida en el desarrollo de software a gran escala de Microsoft, la experiencia de los consultores de Microsoft en la dirección de proyectos para clientes corporativos y los mejores conocimientos del sector de TI de todo el mundo. La guía se divide en dos secciones de conocimientos, o plataformas, complementarias y perfectamente integradas. Estas dos secciones son Microsoft Solutions Framework (MSF) y Microsoft Operations Framework (MOF).
La creación de una solución empresarial que se ajuste a unos plazos y a un presupuesto requiere contar con un enfoque contrastado. MSF proporciona soluciones para planear, diseñar, desarrollar e implementar soluciones de TI con éxito. En contraposición a una metodología prescriptiva, MSF ofrece una plataforma flexible y escalable que se ajusta a las necesidades de cualquier organización o equipo de proyecto con independencia de su tamaño. La guía de MSF está formada por principios, modelos y disciplinas que sirven para administrar personas, procesos y elementos tecnológicos así como aspectos que tienen que abordarse en la mayoría de los proyectos.
Para obtener más información sobre MSF, vea: http://www.microsoft.com/msf/ (en inglés)
MOF ofrece directrices técnicas que permiten a las organizaciones lograr la confiabilidad, la disponibilidad y compatibilidad de los sistemas más importantes, así como la manejabilidad de las soluciones de TI desarrolladas a partir de productos y tecnologías de Microsoft. La guía de MOF aborda temas relacionados
68 Fuente: http://www.microsoft.com/spain/technet/recursos/articulos/welcome3.asp?opcion=0703031
262
con las personas, los procesos, la tecnología y la administración que pertenecen a entornos operativos complejos, distribuidos y de TI heterogéneos. MOF se basa en las prácticas recomendadas de la industria tal y como se documenta en la IT Infrastructure Library (ITIL) de la Office of Government Commerce (OGC) del gobierno del Reino Unido.
Para obtener más información sobre MOF, vea: http://www.microsoft.com/mof/
INTRODUCCIÓN
Una de las características más importantes de MSF es la ausencia de una función o nombre de un puesto denominado gerente de proyectos. Esto puede parecer sorprendente en una plataforma que aborda temas relacionados sobre cómo llevar a cabo con éxito proyectos de TI. Sin embargo, MSF da mucha importancia a la disciplina y las competencias asociadas a la administración de proyectos.
Este documento resume los aspectos clave de la disciplina de la administración de proyectos y muestra cómo MSF se enfrenta a estos aspectos. También muestra cómo los principios sobre los que se inscribe MSF conducen a algunos conceptos y algunas prácticas distintivas en la implementación de la administración de proyectos.
También describe cómo la función de administración de programas MSF ofrece técnicas de administración de proyectos especializadas que ayudan a apoyar a todo el equipo y el modo en que se distribuyen las actividades relacionadas con la administración de proyectos entre los distintos jefes de equipo MSF.
Este documento no tiene como objetivo ser una guía de cómo llevar a cabo la administración de proyectos, ni trata de explicar las técnicas utilizadas por los administradores de proyectos con experiencia. Por el contrario, muestra cómo los principios de MSF conducen a un enfoque de administración de proyectos en donde:
• La responsabilidad de la administración de los proyectos se reparte entre los distintos jefes de equipo.
263
• Los especialistas en la administración de proyectos ofrecen un enfoque que se basa en dar facilidades y ayuda, en lugar de en imponer el control sobre el resto del equipo.
Es importe y de gran ayuda para un mejor entendimiento leer el documento MSF Team Model (Modelo de equipo MSF)69 antes de leer el presente documento.
Principios de MSF subyacentes
Responsabilidad clara-Responsabilidad compartida
El Modelo de equipo MSF se basa en la premisa de que cada función presenta una perspectiva única en el proyecto y que ninguna persona por sí misma puede representar de una manera satisfactoria todos los objetivos de calidad de todas las funciones. Sin embargo, el cliente necesita una sola fuente de información que cuente con autoridad sobre el estado del proyecto, las acciones y los problemas actuales. Para resolver este dilema, el equipo de compañeros debe combinar una línea clara de responsabilidad hacia el cliente con la responsabilidad compartida con el fin de lograr el éxito en general.
Dentro del equipo, cada función es responsable de todas las actividades que son necesarias para lograr su propio objetivo de calidad.
Cada miembro del equipo es responsable del éxito general del proyecto y de la calidad de la solución y se espera que contribuya con ideas y observaciones que se deriven de su conocimiento incluso en áreas en las que no es responsable de una manera personal.
En concreto, las funciones del equipo MSF comparten responsabilidad en muchos aspectos de la administración del proyecto, por ejemplo, la administración del riesgo, la administración del tiempo, la administración de la calidad, el planeamiento, la programación, la selección de los miembros del equipo y la administración de los recursos humanos.
69 vea: http://www.microsoft.com/msf/ (en inglés)
264
Los equipos reforzados resultan más efectivos
En un equipo efectivo, se anima a sus miembros a ofrecer sus propios compromisos y se confía en que, en aquellas áreas en las que ellos dependen de los compromisos de otras personas, se cumplirán dichos compromisos. Igualmente, el cliente tiene el derecho a asumir que el equipo cumplirá su cometido y hará planes sobre esta base. Cualquier retraso o cambio debe comunicarse lo más pronto posible.
Un equipo MSF debe ofrecer a sus miembros la autorización que éstos necesitan para cumplir su cometido. Esto tiene un profundo impacto en la función de la administración del proyecto en su capacidad de supervisar el progreso. Sin autorización y compromiso, los administradores de equipos deben comprobar continuamente y doblemente si los miembros del equipo siguen en la buena dirección. Una vez estén seguros de que informarán de cualquier retraso tan pronto como se conozca, los jefes de equipo pueden tener una función de mayor ayuda que facilite a los miembros del equipo a obtener los objetivos planteados, ofreciéndoles al mismo tiempo ayuda y asistencia. La supervisión del progreso se distribuye entre los distintos miembros del grupo y se convierte en una función de ayuda en vez de en una función de control.
Conceptos clave
Para entender el enfoque MSF en la administración de proyectos, es importante comprender la manera en que MSF define los siguientes conceptos y términos.
Disciplinas en MSF
MSF reconoce distintas áreas de conocimiento no tecnológico que son competencias importantes de todas las funciones del modelo de equipo MSF. Estas competencias se denominan disciplinas. Para obtener más información, vea el documento MSF Team Model (Modelo de equipo MSF).
Actualmente, MSF ha abordado tres disciplinas. Estas tres disciplinas son: administración del riesgo, administración de la disponibilidad y administración de proyectos.
MSF reconoce que estas disciplinas han desarrollado las prácticas recomendadas que están bien asentadas en muchas industrias, no sólo en las de la tecnología de la información (TI). A menudo, estas soluciones pueden aplicarse a operaciones
265
de TI y a otros procesos empresariales así como a proyectos de TI. En lugar de volver a inventar estas prácticas, MSF resume lo que los jefes de equipo deben conocer de estas disciplinas y agrega la perspectiva interna obtenida por los equipos de Microsoft a lo largo de estos últimos años.
Para llevar a cabo el trabajo de una manera efectiva, los jefes de todas las funciones del equipo MSF deben tener un nivel de competencia adecuado en cada disciplina.
¿En qué consiste la administración de proyectos?
Antes de describir la administración de proyectos de TI, es de una gran ayuda entender la definición de administración de proyectos, con independencia del tipo de proyecto del que se trate.
Un proyecto es una empresa temporal que cuenta con un principio y un final definidos cuyo objetivo es crear un producto o servicio único. La administración de proyectos es un área de conocimiento con técnicas y herramientas que se utilizan para lograr los objetivos del proyecto dentro de unos parámetros de calidad, costos, plazos y límites previamente acordados. (i)
En algunas empresas y en algunos países, el término programa se utiliza para describir grupos de proyectos que se coordinan conjuntamente. Para evitar confusiones con el grupo de funciones de equipo MSF denominado administración de programas, haremos referencia a un grupo de proyectos como portafolio de proyectos.
MSF categoriza las siguientes áreas de responsabilidades, técnicas y actividades en la administración de proyectos (ii).
Área de administración de proyectos Descripción Planeamiento/seguimiento/control de cambios del proyecto
Integración y sincronización de los planes sobre el proyecto; establecimiento de los procedimientos y los sistemas usados para administrar y realizar un seguimiento de los cambios.
Administración del alcance Definición, división del alcance de trabajo (alcance del proyecto); administración de los aspectos del proyecto.
Administración de la programación Generación de programas a partir de las
266
estimaciones del equipo, secuenciación de tareas, adecuación de los recursos a las tareas, aplicación de técnicas de estadística, mantenimiento del programa.
Administración de costos Preparación de estimaciones de costos en base a las estimaciones temporales del equipo; creación de informes sobre el progreso y análisis; análisis de los factores de riesgo de los costos, análisis de los valores.
Administración de los recursos humanos Planeamiento de recursos, creación de equipos, resolución de conflictos, planeamiento de la disponibilidad (para el proyecto).
Administración de las comunicaciones Planeamiento de las comunicaciones (equipo, cliente/patrocinador, usuarios, participantes), creación de informes sobre el estado del proyecto.
Administración del riesgo Facilitación y dirección del proceso de administración de los riesgos del equipo; mantenimiento de la documentación sobre los riesgos.
Adquisición Solicitación de ofertas de proveedores por servicios o hardware/software; preparación de solicitudes para propuestas, administración de proveedores o proveedores secundarios; administración y negociación de contratos, acuerdos; apertura de pedidos de compra y aprobación de facturas.
Administración de la calidad Planeamiento de la calidad, determinación de los estándares a usarse, documentación de los criterios de calidad y de los procesos de medición de la misma.
Si bien en este documento no se ofrece una guía completa sobre cada una de las áreas mencionadas anteriormente, sí se proporcionan determinadas prácticas recomendadas para MSF.
267
La administración de proyectos no sólo la realizan los administradores de proyectos
En el lenguaje de hoy en día, el término administración de proyectos puede utilizarse para describir tanto una función como un área de técnicas y conocimientos. Por ejemplo, piense en las siguientes frases "Los encargados de la administración del proyecto dijeron que lo tendrían acabado en esta fecha" y "Las agencias espaciales tienden a contar con excelentes funciones de administración de proyectos".
Esta distinción es importante porque la administración de proyectos, como actividad, la realizan varias personas que no son administradores de proyectos.
Tal y como se utiliza en MSF, administración de proyectos siempre se utiliza para hacer referencia a un grupo específico de áreas de conocimientos y técnicas que se han citado anteriormente, no a una función o al nombre de un puesto. El término administrador de proyectos se utiliza para describir a alguien que está especializado en la administración de proyectos.
Administración de proyectos y procesos específicos de la TI
En general, la administración de proyectos está formada por áreas de conocimiento y técnicas que se aplican ampliamente a cualquier sector de la industria que realice proyectos. Cada sector de la industria (por ejemplo, el sector aeroespacial, la construcción, la TI, etc.) tiene sus propios procesos, fases, funciones y prácticas que funcionan mejor en ese sector en específico. Para lograr el éxito de los proyectos, estos procesos específicos de cada industria deben complementarse con prácticas generales aplicadas a la administración de proyectos.
MSF ofrece procesos y prácticas recomendadas para los proyectos de la TI. Su relación con la disciplina de la administración de proyectos se muestra en la Figura1.
268
Figura 1 Relación de MSF con la disciplina de la administración de proyectos
El dominio concreto de la industria en este caso son las cinco fases del modelo del proceso MSF. Un ejemplo de una actividad relacionada con la administración de proyectos específica de un sector de la industria son las prácticas recomendadas para realizar un seguimiento de los errores. Las áreas de conocimiento genéricas de la administración de proyectos se sitúan a la izquierda. Un ejemplo son las prácticas recomendadas para administrar contratos o realizar un seguimiento de los presupuestos. La intersección representa ciertas prácticas de la administración de proyectos que son típicas de MSF. A continuación se presentan estas prácticas.
Características de la administración de proyectos MSF
A continuación se presentan y se explican más en detalle tres características distintivas del enfoque MSF:
• La mayoría de las responsabilidades de la función del administrador de proyectos se incluyen en el grupo de funciones de la administración de programas MSF.
• En proyectos grandes en los que se requieren equipos MSF más grandes, las actividades relacionadas con la administración del proyecto tienen lugar en varios niveles.
• Algunos proyectos grandes o complejos necesitan un administrador de proyectos dedicado o un equipo de administración de proyectos especializado.
269
La función del administrador de proyectos está incluida en la administración de programas
El grupo de funciones de la administración de programas MSF incluye las áreas de responsabilidad funcional que se muestran a continuación. En proyectos más pequeños, normalmente un solo administrador de programas se encarga de todas las responsabilidades funcionales. A medida que aumenta el tamaño y la complejidad de un proyecto, este grupo de funciones se divide en dos áreas de especialización: una de ellas se encarga de la arquitectura y las especificaciones y la otra de la administración de proyectos.
Cómo la administración de programas se integra con los jefes de proyecto
Para entender cómo funciona la administración de proyectos en MSF, es necesario entender cómo el modelo de equipo se hace más grande, dirige el planeamiento, se comunica y toma decisiones. Para obtener más información, vea el documento MSF Team Model (Modelo de equipo MSF).
Para ser más precisos, el modo en que se distribuye la administración del proyecto depende en gran parte de la escala y la complejidad de éste.
MSF es una plataforma altamente escalable que puede utilizarse en proyectos pequeños en los que participen de dos a tres personas, o en proyectos muy grandes. Los equipos de creación de productos internos de Microsoft están formados por cientos e incluso miles de miembros. MSF ha generalizado las lecciones sobre la organización de los equipos en Microsoft para que puedan utilizarse en una gran variedad de proyectos de TI.
Gran parte de la escalabilidad de MSF se debe al modelo de equipo. Este modelo de equipo puede escalarse de dos maneras principales:
1. Abstrayendo las funciones del equipo como un grupo de responsabilidades funcionales, en lugar de como descripciones de trabajos específicos. De esta manera, las responsabilidades de cada función no están sujetas a los límites de una sola persona. Una función puede ampliarse a grupos de funciones y cada uno de ellos se especializa en un grupo más específico de responsabilidades. Una o más personas pueden llevar a cabo estas funciones más especializadas.
2. Usando equipos de producto y calidad y equipos funcionales en diversas combinaciones para crear cualquier número de posibles estructuras de grandes equipos. A continuación se describen los equipos de producto y calidad y los equipos funcionales.
270
Equipos funcionales
Los equipos funcionales son equipos secundarios que existen dentro de una función y que se forman cuando las tareas de una función son suficientemente grandes y requieren recursos exclusivos. Un aspecto clave de un equipo funcional no es simplemente que la función requiere más de una persona para llevarse a cabo, sino que existe una delimitación de las tareas entre sus miembros. La Figura 2 muestra un ejemplo de este concepto.
El jefe de equipo es el punto de integración con el resto del equipo. Los jefes de equipo tienen algunas responsabilidades en la administración del proyecto al nivel de su equipo secundario.
Figura 2 Equipo funcional de ejemplo para la experiencia del usuario
Equipos de producto y calidad
Los equipos de producto y calidad son equipos secundarios multidisciplinarios que se organizan en torno a una característica concreta de la solución. Estos equipos se crean a partir de seis funciones que componen el modelo de equipo. La Figura 3 muestra un equipo de producto y calidad. La función de administración de programas también es el jefe de equipo que proporciona el punto de integración con el equipo más grande. La estructura del equipo de producto y calidad es una buena candidata para crear componentes bastantes pequeños de equipos secundarios remotos o "distantes" para la solución.
271
Figura 3 Ejemplo de equipos de producto y calidad
Escalado de las funciones de administración de proyectos
La Figura 4 muestra cómo se gestionan las actividades relacionadas con la administración de proyectos en tres niveles de la escala del proyecto. En el proyecto A donde todas las funciones las llevan a cabo aproximadamente seis personas o menos, todas las actividades relacionadas con la administración de proyectos las gestiona la administración de programas. Esto no significa que las otras funciones no tengan ninguna influencia en la administración del proyecto. De hecho, lo que significa es que son responsables de planear, estimar e identificar los riesgos de sus áreas respectivas.
272
Figura 4 Un enfoque escalable para la administración de proyectos
273
En el proyecto B, la mayoría o todas las funciones las llevan a cabo los equipos secundarios, cada uno de ellos dirigido por un jefe de equipo. Los jefes de equipo se encargan de la administración del proyecto de sus respectivos equipos secundarios. El grupo de funciones de administración de proyectos posee actividades relacionadas con la administración del proyecto en general. Recuerde que los equipos de producto y calidad no se muestran en el gráfico, pero también son equipos secundarios. Puesto que cada equipo de producto y calidad es multidisciplinar, cada uno de ellos cuenta con un jefe de administración de programas.
El proyecto C es similar al proyecto B, si bien tiene unos riesgos especiales debido a su tamaño o complejidad. Un proyecto completo, tal y como se usa en MSF, significa que el proyecto tiene muchos riesgos relacionados con los siguientes factores:
• Tamaño o costo grandes. • Equipos dispersos geográficamente. • Los miembros de los equipos pertenecen a varias empresas,
organizaciones o proveedores secundarios. • Planeamientos o presupuestos fijos o muy limitados. • Temas contractuales o legales que requerirán técnicas y tiempo para
enfrentarse a ellos.
Para mitigar estos riesgos, el grupo de funciones de administración de programas dispone de un equipo funcional que incluye administradores de proyectos y diseñadores de soluciones especializados. Recuerde que el umbral del riesgo no será el mismo para todas las organizaciones y para todos los proyectos. Lo que resulta muy costoso para una organización, puede que no sea tan costoso para otra. Depende totalmente de la evaluación del riesgo que se realice al principio del proyecto.
Responsabilidades de la administración de proyectos
La sección anterior abordaba cómo se distribuyen las actividades relacionadas con la administración de proyectos entre los miembros del equipo en distintos niveles de escala y complejidad. Esta sección describe estas actividades.
La Figura 5 describe las responsabilidades de la administración de proyectos que pertenecen a los jefes de equipo de cada función y administración del programa. Los administradores de proyectos especializados que trabajan en un proyecto complejo (por ejemplo, el proyecto C que se muestra en la Figura 4) se centran en las mismas áreas tal y como se muestra de la administración de programas, sólo
274
de manera exclusiva. Recuerde que a menudo la misma área de responsabilidades queda cubierta en el nivel del proyecto y en el nivel del equipo secundario.
Figura 5 Responsabilidades de la administración de proyectos para los jefes de equipo
Jefes de equipo
Los jefes de equipo preparan los planes para sus equipos secundarios y en ellos describen cómo realizar el trabajo, realizar un seguimiento del trabajo real y confrontarlo con los planes, administrar los ámbitos y los cambios, asignar recursos a tareas específicas del equipo secundario y coordinar las comunicaciones internas de los equipos secundarios. Los jefes de equipo llevan a cabo estas actividades con la participación y las sugerencias de cada uno de los miembros de los equipos secundarios. Al mismo tiempo que participan en la
275
identificación del riesgo en general, los jefes de equipo son específicamente responsables de la identificación de los riesgos en el área de conocimiento de sus funciones.
La Figura 5 muestra tres lugares en los que las responsabilidades de los jefes de equipo difieren del patrón de los otros:
1. La administración de costos de un proyecto normalmente se centraliza como una responsabilidad de la administración de programas. Repartir esta función entre los jefes sería confuso y probablemente crearía caos.
2. Las responsabilidades de adquisición recaen sobre la administración de programas y/o versiones, pero no sobre los otros jefes de equipo. La administración de programas se encarga de la contratación de la mayoría de los servicios relacionados con el proyecto y de diversos tipos de compras. Un ejemplo sería la subcontratación de una empresa de diseño de páginas Web para que formara parte del equipo. La administración de versiones, como representante de las operaciones de TI del equipo, se encarga de la adquisición de hardware, software y activos materiales para la solución que está siendo creada así como del desarrollo del equipo y del entorno del laboratorio de pruebas.
3. La administración de las comunicaciones a nivel general del proyecto se reparte entre la administración de programas y la administración de productos. La administración de productos se encarga de crear y enviar el plan de comunicaciones al usuario (cliente), los participantes y a cualquier audiencia externa. La administración de programas planea y es responsable de las comunicaciones en el proyecto, por ejemplo, la creación de informes sobre el estado del proyecto, la celebración de reuniones con el equipo y similares. La administración de las comunicaciones también incluye planear las comunicaciones, asignar los puntos de contacto designados e informar del progreso realizado a personas ajenas al equipo.
Administración de programas
Además de ser responsable de la arquitectura de la solución a un alto nivel y de escribir especificaciones funcionales (tal y como se describe en el modelo de equipo), a la administración de programas le pertenecen todas las áreas de la administración de proyectos del proyecto en general.
La administración de programas integra los planes del equipo secundario en el plan maestro, sincroniza los programas y administra las dependencias que existen en el equipo.
276
La gran ventaja de asignar la responsabilidad tanto del diseño de la solución como de las especificaciones funcionales en la misma función que la responsabilidad de programación y costos es la siguiente: fija un equilibrio entre la tendencia a recrearse en exceso en el diseño y las implicaciones en cuanto a costos y programación que ello supone.
Administración de proyectos grandes y complejos
A medida que un proyecto se hace más grande o complejo, puede que resulte una tarea abrumadora administrar especificaciones funcionales, actualizar programaciones, enviar comunicaciones al equipo, informar del progreso del proyecto y llevar a cabo otras actividades relacionadas con la administración del mismo. Para enfrentarse a esto, a menudo es recomendable dividir las responsabilidades del grupo de funciones de administración de proyectos en una arquitectura de la solución y una función de administración de proyectos exclusiva.
Servicios administrativos del proyecto
En algunos aspectos, en un gran proyecto se realizan las mismas tareas que en un pequeño negocio: realizar un seguimiento de las finanzas, adquirir suministros y servicios, administrar el rendimiento del personal, proporcionar orientación y formación, acondicionar las instalaciones de trabajo del equipo y el alojamiento del mismo, etc. Sin embargo, en proyectos muy grandes, realizar el seguimiento del estado, los costos y los plazos del proyecto de una manera rutinaria lleva mucho tiempo. Para permitir al administrador de proyectos centrarse en los asuntos más apremiantes, la mayoría de las actividades de la administración del proyecto se delegan en un puesto (o asistente para el proyecto) administrativo del proyecto. Los servicios administrativos del proyecto también proporcionan soporte a jefes de equipo y ayudan a mantener los programas del equipo y otras actividades relacionadas con la administración de proyectos.
Responsabilidad del cliente
Los clientes a menudo desean un único punto de responsabilidad que ayude a lograr el éxito del proyecto en general. Algunas organizaciones recurren a un administrador de proyectos para desempeñar esta función. Esto a veces está justificado en el caso de proyectos grandes y complejos, pero este enfoque puede suponer una falta de equilibrio en cuanto a la responsabilidad de las distintas funciones del equipo, lo que ocasionará un mal funcionamiento del proyecto. MSF se acomoda a la necesidad del cliente de contar con un solo punto de autoridad para asegurar su satisfacción y al mismo tiempo conservar la responsabilidad compartida entre los miembros del equipo.
277
En el equipo MSF, cada función del equipo es internamente responsable de sus propias actividades. Además, las personas que trabajan en cada función normalmente son responsables ante alguna estructura de administración ajena al equipo del proyecto. Debido a que MSF no asume que todos los miembros del equipo trabajan en la misma empresa u organización, estas rutas de responsabilidad conducen a cualquier organización, grupo o departamento al que pertenecen esas personas.
Los puntos clave aquí son los siguientes:
• No hay nada definitivo sobre este tema. Más allá del equipo del proyecto inmediato, existen muchas posibles diferencias en las estructuras organizativas para rendir informes y en las relaciones de los servicios.
• Identifique las rutas de responsabilidad de su proyecto. Clarifique quién es responsable de los distintos aspectos del proyecto, más allá del mismo equipo.
El modelo de equipo MSF otorga responsabilidad al cliente de las siguientes maneras:
• La administración de productos mantiene una relación con el cliente y actúa como defensor de éste. El objetivo del rendimiento de esta función es lograr la satisfacción del cliente.
• El objetivo del rendimiento de la administración de programas es enviar con éxito el proyecto dentro de los límites del mismo (funcional, tiempos y costos)
• La administración de productos y programas funciona de una manera integrada para satisfacer las necesidades del cliente dentro de las restricciones del proyecto. Ambas comparten la responsabilidad de lograr el éxito en general del proyecto aunque sus funciones luchan por conseguir objetivos diferentes.
Recomendaciones seleccionadas para los equipos MSF
Las siguientes prácticas recomendadas para la administración de proyectos van dirigidas a los jefes de equipo MSF y a la administración de programas. Estas prácticas se corresponden con algunas, no todas, las áreas de responsabilidad de la administración de proyectos que aparecen en la Figura 5.
Administración de los ámbitos (Del alcance)
278
El objetivo de la administración de alcances es asegurar que el proyecto identifica todo el trabajo que se necesita para completar la solución y que no se desvía hacia actividades situadas fuera del ámbito sin una revisión y aprobación preliminar.
Alcance durante la previsión
En el proceso inicial del proyecto, es necesario identificar y documentar el alcance amplio de un proyecto.
Durante la fase de previsión de MSF, el equipo genera una visión ilimitada de la solución. A continuación, se identifica el alcance de la primera versión. Esto se describe en el documento de visión/alcance y es aprobado por el equipo, el cliente y los participantes antes de que el proyecto pueda continuar. Durante esta fase, el alcance sólo se entiende en términos muy amplios, al nivel de descripción de características.
Alcance de la solución y del proyecto
El alcance puede referirse al ámbito de la solución y a la del proyecto. El alcance de la solución es la suma de todas las características y los elementos a entregar que deben crearse. El alcance del proyecto es la suma de todo el trabajo que debe realizarse para ofrecer la solución.
El equipo utiliza el proceso de diseño MSF para definir el alcance de la solución.
Definición del alcance
En la fase de planeamiento, el alcance del proyecto en general debe subdividirse en partes más pequeñas y manejables. Este proceso clarifica las áreas especiales que no se encuentran en ese alcance determinado. Normalmente, en estas áreas hay un riesgo especial de que se produzcan malentendidos.
Durante la definición del alcance, el equipo identifica los tipos de tareas y técnicas que se necesitan para crear cada característica y los elementos a entregar. Esto se documenta en una estructura de división de trabajo (WBS) que se describe posteriormente en este documento.
Control del cambio del Alcance
279
Una vez el alcance ha sido definido y se ha establecido su línea base, el equipo considera que lo tiene bajo control. Los cambios en el alcance deben ser revisados y aprobados tanto por el equipo responsable del proyecto como por el cliente.
Parte de un buen control del cambio implica tomar buenas decisiones sobre las compensaciones. El triángulo de tres variables interdependientes MSF y la matriz de compensaciones son herramientas útiles para facilitar el cambio de una manera controlada.
Para obtener más información, vea el documento Modelo de proceso MSF.
Preparación de los planes
El planeamiento como actividad se lleva a cabo a lo largo del proyecto. Durante la fase de previsión, el equipo establece el enfoque de alto nivel necesario para crear los elementos a entregar del proyecto.
Por ejemplo, el enfoque de pruebas describe los tipos de pruebas, las herramientas y las técnicas que se necesitan. En función del tamaño del proyecto, el documento puede ocupar solamente una o dos páginas, o incluso un párrafo.
Si bien los planes se detallan y actualizan en cada fase, la mayor parte del planeamiento se produce durante la fase de planeamiento MSF.
La secuencia general de los procesos durante esta fase es la siguiente:
• Proceso de diseño (¿qué creará?) • Proceso de planeamiento (¿cómo lo creará?) • Desarrollo de la programación (¿cuándo lo creará?)
Estos procesos pueden superponerse de algún modo, pero es preciso establecer la línea base del proceso anterior antes de que el siguiente pueda lograr detalles significativos. Esta sección se centrará en el proceso de planeamiento.
Reutilización de documentos
Los equipos de proyectos están sometidos a una presión constante para que minimicen el tiempo y los gastos del planeamiento. ¿Cómo se pueden obtener
280
ventajas de un buen planeamiento minimizando al mismo tiempo la carga del planeamiento?
La respuesta es recogiendo y volviendo a usar de una manera inteligente los documentos del planeamiento. Las organizaciones que se den cuenta de que los documentos de planeamiento son propiedad intelectual valiosa invertirán en organizar y mantener estos documentos en almacenes a los que pueda obtenerse acceso fácilmente.
Antes de crear un nuevo plan, los equipos siempre deben buscar cualquier cosa que ya se haya realizado. Una vez se ha completado un proyecto, es preciso archivar los documentos del mismo en una ubicación para que los equipos del futuro puedan volver a usarlos.
Planes del proyecto
En MSF, los planes de proyectos hacen referencia a un grupo de documentos que describen cómo se van a completar los elementos del proyecto que deben entregarse. Las especificaciones funcionales describen qué se creará. El plan de proyecto maestro es una sucesión integrada de planes de equipo para cada función. Cada función del equipo cuenta con planes que describen cómo completarán sus elementos a entregar.
MSF no prescribe una lista de planes del tipo "en un tamaño entra todo" que todos los proyectos deben tener. La siguiente lista predeterminada cubre las áreas de planeamiento habituales que se encuentran en los proyectos de desarrollo de software y de implementación de infraestructuras. En proyectos más pequeños, es posible combinar algunos de estos planes. Es posible que algunos proyectos necesiten más planes.
Tipo de plan Función predominante Plan de comunicaciones Administración de productos Plan de desarrollo Desarrollo Plan de formación Experiencia del usuario Plan de seguridad Desarrollo, administración de versiones Plan de pruebas Pruebas de QA (calidad) Plan de presupuesto Administración de programas Plan de educación del usuario Experiencia del usuario
281
Plan de implementación Administración de versiones Plan de compras e instalaciones Administración de versiones, Administración
de programas Plan piloto Administración de versiones Estructura de división del trabajo
Una WBS es una agrupación de elementos de trabajo del proyecto orientados a la entrega que organiza y define el alcance total del proyecto (iii). Consiste en un esquema del trabajo que va a realizarse. El trabajo no incluido en una WBS bien construida está fuera del alcance del proyecto. Los jefes de equipo y la administración de programas utilizan la WBS como herramienta en la administración de proyectos para crear planes y programaciones.
En MSF, la creación de la WBS es un ejercicio de colaboración en el que participan todas las funciones del equipo. Cada función es principalmente responsable de la definición de los detalles del trabajo de su área respectiva. En proyectos más grandes, los equipos secundarios (equipos funcionales o de producto y calidad) puede que necesiten aportar ideas sobre el trabajo que es necesario llevar a cabo. Los jefes de equipo documentan los resultados de la sesión de aportación de ideas y ofrecen los resultados al equipo (jefe) principal. A continuación, la administración de programas sincroniza estas contribuciones en una WBS común.
Ventajas
El valor de una WBS se entiende mejor si se piensa en él como un grupo de datos (información y conocimiento) en lugar de como un documento específico. Estos datos, cuando se combinan con los datos de otros proyectos, se utilizan para crear planes, programas, presupuestos y otros elementos del proyecto que se han de entregar. Es posible visualizar una WBS como una lista con sangría o un diagrama de bloque que puede crearse en diversas herramientas tales como hojas de cálculo, programas de procesador de texto o software para la administración de proyectos.
La WBS ofrece ventajas por lo siguiente:
• Estimación. Proporciona una lista básica de las tareas de las que deben realizarse estimaciones. Las estimaciones proporcionadas determinan el costo, tiempo y la programación.
• Recursos. Las necesidades de recursos y de plantilla se conocen clarificando los trabajos que deben llevarse a cabo. Ello también ayuda
282
demostrar las necesidades de los recursos si los participantes del proyecto piden una justificación.
• Secuenciación. Proporciona una lista básica de las tareas que pueden analizarse para conocer las restricciones de dependencias y recursos que pueden desarrollarse en una programación.
• Identificación de riesgos. Ayuda al equipo a considerar cada tarea al identificar los riesgos.
• Responsabilidad. Puede utilizarse para generar una matriz de responsabilidades.
Capacidad de seguimiento existente entre una WBS, las especificaciones funcionales y un plan de proyecto maestro
Existe una relación de la que puede realizarse un seguimiento entre las especificaciones funcionales, un plan de proyecto maestro y la WBS. Refleja la relación existente entre los elementos a entregar y las tareas que se necesitan para crear dichos elementos.
Por cada característica o componente de las especificaciones funcionales, la WBS confecciona un listado de las tareas asociadas a la creación de ese elemento que debe entregarse. La manera en que las características o los componentes se agrupan en especificaciones funcionales no es la misma en que sus tareas asociadas aparecen en la WBS.
Si una característica no tiene una tarea asociada a ella en algún lugar de la WBS, posteriormente puede "colarse" en el proceso de estimación, lo que posiblemente se traducirá en una programación o un presupuesto no realista.
El plan de proyecto maestro y la WBS se complementan. La WBS lista cada una de las tareas de una manera breve. Las descripciones detalladas de cómo deben llevarse a cabo las tareas, las barras de calidad y las tareas secundarias detalladas o las listas de comprobación se documentan en los planes.
La Figura 6 muestra de una manera esquemática cómo una WBS puede ser una herramienta potente para mantener la capacidad de seguimiento entre especificaciones, planes y programaciones.
283
Figura 6 La WBS ofrece capacidad de seguimiento entre especificaciones, planes y programaciones
Creación de una estructura de división del trabajo
Cada equipo se encarga de identificar actividades específicas que son necesarias para crear los elementos del proyecto que deben entregarse. Diversas funciones o equipos secundarios se encargan de realizar y mantener un seguimiento de los detalles de las actividades mediante listas de comprobación y planes.
En MSF, el nivel más bajo de actividad aparece en el plan de proyecto maestro, pero no en la WBS. Estas actividades se convierten en tareas suficientemente grandes sobre las que vale la pena realizar seguimientos e informes al nivel del proyecto en general que es la WBS.
284
Los jefes de equipo se reúnen con sus equipos funcionales para dividir los requisitos del trabajo. Trabajando en equipo a través de las especificaciones funcionales y de las especificaciones de otros elementos que deben entregarse, se identifica el trabajo necesario y se divide en actividades y tareas más pequeñas. A este proceso se le conoce como división o descomposición del trabajo.
Uno de los resultados del proceso de administración del riesgo MSF son tareas adicionales que responden a los riesgos (a los que a veces se denominan "amenazas") o planes de contingencia y actividades. Estas tareas deben agregarse a la WBS, a lo estimado, a lo planeado y a lo programado de la misma manera que el resto de tareas. Considere la opción de programar las sesiones de división del trabajo del equipo y las sesiones de aportación de ideas para el riesgo de manera conjunta.
El primer nivel de la WBS debe contener una fase del ciclo de vida del proyecto. El modelo de proceso MSF se presta a sí mismo a esto perfectamente. MSF sugirió que los objetivos importantes provisionales estén vinculados a la finalización o el establecimiento de la línea base de los elementos a entregar. Los objetivos importantes provisionales también forman un segundo nivel natural. Por debajo de este nivel, se identifican todos los elementos para entregar y se desglosan las tareas necesarias para crear cada uno de ellos. A este proceso se le denomina descomposición del trabajo o de las tareas.
Directrices para la descomposición de tareas
Éstas son las directrices que se recomiendan al llevar a cabo la descomposición de tareas:
• Puede realizarse una estimación de ellas de una manera realista. • No se cree que lleven menos de un día ni más de 40 (en el caso de
proyectos de TI). • Tienen una conclusión y un elemento a entregar significativos. • Pueden completarse sin grandes interrupciones. • Pueden asignarse a una persona responsable de su realización. • Pueden dividirse más que otras a ciertos niveles. • Las actividades de alto riesgo pueden dividirse más que las de bajo riesgo. • Excepto en el caso del nivel uno o dos, utilice una frase formada por sujeto
y verbo para describir la tarea. Por ejemplo, utilice "Diseñar esquema de base de datos" en lugar de simplemente "Esquema de base de datos".
• Contiene entre tres y cinco niveles en el formulario de esquema.
285
• La WBS evoluciona de manera interactiva durante el curso del proyecto, pero normalmente adquiere la forma durante la fase de planeamiento.
Estimación en alcances que van de lo particular a lo general
Las estimaciones de los proyectos de TI deben realizarlas aquéllos que están programados para realizar el trabajo. La estimación en alcances que van de lo particular a lo general es un proceso para desarrollar e integrar estimaciones de varios miembros del equipo. Proporciona las siguientes ventajas:
Mayor exactitud. Las estimaciones realizadas por aquéllos que harán el trabajo son más precisas ya que la persona que realiza las estimaciones ya tiene experiencia en la realización de trabajos similares.
Responsabilidad. Las personas que desarrollan sus propias estimaciones de trabajo se sienten más responsables de su trabajo. También se sienten más responsables del éxito que pueden tener al cumplir las estimaciones que han realizado.
Reforzamiento del equipo. Tener fechas fijadas por el equipo en contraposición a fechas dictadas por la administración refuerza al equipo ya que los plazos se establecen en función de estimaciones que los miembros del equipo pueden aceptar como realistas.
Integración de las estimaciones de los equipos
Cada jefe de equipo, junto con sus equipos secundarios, es responsable de preparar las estimaciones del tiempo necesario para completar los elementos que se han de entregar pertenecientes a su área de funciones. Por ejemplo, el jefe de desarrollo prepara estimaciones para los desarrolladores; el jefe de la experiencia del usuario prepara estimaciones para los elementos que deben entregarse de la experiencia del usuario (EU) y así sucesivamente, siempre escuchando los comentarios de su equipo.
La función de la administración de programas facilita el proceso de realización de estimaciones del equipo e integra todas las estimaciones en una programación y un presupuesto maestros.
Estimación en los proyectos de software
286
El costo de los proyectos de TI recae principalmente en el trabajo y los costos de Infraestructura (Hardware), por lo que las estimaciones del trabajo se convierten en datos esenciales y necesarios para generar estimaciones de costos y tiempo.
Creación de expectativas adecuadas
Las estimaciones crean expectativas sobre ciertos resultados que se producirán en el futuro. Por ello, crear expectativas razonables sobre la exactitud de una estimación es tan importante como la técnica utilizada para generar dicha estimación. Los grupos funcionales de administración de programas y productos deben trabajar duro para garantizar que se tienen expectativas comunes sobre lo siguiente:
Las estimaciones dependen de la especificación. El desarrollo de soluciones de TI es muy parecido a construir su propia casa. Es imposible saber cuánto costará sin antes haber definido perfectamente todos sus elementos. Esto no significa que las especificaciones son lo único necesario para realizar una estimación del proyecto. Otros elementos del trabajo tales como la comunicación con el cliente, las reuniones sobre el proyecto, los informes sobre el estado ocupan tiempo y también deben tenerse presentes en las estimaciones.
Es inevitable no tener alguna imprecisión. Debido a que el desarrollo de una solución es un proceso de mejora continua, las estimaciones tienen un margen para la variación.
Vuelva a realizar una estimación tras lograr un objetivo importante. El equipo debe comprometerse a proporcionar una serie de estimaciones más precisas a medida que avanza el proyecto.
Incertidumbre y exactitud de las estimaciones
Las estimaciones en el desarrollo de software son un proceso de mejora gradual. La Figura 7 muestra el llamado "cono de incertidumbre" (convergencia de estimaciones) de las estimaciones en el desarrollo de software. En la fase temprana del proyecto, el intervalo de variación de las estimaciones con respecto al costo real es muy grande. Este intervalo se hace más pequeño a medida que avanza el proyecto.
Tenga presente que al lograr objetivos importantes aprobados en el documento de visión/alcance, la estimación puede ser demasiado baja por un factor de 2, o demasiado alta por un factor de 0,5. Los valores de los datos específicos que se muestran, y que se han tomado de una encuesta realizada a mediados de los 90,
287
no deben aplicarse de una manera demasiado literal. Lo importante es entender el orden de la magnitud de la variación en cada fase.
La lección en este caso es que durante la fase de previsión, el equipo desarrolla intervalos de estimaciones (que a veces se denominan "estimaciones aproximadas") de tiempo y costos. Nunca ofrezca una estimación de costos o tiempo que sea invariable durante esta fase. Es preciso tener claro que estas estimaciones pueden variar por un gran factor al lograr objetivos importantes aprobados en los documentos de visión/alcance.
Figura 7 Cono de incertidumbre
Fuente: Adaptado del documento “Cost Models for Future Lifecycle Processes: COCOMO 2.0 (Modelos de costos para procesos de ciclo de vida próximos: COCOMO 2.0)” Boehm, et. al., 1995 (iv).
Estimación en el nivel más bajo de la división de tareas
Hay varias maneras de preparar las estimaciones de esfuerzo en el nivel de tareas. Todas estas maneras comienzan con la división de cada tarea de la WBS
288
en actividades más pequeñas. Esto se realiza en el nivel de los equipos secundarios y lo dirige cada jefe de equipo.
A continuación, se genera una estimación por cada una de las actividades del nivel más bajo. Estas estimaciones se agregan para realizar la estimación de las distintas tareas de la WBS.
La revisión de los datos e información reales de proyectos anteriores es uno de los mejores modos de sentar las bases de las estimaciones. Las organizaciones inteligentes recogen y analizan estos datos. Muchas actividades del proyecto cuentan con indicadores de la industria que pueden proporcionar buenas pruebas comparativas.
Una técnica recomendada más precisa es generar estimaciones de tres parámetros por cada actividad del nivel bajo. Las estimaciones de tres parámetros incluyen un valor de estimación optimista, pesimista y muy probable para cada tarea. Los criterios deben clarificar lo que significan estas estimaciones. El grado pesimista no tiene que significar necesariamente el peor de todos los escenarios posibles. Por el contrario, las estimaciones optimistas y pesimistas deben basarse en riesgos razonables y probables.
Una vez las actividades del nivel bajo se suman a las actividades del nivel WBS, hay tres valores de estimación por tarea. Los jefes de equipo envían esta información a la administración de programas para que lleven a cabo el análisis de los costos, tiempo y, a continuación, utilizan los datos de las estimaciones para preparar programaciones.
Análisis PERT
Una vez se han reunido las estimaciones de todas las tareas en la WBS, la administración de programas (o un administrador de proyectos especializado) aplica los análisis estadísticos para ajustar la estimación de tiempo en general. Existen varias técnicas para esto, pero la más usada es PERT (técnica de revisión de evaluación de programas). PERT toma estimaciones de tres parámetros y calcula el promedio de la distribución. Esto se utiliza para hacer una predicción de la fecha de finalización más probable, en lugar del único valor de la estimación más probable. También proporciona un intervalo de resultados de las estimaciones que tiene como base las variaciones de todas las tareas de la ruta crítica.
289
La descripción completa de la PERT se encuentra fuera del alcance de este documento. Sin embargo, las herramientas de administración de proyectos, tales como Microsoft® Project®, permiten realizar análisis PERT.
Recomendaciones sobre las programaciones
La administración de las programaciones incluye los procesos necesarios para garantizar que el proyecto se finalice a tiempo.
Secuenciación de tareas
Una vez se han documentado y se han realizado las estimaciones de las tareas y las actividades del proyecto en la WBS, se identifican las dependencias entre ellas. Por ejemplo, no es posible completar el borrador de la documentación del usuario de una característica sin antes completarse la especificación funcional que describe esa característica. Las dependencias deben identificarse a los niveles de tareas más pequeños.
Lucha contra el tiempo
Utilice límites de tiempo internos para mantener la presión sobre el equipo del proyecto con el fin de dar prioridad a características y actividades; a esta técnica se le conoce como "lucha contra el tiempo". Esto no debe usarse de mala manera para reducir de una manera arbitraria las estimaciones de tiempo del equipo. Una lucha contra el tiempo correcta comienza con una estimación de tiempo razonable y con la idea de que es posible que sea necesario recortar algunas características para ajustarse al límite del tiempo.
Programación basada en los riesgos
Las características o los componentes de alta prioridad con más riesgo deben programarse en la fase temprana del proyecto. De este modo se amplía al máximo el tiempo disponible para reaccionar ante problemas.
Administración del tiempo adicional
Agregue tiempo adicional a los plazos del proyecto para permitir al equipo acomodarse a los problemas y cambios que se produzcan de manera inesperada. La cantidad de tiempo adicional que debe aplicarse depende del nivel de riesgo. Al evaluar los riesgos en la fase inicial del proyecto, es posible evaluar los riesgos más probables para conocer el impacto que éstos tendrán en los plazos y cómo se pueden compensar usando tiempo adicional.
290
Un modo de pensar en el tiempo adicional es como si fuese una estimación para tareas y eventos desconocidos. No importa la experiencia que tenga el equipo, no todas las tareas de los proyectos pueden conocerse ni se puede realizar una estimación de ellas con antelación. Sin embargo, es prácticamente cierto que habrá riesgos en algunos proyectos y tendrán un impacto en el proyecto, y que las acciones correctoras necesarias para responder al riesgo necesitarán más tiempo.
Éstas son las directrices recomendadas para hacer un buen uso del tiempo adicional.
• El tiempo adicional no debe agregarse inflando las estimaciones para las tareas individuales. Puesto que el trabajo aumenta para ocupar el tiempo asignado para hacer dicho trabajo (un efecto denominado Ley de Parkinson), el tiempo adicional será absorbido por las tareas planeadas, no por los eventos no planeados.
• El tiempo adicional debe programarse como si fuese cualquier tarea. Normalmente, el tiempo adicional se asigna inmediatamente antes de lograr objetivos importantes, especialmente los últimos. Siempre debe situarse en la ruta crítica del proyecto. La ruta crítica es la cadena más larga de tareas dependientes de un proyecto y determina directamente la duración del proyecto.
• A medida que aumenta el tiempo adicional durante el curso del proyecto, la Administración de programas debe realizar un seguimiento y conservar cuidadosamente la cantidad restante. El tiempo adicional es un conjunto compartido, por lo que sólo debe asignarse cuando se solicite.
• Si se agrega una característica, o si se suprimen recursos del proyecto, no compense estos recursos usando el tiempo adicional. Si lo hace, su capacidad de compensar los riesgos se verá reducida consecuentemente. Negocie las características, los recursos y los plazos usando el triángulo de tres variables interdependientes.
• Si se utiliza todo el tiempo adicional, asegúrese de que todo el equipo sepa que cualquier interrupción o retraso es probable que tenga un efecto "cascada" y ponga en peligro la fecha de finalización.
Notas finales
(i) PMI, Inc., A Guide to the Project Management Body of Knowledge, 2000 Edition (Guía sobre el conocimiento principal necesario en la administración de proyectos, Edición de 2002) (Newtown Square, PA: Project Management Institute, 2000), p. 4-6. Para obtener definiciones similares usadas en Europa y el Reino Unido, vea también G Caupin, H Knopfel, P Morris, E. Motzel, O Pannenbacker, IPMA Competence Baseline (Bremen, Germany: International Project Management
291
Association, 1999), p. 23, y Central Computer and Telecommunications Agency, Managing Successful Projects with Prince2 (Administración satisfactoria de proyectos con Prince2), (London: UK Stationery Office, 1998), p. 7.
(ii) Adaptación de A Guide to the Project Management Body of Knowledge (Guía sobre el conocimiento necesario en la administración de proyectos), p. 39. IPMA hace referencia a 28 áreas de conocimiento, que incluye las nueve descritas por PMI. Prince2 incluye ocho ‘componentes de la administración de proyectos’, de los que sólo tres de ellos se asignan directamente a PMI. Las áreas de IPMA se asignan perfectamente tanto a PMI como a Prince2.
(iii) A Guide to the Project Management Body of Knowledge (Guía sobre el conocimiento necesario en la administración de proyectos), p. 4-6. WBS también se define en IPMA Competence Baseline (Línea base de la competencia IPMA), p. 34.
(iv) Adaptado a MSF del documento Cost Models for Future Lifecycle Processes: COCOMO 2.0 (Modelos de costos para procesos de ciclo de vida próximos: COCOMO 2.0)” Boehm, et. al., 1995. Anteriormente se adaptó en Steve McConnell, Rapid Development (Desarrollo rápido) (Redmond, WA : Microsoft Press, 1996), p. 168.
292
Anexo B.
Encuesta sobre gerencia de proyectos de TI Bienvenido a participar en la cuesta sobre Gerencia de Proyectos de TI , organizada por estudiantes del MBA – Universidad EAFIT - Estamos muy interesados en su opinión y agradecemos sinceramente su participación en esta iniciativa. Los resultados de la encuesta le permitirán comparar su organización con otras similares respecto a algunas variables, ofreciendo un espectro de análisis y evaluación que puede ser útil para repensar y analizar las actuales prácticas y opciones de gerencia de proyectos de TI vigentes en su organización. Todas las respuestas por favor enviarlas vía correo electrónico, identificando el correo en el asunto con ENCUESTA PROYECTOS TI Todas las respuestas son de carácter confidencial y las respuestas individuales no serán reveladas. La información sólo se utilizará en conjunto y agregada una vez compilada y analizada. Por su participación le estaremos enviado los resultados de esta investigación vía correo electrónico. Gracias nuevamente por su tiempo. ______________________________________________________________ Favor marcar con una equis (X) según corresponda. Total No. Preguntas: 15. Total Secciones: 5 (Demografía, Presupuestos, los proyectos, herramientas y Políticas de
Gerencia de proyectos)
Nota. Para propósitos de la presente encuesta la función Gerente de Proyecto, Líder de
Proyecto o Responsable de Proyecto tiene el mismo significado.
Esta encuesta aplica a los proyectos llevados a cabo en el área de Tecnología o
proyectos en los cuales el área de tecnología hubiera tenido participación.
I. DEMOGRAFÍA 1. Cuál es el sector primario de su empresa? (Elija una) [ ] Banca [ ] Ingeniería [ ] Industria Informática [ ] Educación [ ] Servicios Públicos / Energía
293
[ ] Gobierno [ ] Seguros [ ] Petróleo [ ] Transporte [ ] Telecomunicaciones [ ] Farmacéutico [ ] Sin ánimo de lucro [ ] Otro, especifique:____________________ 2. Cuántos empleados existen en total en su organización (Incluye temporales y subcontratados)? Si su empresa es una multinacional, por favor indique los empleados en Colombia (Elija una) [ ] 1 a 100 [ ] 101 a 250 [ ] 251 a 500 [ ] 501 a 1000 [ ] 1001 a 2500 [ ] 2501 a 5000 [ ] Más de 5000 3. Cuántas personas de tiempo completo o equivalente se dedican a la Gerencia de Proyectos de TI? (Elija una) [ ] Ninguna [ ] 1 a 2 [ ] 3 a 5 [ ] 6 a 10 [ ] Mas de 10 Si la respuesta es NINGUNA por favor aclare _____________________________________________________________________ _____________________________________________________________________ 4. De quién depende la responsabilidad de la Gerencia de proyectos de TI en su organización? [ ] Director Departamento de Sistemas/Tecnología [ ] Gerente Departamento de Sistemas/Tecnología [ ] Presidente / Gerente General / Director Ejecutivo [ ] Gerente de Finanzas [ ] Gerente de Planeación [ ] No se tiene especificado formalmente [ ] Otro, especifique: ___________________ 5. El cargo que Ud. Ocupa en la organización es: [ ] Presidente / Gerente General / Director Ejecutivo [ ] Director / Vicepresidente [ ] Profesional de Departamento de Sistemas / Tecnología [ ] Gerente de Proyecto [ ] Director / Gerente / Jefe de TI
294
[ ] Otro, especifique: _____________________
II. PRESUPUESTOS 6. El presupuesto global de informática de su organización, incluye aspectos de capacitación en metodologías y desarrollo de habilidades en Gerencia de proyectos? [ ] Si [ ] No 7. ¿En qué se centra el gasto en Gerencia de proyectos de TI? (Elija todas las que apliquen) [ ] Administrar los proyectos de TI de la organización [ ] Concientización / formación del usuario final [ ] Asesores / Consultores en Gerencia de Proyectos [ ] Contratación de personal con experiencia en Gerencia de proyectos [ ] Evaluaciones de los proyectos en marcha [ ] Capacitación en Gerencia de Proyectos [ ] Otro, especifique: ______________________ III. LOS PROYECTOS 8. Durante el 2003 y el 2004 proyectos de qué tipo tuvieron lugar en su organización? (Elija todas las respuestas aplicables) [ ] Ninguno [ ] Adición de Infraestructura (cableado, aire acondicionado, piso falso etc) [ ] Redes de datos (LAN, WAN. MAN) [ ] Intranet / extranet [ ] Desarrollo de software [ ] Renovación/Adición de PCs con sus programas correspondientes [ ] Adición / Renovación Mainframe [ ] Adición / Renovación equipos de rango medio [ ] Adición / Renovación de servidores [ ] Software de servidores [ ] Seguridad [ ] BI o DWH [ ] Adición / Nueva versión ERP [ ] Actualización de Software [ ] Actualización de Hardware [ ] Otros, especifique: _____________________ 9. Una vez en desarrollo el proyecto, el avance se conoce a través de: (Elija todas las aplicables)
295
[ ] Medios de divulgación interno [ ] Gerente del Proyecto [ ] Jefe / Gerente del Departamento dueño del proyecto [ ] Ninguno: No se conoce [ ] Otro, especifique:______________________ 10. Cuáles son las causas del fracaso de los proyectos de TI (Entendiendo como fracaso en los proyectos, proyectos que finalizan no obteniendo el objetivo planteado, ni en el tiempo y con los recursos estimados) (Elija todas las aplicables) [ ] Cambios en los objetivos [ ] Falta de claridad y unidad alrededor de los objetivos del proyecto [ ] Problemas de Integración de TI [ ] Trabajo en Equipo y sentido de pertenencia [ ] Poca claridad e inadecuada asignación de las responsabilidades en el equipo de trabajo [ ] Problemas de administración de tecnología [ ] No participación de áreas claves del negocio desde el inicio del proyecto [ ] Falta de compromiso y sentido de pertenencia del usuario líder del proyecto. [ ] Desconocimiento de la tecnología [ ] La falta de cultura de trabajo por proyectos en la organización [ ] Errores en la planeación del Proyecto (Poca precisión para estimar el tiempo y los recursos) [ ] Inadecuado manejo de control de Cambios [ ] Inadecuado manejo de Riesgos [ ] Proyectos demasiado ambiciosos [ ] Falta de Un plan de aseguramiento de la calidad del proyecto [ ] Especificación de requerimientos incompleta, ambigua, inconsistente [ ] No utilización, o mala utilización de metodologías de Gerencia de Proyectos [ ] Problemas Humanos, de conducción, comunicación y conflicto [ ] Recurso Humano incompetente [ ] Falta de conocimientos y Habilidades para Gerenciar Proyectos [ ] Otros, especifique cuales: ____________________________________________________ A. B. C. D. E. F. G. H. I. J. K. L.
296
11. Cuáles son las causas del Éxito de los proyectos de TI (Entendiendo como éxito en los proyectos, proyectos que finalizan obteniendo el objetivo planteado, en el tiempo pactado y con los recursos estimados) (Elija todas las aplicables) [ ] Claridad y unidad alrededor de los objetivos del proyecto [ ] Trabajo en Equipo y sentido de pertenencia [ ] Claridad y una adecuada asignación de las responsabilidades en el equipo de trabajo [ ] Participación y compromiso de áreas claves desde el inicio del proyecto [ ] Gran compromiso y sentido de pertenencia del usuario líder del proyecto [ ] Conocimiento de la tecnología [ ] Cultura de trabajo por proyectos en la organización [ ] Buena planeación del Proyecto (Precisión para estimar el tiempo y los recursos) [ ] Adecuado manejo de control de Cambios [ ] Adecuado manejo de Riesgos [ ] Proyectos Cortos [ ] Un plan de aseguramiento de la calidad del proyecto [ ] Especificación de requerimientos completa, clara y consistente [ ] Utilización de metodologías de Gerencia de Proyectos [ ] Recurso Humano competente [ ] Buenas estrategias de conducción, seguimiento, control, comunicación y manejo del conflicto [ ] Buenos conocimientos y Habilidades para Gerenciar Proyectos [ ] Otros, especifique cuales : ______________________________________________________ A. B. C. D. E. F. G. 12. Se aplica alguna metodología para el manejo de los proyectos en su organización? [ ] Si, cual__________________________________________ [ ] No 13. Se dicta internamente ó se recibe externamente capacitación respecto a la metodología de Gerencia de Proyectos? [ ] Si, [ ] Externa - [ ] Interna [ ] No Explique la respuesta ya sea Si ó No por favor ____________________________________________________________________ ____________________________________________________________________
297
IV. HERRAMIENTAS 14. Para la Administración de los proyectos, su organización utiliza alguna herramienta? [ ] Si Cúal?______________________________________________________________ [ ] No V. POLÍTICAS DE GERENCIA DE PROYECTOS 15. Su organización tiene políticas para Manejo de los Proyectos? [ ] Si [ ] No Explique la respuesta ya sea Si ó No por favor _______________________________________________________________________ _______________________________________________________________________ Muchas gracias por su colaboración Cordialmente James Torres Obando Estudiante de MBA – EAFIT Tesis Modelo de Gerencia de Proyectos de TI
298
Anexo C.
Plantilla Enunciado del Alcance (Scope Statement)
Nombre del Proyecto: Preparado por: Fecha: Justificación del Proyecto:
Las necesidades del negocio a las que el proyecto apunta. La justificación del proyecto provee las bases para evaluar futuras negociaciones XXXX XXXXX XXXXXXXXXXX XXX XXXXXXXX XXXXX XX XXXXXX
Descripción del Proyecto:
Un breve resumen de la descripción del proyecto. XXXXXXXX XXXXXX XXXXXX XX XXXXXX XXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXX
Entregables del Proyecto
Lista resumen de sub productos cuya entrega satisfactoria marcarán la terminación del proyecto.
Entregable A
Entregable B
Entregable C
Entregable D
Entregable E
Entregable F Otros
Exclusiones
Conocidas
299
Objetivos del proyecto
Los criterios cuantificables que el producto debe reunir para que el proyecto sea considerado exitoso. Los objetivos deben incluir al menos medidas de costo, programación y calidad.
Objetivos de Costos (Cantidad)
Objetivos de la Programación (fechas de comienzo y de finalización)
Medidas de calidad (criterios que determinarán la aceptabilidad)
Otros Objetivos
Plantilla del Acta (Carta) del Proyecto (Project Charter)
Nombre del Proyecto: Preparado por: Fecha: Iniciación:
Incluye el nombre del proyecto y justificación del nombramiento del director del proyecto designado
Propósito / Necesidades de Negocios:
Identifica los actores que reciben y se benefician del producto que el proyecto desarrolla y las necesidades que el producto intenta reunir (ya sea como la solución a un problema, o el aprovechamiento de una oportunidad)
300
Descripción del Producto y Entregables:
Identifica que producto se entrega al final del proyecto y las diferentes entregas parciales. Describe el producto completo, para que el equipo del proyecto pueda crearlo, y para que se cumplan los objetivos acordados y la entrega a tiempo del producto.
SUPUESTOS
RESTRICCIONES
Supuestos, Restricciones, Riesgos:
Brevemente identifica los supuestos relevantes, restricciones y riesgos conocidos, si de alguna forma pueden ser anticipados para tener un mejor impacto en los procesos y/o resultados del proyecto, y que decisiones o acciones son requeridas por el patrocinador o por el equipo.
RIESGOS
Recursos:
Indica los recursos requeridos y/o disponibles para el proyecto. Conforme sea apropiado, indica recursos material, personal, económico (tales como instalaciones, equipos, suministros y servicios).
Comunicación e informes:
Identifica los requerimientos de comunicación entre el patrocinador y el equipo.
301
Aceptación:
Indica el método y el criterio para que el patrocinador acepte las entregas específicas del proyecto como completadas y adecuadas.
Gerencia del cambio:
Indica los procedimientos que se usarán para realizar y documentar los cambios al acta.
Otros:
Identifica y explica otros asuntos relevantes para la iniciación y dirección del proyecto.
Resumen:
Breve resumen de los aspectos relevantes del proyecto que responde a las preguntas: "Por qué?" (Propósito), "Que?" (Descripción del producto / alcance), "Cuándo?" (Tiempo), y "Cuánto?" (Recursos)
Aprobación (opcional) Director del proyecto:
Patrocinador:
302
303