Tema 3

Metodologías de control del proyecto
tecnológico
[3.1] ¿Cómo estudiar este tema?
[3.2] ¿Qué es controlar un proyecto?
[3.3] Metodología de control de proyectos: Gestión del Valor

Ganado o Earned Value Management (EVM)
[3.4] Técnicas para gestionar los cambios de un proyecto
[3.5] Los entregables del proyecto o “Gestión de la

Configuración”
[3.6] La gestión de los riesgos
[3.7] La gestión de los problemas
[3.8] La calidad como uno de los factores críticos

de éxito del proyecto
3 TEMA
Esquema
¿QUÉ ES CONTROLAR UN PROYECTO?
TEMA 3 – Esquema
EL MÉTODO DEL VALOR LA GESTIÓN DE LOS
DEL TRABAJO RIESGOS
REALIZADO
2
TÉCNICAS PARA
LA GESTIÓN DE LOS
GESTIONAR LOS CAMBIOS
RIESGOS
DE UN PROYECTO
LA CALIDAD COMO UNO DE LOS FACTORES CRITICOS DE ÉXITO DEL PROYECTO
© Universidad Internacional de La Rioja (UNIR)

Ideas clave
3.1. ¿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.
TEMA 3 – Ideas clave 3 © Universidad Internacional de La Rioja (UNIR)

3.2. ¿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.
En general se trata de dar respuesta a

preguntas del tipo:
¿Estamos de acuerdo con el calendario?
¿Vamos cumpliendo el presupuesto?
¿Qué riesgos potenciales tenemos?
¿Vamos resolviendo los problemas encontrados?
¿Están funcionando las medidas correctivas?
…/…
Principios fundamentales de control
Los principios fundamentales del control de proyectos son:
Prevención
Detección Acción

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.
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

o Los hitos de control predefinidos son puntos fundamentales para evaluar la
marcha del proyecto: permiten revisar riesgos y problemas, cumplimiento del
calendario, objetivo, presupuesto,…
o 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.

3.3. 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”.
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
coste del 23.000 € 15.000 € 16.000 € 19.000 € 20.000 € 22.000 € 115.000 €
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:
Línea base de
1 2 3 4 5 6 Total
coste
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 por
23.000 € 15.000 € 16.000 € 19.000 € 20.000 € 22.000 € 115.000 €
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

Es el coste o presupuesto previsto para el total del
BAC: Presupuesto a la conclusión proyecto. También es conocido como: Presupuesto a la
(Budget At Completion) Terminación, Presupuesto Final o Presupuesto 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, tendremos valores
PV: Valor planificado de PV para, por ejemplo, cada semana o mes del proyecto.
(Plan Value) Esto es normal porque 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 este
(Actual Cost)
caso tendremos valores de AC para cada periodo del
proyecto.
Es el costo presupuestado del trabajo realmente ejecutado.
Sirve para medir el avance del trabajo realmente
realizado para cada periodo del proyecto. Para
EV: Valor Ganado
calcularlo no es necesario conocer el coste real, pero sí el
(Earned Value)
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:

Este valor calcula la desviación en el presupuesto (positiva
CV: Variación de Costo o negativa) que tenemos en un determinado periodo
(Cost Variance) respecto a la estimación de la línea base. Se calcula como:
CV = EV – AC
Este indicador nos permite saber si vamos por encima
(sobrecostes) o por debajo del presupuesto estimado. Se
calcula como:
CPI: Índice de desempeño del costo
CPI = EV / AC
(Cost Performance Index)
Si CPI > 1 el proyecto va bien (por debajo del presupuesto)
Si CPI = 1 el proyecto va según lo planificado
Si CPI < 1 el proyecto va mal (por encima del presupuesto)
Para analizar los desvíos de tiempos se debe comparar el valor ganado (EV) con el
costo planificado (PV) a través de los siguientes elementos y fórmulas:

Este valor calcula la desviación que tenemos sobre el
calendario del proyecto (positiva o negativa) en un
SV: Variación del Cronograma
determinado periodo respecto a la estimación de la línea
(Schedule Variance)
base. Se calcula como:
SV = EV – PV
Este indicador nos permite saber si vamos por encima
(sobrecostes) o por debajo del presupuesto estimado. Se
SPI: Índice de desempeño del calcula como:
cronograma SPI = EV / PV
(Schedule Performance Index) Si SPI > 1 el proyecto va bien (con adelanto)
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:
Elementos Definición y observaciones

Este valor es una estimación del presupuesto del proyecto
teniendo en cuenta los costes reales ejecutados hasta el
momento. Se puede calcular de varias formas,
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
EAC: Estimación a la Conclusión mismo nivel de eficiencia/ineficiencia que hasta el
(Estimation At Completion) 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

Elementos 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
formas:
TCPI: Índice de desempeño del TCPI = (BAC – EV) / (BAC – AC)
trabajo por completar TCPI = (BAC – EV) / (EAC – AC)
(To Conclude Performance Index)
Si TCPI > 1 es malo porque estamos gastando más de lo
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:
Línea base de
coste del 23.000 € 15.000 € 16.000 € 19.000 € 20.000 € 22.000 € 115.000 €
proyecto (PV)
Valores
acumulados de 23.000 € 38.000 € 54.000 € 73.000 € 93.000 € 115.000 € 115.000 €
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:
Coste real (AC) 21.000 € 18.000 € 19.000 € 58.000 €
Valores
acumulados de 21.000 € 39.000 € 58.000 € 58.000 €
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.
3.4. Técnicas para gestionar los cambios de un proyecto
¿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
La creación de un sistema de gestión de

cambios permitirá:
Garantizar que las personas adecuadas están implicadas

en el proceso de toma de decisiones.
Refuerza la credibilidad del Director de Proyecto.
Evita o minimiza conflictos cuando surgen los cambios.

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.
o 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.
o Realizar pruebas piloto.
o Implementaciones por fases y decisiones de “sí” o “no” al final de las fases.
o Controlar el efecto “gold plating”.
o Controlar los cambios pequeños: una serie de cambios pequeños sumados
pueden terminar afectando seriamente al proyecto.
Para que el sistema de gestión de control de cambios sea eficaz deben

tenerse en cuenta los siguientes principios:
Con relación a los implicados:
Deben participar en el proceso de evaluación y aprobación
Pueden realizar una petición de cambio en el proyecto si

la consideran oportuna
Las solicitudes son evaluadas según su impacto en los

factores críticos de éxito
Cualquier cambio en el proyecto debe estar bien

documentado y comunicarse

Con relación al director de proyecto:
Cualquier petición de cambio debe aprobarse antes de

ponerse en marcha.
Debe velar porque las funciones y responsabilidades

estén claramente definidas y el proceso del flujo de
trabajo cumpla las necesidades de todos los implicados.
3.5. Los entregables del proyecto o “Gestión de la

Configuración”
¿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 gestionar.
Objetivos
Debe ser exhaustivo.
Repositorio La ubicación y definición del repositorio central del proyecto.
Estructura del Define la organización del repositorio del proyecto. Se suele organizar
directorio por fases de proyecto y tipo de producto de trabajo.
Convenciones de Define las convenciones que se van a utilizar para denominar los
denominación de archivos del proyecto.
archivos Como mínimo debe incluir el nombre del proyecto y el nombre del
producto de trabajo.
Enumera las herramientas de gestión de la configuración que se van a
Herramientas
utilizar en el proyecto.
Define cómo se introducen en el repositorio del proyecto los productos
del trabajo y cómo se llevan a cabo las revisiones de los mismos.
Proceso y
Define el proceso de revisión y aprobación para cualquier producto del
procedimientos
trabajo que requiere autorización antes de que un cambio se haga
oficial.
Define las funciones principales ene l proceso de gestión de la
Funciones y
configuración y lo que puede hacer cada miembro del equipo.
responsabilidades
El documentalista es una función muy importante.
Define cómo se va a informar sobre el estado de la gestión de la
Información
configuración y qué medidas se necesitan para este proyecto
Define cómo se va a auditar el proceso de gestión de la configuración
Auditorías
para que se cumpla y cuándo sucederán esas auditorias.
Fuente: Horine G (2009)
3.6. La gestión de los riesgos
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 riesgo Ejemplos / Factores

Horas de esfuerzo.
Tiempo de calendario.
Presupuesto estimado.
Tamaño del equipo (número de recursos).
Número de localizaciones.
Tamaño y complejidad del 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.
Requisitos Normas de rendimiento no realistas o 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.
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.
Las necesidades de los implicados no se han
Nivel de compromiso de 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.

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:
1º •Utilizar los “perfiles de riesgo” o “formularios de

evaluación de riesgos”.
IDENTIFICAR LOS •Los mejores perfiles de riesgo son los del sector
RIESGOS DEL industrial y tipo de proyecto en el que estamos
PROYECTO trabajando.
2º •Para cada factor de riesgo identificado evaluar el nivel

de probabilidad de que ocurra bien en una escala
DETERMINAR LA numérica (1-5, o 1-10) o cualitativa (Bajo, medio,
PROBABILIDAD alto).
3º •Igual que en el caso anterior para cada factor de

riesgo identificado evaluar su nivel de impacto en una
EVALUAR EL IMPACTO escala numérica o cualitativa.

•Para cada factor de riesgo, a partir de la probabilidad
4º de ocurrencia y de su impacto elaborar un ranking de
ESTABLECER clasificación combinando ambos valores
PRIORIDADES (multiplicando los dos valores para obtener una
puntuación final).
•Evitar.
5º •Aceptación.
DOCUMENTAR UN PLAN •Controlar y Aceptación.
DE RESPUESTA PARA •Reducción
CADA RIESGO •Transferencia
•(1) Se verá más adelante
6º
CONSEGUIR LA
ACEPTACIÓN DE LOS
IMPLICADOS Y
REALIZAR UN
SEGUIMIENTO
Plan de respuesta a los riesgos
En el siguiente cuadro se muestran diferentes opciones de respuesta a los riesgos.
Respuesta ante los riesgos Descripción

• Evitar los riesgos.
• Cambiar el plan del proyecto para eliminar los
Evitar riesgos o para proteger un objetivo y que no resulte
afectado.
• “Aceptar” las consecuencias del riesgo.
• Para enfrentarse a los riesgos, no cambiar el plan
del proyecto.
Aceptación
• No es posible identificar una estrategia de
respuesta mejor.
• Aceptar el riesgo desde el principio y controlarlo
de cerca.
Control y preparación • Desarrollar un plan de acción alternativo por si el
evento ocurre.

Respuesta ante los riesgos Descripción
• Emprender acciones para reducir la probabilidad
de que el riesgo se haga realidad.
• Emprender acciones para reducir el impacto del
Reducción riesgo.
• Reducir la probabilidad siempre es más efectivo
que minimizar las consecuencias.
• Transferir la responsabilidad sobre el factor de
riesgo.
Transferencia • Pasar la consecuencia del riesgo y la
responsabilidad de la respuesta a una tercer parte.
3.7. La gestión de los problemas
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.
Causas comunes de los proyectos con problemas
Causa Ejemplo
Proyecto no alineado con la unidad empresarial o con los objetivos de la
Proyecto no alineado organización.
Proyecto no alineado con otros proyectos
Financiación y/o recursos insuficientes.
Falta de apoyo de la Temas no resueltos.
dirección Criterios de la gestión principal no alineados con los criterios de éxito del
proyecto.
Propósito y objetivos nada claros.
Falta de implicación
Relación de confianza no establecida.
de las partes en el
Comunicaciones no adecuadas.
proyecto
Expectativas desiguales.
Patrocinador inactivo, no comprometido
Patrocinador del
No se ocupa de asuntos de la organización.
proyecto inadecuado
No apoya el proceso de gestión del proyecto.
Demasiados Objetivos contradictorios del proyecto.
patrocinadores del Enfrentamientos políticos.
proyecto
Esfuerzos laborales ineficaces.
Falta de claridad en
Plazos no cumplidos.
las funciones y
Baja moral del equipo.
responsabilidades
Resolución de los temas retrasada.
Información inconsistente, incompleta o inexistente del estado del proyecto
en las mediciones básicas del proyecto.
Seguimiento y control inadecuados del progreso del proyecto.
Mala comunicación No escuchar los intereses ni las reacciones de los implicados.
No utilizar los medios oportunos para ciertas comunicaciones.
Los mensajes no están claros o son demasiado frecuentes.
Por causa de medidas de reducción o presiones del mercado, la dirección se
Guerras de precios compromete a llevar a cabo el proyecto según los costes previstos o a reducir
los costes.

Causa Ejemplo
Falta de miembros del equipo con dedicación exclusiva.
Conflictos de recursos
Los recursos no están disponibles dentro del plazo establecido
Falta de liderazgo.
Jefe de proyectos
Jefe de proyectos sin experiencia o sin formación.
incompetente
Jefe de proyectos ineficaz.
No comprender los efectos completos que el “cambio” introducido en el
Subestimar los efectos
proyecto tendrá sobre los procesos existentes y las personas.
de los cambios
Preparación y planificación inadecuadas para el “cambio”
La dirección no requiere el tiempo suficiente, o no lo concede, para realizar
una planificación adecuada.
Lista de alcance o de entregables incompleta.
Identificación del trabajo sin completar.
Mala planificación Falta de un calendario detallado.
Identificación insuficiente de los riesgos.
Suposiciones sin documentar.
Falta de calendario y de contingencia de presupuesto.
El alcance del trabajo aumenta sin realizar ajustes adecuados en el calendario,
en los recursos o en los presupuestos.
Falta de gestión de
Hay cambios en los entregables, en el calendario o en el presupuesto sin
control de cambios
notificarse o aprobarse correctamente.
Expectativas erróneas por parte de las partes implicadas.
Falta de criterios de Aumento en los costes e incumplimiento de plazos debido a la necesidad de
finalización rehacer el trabajo.
No hay una transición progresiva entre una fase y la siguiente.
Seguimiento Incapacidad para medir el estado del proyecto y las probabilidades de éxito.
incorrecto del Incapacidad para revisar los puntos clave del proyecto y tomar decisiones de
progreso “si/no”.
Dificultades técnicas El esfuerzo invertido en la resolución de problemas técnicos lleva al

imprevistas incumplimiento de calendarios y al aumento de los costes.
La tecnología de eficacia no demostrada no se corresponde con las
expectativas de los usuarios.
¿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:
o Documentar el problema.
o Realizar un seguimiento hasta su resolución.
o El proceso en su conjunto debe estar alineado con el flujo del proyecto.
o 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 Pros Contras

Limitado en cuanto a: filtrado,
Bajo coste. capacidad de información,
Sencillo acceso y visibilidad
Procesador de textos Portátil. Pesado a medida que aumenta
Rápido el registro
Se necesitan procesos
manuales
Bajo coste.
Simple. Idem
Aprovecha la clasificación, el
filtrado y las capacidades de
Hoja de cálculo
información del programa de
hojas de cálculo.
Portátil
Tiene en cuenta las Se necesita más tiempo de
actualizaciones de múltiples configuración y de
usuarios. administración.
Base de datos Mejor relación entre los datos. Aumentan los costes.
Mejor información. No es tan portátil.
Refuerza el proceso Se puede necesitar formación.

Opciones Pros Contras
Pueden funcionar en la Web. Aumenta el tiempo de
Todas las ventajas del configuración y de
Herramientas de programa de base de datos. administración.
colaboración virtual Mapa del flujo de proceso. Aumentan los costes.
Notificaciones automáticas. Se puede necesitar formación.
Los pasos siguientes son:
o Definir cómo deben presentarse los problemas, como se van a resolver, cuando se
van a resolver y los requisitos para considerarlos resueltos.
o Asignar la responsabilidad de administrar el registro de problemas.
Los campos recomendados de registro de problemas se muestran a continuación:
Identificador del Identificador único que se puede utilizar para seguir claramente ese
problema problema
Categoría del problema: los valores del dominio variarán dependiendo
Tipo de problema
del proyecto
Nombre del problema El nombre corto del problema
El estado actual del problema debe estar alineado con el flujo de trabajo
Estado del problema
del proceso establecido para la resolución del problema
Prioridad del problema Resume la importancia y gravead del problema
Detalles del problema Todos los detalles del problema
Enumera el impacto potencial para los factores críticos de éxito del
Impacto potencial
proyecto si no se resuelve el problema
Fecha de presentación La fecha en la que el problema es identificado y aceptado.
Propuesto por Persona que ha dado origen al problema
Fecha de asignación Fecha en la que se asigna el problema a una persona
Asignado a Persona a la que se le ha asignado el problema para tomar medidas
Fecha de resolución
Fecha establecida para su resolución
establecida
Fecha de actualización Fecha en la que se ha actualizado la entrada del registro por última vez
Fecha de resolución
Fecha en la que se ha resuelto el problema
definitiva
Fecha de cierre Fecha en la que se ha cerrado el problema

Contiene actualizaciones e información sobre los elementos de acción,
Notas sobre el progreso
los descubrimientos y los pasos para su resolución.
El muchos casos, un problema viene asociado con otros problemas o
Elementos relacionados genera otros problemas/elementos de acción.
Es recomendable seguir esa asociación.
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:
o Debe haber un responsable que centralice la operativa de registro y seguimiento.

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

Ejemplos
Why Do Projects Fail? Learning How to Avoid Project Failure
A lo largo del artículo se define lo que es un fracaso en el proyecto y se exploran los

factores que lo originan:
“We can probably all think of projects that have "failed" – perhaps processes got worse rather
than better, maybe they were cancelled because of cost overruns, or perhaps systems were
launched with fundamental errors.
How do you know when – and why – a project has failed? In many cases, the reason for
failure is obvious. However, the definition of failure isn't always clear: one project with a
significant delay might be described as a failure; yet another, with a similar delay, might be
seen as a stunning success”.
El artículo está disponible en el aula virtual y en la siguiente dirección web:

http://www.mindtools.com/pages/article/newPPM_58.htm
Earned Value Management Tutorial. Module 1: Introduction to

Earned Value Management
Se trata de un documento preparado por Booz Allen Hamilton para el Departamento de

Energía de Estados Unidos:
“This module defines Earned Value management. It looks at the differences between
Traditional management and Earned Value management, examines how Earned Value
management fits into a program and project environment, and defines the framework
necessary for proper Earned Value management implementation”.

http://energy.gov/sites/prod/files/maprod/documents/EVMModule1.pdf
TEMA 3 – Ejemplos 32 © Universidad Internacional de La Rioja (UNIR)

Lo + recomendado
No dejes de ver…
Conceptos y Definiciones relevantes en Gestión de Riesgos
Se trata de un vídeo que enumera y

explica los principales conceptos y
definiciones a tener en cuenta en la
Gestión de Riesgos.
El vídeo está disponible en el aula virtual y en la siguiente dirección web:

https://www.youtube.com/watch?v=pLX4A8S3OBs
TEMA 3 – Lo + recomendado 33 © Universidad Internacional de La Rioja (UNIR)

+ Información
A fondo
Earned value management
Más información en Wikipedia sobre el Método de Valor del Trabajo realizado.
La información está disponible en el aula virtual o en la siguiente dirección web:

http://en.wikipedia.org/wiki/Earned_value_management
Make sure your project deliverables are aligned to your objectives
Una reflexión sobre la importancia de alinear los entregables del proyecto con los
objetivos.

http://www.techrepublic.com/blog/project-management/make-sure-your-project-
deliverables-are-aligned-to-your-objectives/127
“Goldplating” ¿Tus entregables están bañados en oro?
Artículo y discusión sobre la conveniencia o no de ampliar el alcance de los objetivos

inicialmente planteados por la organización/cliente. Aunque el artículo ya se vio en la
asignatura “Metodología de Diseño y Planificación de Proyectos”, merece la
pena releerlo.

http://iaap.wordpress.com/2010/07/07/goldplating-%C2%BFtus-entregables-estan-
banados-en-oro/
TEMA 3 – + Información 34 © Universidad Internacional de La Rioja (UNIR)

How Good Are Your Problem-Solving Skills?
¿Cómo eres de bueno resolviendo problemas? Se trata de un test para evaluar las
capacidades personales para la resolución de problemas.

http://www.mindtools.com/pages/article/newTMC_72.htm
Problem Solving Techniques
The 25+ tools in this section help you solve complicated business problems.

http://www.mindtools.com/pages/main/newMN_TMC.htm
Risk Analysis
Evaluating and Managing Risks.

http://www.mindtools.com/pages/article/newTMC_07.htm

Webgrafía
PMI
PMI is one of the world's largest not-for-profit membership associations for the project
management profession, with more than 650,000 members and credential holders in
more than 185 countries.
www.pmi.org
QFDI
Más información sobre la gestión de la calidad del proyecto: web del Quality Funtion
Deployemnt Institute.
www.qfdi.org
Bibliografía
Horine, G. (2009). Gestión de Proyectos. Edit. Anaya Multimedia 10ª edición.

Test
1. Los factores críticos de éxito del proyecto engloban a las variables conocidas como la
triple restricción de la gestión de proyectos.
A. Cierto.
B. Falso.
2. Cuando hablamos de umbrales de escalada, estamos hablando de:

A. El nivel de riesgo del proyecto.
B. EL nivel de retraso en el cumplimento del calendario.
C. El nivel jerárquico implicado en la toma de decisiones.
D. El nivel de desfase del presupuesto en relación a lo planificado.
3. Si utilizando el método de Gestión del Valor Ganado, un proyecto obtiene un valor

del índice de desempeño del cronograma (SPI) del 0,85 y un valor del índice de
desempeño del costo (CPI) de 1,22 nos indicará que:
A. El proyecto va retrasado y con unos costes superiores a lo presupuestado.
B. El proyecto va retrasado y con unos costes por debajo del presupuesto.
C. El proyecto va adelantado con unos costes superiores a lo presupuestado.
D. El proyecto va adelantado con unos costes por debajo del presupuesto.
4. Habitualmente los cambios del proyecto tienen su origen en cambios en el alcance

en un:
A. 40 %
B. 50 %
C. 90 %
D. 80 %
5. El plan de gestión de la configuración del proyecto se debe realizar:

A. Lo más completo posible.
B. Teniendo en cuenta el tipo de organización del proyecto y la cultura de la
empresa.
C. De manera coherente con el nivel de complejidad y tamaño del proyecto.
D. De acuerdo con las directrices del director de proyecto.
6. Los riesgos del proyecto:
A. Se originan en un 80% a partir de las mismas fuentes en cada proyecto.
B. Se originan en un 80% al inicio del proyecto.
TEMA 3 – Test 37 © Universidad Internacional de La Rioja (UNIR)

C. Se originan en un 80% por la evolución de la tecnología.
D. Se originan en un 80% por decisiones equivocadas.
7. Las causas de los problemas tienen su origen:

A. En el equipo de trabajo.
B. En la organización y en el propio proyecto.
C. En las condiciones de entorno.
D. En la gestión de los recursos.
8. Para la gestión operativa de los problemas debe haber tantos responsables de la

operativa de registro y seguimiento como sean necesarios para agilizar el proceso.
A. Cierto.
B. Falso.
9. Los problemas deben resolverse en el nivel jerárquico más alto posible para que
puedan ser supervisados.
A. Cierto.
B. Falso.
10. El coste del plan de calidad del proyecto sólo debe ser asumido si la importancia y
complejidad del proyecto lo hacen necesario.
A. Cierto.
B. Falso.
TEMA 3 – Test 38 © Universidad Internacional de La Rioja (UNIR)

Tema 3

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 3

Cargado por

Copyright:

Formatos disponibles

Metodologías de control del proyecto

[3.2] ¿Qué es controlar un proyecto?

[3.3] Metodología de control de proyectos: Gestión del Valor

[3.4] Técnicas para gestionar los cambios de un proyecto

[3.5] Los entregables del proyecto o “Gestión de la

[3.6] La gestión de los riesgos

[3.7] La gestión de los problemas

[3.8] La calidad como uno de los factores críticos

¿QUÉ ES CONTROLAR UN PROYECTO?

LA CALIDAD COMO UNO DE LOS FACTORES CRITICOS DE ÉXITO DEL PROYECTO

© Universidad Internacional de La Rioja (UNIR)

3.1. ¿Cómo estudiar este tema?

Este tema sirve de puente entre la fase de DISEÑO y PLANIFICACION de un proyecto

Tener claro lo que significar controlar un proyecto.

TEMA 3 – Ideas clave 3 © Universidad Internacional de La Rioja (UNIR)

Lo que se entiende por controlar un proyecto

Con controlar un proyecto nos estamos refiriendo a la implementación de las técnicas

En general se trata de dar respuesta a

¿Estamos de acuerdo con el calendario?

¿Vamos cumpliendo el presupuesto?

¿Qué riesgos potenciales tenemos?

¿Vamos resolviendo los problemas encontrados?

¿Están funcionando las medidas correctivas?

Principios fundamentales de control

Los principios fundamentales del control de proyectos son:

TEMA 3 – Ideas clave 4 © Universidad Internacional de La Rioja (UNIR)

Consejos y recomendaciones de control de proyectos

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

Realizar reuniones periódicas de estado del proyecto

Combinación de hitos de control y revisiones

Diseñar paquetes de trabajo pequeños

TEMA 3 – Ideas clave 5 © Universidad Internacional de La Rioja (UNIR)

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

No se trata de evitar los cambios sino de gestionarlos adecuadamente

¿Cómo es la cultura organizativa?

Regla del 15% del punto de finalización

Es muy importante establecer un criterio claro de finalización

Establecer “umbrales de escalada”

TEMA 3 – Ideas clave 6 © Universidad Internacional de La Rioja (UNIR)

Independientemente de la metodología de control que se establezca, los principios a

Es importante mantener y establecer una frecuencia de informes de estado

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

En la práctica integra el alcance, el cronograma y los costos en un gráfico de evolución,

El método se basa en las siguientes premisas:

TEMA 3 – Ideas clave 7 © Universidad Internacional de La Rioja (UNIR)

El trabajo total se puede dividir en tareas o paquetes de trabajo. Cada tarea o

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

El proyecto tiene un valor acumulado en cualquier punto de su ejecución: este

TEMA 3 – Ideas clave 8 © Universidad Internacional de La Rioja (UNIR)

La mayor utilidad del método reside en su capacidad para hacer un seguimiento

Elemento Definición y observaciones

TEMA 3 – Ideas clave 9 © Universidad Internacional de La Rioja (UNIR)

Elemento Definición y observaciones

Elemento Definición y observaciones

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

TEMA 3 – Ideas clave 10 © Universidad Internacional de La Rioja (UNIR)

Elementos Definición y observaciones

a) Proyección de costo según presupuesto

b) Proyección de costo según CPI actual. Supone

c) Proyección de costo considerando el CPI y el

d) Proyección de costo en base a una nueva

TEMA 3 – Ideas clave 11 © Universidad Internacional de La Rioja (UNIR)

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