Gestión de proyectos informáticos

1. ADMINISTRACION DE PROYECTOS INFORMATICOS
¿Qué es la Administración de Proyectos?. Es un método y conjunto de técnicas basadas en
los principios de la Administración para alcanzar el resultado esperado en el tiempo
esperado dentro del presupuesto y de acuerdo a las especificaciones.
¿Qué es un proyecto?. Es la búsqueda de una solución inteligente al planteamiento de un
problema tendiente a resolver, entre muchas, una necesidad humana. En esta forma
puede haber diferentes ideas, inversiones de diverso monto, tecnología y metodologías
con diverso enfoque, pero todas ellas destinadas a resolver las necesidades del ser
humano en todas sus facetas como puede ser: educación, alimentación, salud, ambiente,
cultura, etc. El recurso humano es lo más importante en un proyecto, de este factor depende el éxito o fracaso del mismo.
En el análisis de un proyecto intervienen los siguientes puntos:
PRESUPUESTO
SITE (ESPACIO)
RECURSOS HUMANOS
SOFTWARE
HARDWARE
NECESIDADES
Planeación: ¿Cómo?, ¿Cuando?. La comunicación es lo más importante a tomar en cuenta en la planeación, ya que esto afecta al
recurso humano.
Organización: ¿Quién?.
Dirección: Coordinación de las cosas.
Control: Debe revisarse paso a paso cada proceso en el desarrollo. Deben hacerse las cosas por el deseo de "hacerlas bien". Por
cada cliente insatisfecho, en promedio se pierden 16.
Reingeniería. La reingeniería es un enfoque para planear y controlar el cambio. La reingeniería de negocios significa rediseñar los
procedimientos de negocios y luego implantarlos.
DEFINICION PLAN ORGANIZACION
• DEFINIR EL PROBLEMA • IDENTIFICAR ACTIVIDADES
• DETERMINAR NECESIDADES DE
PERSONAL
• IDENTIFICAR METAS
• ESTIMAR TIEMPO Y
COSTOS
• RECLUTAR AL ADMINISTRADOR
DEL PROYECTO
• LISTAR OBJETIVOS • SECUENCIAR ACTIVIDADES
• RECLUTAR EQUIPO PARA EL
PROYECTO
• DETERMINAR RECURSOS
PREELIMINARES
• IDENTIFICAR ACTIVIDADES
CRITICAS
• ASIGNAR CARGAS DE TRABAJO
• IDENTIFICAR OPORTUNIDADES
Y RIESGOS
• ESCRIBIR PROPUESTA
Object 1

2. CONTROL CERRAR
• DEFINIR ESTILO DE ADMINISTRACION • OBTENER ACEPTACION DEL CLIENTE
• ESTABLECER HERRAMIENTAS DE CONTROL • INSTALAR VARIABLES
• REPAR REPORTES DE STATUS • DOCUMENTAR EL PROYECTO
• REVISAR CALENDARIO DEL PROYECTO • EMITIR REPORTE FINAL
• EMITIR ORDENES DE CAMBIO • AUDITORIA POST-IMPLANTACION
Usuarios Finales. Son los Gerentes o empleados de una organización que interactúa con los sistemas de información. El grado de
participación quizás cambie y esto depende del tipo de usuario. Son personas que no son especialistas en Sistemas de Información
pero utilizan las computadoras para desempeñar su trabajo. Hay varios tipos de usuario, y son: Usuario Final Directo, Usuariop Final
Indirecto, Administradores, Directivos.
10 CAUSAS PRINCIPALES POR LAS QUE UN PROYECTO FALLA
DANEK BIENKOWSKI.
1.- EL PROYECTO ES UNA SOLUCIÓN EN BUSCA DE UN PROBLEMA.
2.- SOLAMENTE EL EQUIPO DEL PROYECTO ESTÁ INTERESADO EN EL RESULTADO FINAL. (SE DEBE CONTAR CON EL
COMPROMISO DE LA CABEZA DE LA ORGANIZACIÓN).
3.- NADIE ESTÁ A CARGO. (DEBE EXISTIR UN LIDER AUNQUE SEA INFORMAL).
4.- EL PLAN DEL PROYECTO CARECE DE ESTRUCTURA.
5.- LA PLANEACIÓN DEL PROYECTO CARECE DE DETALLES.
6.- EL PROYECTO ESTÁ SOBRE ESTIMADO DEL PRESUPUESTO.
7.- LOS RECURSOS LOCALIZADOS SON INSUFICIENTES.
8.- EL PROYECTO NO SE SIGUE DE ACUERDO A SU PLAN.
9.- EL EQUIPO DEL PROYECTO NO TIENE COMUNICACIÓN.
10.- EL PROYECTO SE ALEJA DE SUS OBJETIVOS ORIGINALES.
Procesos Claves en la Administración de Proyectos
Por Norberto Figuerola, PMP®
[ Acerca del autor ]
El Dr. Roger Kaufman señaló en uno de sus artículos (“Benchmarking”) que es casi universalmente popular tomar como referencia a
otras organizaciones y buscar en ellas las mejores prácticas que utilizan para que la propia organización pueda copiarlas y ser más
eficaz, previo a un análisis de las mismas. Un error común es creer que los procesos en sí mismos deben ser la base para determinar
la mejor práctica, sin relacionar a éstos a la creación interna de valor. Si uno busca una organización o metodología como referencia,
debería asegurarse de que las metas y objetivos de la institución referente sean similares a la suya y que los procesos que se tomarán
como modelo sean adecuados y funcionarán dentro de su organización.
Si los procesos que actualmente utiliza para la gestión de proyectos o los que se propone implementar resultan en más trabajo que el
proyecto mismo, evidentemente usted necesitará repensar o simplificar dichos procesos.
Eso ocurre frecuentemente con procesos propietarios o metodologías desarrolladas que no tienen en cuenta aspectos más ágiles del
negocio. Recuerdo un proyecto en donde me tocó trabajar con otros consultores de la ex Arthur Andersen quienes utilizaban
“Method/1”. Si bien ellos me dieron acceso a dicha metodología francamente nunca la leí, pero puedo asegurar que ocupaba toda una
biblioteca, y uno debería tener mucho tiempo para poder leer todos esos libros en menos tiempo del que se necesitaba para llevarlos a
la práctica. No discuto el proceso sino su usabilidad. Cualquier proceso o metodología que ayude en el trabajo es bueno, con tal que,
genere valor al cliente y no sea excesivamente pesado.
Para asegurar el éxito en la gestión de proyectos se necesita recurrir a las mejores prácticas del mercado y no re-inventar la rueda. Los
procesos o métodos de mejores prácticas deberían ser una biblioteca de toda la experiencia pasada de una organización en la
ejecución de sus proyectos. Estos deberían ser modulares de manera de poder adaptarlos a los distintos tamaños o complejidades de
los proyectos. La biblioteca de las mejores prácticas se construye realizando los análisis post-mortem o lecciones aprendidas y
documentando esa información para la mejora continua de los mismos.
Para las organizaciones que no tienen información histórica de proyectos anteriores o desean desarrollar la propia basándose en las
mejores prácticas del mercado de metodologías existentes para la administración de proyectos, el material de referencia estándar es el

3. PMBOK® del Project Management Institute con información muy detallada acerca de los procesos para la gestión de proyectos. Otras
normas o metodologías tales como ISO, CMMI, Prince 2, APM, etc., son otras fuentes de información aunque en algunos casos son
propias de determinadas industrias (IT) y otras no tan difundidas o completas. El PMBOK® distribuye las mejores prácticas en 42
procesos y nueve áreas de conocimiento o disciplinas. En la práctica muchos proyectos no utilizan ni la mitad de esos 42 procesos, sin
embargo a los efectos educacionales el PMBOK® provee la más clara y profunda explicación de las distintas áreas que envuelven a la
gestión de cualquier proyecto. La flexibilidad es muy importante aquí.
Primero se trata de otro BOK (Body of Knowledge) por lo que no se espera encontrar todas las respuestas allí sino que cada
profesional deba consultar infinidad de otras fuentes relacionadas con cada proceso y disciplinas descriptas. Segundo, utilizar el
sentido común, la experiencia y la intuición para decidir qué procesos son los que conviene aplicar en cada proyecto que vamos a
encarar.
Tomando como base el PMBOK®, a mi criterio el documento que sigue siendo más importante como referencia para la gestión de
proyectos, en este artículo vamos a detallar algunos conceptos muy importantes, advertencias y temas claves que se deben
contemplar en la administración de todos los proyectos y que normalmente suelen pasarse por alto o no darles la importancia
necesaria en la gestión de los mismos.
1 - Seguir un proceso de iniciación estructurado: realizar un estudio de factibilidad financiero, tecnológico, de recursos, impactos,
estratégico y de negocio del proyecto, para prevenir inconvenientes, priorizarlo y obtener el soporte y justificación de negocio necesario
para poder implementarlo. Durante la fase de inicio o arranque, una correcta valoración de riesgos, asunciones, obstáculos y
restricciones deben ser convenientemente evaluados y el factor crítico es realizar un adecuado proceso de valoración de
requerimientos (RM) para clarificar objetivos, necesidades y alinear las expectativas. En muchos casos los procesos de RM pueden
automatizarse pero siempre es conveniente mantener sesiones y reuniones con los stakeholders para aclarar los puntos grises. Todas
las metodologías de administración de proyectos recalcan la importancia de una fuerte relación con los stakeholders y su proceso de
análisis, dado que con ellos podremos lograr más fácilmente el éxito y romper diversas barreras en los proyectos. Un error frecuente es
que muchos proyectos pueden tener un gran número de stakeholders y el team sólo dialoga con aquel más sociable y entusiasta sin
evaluar las expectativas de los otros que directa o indirectamente están involucrados y son precisamente los que pueden ponernos los
palos en la rueda. Un factor común para el éxito de los proyecto es poseer la habilidad de negociar y manejar las expectativas y
necesidades de los stakeholders afectados por el proyecto. La relación con el sponsor y los stakeholders es vital y la clave es
establecer una buena “relación” lo que implica más que identificar y manejar sus expectativas, manejar una conexión emocional con la
gente. El PM debe focalizarse en mejorar sus habilidades interpersonales, y asegurarse de que todos los stakeholders están a bordo
del proyecto manteniendo fluida comunicación con ellos. El análisis de los stakeholders debería permitir al PM no sólo identificarlos
sino categorizarlos bajo distintos aspectos: relación y actitud hacia el proyecto, están a favor o en contra del proyecto, cuál es su poder
e influencia, existen conflictos entre ellos, etc.
2 - Planificación del Proyecto: de acuerdo a la industria donde se realice el proyecto, la planificación podrá tomar diferentes matices.
Los proyectos para el desarrollo de software son bastante particulares, tan es así, que surgieron metodologías propias para los mismos
(“Agil Development”) diferentes a las tradicionales como el PMBOK®. Algunos aspectos de las metodologías ágiles pueden ser
utilizados en cualquier otro proyecto. Actualmente está de moda hablar también de Lean Six Sigma Project Management, otra
aproximación a la gestión efectiva de proyectos. Independientemente de que se utilice una metodología tradicional, ágil o lean; una
buena planificación siempre es necesaria. En la metodología tradicional la planificación es exhaustiva y completa, en los ciclos más
acelerados y livianos (ágil o lean) la planificación se concentra en delimitar los bordes del proyecto para crear una lista priorizada de
entregables que serán liberados en fases de tipo iterativa. Planes comprensivos, realistas y bien comunicados son imprescindibles en
todos los proyectos, aún con cortos ciclos de vida. Involucrar no sólo al team sino a los stakeholders en el desarrollo de los planes,
discutir acerca de todos los objetivos y entregables del proyecto y explicar claramente los riesgos involucrados son también factores
esenciales. Como corolario final el consejo es no embarcarse en planificaciones extensas, construir planes a corto plazo y detallados
(elaboración progresiva según el mismo PMBOK®), e ir elaborando los requerimientos sobre la marcha en una aproximación de tipo
iterativo.
3 - Utilizar auditorías: para evaluar la salud del proyecto, deberían realizarse auditorías y reuniones de “quality assurance” en forma
frecuente para chequear no sólo los entregables sino el estado y progreso del proyecto. Medir el progreso real versus el costo y tiempo
estimado es muy importante, al igual que realizar mediciones de calidad respecto del cumplimiento de los requerimientos y el alcance
de los entregables. No podemos controlar y mucho menos mejorar si no tenemos métricas. Debemos desarrollar criterios estándar de
medición tanto de calidad como de productividad y eficiencia, para saber no sólo dónde estamos sino qué y cómo debemos mejorar. El
PM debe desarrollar todas las actividades y procesos definidos dentro del grupo de Monitoreo y Control del Proyecto que involucra el
control del progreso del mismo (tiempo y tareas), el control del alcance (cambios), control del rendimiento (performance), control de los
costos (método del valor ganado) y el control de calidad. De dichos controles surgirán reportes y medidas correctivas o preventivas.
Las auditorías también pueden ser efectuadas por personal externo al proyecto, y se denominan “peer reviews”, realizadas por colegas
o el departamento PMO o de Aseguramiento de Calidad. El alcance de la misma debería ser similar al comentado más arriba. Toda
auditoría consta de las siguientes etapas:
•Planificación: Elección del tipo de auditorías a realizar (costos, performance, calidad, etc.), determinar los procedimientos a
utilizar, elección del personal, fijación de su periodicidad (mensual, anual, esporádica, etc.).
•Realización de auditorías según procedimiento y plan definidos: Es conveniente desde el punto de vista práctico que la
realización de auditorías sea sistemática, y el propio director o responsable del área a auditar transmita a sus subordinados
afectados las fechas concretas en las que estas auditorías sistemáticas van a realizarse para que presten su mayor
colaboración. Los documentos que recaben los resultados de las auditorías, es decir, respuestas, comprobaciones,
resultados de medidas y ensayos, etc., han de estar consensuados entre auditor y auditado, de tal forma que recojan la
conformidad de ambos, evitándose discusiones inútiles. Se trata de auditar la efectividad de la gestión del proyecto, tanto a
través del grado de cumplimiento de los procesos, como a través de la calidad del producto obtenido.
•Evaluación de los resultados de la auditoría: Toda auditoría ha de realizarse para obtener una nota final que sirva, aunque
sólo sea comparativamente, para medir la evolución y progreso del proyecto. Lo que se pretende es la obtención de una
valoración totalmente objetiva por lo que el sistema de valoración ha de ser consensuado, y además, experimentado durante
cierto tiempo, para poder fijar las señales de alerta, índices de ponderación, etc.
•Redacción de un informe y propuesta de medidas correctivas de ser necesario, con expresión de su grado de urgencia: Una
vez valorada la auditoría y antes de la redacción del informe final y propuesta de las medidas correctoras, es conveniente la
reunión con el PM afectado por la auditoría para que sea el primer informado y pueda incluso colaborar en la propuesta de

4. medidas correctoras así como la decisión sobre la urgencia de las mismas, pues es conveniente que tanto el informe de la
auditoría como la propuesta de medidas correctoras, lo asuma como algo propio, entre otras cosas porque a veces, podrá
ejercer más presión sobre la Gerencia que el propio auditor, sobre todo si alguna de las medidas propuestas corresponden o
requieren inversiones.
4 - Utilización de recursos humanos: la correcta utilización de las “técnicas blandas” y el uso adecuado de las habilidades
interpersonales son factores críticos en el manejo de todos los proyectos. Un tema controversial que suele traernos dolores de cabeza
se refiere a las horas que cargan los recursos al proyecto: ¿deben ser las reales o teóricas?. En las organizaciones en las que trabajé,
como ocurre con muchas consultoras o empresas de servicios, al cliente se le cobra de acuerdo al proyecto un “precio fijo” o “time &
material” (por hora de consultoría). En ambos casos se toma para la formación del precio el “cost rate” de los recursos que trabajarán
en el proyecto, independientemente de que el recurso pertenezca o no a la organización ejecutante. Si pertenece a la organización y
trabaja más de 40 horas a la semana, su salario será siempre el mismo, pero a los efectos de cobro al cliente en el caso de time &
material podríamos cobrar las horas “overtime”, algo que, en la práctica sólo se le paga al recurso si es externo a la organización. En
los casos de precio fijo, durante la planificación normalmente calculamos en la herramienta de scheduling 40 horas de trabajo semanal.
Si observamos que existen recursos con sobre alocación (más de 8 horas por semana) la técnica más común a utilizar sería el
resource-leveling algo que generalmente terminará por enviarnos el final del proyecto al lado oscuro de la luna. En la práctica
normalmente no se hace nada dado que el recurso si es parte de la plantilla de la organización, trabajará esas horas extras que por lo
general y debido a su rango no son pagadas en la práctica dado que recibe su sueldo mensual fijo. El problema se presenta cuando
existen sistemas de control de costos y productividad que no toma en cuenta esta realidad (dado que se maneja con planillas
separadas). En estos casos es frecuente que se le obligue al recurso a cargar las horas que realmente trabaja en el proyecto en algún
sistema para su registro. De ser así, estaremos en un aprieto desde el punto de vista de costos, dado que las horas cargadas y
costeadas superarán lo que estaríamos facturando. La única solución en este caso será que no cargue sus horas extras, bajando su
nivel de “billability”, algo que no sólo puede perjudicar al recurso sino también al mismo gerente (problemas de utilización y
productividad). Otro tema importante es la no disponibilidad de los recursos claves (algo frecuente en los proyectos de alta tecnología).
La demanda puede ser superior a la oferta y los planes suelen subestimar el tiempo requerido para adquirir estos recursos, lo mismo
que el tiempo necesario para organizar el grupo (“team building”).
5 - Estimación en los Proyectos: las estimaciones de costos y tiempos en un proyecto constituyen la parte más difícil en la planificación,
y es más un arte que una ciencia. Como consultor tuve que realizar una revisión a un proyecto que estaba con un sobrecosto muy
elevado y querían un análisis de la causa de la variación del mismo. Mi primera pregunta fue “cuál era el método que utilizaban para las
estimaciones”, la respuesta clásica fue el proyecto tiene que estar listo para Octubre y se vendió en este precio considerando una
determinada carga de recursos. Mi segunda pregunta fue “¿si la base de estimación es una ficción, como quiere que la varianza en el
costo tenga algún significado?”. Lamentablemente muchas organizaciones venden sus proyectos de acuerdo a lo establecido por
Ventas y no tienen tiempo de realizar una estimación bottom-up o utilizar buenas técnicas de métodos cuantitativos de administración
de proyectos para al menos estimar las variaciones e incertidumbres con los buffers de contingencias necesarios. Cuanto más largos
en recursos, tiempo, costos o complejidad son los proyectos mucho más complicada resultará la realización de las estimaciones. El
Standish Group a través de sus estudios empíricos nos arroja estos resultados de éxito/fracaso de proyectos en su relación con su
tamaño y duración.
Tamaño del proyecto Personas Tiempo (meses) Porcentaje de éxito
Debajo de $750K 6 6 55%
$750K-$1.5M 12 9 33%
$1.5M-$3M 25 12 25%
$3M-$6M 40 18 15%
$6M-$10M +250 +24 8%
>$10M +500 +36 0%
Esto nos demuestra una vez más que los mega-proyectos pasaron de moda y que el desarrollo iterativo es el mejor método para
mitigar riesgos y una estrategia buena para estimar mejor el alcance, costo y tiempo de los entregables a distribuír en el proyecto.
6 - Practicar un estricto control de cambios: independientemente del tamaño del proyecto y para evitar el “Scope Creep” se deberá ser
muy riguroso en lo que respecta al control y seguimiento de los cambios al proyecto, utilizar herramientas automáticas de RM
(Requirement Management) y CM (Configuration Management). Tener muy claro el procedimiento para solicitar los cambios, el tipo de
formulario, cómo debe ser completado y el método para aprobación respectivo. Si el Gerente de Proyecto no ha definido bien el
alcance inicial del proyecto, será tremendamente difícil administrar el mismo. El propósito de la administración de cambios es proteger
la viabilidad de la definición del proyecto ya definida y aprobada. Cuando se solicita formalmente un cambio implica que dicho cambio
está fuera del alcance acordado en la definición del Proyecto o de los requerimientos o solicitudes detallados durante el análisis. Si
dicho alcance es confuso, poco claro, o deja lugar a interpretaciones, entonces el cliente dirá que el cambio está dentro del alcance, y
el Gerente de Proyecto encontrará difícil apegarse a un proceso formal de Gestión de Alcance. En algunos proyectos es posible
anticipar todas las solicitudes y requerimientos durante el proceso de análisis. No obstante lo cual, siempre podrá existir la posibilidad y
la necesidad de incorporar cambios durante el ciclo de vida. Estos cambios pueden ser muy necesarios para la solución, y pueden
existir razones poderosas de negocio por las que deberían incorporarse. El Gerente de Proyecto y el equipo de trabajo, deben
reconocer el momento en que los cambios son requeridos y deberán seguir un proceso predefinido de gestión del alcance. Este
proceso, eventualmente, proporcionará información para que el sponsor tome las decisiones pertinentes y también le permitirá decidir
si la modificación deberá aprobarse en base al valor e impacto en el proyecto en términos de costo y tiempo. Debe ser claro para todas
las partes que cumplir estos nuevos requerimientos con los mismos recursos de la definición anterior, es prácticamente imposible.
7 - Buffers: incertidumbre, probabilidades: son temas que hacen a la gestión cuantitativa de los proyectos. Primero y fundamental es
necesario no mezclar (al menos sin identificar claramente) las contingencias que nos tomamos en las estimaciones con la duración
puesta a cada tarea. Esta contingencia debe ser claramente identificada y manejada para evitar el efecto de la famosa “Ley de
Parkinson”. El método de la Cadena Crítica coloca todas estas contingencias en un buffer compartido para todo el proyecto de uso
exclusivo del PM. De no utilizar este método el PMBOK® nos aconseja utilizar contingencias o buffers por las incertidumbres en las
estimaciones utilizando CPM/PERT, MonteCarlo, Varianza de la media, o simplemente un porcentaje del total de costo o tiempo
adicional. El cálculo del tamaño del buffer debe tener en cuenta muchos factores. Hablar de incertidumbre en riesgos o en las

5. estimaciones no es exactamente lo mismo que hablar de cuál sería la probabilidad de ocurrencia. En forma simple, al arrojar una
moneda existe una incertidumbre respecto de si saldrá cara o ceca. Pero no hay incertidumbre respecto de las probabilidades de que
salga cara dado que ambas tienen un 50%. Si la probabilidad de un evento se acerca más al 100% estaremos mucho más tranquilos
porque reducimos su incertidumbre, pero inevitablemente aumentaremos su rango. Por ejemplo, si tenemos una pieza mecánica que a
través de mediciones hechas durante 5 años sabemos que puede causar daños humanos en un impacto con rango del 35% al 45%
(10%) y esto no es aceptable, lo que ocurrirá es que se realizarán tareas de ingeniería para mejorar dicha pieza y reducir ese impacto
negativo. Supongamos que logramos armarla de otra forma y que ahora las probabilidades de que ocurra algo malo son del rango
entre 5% y 25% (20%). Hemos reducido significativamente la probabilidad de un accidente pero como no hay historia pasada el rango
de la incertidumbre es más alto (del 10 al 20%).
8 - Subcontratar desarrollos externos (“Outsourcing”): muchas veces he trabajado como “prime contractor” en proyectos en donde
teníamos muchos proveedores involucrados (en algunos casos, su desarrollo era más importante que el nuestro). En este aspecto son
válidas todas las recomendaciones del PMBOK® sobre adquisiciones, además de tener en cuenta todas las modalidades contractuales
y de mantener el “pari passu” (mismas condiciones de obligaciones y responsabilidades contractuales) de las cláusulas del cliente con
nuestros proveedores. En este caso me referiré a un tema muy corriente en el ambiente de IT que es la exigencia de ciertos niveles de
calidad (CMMI) que se suele requerir cuando se contrata o se hace un outsourcing. La mayoría de las empresas hoy en día pregonan
ser certificadas en CMMI. Esto es imposible dado que CMMI no es una certificación, el SEI no certifica organizaciones como el ISO o el
ITSMF, sino que autoriza a personas denominadas “lead appraisers” a conducir auditorías para determinar el grado de madurez de la
organización respecto del modelo. El SEI no confirma la certeza del nivel de madurez reportado, sino que su foco es más bien la
calidad continua de la organización, que identifique en qué nivel se encuentra y que realice todos los esfuerzos necesarios para
mejorar su calidad y hacer sus procesos repetibles.
Datos de desempeño
India Japón Estados Unidos Europa y otros Total
Número de proyectos 24 27 31 22 104
Programador LOC/MO 209 469 270 436 374
Mediana de índice por defecto/KLOC .263 .020 .400 .225 .150
El gráfico mostrado más arriba es un informe del IEEE Software que documenta un estudio sobre 104 proyectos de software en el
mundo. India es el país que proclama tener la mayoría de sus empresas con Nivel 5 de CMMI y sin embargo está en el tercer lugar en
cuanto a programas con errores (el informe incluye empresas como Motorola India, Infosys, Tata Consulting), ¿algo como para tener en
cuenta no?. No estoy desmereciendo la evaluación del modelo de madurez sino que debería preguntarse mucho acerca de cómo se
obtuvo y otras cuestiones de la empresa a contratar tales como:
•¿Cuándo fue publicado su último assessment? (dura 2 años)
•Copia de la documentación donde figura ¿qué áreas son las más fuertes y cuáles con las más débiles?.
•¿Quién desarrolló el lead assessment?
•¿Cuáles son sus planes de mejora continua?
•¿Con qué otros clientes trabaja?
Otra característica asociada a la inmadurez de nuestro mercado es el error de escuchar a un gerente decir: “esta tarea ya no
representa un problema porque la hemos subcontratado”. Esto es falso, fundamentalmente porque la inestabilidad de nuestro mercado
hace que sea muy difícil desarrollar relaciones cliente – proveedores que perduren en el tiempo. Por otro lado, esta inestabilidad y lo
pequeño del mercado generan el problema que los proveedores en gran medida sean Pymes, y éstas permanentemente deben de
tener una muy agresiva actitud de venta, sobre todo si son proveedores que dependen de la aparición de proyectos en el mercado para
tener trabajo y resulta muy difícil su evaluación porque no hay una manera simple de saber el estado en que se encuentra dicho
proveedor. Es posible analizar los contratos que tiene en ejecución, pero no es posible analizar los contratos que “están a la firma”, y
muchas veces la concreción de uno, genera mejores condiciones en las Pymes para enfrentar las negociaciones con los otros
contratos, y se produce una cascada de contratos que se firman, una cantidad de compromisos simultáneos que este proveedor tiene
que cumplir, y como generalmente no cuenta con reservas de recursos humanos ni con una planificación previa tiene como resultados
crisis de recursos y falta de cumplimiento en todos los contratos. En el caso a su vez que el contratista sub-contrate el servicio en otra
organización se le suma a la inestabilidad propia del contratista, que tiene sus crisis internas, las que potencian a la de los
subcontratistas. Cuando bajamos de nivel, nos encontramos con empresas más pequeñas, más inestables, más riesgosas y más
difíciles de predecir, con grandes inconvenientes para tomar buenas decisiones.
9 – Project Manager, Líder o Facilitador: Un Gerente de Proyecto debe desarrollar diferentes roles por lo que es importante la óptima
aplicación de sus habilidades personales. Normalmente un PM debe cumplir con su rol de Gerente pero además debe también ser el
Líder del grupo de trabajo, aspectos que tienen distintos objetivos. El lector debería conocer la importancia del proceso de “Team
Building” y cómo los grupos van madurando a lo largo del desarrollo del proyecto. Actualmente también podemos clasificar a los
equipos de trabajo conforme a su capacidad técnica y resolutiva, llegando a tener equipos de trabajo denominados de Alto Desempeño
en donde los conflictos los resuelven entre ellos, toman decisiones propias y pueden autogestionarse. En estos casos el rol del PM
más importante es el de Facilitador donde lo que prima es dejar trabajar con libertad y preocuparse más en eliminar los problemas u
obstáculos del equipo. Las características de los facilitadores son: Lideran pero no dominan; utilizan mucha escucha activa; motivan a
la participación y trabajo cooperativo; lideran con el ejemplo; mantienen al sponsor activamente involucrado pero se aseguran que no
interfiera en el trabajo; documentan al nivel necesario. Estamos hablando de gente de alta confianza y estima que demuestran carisma,
empatía, respeto y sensibilidad por el grupo de trabajo. Podemos decir entonces que otro factor clave en la gestión de los proyectos es
colocarse el sombrero adecuado teniendo en cuenta el tipo de proyecto, el team de trabajo o las circunstancias especiales que
estemos controlando.
LÍDER MANAGER FACILITADOR
Focalizado en hacer que se
haga bien el trabajo
Focalizado en lograr el trabajo
correcto
Focalizado en ayudar a la gente
en el logro del trabajo

6. Se concentra en el qué y el por
qué
Se concentra en el cómo Ayuda a la gente a concentrarse
Establece la Dirección y Metas Establece el Plan Ayuda a la gente a entender la
Dirección y Metas
Se asegura que los otros
respondan y lo sigan
Ordena a los otros a completar
sus tareas
Se asegura que los otros se
comprometan en las tareas
Inspira, motiva, incita creación
e innovación
Ejecuta, controla, gestiona,
resuelve problemas
Ayuda a la gente a resolver sus
problemas eliminando barreras
10 – Project Management Estratégico: el tema se basa en asegurarse de que todos los proyectos están estratégicamente alineados y
fueron previamente analizados por la PMO o un proceso de PPM. Se debe definir un criterio contra el cual todos los proyectos pueden
ser priorizados que incluya el impacto en las estrategias corporativas y los clientes, y confeccionar una lista de todos los proyectos, sus
metas y objetivos estratégicos. Después, tratar de identificar el criterio de éxito de los mismos y determinar el impacto esperado que
cada proyecto tendrá en la organización y sus clientes. Asignar un rango para cada proyecto cuantitativamente y determinar su nivel de
prioridad. Alinear los proyectos con los planes estratégicos corporativos y departamentales, y ejemplificar cómo la ejecución exitosa de
cada proyecto apoyará la estrategia corporativa o departamental. En ciertos casos no queda otra salida que cancelar los proyectos que
son de baja prioridad o que no están ligados al plan estratégico de la corporación o del departamento. ¿Qué se puede hacer para
implementar las mejores prácticas de Project Management Estratégico?: la retención del conocimiento es uno de los mayores
beneficios para las organizaciones ya que contribuye al aprendizaje continuo y ayuda a evitar la repetición de errores. Con objeto de
retener el conocimiento sobre la implementación efectiva de proyectos y que puedan ser pasados como lecciones aprendidas hacia
equipos de proyectos a futuro, la PMO debería tener una reunión de cierre de proyecto tan pronto como haya terminado, mientras el
conocimiento sobre la administración del mismo aún está fresco en las mentes de todos. El propósito de esta reunión es revisar qué
sucedió durante el transcurso del proyecto y qué puede aprender el equipo y la organización de lo sucedido. El sponsor del proyecto, el
responsable del proyecto y el equipo de trabajo deberán estar presentes así como cualquier recurso exterior o “stakeholders” quienes
quisieran contribuir con ideas. El resultado final de esta reunión de cierre del proyecto será la creación de un documento formal de
“lecciones aprendidas” para ser llevadas a proyectos futuros, a los gerentes y a sus equipos de trabajo. El establecimiento de
mediciones de proyectos exitosos desde el punto de vista estratégico también ayudará a proveer a la alta dirección de información
relevante y necesaria para tomar decisiones que afecten el proyecto. Por ejemplo, la presentación estratégica de las medidas del éxito
del proyecto puede convencer a la alta dirección de re-priorizar proyectos o de re-asignar recursos. Las medidas del éxito del proyecto
proveerán a la PMO de la información necesaria para que venda el impacto de la efectividad al nivel gerencial. Los criterios para el
éxito en la medición de los proyectos estratégicos deben incluir:
•La utilización de un criterio de calidad especificado.
•La habilidad para enfrentar cambios en los requerimientos.
•El número de recursos usados actualmente contra el número de recursos anticipados originalmente.
•La habilidad del proyecto para alcanzar sus objetivos y entregables específicos.
•Las encuestas de satisfacción de clientes que indican su conformismo con el producto o la entrega del servicio del proyecto.
•La puesta en producción o lanzamiento exitoso y sin problemas.
•Mediciones financieras adecuadas y dentro de los límites.
Finalmente, para las organizaciones que están considerando en definir cuál es la mejor metodología para administrar sus proyectos, o
cómo adaptar la metodología del PMBOK® a sus propias necesidades, la recomendación es considerar un buen programa de
entrenamiento de sus PM y considerar su posible certificación, que ofrezca una revisión de la metodología y las áreas claves para su
organización: costos, tiempos, riesgos, calidad, junto con una visión más amplia, crítica y realista. Otra alternativa es contratar a una
organización con consultores especializados y certificados PMP® para que colaboren en la implementación de los proyectos y realicen
la transferencia de conocimientos y prácticas necesarias.
Un plan de desarrollo herramienta de gestión que promueve el desarrollo social calidad de vida de todos los ciudadanos.
Propósito
El objetivo de este Plan de desarrollo de software es la definición de las actividades de desarrollo en términos de las fases y las
iteraciones necesarias para la implementación de un Servicio identificación de estilos de aprendizaje en grupos.
Alcance
Este Plan de Desarrollo de Software describe el plan general para ser utilizado por el equipo para desarrollar el sistema. Los detalles de
las iteraciones individuales se describen en los planes de iteración.
El plan de desarrollo de software se refiere a la metodologia de desarrollo de software, es decir, como se va a desarollar el proyecto, en
cuantas fases y describir cada una de las fases.
El plan de desarrollo de software puede ser la metodologia RUP, Merinde, entre otras.
PLAN DE FASES
Plan de Fase

7. Fecha de los hitos importantes
• Objetivo del ciclo (fase de inicio) : 21 Noviembre 2007
• Arquitectura del ciclo (final de la fase de elaboración, arquitectura completa): mediados de enero
• Capacidad operativa inicial (final de la fase de construcción): finales de marzo o principios de abril
• Fase de transición: mediados de mayo.
• Entrega del producto: finales de mayo.
Recursos humanos
• 18 personas (integrantes del grupo)
• Testeadores (voluntarios externos al grupo de desarrollo)
Fechas de los hitos secundarios
• Finales de cada mes: entrega
• Primera entrega: 20 diciembre
Iteraciones previstas
Primera iteración (Iteración de Noviembre)
• Objetivos: Requisitos, riesgos, especificación, casos de uso, glosario.
• Periodo: 20 octubre - 20 noviembre
• Estado: terminada
• Evaluación: completado. Se entiende qué va a hacer nuestra aplicación.
Segunda iteración (Iteración de Diciembre)
• Objetivos: Investigación de tecnologías, creación del primer prototipo.
• Periodo: 21 noviembre - 20 diciembre
• Estado: terminada
• Evaluación: se ha conseguido un prototipo funcional y se han actualizado los riesgos
Tercera iteración (Iteración de Enero)
• Objetivos: Fijar el modelo definitivo de arquitectura y adaptar/corregir la documentación del proyecto.
• Periodo: 21 diciembre - 18 enero
Cuarta iteración (Iteración de Febrero)
• Periodo: 19 enero - 24 febrero
• Objetivo: preparar la fase de construcción.
• Revisión de errores y problemas de diseño
• Planificar la construcción en detalle
Quinta iteración (Iteración de Marzo)
• Periodo: 24 febrero - 31 marzo
• Objetivo: comenzar la fase de construcción.
Sexta iteración (Iteración de Abril)
• Periodo: 1 abril- 30 abril
• Objetivo: Finalizar la fase de construcción.
Séptima iteración (Iteración de Mayo)
• Periodo: 1 mayo - fecha de entrega (6 de junio)

8. • Objetivo: Realizar la fase de transición.
• Probar el proyecto y corregir errores
• Ampliar el número de juegos disponibles
Fase Inicial
Introducción
•En esta fase se delimita el alcance del proyecto, para lo cual se debe:
•Identificar todas las entidades externas con las que el sistema interactuará y definir en alto nivel la naturaleza de esta interacción, lo que
implica identificar todos los casos de uso y describir unos pocos significantes.
•Establecer los criterios de aceptación, identificar los riesgos, y estimar los recursos necesarios.
•Elaborar un plan de fase que muestre los hitos más importantes.
•Comenzar a construir un prototipo ejecutable de la arquitectura, que contenga los casos de uso críticos identificados hasta el momento.
Objetivos
•Adecuación al modelo de proceso.
•Identificar los requerimientos relevantes para definir el Alcance y la Arquitectura.
•Especificar los requerimientos.
•Definir el Alcance del Sistema.
•Definir la Arquitectura inicial del sistema.
•Identificar riesgos, planificación de mitigación y contingencia de los mismos.
•Implementar prototipos que permitan resolver los riesgos técnicos identificados.
•Definición del Glosario.
•Realización de los planes Plan de Calidad, Plan de Configuración, Plan de Verificación y Validación, Plan de Proyecto.
•Evaluar la capacidad de hacer el proyecto.
Actividades críticas
•Relevar los Requerimientos
•Especificar los Requerimientos
•Priorizar los Requerimientos
•Diseñar el Sistema
•Planificar la Integración de la Iteración.
•Actividades técnicas:
•Preparar el ambiente de desarrollo.
•Auto estudio
•Implementar un prototipo que permita resolver los riesgos técnicos identificados.
•Reunión del Equipo del Proyecto
•Planificación de Proyecto
Actividades no críticas
•Planificación de Calidad
•Planificación de Configuración
•Planificación de Verificación
•Definir el Glosario
Plan de Iteración
n plan de iteración está constituido por un conjunto secuencial de actividades y tareas, cada una de las cúales tiene
recursos asignados y pùeden depender a su vez de otras tareas. Es un plan detallado, que se realiza una vez por
iteración.
El contenido de la iteración puede variar, dependiendo de la posición dentro del ciclo de vida y de la naturaleza del
proyecto. El plan de iteración incluye porciones relevantes de todas las disciplinas para cada iteración en particular. Los

9. planes de iteración por lo general muestran un planeamiento detallado de quien va a realizar una tarea/actividad de
acuerdo en conformidad a que criterios de evaluación.
Los planes de iteración durante las fases de inicio y elaboración se centran en el alcance del proyecto y en reducción
de riesgos, especialmente los riesgos de arquitectura. Durante las fases de construcción y transición, hacen énfasis en
eficiencia en el desarrollo y calidad del producto.
administracion de riesgos
efinición de estrategias que a partir de los recursos (físicos, humanos y financieros) busca, en el corto plazo minimizar las pérdidas
ocasionadas por la ocurrencia de dichos riesgos y, en el largo plazo, cumplir con la misión y visión asignada.
La Administración del Riesgo Empresarial (Enterprise Risk Management-ERM) es el proceso por el cual la dirección de una empresa u
organización administra el amplio espectro de los riesgos a los cuales está expuesto (tanto sean de mercado como operacionales) de
acuerdo al nivel de riesgo al cual están dispuestos a exponerse según sus objetivos estratégicos. Así, ya en el terreno del impacto de la
TI sobre este tema, la evaluación de riesgos y vulnerabilidades ayuda a identificar y evaluar los riesgos operativos, poniendo énfasis en
los activos de IT físicos y lógicos, pudiendo incluir una revisión de las instalaciones y la seguridad de los elementos lógicos y físicos.
Uno de los desafíos claves es recolectar y analizar numerosos datos (de acuerdo al rango de riesgos definido), así Riesgos,
Conformidad a Normas y Funciones de TI enfrentan la paradoja de tener que disponer de mayor volumen de datos de los sistemas
corporativos para contar con más información dinámica y compleja, pero al mismo tiempo seguir manteniendo los costos de
implementación y los riesgos bajo control. De esta manera, se obtiene una mayor comprensión de las exposiciones que suponen los
mayores riesgos en la interrupción de su empresa, de modo que se puedan implementar las técnicas de mitigación apropiadas.
Desafíos
A medida que dependen cada vez más del continuo funcionamiento de los sistemas de información, las empresas actuales enfrentan
una creciente exposición a los riesgos informáticos. En el mundo actual, hasta la máxima dirección está preocupada por los riesgos
informáticos, ya que la tecnología informática claramente sostiene cada proceso comercial de la empresa.
Los riesgos informáticos típicos incluyen pérdida de productividad o negocios debido al tiempo de inactividad, responsabilidad por
brechas de seguridad que exponen la información de los clientes, multas por violaciones de normas y la imposibilidad de defenderse de
demandas debido a la conservación inadecuada de registros. No todos los riesgos provienen de sucesos inevitables, como una
inundación o un terremoto. Muchos de los riesgos informáticos son provocados por contratiempos operacionales, procesos
inadecuados, mayores requisitos normativos u otros factores más controlables.
Soluciones
Para evitar ello, es preciso combinar un conjunto de las mejores prácticas que se desprenden de numerosas organizaciones, grandes y
complejas, para hacer frente a los riesgos informáticos de sus entornos a los efectos de poner en marcha una administración de
riesgos informáticos efectiva mediante priorizar y planificar opciones de mitigación, calcular los impactos comerciales de los riesgos
informáticos, diseñar soluciones, alinear los riesgos informáticos y los costos con la empresa para optimizar las inversiones y construir
una capacidad unificada para administrar los riesgos informáticos de manera continua.
Beneficios
Permite identificar los activos empresariales que están en máximo riesgo, valuar las vulnerabilidades y los impactos potenciales, y
proponer resguardos y tácticas de mitigación, lo que permitirá:
• Priorizar y establecer niveles de riesgo para sus procesos y recursos empresariales críticos.
• Pasar de un enfoque de mitigar el riesgo a prevenir proactivamente las fallas.
• Tomar decisiones más informadas sobre cómo proteger su empresa.
• Evaluar las tácticas y los costos de la administración de riesgos relacionados con los diferentes niveles de protección.
• Prepararse adecuadamente para las auditorías de las agencias de control
Problemas que se atacan
• Identificar eventos o amenazas que podrían tener impacto en la continuidad de las operaciones empresariales, en la imagen o en la
reputación de la marca, y la probabilidad de que ocurran.
• Realizar un análisis detallado de amenazas o establecer planes de avance para mitigar riesgos.
• Determinar cómo las nuevas iniciativas empresariales o la nueva tecnología tendrán impacto en la empresa.
• Establecer planes de avance para mitigar riesgos.
• Identificar las exposiciones con respecto al cumplimiento reglamentario.
Un importante Estudio identifica los mitos comunes que contribuyen a las fallas de TI
Symantec dio a conocer en enero su Informe de Administración de Riesgos de TI, Volumen II, el cual revela que la administración de
riesgos de TI está cobrando más importancia, pero también menciona que siguen existiendo algunos mitos sobre el tema.
Aún cuando los resultados muestran que los profesionales están adoptando un enfoque más equilibrado que incluye riesgos de
disponibilidad, seguridad, cumplimiento y desempeño, los malos entendidos de la administración de riesgos de TI pueden producir
fallas potenciales y, como consecuencia, impactar la continuidad del negocio.
El informe también indica que los problemas en los procesos generan más de la mitad de los incidentes de TI, mientras que el
departamento de TI generalmente da poca importancia a la frecuencia con que se presentan los incidentes de pérdida de datos. El
informe está basado en el análisis de más de 400 encuestas realizadas a profesionales de todo el mundo, en el que se identifican
importantes aspectos, tendencias y análisis al tiempo que disipa los cuatro mitos asociados a los riesgos de TI, entre los cuales están:
1.- La administración de riesgos de TI está enfocada sólo en la seguridad Contrario a las percepciones tradicionales que
generalmente asocian los riesgos de TI con los riesgos de seguridad, los resultados de la encuesta muestran el surgimiento de una
visión más amplia entre los profesionales de TI. Un 78% de los participantes calificaron los riesgos de disponibilidad como “críticos” o
“graves”, mientras que los riesgos de seguridad, de desempeńo y de cumplimientos obtuvieron una calificación de 70, 68 y 63%
respectivamente.
2.- La administración de riesgos de TI es un proyecto El mito de que el control de riesgos de TI se puede realizar en un sólo
proyecto o incluso como una serie de ejercicios puntuales por periodos o ańos de presupuestos, desconoce la naturaleza dinámica del
entorno de riesgos internos y externos de TI. La administración de riesgos debe verse como un proceso continuo para mantener la
estabilidad ante el cambiante panorama que los negocios enfrentan actualmente.
3.- La tecnología por sí sola puede manejar los riesgos de TI Los incidentes de seguridad, cumplimiento, disponibilidad y
desempeño de TI atacan a la organización moderna a una velocidad alarmante. El reporte muestra que las organizaciones más
efectivas tienen un enfoque más integral. Sin embargo, muchas organizaciones parecen estar fallando en la implementación de
controles fundamentales de riesgos.
4.- La administración de riesgos de TI se ha convertido en una disciplina formal El reporte deja claro que la administración de
riesgos de TI es una disciplina en evolución, pues se basa en la experiencia acumulada de los individuos y las organizaciones que se
van adaptando a los cambios en el ambiente de negocios y tecnología. El informe reveló una mayor comprensión entre los
profesionales sobre cómo la administración de riesgos de TI incorpora elementos de manejo de riesgos en la operación, control de
calidad y gobernabilidad de las mismas.

10. identificacion de riesgos
El proceso mediante el cual se reconoce que existe un riesgo y se definen explícitamente sus causas y características.
Identificación del riesgo
Se deben identificar los riesgos relevantes que enfrenta un organismo en la persecución de sus objetivos, ya sean de origen
interno como externo.
La identificación del riesgo es un proceso iterativo, y generalmente integrado a la estrategia y planificación. En este proceso
es conveniente "partir de cero", esto es, no basarse en el esquema de riesgos identificados en estudios anteriores.
Su desarrollo debe comprender la realización de un "mapeo" del riesgo, que incluya la especificación de los dominios o
puntos claves del organismo, la identificación de los objetivos generales y particulares, y las amenazas y riesgos que se
pueden tener que afrontar.
Un dominio o punto clave del organismo, puede ser:
• un proceso que es crítico para su sobrevivencia;
• una o varias actividades que sean responsables de la entrega de porciones importantes de servicios a la
ciudadanía;
• un área que está sujeta a Leyes, Decretos o Reglamentos de estricto cumplimiento, con amenazas de severas
puniciones por incumplimiento;
• un área de vital importancia estratégica para el Gobierno (ejemplo: defensa, investigaciones tecnológicas de
avanzada).
Al determinar estas actividades o procesos claves, fuertemente ligados a los objetivos del organismo, debe tenerse en cuenta
que pueden existir algunos de éstos que no están formalmente expresados, lo cual no debe ser impedimento para su
consideración. El análisis se relaciona con la criticidad del proceso o actividad y con la importancia del objetivo, más allá que
éste sea explícito o implícito.
Existen muchas fuentes de riesgos, tanto internas como externas. A título puramente ilustrativo se pueden mencionar, entre
las externas:
• desarrollos tecnológicos que en caso de no adoptarse, provocarían obsolescencia organizacional;
• cambios en las necesidades y expectativas del ciudadano/usuario;
• modificaciones en la legislación y normas regulatorias que conduzcan a cambios forzosos en la estrategia y
procedimientos;
• alteraciones en el escenario económico que impacten en el presupuesto del organismo, sus fuentes de
financiamiento y su posibilidad de expansión.
Entre las internas, podemos citar:
• la estructura organizacional adoptada, dado la existencia de riesgos inherentes típicos tanto en un modelo
centralizado como en uno descentralizado;
• la calidad del personal incorporado, así como los métodos para su instrucción y motivación;
• la propia naturaleza de las actividades del organismo.
Una vez identificados los riesgos a nivel del organismo, deberá practicarse similar proceso al nivel de programa y actividad.
Se considerará, en consecuencia, un campo más limitado, enfocado a los componentes de las áreas y objetivos claves
identificadas en el análisis global del organismo. Los pasos siguientes al diagnóstico realizado son los de la estimación del
riesgo y la determinación de los objetivos de control.
evaluacion de riesgos
Evaluación de riesgo) Evaluación de riesgo es uno de los pasos que se utiliza en un proceso de gestión de riesgos. …
Evaluación de riesgo es uno de los pasos que se utiliza en un proceso de gestión de riesgos. El riesgo R se evalúa
mediante la medición de los dos parámetros que lo determinan, la magnitud de la pérdida o daño posible L, y la
probabilidad p que dicha pérdida o daño llegue a ocurrir.
La evaluación de riesgo es probablemente el paso más importante en un proceso de gestión de riesgos, y también el paso más difícil y
con mayor posibilidad de cometer errores. Una vez que los riesgos han sido identificados y evaluados, los pasos subsiguientes para
prevenir que ellos ocurran, protegerse contra ellos o mitigar sus consecuencias son mucho más programáticos.
Parte de la dificultad en la gestión de riesgos es que la medición de los dos parámetros que determinan el riesgo es
muy difícil, por lo cual se dice que es un proceso subjetivo. La incertidumbre asociada a la medición de cada uno de los
dos parámetros (L y p) es por lo general grande. La gestión de riesgo también sería más simple si fuera posible contar
con una única métrica que refleje en la medición toda la información disponible. Sin embargo esto no es posible, ya
que se trata de medir dos cantidades. Un riesgo con gran magnitud de perdida o daño y una baja probabilidad de
ocurrencia debe ser tratado en forma distinta que un riesgo con una reducida magnitud de perdida o daño y una alta
probabilidad de ocurrencia. En teoría los dos riesgos indicados poseen una idéntica prioridad para su tratamiento, pero
en la práctica es bastante difícil gestionarlos cuando se hace frente a limitaciones en los recursos disponibles,
especialmente tiempo para llevar a cabo el proceso de gestión de riesgo.
Matemáticamente se expresa:

11. En el campo de las decisiones financieras, tales como seguros, las pérdidas por lo general se expresan como
cantidades de dinero. Cuando la evaluación de riesgos se utiliza para decisiones relacionadas con la salud pública o el
medio ambiente, existen diferentes opiniones sobre si la pérdida debe ser cuantificada en dinero o alguna medida
numérica asociada a la calidad de vida. Por lo general en el campo de las decisiones en temas de salud pública o
medio ambiente, el término de pérdida se expresa como una descripción del resultado o daño causado, como por
ejemplo el incremento en la frecuencia de cáncer o de defectos genéticos en los nacimientos. En dicho caso, el "riesgo"
se expresa como: 2 una y dos
Si la evaluación de riesgos toma en cuenta información relacionada con la cantidad de personas expuestas, entonces
se lo denomina riesgo colectivo y se expresa en unidades de aumento esperado de casos durante un dado período. Si
la evaluación de riesgos no tiene en cuenta la cantidad de individuos expuestos, entonces se habla de riesgo
individual y el mismo se expresa en unidades de probabilidad de ocurrencia durante un dado período. El riesgo
colectivo es más utilizado en análisis de relaciones de costo-beneficio; mientras el riesgo individual es más utilizado
para evaluar si los riesgos a que son sometidos los individuos son "aceptables".
Evaluación de riesgos en proyectos de ingeniería[editar]
Identificación de riesgos en proyectos de ingeniería[editar]
El proceso de identificación de riesgos inicialmente se enfoca en detectar cuales son las fuentes principales de riesgo.
Para ello se pueden emplear distintas metodologías tales como: sesiones de discusión e intercambio de ideas entre los
participantes en un proyecto, análisis de datos históricos obtenidos durante la realización de proyectos de
características similares, o listas de revisión de proyectos de ingeniería junto con revisiones por personal con
experiencia específica en este tipo de emprendimientos.1
No es posible identificar absolutamente todos los riesgos posibles, y aún si se pudiera sería de muy poca ayuda. Ni
tampoco es posible saber si todos los riesgos conocidos han sido identificados; pero no es este el objetivo del proceso
de identificación de riesgos. Lo que en realidad se persigue es poder identificar las probables contribuciones al riesgo
de un proyecto que tienen mayor impacto sobre el éxito o no del proyecto y mayor probabilidad de ocurrencia.2
Es conveniente para mayor claridad agrupar los riesgos en grupos de acuerdo por ejemplo a cual sea su origen o la
entidad primariamente responsable por ellos. Por ejemplo: riesgos del dueño, riesgos del diseñador, riesgos del
entorno político, riesgos regulatorios, fuerza mayor, riesgos por subcontratistas,.....2
Como elaborar un plan de administracion de riesgos para librarte de riesgos excesivos
Un plan de administracion de riesgos y estrategia básicos puede ayudar a mucha gente como tú a estar preparado
para los eventos esperados e inesperados a lo largo de la vida.
Para elaborar este plan debes utilizar una herramienta denominada Matriz de Riesgos. Esta herramienta te brinda un
entendimiento claro de las situaciones, los problemas que podrías tener y las soluciones para esas circunstancias, todo
este esquema se presenta de un modo sencillo.
Puedes remitirte a la Matriz de Riesgos seleccionando los riesgos por categorías e inmediatamente esto te dará un
panorama claro de la probabilidad de ocurrencia, las consecuencias en caso de que este evento ocurra, cómo
minimizarlo o evitarlo, transferirlo o retenerlo. Algunos riesgos pueden involucrar un efecto económico pequeño si los
retienes.
Matriz de Riesgos
Tu plan de administracion de riesgos esta por lo tanto detallada en esta herramienta. Las soluciones que planteas
deben estar bien alineadas con tus riesgos de manera tal que si un evento este contemplado el plan funcione. La
Matriz de Riesgos es una herramienta simple pero funciona eficientemente.
Esta es la herramienta que alinea tus objetivos con tu plan de acción y un ejemplo de su uso:
Objetivo Area relacionada Riesgo
¿Tienes algún
control? ¿Cúal?
Probabilidad de
ocurrencia
Acciones para mitigar el
riesgo

12. Reducir mis
deudas a
$us1.000
hasta fin de
año
Administración de
deudas
Que mis gastos
se incrementen
y que no pueda
pagar mis
deudas
Actualmente no
tengo control
Moderado
Elaborar un presupuesto y
compararlo mensualmente
con mi estado de ingresos y
gastos
Que puedes hacer con tus riesgos?
En general, tienes cuatro opciones para considerar en tu plan de riesgos:
1.Evitar riesgos.- muchos riesgos pueden ser evitados hoy en día si se realiza una adecuada planificación.
Haciendo una evaluación de riesgos antes de invertir tu dinero puedes saber si la operación en general
representa un riesgo alto, moderado o bajo.
2.Reducir riesgos.- la probabilidad de ocurrencia de un evento puede ser reducida por ejemplo incrementando
las medidas de seguridad en tu casa o incrementando las medidas de seguridad contra incendios lo cual
puede reducir los riesgos que tú o tu casa enfrentan.
3.Retener riesgos.- Existen riesgos muy pequeños como para ser considerados en el plan de administración
de riesgos y que no necesitarían seguro. Existen riesgos cuya posibilidad de ocurrencia es baja, nula o incluso
si suceden pueden ser afrontados fácilmente.
4.Transferir riesgos.- existen riesgos que pueden costarte demasiado, como por ejemplo si alguien de tu
familia resulta herido, esto puede costarte muchísimo en términos de gastos médicos. En este caso, transferir
estos riesgos a una compañía de seguros es la mejor opción a considerar en tu plan de administracion de
riesgos.
Cuando enfrentas una crisis financiera, inmediatamente te causa estrés y te ves imposibilitado de pensar claramente
por ello. Es en estos casos que el plan de administracion de riesgos es una estupenda ayuda porque te ayuda a
enfrentar una crisis financiera. El proceso de administración de riesgos te ayuda a crear un colchón y reservas que
puedes necesitar en tiempos difíciles.
Administración de la configuración del software
La Administración de la Configuración del Software (SCM) es la disciplina de identificar la configuración de un sistema en distintos
puntos en el tiempo, con el propósito de controlar sistemáticamente cambios en la configuración del software y mantener la integridad y
la rastreabilidad de la configuración a través del ciclo de vida del sistema. Esta área del conocimiento incluye seis subáreas.
La primera subárea es la administración del proceso de SCM. Cubre los tópicos del contexto de la organización para SCM, las
restricciones y las guías para SCM, planeando para SCM, el plan mismo del SCM y la vigilancia del SCM.
La segunda subárea es la identificación de la configuración del software, la cual identifica los elementos que se controlarán, establece
esquemas de identificación para los elementos y sus versiones, y establece las herramientas y las técnicas que se utilizarán en la
adquisición y manejo de los artículos controlados. Los tópicos en esta subárea son, primero la identificación de los artículos que se
controlarán y la biblioteca del software.
La tercera subárea es el control de la configuración del software, que es la administración de cambios durante el ciclo de vida del
software. Los asuntos son, primero, solicitando, evaluando y aprobando los cambios al software, y segundo, implementar los cambios al
software, y tercero, desviaciones y renuncias.
La cuarta subárea es contabilización del estado de la configuración del software. Sus tópicos son información de estado de la
configuración del software y reportes de estado.
La quinta subárea es la revisión de la configuración del software. Que consiste en revisión de la configuración funcional del software,
revisión de la configuración física del software y de revisiones en proceso de una línea base del software.
La última subárea es la administración de versiones y entrega, que cubre la construcción de software y la administración de versiones.
Configuracion Del Entorno de Desarrollo
Visión general del sistema
AL SIGM es la plataforma de Tramitación Electrónica del MINETUR, solución integral para la tramitación electrónica de
los procedimientos administrativos, que fomenta la interoperabilidad entre administraciones mediante su adaptación a
estándares de comunicación así como la reutilización de recursos e información pública.
Finalidad del documento
El objeto del presente documento es el de detallar los requisitos de configuración para establecer un entorno de
desarrollo para AL SIGM. Los requisitos de configuración expuestos en este documento se establecen en base al IDE
Eclipse.

13. Requisitos del entorno de desarrollo
Requisitos Hardware
Memoria 2 GB
Espacio libre en disco mínimo 5GB
Requisitos Software
Sistema operativo Windows XP, OpenSUSE 11, Windows 7
Servidor de aplicaciones Apache Tomcat 7.0.16
Servidor de base de datos PostgreSQL 9.0.3
Cliente de base de datos pgAdmin III 1.12
Gestor de documentos LibreOffice 3.3 o superior, escuchando en el puerto 8100
IDE Eclipse 3.6 Helios o superior
Máquina virtual Java JDK 1.5 para compilar, 1.6 para Apache Tomcat
Requisitos de instalación
•Base de datos: Se deben crear los esquemas de base de datos correspondientes siguiendo las indicaciones del
documento SGM_2012_*_Manual Instalación AL SIGM.doc.
•Servidor de aplicaciones: el servidor de aplicaciones Apache Tomcat se debe configurar siguiendo las indicaciones del
documento SGM_2012_*_Manual Instalación AL SIGM.doc.
•Gestor de documentos (LibreOffice): se debe configurar siguiendo las indicaciones del documento
SGM_2012_*_Manual Configuración LibreOffice 3.3.doc.
Configuración del IDE
Máquina virtual Java (JVM)
Se requiere la versión 1.5 o superior de JDK para la ejecución del IDE Eclipse 3.4 Helios.
Directorio del espacio de trabajo (workspace)
Después de haber instalado, el IDE Eclipse, se debe ejecutar una primera e introducir el directorio del espacio de
trabajo (workspace) para los proyectos de AL SIGM.