TEMA 3.

METODOLOGÍAS DE CONTROL DEL PROYECTO TECNOLÓGICO

¿Cómo estudiar este tema?

Para estudiar este tema han de entenderse en su totalidad los conceptos descritos a continuación,
así como realizar las lecturas complementarias sugeridas. Estas lecturas ayudan a entender y
clarificar el material didáctico desarrollado en los siguientes apartados.

Este tema sirve de puente entre la fase de DISEÑO y PLANIFICACION de un proyecto y la fase final
de EJECUCIÓN. A lo largo de este tema se pretende que el alumno asimile los conocimientos
necesarios para entender lo que significa “controlar un proyecto”. 

Una vez estudiado el material didáctico, leídas las lecturas recomendadas y realizadas las
actividades del tema “La gestión del control del proyecto” el alumno deberá:

 Tener claro lo que significar controlar un proyecto.

 Conocer los principios de un sistema de control de proyectos.

 Aprender la técnica de control del “Valor del Trabajo Realizado”.

 Comprender por qué se realizan cambios, el significado de un cambio en el proyecto y

cómo gestionarlos y reducirlos.

 Entender lo que es un Plan de Gestión de la Configuración y los principios de

gestión de los entregables.

 Conocer las fuentes de riesgo del proyecto y la operativa elemental para

gestionarlos y elaborar un plan de respuesta.

 Entender que los problemas son compañeros habituales en los proyectos y cómo debe ser
su gestión operativa.

 Entender el significado de la calidad del proyecto como uno de los factores críticos de
éxito.

 Conocer las técnicas recomendadas para gestión de la calidad.

¿Qué es controlar un proyecto?

Lo que se entiende por controlar un proyecto

Con controlar un proyecto nos estamos refiriendo a la

implementación de las técnicas necesarias para mantener el
proyecto alineado con sus objetivos.

Este control debe realizarse teniendo en cuenta todas las dimensiones de los

factores críticos de éxito: coste, plazo, alcance y calidad.
 Se trata de poder evaluar en cualquier punto de la vida del proyecto, cómo
estamos en relación a la planificación efectuada al inicio de los trabajos.

¿Qué es controlar un proyecto? (II)

Principios fundamentales de control

Los principios fundamentales del control de proyectos son:

 La prevención: se trata de evitar en la medida de lo posible la aparición de problemas.

Para ello resulta fundamental una buena planificación, un sistema de control apropiado y
una buena comunicación.
 Detección: hablamos de implementar un sistema de identificación de riesgo y variaciones
del proyecto que permita identificarlos en una fase temprana.

¿Qué es controlar un proyecto? (III)

 Acción: una vez detectada una variación o un riesgo que se ha transformado en un
problema, se trata de pasar a la acción en alguna de sus formas más comunes:
o Acciones correctivas.

o Procedimientos de control del cambio.

 o Lecciones aprendidas que se transforman en un recurso de prevención tanto del
proyecto actual como de futuros proyectos.

Consejos y recomendaciones de control de proyectos

A continuación, se enumeran una serie de consejos y recomendaciones a tener en

cuenta para el control efectivo de proyectos (a tener en cuenta en la fase de
planificación para su implementación en la fase de ejecución).
Realizar reuniones periódicas de estado del proyecto

Mantener reuniones periódicas en donde se expongan y analicen los informes y

las medidas de control implementadas.

Combinación de hitos de control y revisiones

 Los hitos de control predefinidos son puntos fundamentales para evaluar la marcha del

proyecto: permiten revisar riesgos y problemas, cumplimiento del calendario, objetivo,
presupuesto,…
 Las revisiones permiten asegurar el cumplimiento de los estándares de calidad fijados y
contrastar las expectativas sobre los entregables del proyecto.
Diseñar paquetes de trabajo pequeños
Los paquetes de trabajo pequeños tienen la ventaja de que las estimaciones de
rendimiento y los trabajos encomendados son más precisos y el control de
cumplimiento más sencillo.

El rigor del sistema de control depende del nivel de riesgo y del presupuesto del
proyecto
Así, cuanto menor sea el nivel de riesgo y/o el presupuesto del proyecto, más
sencillo será el sistema de control.

El control debe realizarse a partir de una línea base

Resulta fundamental establecer una línea base que sirva como punto de
comparación para el control del proyecto. Se trata de establecer un escenario
inicial con el valor de todos los indicadores contemplados. Esta línea base se
puede construir con información primaria (“ad hoc”) o secundaria procedente de
eventos documentales de la propia empresa o de terceros.

No se trata de evitar los cambios sino de gestionarlos adecuadamente

El control de un proyecto no supone evitar los cambios a toda costa, sino de
gestionarlos adecuadamente.

¿Cómo es la cultura organizativa?

En función de cómo sea la cultura organizativa se diseñará la implementación de
los procedimientos de control.

Regla del 15% del punto de finalización

 Como resultado de un estudio sobre 800 proyectos realizados por el departamento
de defensa de Estados Unidos desde 1.977, se comprobó que el resultado de un
proyecto no superaba nunca el rendimiento medido cuando había transcurrido un
15% de su desarrollo.

Es muy importante establecer un criterio claro de finalización

Tiene que quedar claro los criterios bajo los cuales sabremos que un entregable,
una tarea, o el propio proyecto se han acabado. Se trata de evitar el síndrome de
“está acabado al 90%”.

Establecer “umbrales de escalada”

Se trata de establecer qué umbrales de problemas y variaciones son gestionados
por el equipo del proyecto y por la dirección. Normalmente se utilizan en %. Así
por ejemplo si la variación en sobrecoste pasa del 10% se implica a la dirección.
En general esta técnica sirve para definir los niveles de tolerancia a partir de los
cuales es necesario implicar a un nivel superior de dirección.

Metodología de control de proyectos:

Gestión del Valor Ganado o Earned
Value Management (EVM)
Independientemente de la metodología de control que se establezca, los principios
a tener en cuenta son los siguientes:
 La evaluación del estado del proyecto debe realizarse a partir de una línea base de
rendimiento.
 La metodología de control que utilicemos debe permitir:
o Conocer nuestra posición en relación a los factores críticos de éxito: coste,
alcance y tiempo.
o Identificar las variaciones y la causa de las mismas.

o Evaluar el cumplimiento y realizar previsiones de calendario.

 Es importante mantener y establecer una frecuencia de informes de estado apropiados al
proyecto (según complejidad del mismo y necesidades de información para la toma de
decisiones).
 El informe de estado debe permitir identificar los riesgos potenciales, los problemas
encontrados y los cambios necesarios.

El método de control habitualmente empleado para el control de proyectos es el

denominado Método de Gestión del Valor Ganado o Earned Value
Management (EVM). Esta es la metodología de control propuesta por el PMI en su
famosa guía de gestión de proyectos, el PMBOK.
 El Método de Gestión del Valor Ganado según el PMBOOK, “es
un método objetivo para medir el desempeño del proyecto en lo
referente a los factores críticos de éxito de alcance, tiempo y
costes”.

Metodología de control de proyectos:

Gestión del Valor Ganado o Earned
Value Management (EVM) (II)
En la práctica integra el alcance, el cronograma y los costos en un gráfico de
evolución, permitiendo realizar una detección precoz en las variaciones del
rendimiento. El PMI publicó el estándar del método como práctica para la dirección
de proyectos en 2005.

El método se basa en las siguientes premisas:

 El proyecto tiene una línea de base de calendario y presupuesto. Esa línea base
representa la estimación de presupuesto para cada periodo de tiempo (ej. semanas o
meses). Por ejemplo, imaginemos un proyecto de desarrollo de software con la siguiente
línea base de coste:

Meses 1 2 3 4 5 6 Total

Línea
base de
23.000 € 15.000 € 16.000 € 19.000 € 20.000 € 22.000 € 115.000 €
coste del
proyecto

 Según esta tabla, el proyecto se ha estimado que será realizado en 6 meses con un coste
total (presupuesto) de 115.000€, pero el coste no se distribuye de forma lineal a lo largo
de los meses, sino que hay meses que el coste previsto es mayo, por ejemplo, en el mes
1, y en otros mucho menor, como en el caso del mes 2.

  El trabajo total se puede dividir en tareas o paquetes de trabajo. Cada tarea o paquete de
trabajo tiene un valor planificado en cada periodo de tiempo. En el ejemplo presentado en
el apartado anterior, dado que es de desarrollo de software, podríamos tener una división
de la línea base de coste similar a la siguientes:

Meses 1 2 3 4 5 6 Total

Tarea 1 8.000 € 2.000 € 2.000 € 1.000 € 1.000 € 0€ 14.000 €

Tarea 2 5.000 € 3.000 € 3.000 € 3.000 € 3.000 € 2.000 € 19.000 €
Tarea 3 10.000 € 5.000 € 5.000 € 6.000 € 6.000 € 5.000 € 37.000 €
Tarea 4 0 € 3.000 € 3.000 € 5.000 € 5.000 € 7.000 € 23.000 €
 Tarea 5 0 € 2.000 € 3.000 € 4.000 € 5.000 € 8.000 € 22.000 €
Total
23.000 € 15.000 € 16.000 € 19.000 € 20.000 € 22.000 € 115.000 €
por mes

 El valor planificado es el coste estimado (presupuestado) del trabajo programado para

completar la tarea o paquete de trabajo en el calendario. Cada una de las casillas de las
tablas expuestas en el ejemplo es un valor planificado.
 El proyecto tiene un valor acumulado en cualquier punto de su ejecución: este valor
acumulado es el coste presupuestado de trabajo realmente completado (no en costes
reales). Si tomamos como referencia la tabla de valores planificados del ejemplo, para la
Tarea 2 en el mes 3 existe un valor acumulado de 11.000 € (5.000 € + 3.000 € + 3.000 €).
 Permite comparar los costes presupuestados con los reales en relación al trabajo
completado.
 La mayor utilidad del método reside en su capacidad para hacer un seguimiento sobre
la duración y el presupuesto de las tareas o del proyecto completo: si están durando
más de lo que deberían (variación en el calendario) o si requieren un esfuerzo mayor de
trabajo para completarse (variación en el coste). Además, es posible hacer proyecciones
de tiempo y coste para saber si, según el rendimiento en periodo determinado, se estima
que el proyecto al final va a tener retraso/adelanto o sobrecoste.

Según lo explicado las variables a tener en cuenta son las siguientes (utilizaremos

los nombres de las variables en inglés tal y como está definido en el PMBOK):

Elemento Definición  y  observaciones

BAC: Presupuesto Es el coste o presupuesto previsto para el total del

a la conclusión proyecto. También es conocido como: Presupuesto a
(Budget At la Terminación, Presupuesto Final o Presupuesto
Completion) hasta la Terminación.
Coste previsto presupuestado según la línea base de
coste, es decir, según la previsión de coste del
proyecto en cada periodo del mismo. Por lo tanto,
PV: Valor tendremos valores de PV para, por ejemplo, cada
planificado semana o mes del proyecto. Esto es normal porque
(Plan Value) los costes de un proyecto no suelen ser lineales, es
decir, no gastamos lo mismo todas las semanas o
meses. Por consiguiente, el BAC es la suma de todos
los PV.
Coste real devengado del trabajo realizado hasta un
determinado momento del proyecto. No es un coste
AC: Coste real
estimado como el PV, sino un coste real. También en
(Actual Cost)
este caso tendremos valores de AC para cada
periodo del proyecto.
EV:  Valor Ganado Es el costo presupuestado del trabajo realmente
(Earned Value) ejecutado. Sirve para medir el avance del trabajo
realmente realizado para cada periodo del proyecto.
 Para calcularlo no es necesario conocer el coste real,
pero sí el porcentaje de avance real para cada
periodo del proyecto (control de avance, en cuyo
caso, para un periodo n:
 EV = BAC · % avance real en el periodo n.

Para analizar los desvíos de costos se debe comparar el valor ganado (EV) con el
costo real (AC) a través de los siguientes elementos y fórmulas:

Elemento Definición  y  observaciones

Este valor calcula la desviación que tenemos sobre el

SV:  Variación del
calendario del proyecto (positiva o negativa) en un
Cronograma
determinado periodo respecto a la estimación de la
(Schedule Variance)
línea base. Se calcula como: SV = EV – PV
Este indicador nos permite saber si vamos por
SPI: Índice de encima (sobrecostes) o por debajo del presupuesto
desempeño del estimado. Se calcula como:  
cronograma SPI = EV / PV
(Schedule Si SPI > 1 el proyecto va bien (con adelanto)
Performance Index) Si SPI = 1 el proyecto va según lo planificado Si SPI
< 1  el proyecto va mal (retrasado)

Por último, es posible utilizar técnicas de proyección para reestimar de forma

periódica cuál será el costo y el calendario estimado a la finalización del proyecto y
así poder prever con anticipación si hay desviaciones importantes de coste y
tiempo.

Respecto a las proyecciones de costo, teniendo en cuenta el BAC o presupuesto

planificado del proyecto, se puede calcular:

Elemento Definición  y  observaciones

EAC:  Estimación a la Este valor es una estimación del presupuesto del proyecto

Conclusión teniendo en cuenta los costes reales ejecutados hasta el
(Estimation At momento. Se puede calcular de varias formas,
Completion) dependiendo de cómo consideremos que se va a comportar
el proyecto desde el periodo analizado hasta la
finalización:

a. Proyección de costo según presupuesto original. Supone

que el costo del trabajo restante se mantendrá según se
había presupuestado:
EAC = AC + (BAC – EV)
b. Proyección de costo según CPI actual. Supone que los
 desembolsos futuros se mantendrán con el mismo nivel de
eficiencia/ineficiencia que hasta el momento:
EAC = BAC / CPI
c. Proyección de costo considerando el CPI y el SPI.
Supone que los costos futuros dependerán de la
ineficiencia actual del CPI y el SPI, ya que los retrasos en
el cronograma afectarán también los costos:
EAC = AC + ((BAC – EV) / (CPI x SPI))
d. Proyección de costo en base a una nueva estimación.
Una forma más precisa, pero también más lenta y costosa,
de estimar los costos a la conclusión sería de la siguiente
forma:
EAC = AC + Nueva estimación de los costos faltantes

Elemento Definición  y  observaciones

Se utiliza para estimar cuánto debemos ajustar los fondos

restantes de costos para cumplir con el presupuesto
aprobado/previsto (el BAC). Puede calcularse de dos
TCPI:   Índice de
formas:
desempeño del trabajo
TCPI = (BAC – EV) / (BAC – AC)
por completar
TCPI = (BAC – EV) / (EAC – AC)
(To Conclude
Si TCPI > 1 es malo porque estamos gastando más de lo
Performance Index)
previsto.
Si TCPI < 1 es bueno porque tenemos holgura para gastar
más de lo previsto.

Ejemplo: Tomemos como caso de ejemplo el proyecto de desarrollo de software

planteado previamente en este apartado, cuya duración estimada es de 6 meses y cuyo
costo total estimado de 115.000 €, siendo los valores planificados y acumulados para
cada mes los siguientes:

Meses 1 2 3 4 5 6 Total

Línea base
de coste del
23.000 € 15.000 € 16.000 € 19.000 € 20.000 € 22.000 € 115.000 €
proyecto
(PV)
Valores
acumulados 23.000 € 38.000 € 54.000 € 73.000 € 93.000 € 115.000 € 115.000 €
de PV
 Teniendo como referencia esta línea base, supongamos que el proyecto se encuentra en
el mes 3 de ejecución. Por lo tanto, tendremos mediciones reales del trabajo realizado y el
coste real hasta ese mes, que podremos utilizar para calcular indicadores que nos sirvan
para saber si vamos bien o mal respecto al presupuesto y el calendario previstos.

Las mediciones que debemos tener del proyecto son los costes reales y el % de
trabajo realmente ejecutado. En nuestro ejemplo, los valores se recogen en la
siguiente tabla:

Meses 1 2 3 4 5 6 Total

Coste real
21.000 € 18.000 € 19.000 €       58.000 €
(AC)
Valores
acumulados 21.000 € 39.000 € 58.000 €       58.000 €
de AC
Avance real
(trabajo 8 % 15 % 14 %       37 %
realizado)
Pues bien, para poder controlar el proyecto las principales preguntas que tenemos
que hacernos, en este caso en el mes 3, son las siguientes:
1. ¿El proyecto va por encima del presupuesto o por debajo?
2. ¿El proyecto va retrasado o adelantado?
3. A este ritmo de gasto, ¿cuál será la estimación de coste a final del proyecto, es decir,
¿cuál será el coste estimado del proyecto a su finalización?
4. A este ritmo, ¿finalizaré el proyecto con retraso o adelanto respecto a los 6 meses
previstos en el calendario?
Para contestar a dichas preguntas bastará con utilizar el método de Gestión del
Valor Ganado. Precisamente la actividad planteada en este tema consistirá en
aplicar dicho método a este ejercicio.
 ¿Qué se entiende por “cambios en el proyecto”? Y ¿Por qué son importantes?
La realidad es que los proyectos tecnológicos se desarrollan en un entorno
de máxima incertidumbre: su principal dificultad es que tratan de desarrollos en
materias que habitualmente no son muy conocidas y además hay pocos expertos,
por lo tanto, lo habitual es que cuando el proyecto empieza a desarrollarse se
empiecen a producir cambios.
Sirva de ejemplo mi experiencia actual en el desarrollo de un proyecto de I+D+i
sobre un prototipo de baliza medioambiental sensorizada: después de un año de
elaboración del diseño y planificación del mismo, en el momento de su desarrollo
en la fase inicial, tuvimos que decidir cambiar una de las premisas tecnológicas
sobre las que estaba basada la comunicación de datos.

Así, podríamos hablar que controlar un proyecto equivale a

gestionar los cambios.

¿Pero qué se entiende por cambio?

Se entiende por cambio cualquier variación de los factores críticos

de éxito (alcance, calendario, costes y calidad) y criterios de
aceptación del proyecto.

Se trata de gestionar estos cambios de manera controlada y de entender que un

cambio en cualquiera de estos factores afecta a los demás: cada vez que se
produzca un cambio es necesario reconocerlo o identificarlo, evaluar su impacto,
comunicar dicho cambio y realizar los ajustes en la planificación.
Tipos de cambios habituales

Habitualmente el 80% de los cambios proceden de cambios en el alcance. A

continuación, se enumeran una relación de situaciones que originan cambios en el
proyecto:

 Variaciones en el alcance, en los hitos del calendario, en los objetivos, en los costes, en el
presupuesto o en los requisitos y características del proyecto.
 Cambios en los criterios de aceptación del proyecto o en la estrategia de implementación.
 Tener que restablecer las líneas base de rendimiento.
 Variaciones en las responsabilidades del proyecto (contractuales o no).

Recomendaciones para gestionar los cambios de un proyecto

 Un sistema de gestión de cambios debe tener en cuenta los
siguientes puntos:

El proceso de control de cambios debe alinearse con los

compromisos contractuales del proyecto.
Debe centrarse en la aceptación; los implicados en el proceso deben
comprender la necesidad y deben estar de acuerdo con los planes de
acción a llevar a cabo.
Debe restablecer la línea base. Se trata de que la línea base de
rendimiento incorpore los cambios en el proyecto.
El sistema debe considerar varias rutas de proceso. Cada ruta recoge
el impacto estimado de la petición de cambio y los umbrales
negociados.

Los principios a tener en cuenta son los siguientes:

 Ya que el 80% de los cambios proceden de variaciones del alcance, veamos que
puede provocarlos:
o Una declaración de alcance ambigua o incompleta.

o Una mala definición de los requisitos (cuantos más lapsus existan más fácil será
que ocurran cambios). Entre las razones que pueden provocar una mala definición
de requisitos se encontrarían:
 No se ha considerado el proceso completo del flujo de trabajo.
 No se han buscado inconsistencias en las revisiones de los requisitos.
 Los requisitos no están alineados con el alcance.
o Cambios en la tecnología.

o Cambios en los criterios de aceptación del proyecto.

o Cambios en las condiciones de entorno de la organización tales como: nueva
reglamentación estatal (sirva de ejemplo el sector de las energías renovables),
nuevas oportunidades comerciales, financiación disponible para el proyecto.
 Por otro lado se trata de minimizar estos cambios de alcance, para ello es preciso tener
en cuenta las siguientes claves:
o Concienciar a los implicados sobre el significado de una solicitud de cambio.

o Mantener al equipo centrado en los objetivos del proyecto.

o Limitar o evitar cambios innecesarios.

 Implementar medidas de prevención, tales como:

o Establecer cierres de aceptación formales: el registro formal de revisión y
aceptación de los entregables evita o minimiza posibles conflictos.
o La definición de requisitos debe ser sólida.

o Unir especificaciones detalladas de trabajo con los objetivos de requisitos

originales.
o Acuerdo firme sobre los objetivos del proyecto y criterios de éxito.
o Comprometer de manera efectiva al equipo de trabajo con los objetivos del
proyecto.
o Utilizar una estructura de desglose de trabajo detallada para ilustrar el impacto.

 De esta manera se puede mostrar que el trabajo para la característica propuesta

nunca se había tenido en cuenta y los elementos de trabajo que se verán
afectados.
 Realizar pruebas piloto.
 Implementaciones por fases y decisiones de “sí” o “no” al final de las fases.
 Controlar el efecto “gold plating”.
 Controlar los cambios pequeños: una serie de cambios pequeños sumados
pueden terminar afectando seriamente al proyecto.
 ¿Qué se entiende por los entregables del proyecto?

Bajo este concepto se recoge el proceso bajo el cual se controlan los productos

del trabajo del proyecto: entregables, documentos de la gestión o cualquier
resultado de las actividades del proyecto.
También se le puede denominar “Gestión de la Configuración”, este proceso está
relacionado con el sistema de control de los cambios en un factor crítico (tiempo,
coste, alcance o calidad) del proyecto.

El documento de planificación del proyecto que define este

proceso recibe el nombre de “Plan de Gestión de la
Configuración”.

El problema es que en general a este aspecto de la gestión de proyecto se le da

muy poca importancia y se deja por defecto que sea el sentido común el que
marque su desarrollo. La realidad es que la falta de disciplina, el abandono y la
falta de un procedimiento claro de actuación, hace que al final la gestión de los
documentos del proyecto no funcione adecuadamente.

En definitiva se trata de establecer un procedimiento para

planificar adecuadamente la gestión de los productos del
proyecto.

Se trata de evitar las situaciones que se derivan de preguntas del tipo:

 ¿Quién ha hecho ese cambio?

 ¿Cuál era la línea base que acordamos?
 ¿Dónde está el archivo?
 ¿Seguro que lo acordamos en la última reunión?
 ¿Está seguro que teníamos la aceptación del cierre?
 ¿Estás seguro que aprobaron el cambio?
 ¿No se había decidido que la reunión pasara a ser semanal?

Básicamente los principios a tener en cuenta para establecer un plan de Gestión

de la Configuración son los siguientes:
 Identificar los productos de trabajo a monitorizar.
 Controlar quién tiene acceso al plan de Gestión de la Configuración y qué cambios puede
realizar.
 Poder realizar seguimiento sobre los cambios que se hacen sobre un producto cualquiera
de trabajo.
 En definitiva, se trata de crear un sistema para garantizar la salvaguarda de los
activos que se van generando a lo largo del proyecto.

Cómo crear un plan de Gestión de la Configuración

El plan de Gestión de la Configuración se debe definir durante el proceso de

planificación del proyecto. Este plan debe realizarse de manera coherente con el
nivel de complejidad y tamaño del proyecto a llevar a cabo.
 Como punto de partida debe establecerse el lugar donde se almacenan todos los
documentos de trabajo, como controlar el acceso y quiénes pueden acceder con distintos
niveles de actuación (consultar, modificar, aprobar,).
 Es conveniente generar plantillas para los diferentes documentos de los productos de
trabajo, por ejemplo:
o Página de título.

o Página de historial de revisión.

o Página de aprobación.

o Datos / formato estándar de la cabecera y pie de página.

 Es recomendable realizar copias de seguridad programadas.

 En la siguiente tabla se enumeran el contenido mínimo que debe

contemplar un plan de Gestión de la Configuración.
 Contenido mínimo que debe contemplar un Plan de Gestión de la
Configuración

Elemento Definición

Los productos del trabajo del proyecto que se van a

Objetivos
gestionar.         Debe ser exhaustivo.
La ubicación y definición del repositorio central del
Repositorio
proyecto.
Define la organización del repositorio del proyecto. Se
Estructura del
suele organizar por fases de proyecto y tipo de
directorio
producto de trabajo.
Convenciones Define las convenciones que se van a utilizar para
de denominar los archivos del proyecto.
denominación Como mínimo debe incluir el nombre del proyecto y el
de archivos nombre del producto de trabajo.
Enumera las herramientas de gestión de la
Herramientas
configuración que se van a utilizar en el proyecto.
Proceso y Define cómo se  introducen en el repositorio del
procedimientos proyecto los productos del trabajo y cómo se llevan a
cabo las revisiones de los mismos.
Define el proceso de revisión y aprobación para
cualquier producto del trabajo que requiere
 autorización antes de que un cambio se haga oficial.

Elemento Definición

Define las funciones principales ene l proceso de

Funciones y gestión de la configuración y lo que puede hacer
responsabilidades cada miembro del equipo.
El documentalista es una función muy importante.
Define cómo se va a informar sobre el estado de la
Información gestión de la configuración y qué medidas se
necesitan para este proyecto
Define cómo se va a auditar el proceso de gestión
Auditorías de la configuración para que se cumpla y cuándo
sucederán esas auditorias.
Fuente: Horine G (2009)

La importancia de la construcción de escenarios de riesgos del proyecto

Realmente la gestión de los riesgos es una parte fundamental del control del
proyecto, máxime cuando los riesgos al materializarse se transforman
en problemas que también hay que gestionar (los veremos en el próximo tema).

Para gestionar los riesgos tenemos que diseñar un sistema de radar que permita
identificar cualquier amenaza para el cumplimiento de los factores críticos de éxito,
y cumplir con las expectativas del cliente.

Como experiencia personal diría que se trata de generar una “paranoia saludable”,

equidistante entre una “actitud psicótica”  y una “actitud optimista”, que permita
evaluar y considerar las posibles eventualidades que pueden tener una
probabilidad cierta de materializarse en problemas.

En cualquier caso el nivel, tipo y gestión del riesgo tiene que

estar en consonancia con la importancia del proyecto y los
efectos y consecuencias que puedan acarrear.

Antes de continuar pasemos a definir algunos términos relacionados con el riesgo.

Términos relacionados con el riesgo:

Riesgo: acontecimiento incierto que podría afectar negativamente a

los factores críticos de éxito si llega a ocurrir. Se evalúa por la
probabilidad de que ocurra entre 0% y 100%
 Problema: riesgo que se materializa en problema y que podría
afectar a los factores críticos de éxito
 Defecto (de planificación o de gestión de proyecto): son fuente de
muchos riesgos desconocidos y son una discrepancia entre lo
 esperado y lo que en realidad es.
 Limitación: límite que se debe planificar y que puede implicar un
riesgo

Fuentes de riesgo más comunes

Algunas premisas a tener en cuenta:

 A medida que aumenta el tamaño y la complejidad del proyecto se multiplican

exponencialmente los niveles de riesgo.
 El 80% de todos los riesgos se originan a partir de las mismas fuentes en todos los
proyectos.
 Los factores de riesgo deben evaluarse por primera vez durante la definición del proyecto
y pueden originar tener que repetir la planificación.

 En el cuadro que figura a continuación se muestran las fuentes de riesgo

más comunes:

Categoría de la fuente de
Ejemplos / Factores
riesgo

Horas de esfuerzo.
Tiempo de calendario.
Presupuesto estimado.
Tamaño del equipo (número de recursos).
Tamaño y complejidad del Número de localizaciones.
proyecto Número de unidades de negocio.
Número de interfaces del sistema.
Número de dependencias de otros proyectos.
Número de dependencias de otros sistemas.
Grado del cambio del negocio.
Requisitos volátiles.
Normas de rendimiento no realistas o
Requisitos
intrusivas.
Requisitos complejos
Sustitución o nuevo sistema.
Impacto en las políticas empresariales.
Impacto del cambio Impacto en los procesos empresariales.
Impacto en la estructura de la organización.
Impacto en las operaciones de sistema.

Categoría de la fuente de
Ejemplos / Factores
riesgo
 Cambios en los objetivos del proyecto.
Falta de prioridades.
Falta de a poyo y aceptación por parte de la
Organización gestión del proyecto.
Financiación inadecuada del proyecto.
Mala asignación y mala gestión de los
recursos.
Falta de compromiso ejecutivo importante.
Patrocinador Falta de responsabilidad clara.
Pérdida de apoyo político.
No se ha identificado a todos los implicados.
Falta la “aceptación” de un implicado clave.
Nivel de compromiso de Las necesidades de los implicados no se han
los implicados identificado completamente.
Los implicados claves no están involucrados
del todo.
Las asunciones estimadas no se mantienen.
Calendario La contingencia del calendario no es la
adecuada.
Fuente: Horine G (2009)

Principios y operativa elementales para la gestión de los riesgos del proyecto

Como principios fundamentales a tener en cuenta se trata de

ser sistemático (cualquier factor de riesgo debe ser evaluado) continuo (proceso
repetitivo), comprometido (durante todo el ciclo de vida del proyecto)
y centrado (en los riesgos que se pueden controlar, especialmente los de alta
prioridad).
Cumpliendo estos principios podemos reducir los riesgos en un 90% según el PMI.

La operativa elemental para gestionar los riesgos pasa por los siguientes pasos
esenciales:
Plan de respuesta a los riesgos

En el siguiente cuadro se muestran diferentes opciones de respuesta a los

riesgos.

Respuesta ante los riesgos

Los problemas son parte del proyecto: causas habituales

Cuando nos movemos con la tecnología y con personas estamos en un entorno

muy dinámico donde las circunstancias son muy cambiantes. Es un caldo de
cultivo donde se producen malentendidos, asunciones equivocadas, surgen
problemas y existen muchos riesgos potenciales.

Todo esto es difícil de evitar, no sería realista ponernos un objetivo de”0”

problemas: los problemas y los riesgos son inherentes a los proyectos, el enfoque
debe ser el de aprender a identificar y gestionar este tipo de situaciones y tener
claro desde el principio los protocolos de actuación.
 Para empezar, hay que tener claro la distinción entre riesgo, problema y defecto:

 Los riesgos son problemas en potencia.

 Los problemas son acontecimientos que ya se han producido y que además

van a tener un impacto negativo sobre los factores críticos de éxito del
proyecto.

 Los defectos son problemas que han surgido de los procedimientos de

gestión de la calidad del proyecto.

En líneas generales podemos considerar que las causas de problemas potenciales

son de dos tipos: proceden de la organización o proceden del propio proyecto. A
continuación, se recoge en una tabla posibles problemas y ejemplos concretos
para cada uno de ellos.

¿Cómo deben gestionarse los problemas?

La gestión de los problemas tiene dos componentes principales:

el proceso administrativo y el propio de su gestión para
eliminarlos o mantenerlos bajo control.

Cómo debe ser el proceso administrativo de los problemas

El proceso administrativo debe contemplar los siguientes principios:
 Documentar el problema.
 Realizar un seguimiento hasta su resolución.
 El proceso en su conjunto debe estar alineado con el flujo del proyecto.
 No perder de vista el control de los costes (el coste de resolución del problema debe ser
coherente con el proyecto y las consecuencias de la no resolución).
En primer lugar debemos definir el soporte donde se va a realizar el registro y
seguimiento de los problemas. A continuación se muestra en un cuadro las
opciones de registro de problemas.

Opciones
Los campos
recomendados
de registro de Pros Contras
problemas se
muestran a
continuación

Limitado en cuanto a:
filtrado, capacidad de
Bajo coste. información, acceso  y
Sencillo visibilidad
Procesador de
textos Portátil. Pesado a medida que
aumenta el registro
Rápido
 Se necesitan procesos
manuales
 Bajo coste.
Simple.
Aprovecha la clasificación, el
Hoja de cálculo filtrado y las capacidades de Idem
información del programa de
hojas de cálculo.
Portátil

Opciones Pros Contras

Se necesita más tiempo de

Tiene en cuenta las
configuración y de
actualizaciones de múltiples
administración.
usuarios.
Base de  Aumentan los costes.
Mejor relación entre los datos.
datos
No es tan portátil.
 Mejor información.
Se puede necesitar
Refuerza el proceso
formación.

Pueden funcionar en la Web. Aumenta el tiempo de

configuración y de
Herramientas Todas las ventajas del programa administración.
de de base de datos.
colaboración  Aumentan los costes.
Mapa del flujo de proceso.
virtual Se puede necesitar
Notificaciones automáticas. formación.
Los pasos siguientes son:

 Definir cómo deben presentarse los problemas, como se van a resolver, cuando se van a
resolver y los requisitos para considerarlos resueltos.
 Asignar la responsabilidad de administrar el registro de problemas.

Los campos recomendados de registro de problemas se muestran a continuación.

Descarga el documento
La gestión operativa de los problemas
En cuanto al enfoque de gestión de los problemas hay que tener en cuenta que
sobre todo es una cuestión de enfoque, actitud y disciplina. La operativa debe
desarrollarse considerando los siguientes puntos:

 Debe haber un responsable que centralice la operativa de registro y seguimiento.

 Cada problema debe tener un único identificador.
 Intentar que el problema se resuelva en el nivel más bajo donde se ha presentado, esto
implica rapidez y un menor coste.
 Identificar la fuente del problema.
 Incluir la revisión de los problemas identificados en las reuniones periódicas de
seguimiento del proyecto.
 Los responsables asignados para la resolución del problema deben comprometerse con
una fecha consensuada por ambas partes.

La calidad como uno de los factores

críticos de éxito
 La calidad es uno de los factores críticos de éxito del proyecto y va mas allá de la
gestión de la calidad operativa contemplada en las normas de calidad industrial
(ISO 9000/1000, QS-9000 GXP, SEI/CMMI) o las metodologías de gestión tipo
seis sigma o mejora continua.

Nos aproximamos a la gestión de la calidad desde la definición

que realiza el PMI: “La calidad es la conformidad con los
requisitos y adecuación de uso”.

En este sentido los principios de la gestión de la calidad del proyecto son los

siguientes:
 No se debe dar nada por sentado, siempre es necesario realizar algún tipo de
comprobación para garantizar que el paquete de trabajo cumple con los criterios de
finalización planificados.
 Asegurarse de identificar las expectativas de calidad del cliente, habitualmente nunca se
identifican completamente y acaba convirtiéndose en un problema, además deben estar
alineadas con el enfoque general de calidad del proyecto.
 La calidad debe planificarse: debe documentarse la forma en que se va a cumplir con los
requisitos. La mejor manera para llevarlo a cabo es mediante un Plan de Gestión de
Calidad, documento que forma parte del Plan de Proyecto.

 Los requisitos deben fijarse desde el punto de vista del cliente y se deben identificar todos
aquellos que tendrán impacto en la percepción del producto final por parte del cliente.
 Nos debe quedar claro lo que el cliente entiende por calidad, la mejor manera es
preguntarlo y (otra vez) no dar nada por sentado.
 Asegurarse que el Plan de Gestión de la Calidad aprobado se está llevando a cabo,
muchas veces el “día a día” del proyecto relega a un segundo plano los aspectos de
calidad.
 Cuidado con el efecto “gold plating”, los añadidos del proyecto aumentan el riesgo y
tienen un impacto directo en los costes y el presupuesto.
 En última instancia el Director de Proyectos es el responsable de la calidad, hay que ser
conscientes que la responsabilidad final es nuestra.
 Evitar caer en el error de pensar que no podemos permitirnos el coste de un Plan de
Calidad, muchas veces las normas de calidad no se perciben como un valor añadido. Es
importante comunicar y transmitir el mensaje de que la no calidad o la baja calidad tiene
un coste mucho mayor que el coste de la prevención.
 ¿La calidad está incluida en el calendario del proyecto?, Asegurarnos que las tareas
reales relacionadas con la calidad están incluidas en el calendario del proyecto.
 ¿Se ha evaluado el impacto que los estándares de calidad tienen en el proyecto?, No se
deben aceptar a ciegas los estándares de calidad sin evaluar adecuadamente el impacto
que éstos pueden tener en los objetivos del proyecto y otros factores críticos de éxito.