Universidad Mariano Glvez de Guatemala

Maestra en Administracin de Negocios

SCOPE CREEP
Proyectos

CONTENIDO

I.

INTRODUCCION................................................................................................2

Scope Creep.............................................................................................................5
1.

DEFINICIN:..................................................................................................5

2. POR QU SE DA LA DISTORSIN DEL ALCANCE?..................................6

3. GOLD PLATING...............................................................................................8
4. CMO DEBE EL GERENTE DE PROYECTO HACER FRENTE A LA
DISTORSIN DE ALCANCE?..............................................................................11
5. ESTRATEGIAS PARA MANEJAR LA DISTORSIN DEL ALCANCE..........13
II.

CONCLUSIONES.............................................................................................16

III.

BIBLIOGRAFA.............................................................................................17

I.

INTRODUCCION
A lo largo del ciclo de vida de un proyecto, y con mayor probabilidad cuanto

mayor es su duracin, se presentan mltiples ocasiones que incitan a cambios en

el curso previsto. Meditar sobre las necesidades y objetivos, la aparicin de una
nueva tcnica o herramienta, la modificacin de las normas o la regulacin
aplicable, o la aparicin de productos sustitutivos o complementarios son algunas
de las buenas razones para verse tentado a modificar alguno (alcance, costo o
tiempo) en la evolucin del proyecto. Cuando se realizan cambios al alcance
original que no se controlan se produce una corrupcin del alcance. En ocasiones
este movimiento sigiloso del alcance es un asesino silencioso que toma
desprevenido y lleva al fracaso del proyecto. Sucede en proyectos de cualquier
tamao.
El fenmeno de corrupcin del alcance trae consigo implicaciones de costos
y tiempos de desarrollo. Consiste en el desplazamiento sigiloso del alcance inicial
previsto para un proyecto. Dentro de este fenmeno del Scope Creep se
encuentran dos manifestaciones causales ms, conocidas como: "Baado en oro"
y "Complaciendo al cliente"
"Baado en oro"
Baado en oro es el fenmeno por el cual el equipo del proyecto muchas
veces entrega ms funcionalidades o caractersticas de las requeridas para el
producto o servicio. Se llama Gold plating ("baado en oro") porque si se encarga
un entregable y al final se entrega lo que se pidi y ms, es como si se entregara
baado en oro. Consiste en que los programadores o desarrolladores adicionan
funcionalidades no especificadas en la definicin de requerimientos aprobada. La
razn para estos cambios puede estar en que los requisitos del negocio carecen
de detalles o el programador es un perfeccionista. [AAP, 2010]
El 78% de los proyectos que se enfocan en "baar en oro" fracasan, hay
que enfocarse en que el proyecto salga bien, no en entregarlo "baado en oro".

Por otra parte:

El principal objetivo del proyecto debe ser asegurarse de que entregamos lo
que el cliente quiere, cumpliendo los tiempos y el presupuesto.
Si los entregables estn baados en oro, se ha tomado una decisin acerca
de lo que el equipo de proyecto cree que tiene ms valor para el cliente. Se parte
de la base de que las funcionalidades extras son lo de ms valor, cuando quizs
puedan serlo el tiempo o el presupuesto. Si se termina antes el proyecto, o se
gasta menos dinero, hay que dejar que el cliente decida cmo proseguir. Las
funcionalidades extra son una decisin del cliente del proyecto, no del
administrador de proyecto.
"Complaciendo al cliente"
Por otra parte el fenmeno "Complaciendo al cliente" se manifiesta cuando
miembros o equipos de proyecto quieren complacer al cliente y son reacios a decir
NO ante un cambio de requerimientos.
Cmo puede darse esta situacin?
El alcance original no se document suficientemente bien.
Un cliente muy exigente, no necesariamente intencional, sino porque
continuamente se le permite pedir ms para mantenerlo contento.
Un administrador de proyecto que no realiza un seguimiento preciso a lo
que est sucediendo en el proyecto. Esto pasa usualmente a grandes equipos
donde hay mltiples puntos de contacto con el cliente.
Aunque hay mltiples causas del fenmeno de corrupcin del alcance, la
causa fundamental est precisamente en las deficiencias en la ejecucin de las
actividades relacionadas con la gestin de alcance. Para minimizar estos
fenmenos es imprescindible realizar las actividades de gestin de alcance en
especial las relacionadas con la verificacin del alcance y el control.

En la presente investigacin se realiza un estudio, con estadsticas y cifras, de una

muestra de proyectos informticos del Centro de Desarrollo de la Facultad
Regional de Granma para identificar si alguno de ellos ha padecido el fenmeno
del Scope Creep en alguna de sus manifestaciones y las causas principales.

Scope Creep
1. DEFINICIN:
Es un riesgo significativo en proyectos de desarrollo de software, es cuando
el equipo del proyecto agrega funcionalidades al producto sin saber que no
estaban

pactadas

en

la

definicin

original,

cuando

acepta

nuevas

funcionalidades pedidas por el cliente porque no sabe decir que no, o porque no
se da cuenta de que eso causar problemas en el futuro.
El Sndrome del lavadero, Arrastramiento del alcance o Corrupcin del
alcance (Scope creep en ingls) en gestin de proyectos se refiere a aquellos
cambios no controlados en el alcance de un proyecto. Este fenmeno puede
ocurrir cuando el alcance de un proyecto no se define, documenta, o controla
correctamente.
Creep tiene muchas acepciones, pero la ms acertada para nuestro caso es
escalofro o estremecimiento. Tener escalofros de alcance en la ejecucin, esa es
la interpretacin correcta.
En el PMBOK este trmino ha sido traducido como Corrupcin del Alcance.
En el Glosario del PMBOK dice: Corrupcin del Alcance (Scope Creep) es
la adicin de funciones y funcionalidad sin considerar los efectos sobre el tiempo,
los costos y los recursos, o sin la aprobacin del cliente. Tambin conocido como:
Adiciones al Alcance; Alteracin del Alcance; o Cambio Mayor del Alcance; o
Deslizamiento de Alcance.
El proceso 5.5. Controlar el Alcance en la ejecucin habla de este
problema. La premisa ms importante a tener en cuenta en este proceso es:
Habr cambios al alcance. Esto es un dato, un supuesto del proyecto. La
responsabilidad del gerente de proyecto es definir e implementar un proceso para
analizar y rechazar o aceptar esos cambios. El control del alcance del proyecto
tambin se utiliza para gestionar los cambios reales cuando suceden y se integra
5

a los otros procesos de control. Los cambios no controlados se denominan

corrupcin del alcance del proyecto (Scope Creep = cambios no controlados). Es
decir: los cambios no controlados deberan hacerte estremecer.
2. POR QU SE DA LA DISTORSIN DEL ALCANCE?
Debido a que cada proyecto es nico y se ejecuta en un perodo de tiempo
definido, es de esperarse que existan variaciones en los factores que lo
condicionan, como cambios en el sistema poltico o la normativa legal, por
ejemplo. Como menciona Montes de Oca (2014) el alcance debe describir
detalladamente el proyecto.
Un caso real que expone este tema tiene que ver con un proyecto
desarrollado en una empresa guatemalteca de consumo masivo para reducir los
tiempos de liquidacin y carga de sus camiones de reparto; para lo cual se
definieron horarios de ingreso a los centros de distribucin entre 5 y 7 de la noche.
Sin embargo, debido a que toda la flotilla comprende camiones de 6 a 12
toneladas, est afecto a la nueva normativa para la circulacin del transporte
pesado en la ciudad capital. Por este motivo, el proyecto debe modelarse bajo
escenarios que no existan al momento de su concepcin y ajustar el alcance a
esta nueva situacin que impactar en costes y tiempos.
Entre las causas ms importantes para que se presente el Scope Creep o
corrupcin del alcance, se ha determinado que existan factores internos propios
del proyecto y otros que son ajenos al mismo, no obstante todos repercuten en
que se produzca la distorsin del alcance.
Factores Internos del Proyecto:
Deficiente comprensin del requerimiento: principalmente por tomar el
proyecto de forma apresurada sin analizar el alcance.

Requerimientos pobremente definidos: si no se especifican de forma

correcta y concreta, es normal que se presenten variaciones en la medida en que
se va desarrollando el proyecto.
Complejidad del proyecto: mientras mayor sea la complejidad del proyecto, el
impacto que produce la corrupcin del alcance es ms grande. Esto significa que
la especificacin del alcance debe ir acorde con el tipo de proyecto que se
desarrolla.

Problemas de comunicacin: cuando no existe fluidez en este tema, los objetivos

del Gerente de Proyectos y los stakeholders puede provocar confusin al elaborar
e interpretar los requerimientos.

Perfeccionismo: cuando el equipo de proyectos busca destacar por su propia

cuenta o existen integrantes que desean promoverse individualmente, se pueden
cambiar los requerimientos por otros que persigan exceder las expectativas.

Factores Externos al Proyecto

Presin de mercado: pueden crearse expectativas por encima de la
realidad. Esto provocar que los requerimientos se vayan adecuando en cuanto a
los elementos que se dispusieron originalmente.
Regulaciones gubernamentales: cambios en la legislacin vigente, puede
forzar a establecer cambios en el alcance an repercuta en otro tipo de
consecuencias como incremento en costos o incumplimiento en la programacin.
Satisfaccin del cliente: si el cliente cambia especificaciones sustanciales
puede motivar a que se produzcan cambios en los requerimientos establecidos
originalmente. Decir si a todo lo que el cliente decida no es siempre la mejor
solucin.

Para el autor Barato (2013) la eficacia en la administracin de los Proyectos

se mide por que se ejecuten en el plazo, coste y calidad, lo cual est directamente
relacionado con el alcance.

3. GOLD PLATING

El trmino gold plating hace referencia a una mala prctica que consiste en
ampliar la funcionalidad de un producto o servicio sin un motivo claro desde el
punto de vista metodolgico y de gestin. La persona encargada de crear un
producto le aade caractersticas que no estn incluidas en la documentacin
aprobada, y lo hace generalmente sin el conocimiento, las indicaciones y el
respaldo de la direccin del proyecto. Es un error especialmente lamentable, ya
que no tiene una causa externa directa: surge en el seno del proyecto y es
generado por el propio equipo. En espaol, se emplea a veces la traduccin
baado en oro.
El Chapado de Oro, bao de oro o Gold plating, se refiere a la adicin de
funcionalidades a un producto por parte del realizador sin que medie una solicitud
expresa por parte de los interesados. Involucra el trabajo invertido en un proyecto,
cuando se ha pasado el umbral que determina si un esfuerzo considerable logra
adicionar valor (o funcionalidad) al proyecto.
El Chapado de Oro es considerada una prctica no ptima por diferentes
mtodos tales como el: PMBoK. Hace referencia a la adicin de caractersticas no
consideradas en el Alcance del Proyecto (PMBoK), en cualquier punto del
proyecto. Esto introduce fuentes de riesgos -por ejemplo: pruebas adicionales,
mayor documentacin, aumento de costos, desplazamiento de cronogramas, etc.
En general, debe evitarse el chapado de oro y gestionarse los cambios de manera
formal para poder prever el impacto de los cambios en todas las reas del
proyecto.
Cmo identificar el gold plating

Aparece generalmente en dos fases del proyecto:

Toma de requisitos. Sucede cuando se modifican los requisitos funcionales
para introducir funcionalidad compleja que no suscita un inters real en el cliente,
y que no est respaldada por un caso de negocio u otro tipo de propuesta formal.
Tambin puede ocurrir con los requisitos no funcionales, elevando los criterios
iniciales de rendimiento, disponibilidad del servicio, tiempos de respuesta, etc.
Creacin del producto. Es el caso ms comn, especialmente en proyectos TI, los
ms afectados por esta mala prctica, donde a la etapa de fabricacin de producto
se la denomina desarrollo. Aparece cuando el desarrollador decide por su cuenta
mejorar el producto, alterando lo definido en la documentacin de anlisis y
diseo, ampliando la casustica inicialmente contemplada para incorporar nuevas
caractersticas

empleando

tecnologas

novedosas

que

complican

la

implementacin.
Por qu es una mala prctica
No

es

difcil

encontrar

opiniones

favorables,

especialmente

de

desarrolladores que ven en esta mala prctica la oportunidad de conseguir ciertos

rditos personales. He aqu algunos ejemplos frecuentemente utilizados para
justificar el fenmeno, y que pueden distraernos de las verdaderas consecuencias
del gold plating:
Al cliente le ha gustado la nueva funcionalidad. No la esperaba y ha sido
una sorpresa agradable.
La mejora introducida ha sido una de las opciones ms utilizadas de la
aplicacin informtica.
La novedad tcnica es bienvenida y cuenta con el visto bueno de otros
tcnicos.
Es conveniente dejar libertad absoluta al creador, de lo contrario se
perjudica la calidad y se castiga la creatividad.

Sin embargo, los efectos del gold plating son casi siempre perjudiciales y su
impacto en la planificacin del proyecto suele ser elevado. Quiz no sea tan
evidente comprobar el precio que se paga:
Prioridades. El equipo permite que pase a un segundo plano el verdadero
objetivo del proyecto: entregar un producto o servicio de acuerdo a los requisitos,
tiempo y presupuesto acordados.
Decisiones. Este apartado es especialmente delicado, ya que quien incurre
en gold plating acaba cometiendo dos errores. Por un lado, toma decisiones que
no le competen, ya que no cuenta con el cliente ni el director de proyecto. Por otro
lado, toma decisiones equivocadas: era imprescindible para el cliente incluir una
nueva caractersticas de la que no haba odo hablar? Quiz lo ms importante era
la fecha de entrega, el presupuesto, la disponibilidad de recursos para otros
proyectos
Recursos. El gold plating es en esencia un sobreesfuerzo injustificado, y por
tanto tiene una consecuencia directa: se malgastan recursos de todo tipo
(horas/hombre, recursos informticos, presupuesto, etc.).
Complejidad. Se aade complejidad al producto y su implementacin, y ello
puede revertir negativamente en tareas de documentacin de anlisis, diseo,
requisitos, manuales, etc., as como en el mantenimiento futuro del producto o
servicio.
Frustracin. En ocasiones detrs del gold plating se esconde la intencin,
ms o menos loable, de colgarse una medalla. No valorar con entusiasmo una
funcionalidad extra puede causar frustracin en ese desarrollador que, sin tener en
cuenta las consecuencias anteriormente descritas, incurre en gold plating por puro
perfeccionismo y cree haber realizado un esfuerzo colosal y digno de aplauso.
Estrategia para evitar el gold plating
En un proyecto hay mltiples factores que favorecen la aparicin del gold
plating, y por tanto la mejor estrategia es considerarlo un riesgo. Para evitarlo o

10

para mitigar sus efectos es necesario actuar de manera continuada en cinco

frentes:
Direccin. Establecer con claridad meridiana las lneas de trabajo y el
rumbo a seguir. Una labor de coordinacin deficiente puede ser causa de
interminables problemas.
Gestin de equipos. Ingenieros y programadores no deben trabajar en
solitario, hacerlo en equipo y estar sujeto a dependencias reduce el riesgo de
desviaciones por gold plating.
Responsabilidad. Un buen reparto de roles y responsabilidades lleva
implcito mecanismos de contrapeso que pueden evitar malas prcticas. La
concentracin excesiva de competencias dificulta la deteccin del gold plating.
Monitorizacin y control. Para prevenir desviaciones innecesarias es
imprescindible que las tareas se deleguen correctamente. Adems, evitar el gold
plating a menudo exige conocimientos tcnicos muy especficos, especialmente
cuando se produce en la fase de desarrollo del producto. Por ello es necesario no
conformarse con las explicaciones de alto nivel, sino bajar ms al detalle y
preguntar, indagar y aclarar.
Expectativas. Detrs de cada caso de gold plating siempre se esconde el
mismo problema: una muy mala gestin de expectativas. Lo que el cliente espera
se entiende mal y se distorsiona. Conviene por tanto llevar a cabo una buena
gestin de expectativas, aclarando completamente qu est incluido (y qu no) en
el

alcance

del

proyecto,

documentndolo,

revisndolo

recordndolo

frecuentemente.

4. CMO DEBE EL GERENTE DE PROYECTO HACER FRENTE A LA

DISTORSIN DE ALCANCE?
Es de suma importancia que el Gerente de proyecto tenga en claro el alcance
del proyecto ya que si no lo tiene muy claro ser muy difcil manejar el proyecto

11

como tal ya que los cambios que llegara a realizarse en el camino distorsionaran
el alcance.
Es por ello que es importante de que el Gerente de proyecto tenga en cuenta
los requerimientos definidos en el acta de constitucin, y debe ser en esta en la
que se deban de definir qu tipo de cambios podrn realizarse y determinar el
impacto que estos cambios conllevara en el presupuesto y tiempo. Adems de
definir si ser necesario la contraccin de personal temporal para que las
actividades adicionales no vengan a sobrecargar al personal inicialmente
requerido.
Segn (PMI, 2013) validar el Alcance es el proceso de formalizar la aceptacin
de los entregables del proyecto que se hayan completado. El beneficio clave de
este proceso es que aporta objetividad al proceso de aceptacin y aumenta las
posibilidades de que el producto, servicio o resultado final sea aceptado mediante
la validacin de cada entregable individual.
Por lo anterior puede entenderse que el gerente de proyecto de alguna forma
debe conocer o esta consiente de los requerimientos y que un cambio sin previo
aviso puede distorsionar o retrasar el entregable inicialmente requerido.
Todo cambio no debe distorsionar la lnea base del proyecto y esto el gerente
de proyecto no tiene que tener claro al momento de que los interesados o
StakeHorders quiera introducir cambios en la lnea base se proyect.
Segn (PMI, 2013) el control del alcance del proyecto asegura que todos los
cambios solicitados o las acciones preventivas o correctivas recomendadas se
procesen a travs del proceso Realizar el Control Integrado de Cambios. El
proceso Controlar el Alcance tambin se utiliza para gestionar los cambios reales
cuando suceden y se integra con los otros procesos de control. La expansin
incontrolada del alcance del producto o del proyecto sin ajustes de tiempo, costo y
recursos se denomina corrupcin o deformacin del alcance.
Lo anterior confirma que el gerente de proyecto debe de gestionar este tipo de
cambios respaldando esta ampliaciones o modificaciones en el respectivo Control
12

de cambios y estar consciente de que no puede hacer cambios a procesos o

entregables terminados pues tal como los menciona (PMI, 2013) la aceptacin
descontrolada de cambios conllevar a que el proyecto se descontrolo y deforme
respecto al alcance inicialmente establecido.
(degerencia.com, 2016) Indica que es necesario Practicar un estricto control de
cambios: independientemente del tamao del proyecto y para evitar el Scope
Creep se deber ser muy riguroso en lo que respecta al control y seguimiento de
los cambios al proyecto, utilizar herramientas automticas de RM (Requirement
Management) y CM (Configuration Management).
Lo anterior confirma lo definido por (PMI, 2013) en que indica que se deben de
seguir los procedimientos y que todos los interesados estn de acuerdo en que los
cambios a implementarse situacin que el gerente de proyectos debe de hacerlos
notar y dejar claro a los solicitantes de los cambios.
Como lo indica (degerencia.com, 2016) el propsito de la administracin de
cambios es proteger la viabilidad de la definicin del proyecto ya definida y
aprobada. Cuando se solicita formalmente un cambio implica que dicho cambio
est fuera del alcance acordado en la definicin del Proyecto o de los
requerimientos o solicitudes detallados durante el anlisis.
A lo anterior tambin (degerencia.com, 2016) aade que El Gerente de
Proyecto y el equipo de trabajo, deben reconocer el momento en que los cambios
son requeridos y debern seguir un proceso predefinido de gestin del alcance.
Este proceso, eventualmente, proporcionar informacin para que el sponsor tome
las decisiones pertinentes y tambin le permitir decidir si la modificacin deber
aprobarse en base al valor e impacto en el proyecto en trminos de costo y
tiempo. Debe ser claro para todas las partes que cumplir estos nuevos
requerimientos con los mismos recursos de la definicin anterior, es prcticamente
imposible.

13

5. ESTRATEGIAS PARA MANEJAR LA DISTORSIN DEL ALCANCE

La distorsin de alcance y sus razones pueden ser de funcionales o bien
tcnicas, y ambas por fuerzas internas o externas. Puede aparecer cuando el
equipo del proyecto quiere complacer al cliente y no puede rechazar la solicitud
del cliente para un cambio en los requisitos durante la ejecucin del proyecto.
(Villanova University, 2013) Por lo regular se puede buscar la felicidad del cliente,
al contrario, tambin se puede ser estricto por lo establecido. Pero existen siempre
diferentes formas de abordar el problema, desde el punto de vista de negocios se
ha encontrado que existen un set de estrategias para delimitar en segundo plano y
mantener una buena relacin de trabajo a largo plazo.
1.

Es una oportunidad abierta

(HBR, 2013) Muchos pueden considerar que es una oportunidad de desarrollo de

negocios con disfraz. Estar en sintona con las necesidades de su cliente desde el
comienzo de un proyecto, tiene como resultado reconocer cundo empiezan a
expresar una necesidad que va ms all de lo que ha acordado entregar, una
situacin de la cual se puede sacar provecho.
Los objetivos de esta estrategia son:

Usted ya entiende el problema de su cliente, as que, si se cree que puede

entregar valor ms all del trabajo acordado, ofrezca ayuda.

El truco es hacer que el cliente sea consciente y pedirles que evalen el

valor de la nueva entrega.

Esto les permite tener empata con el cliente y crea una comprensin de

que habr una inversin adicional (en tiempo, dinero o recursos) en ambos
extremos.
Por supuesto, se debe ser lo ms claro posible sobre entregables y cronograma
en su mbito de trabajo inicial, pero ningn contrato puede tomar el lugar de una
buena gestin de relaciones.

14

2.

Enve una "factura cero"

Cuando un nuevo cliente hace una pequea solicitud, debe cumplir con la
solicitud, crear una factura por lo que tendra que costar y luego anular el costo.
Enve la factura al cliente y pdales que la firmen, reconociendo que la han
recibido. Haga esto cada vez que piden algo fuera del alcance del proyecto.
Los objetivos de esta estrategia son:

Esto sirve como un recordatorio visual y hace que el cliente sea ms

consciente de lo que estn pidiendo y el valor de lo que han recibido.

Tambin ayuda al administrador del proyecto a realizar un seguimiento del

tiempo que estn gastando en proyectos no facturables y minimizar las prdidas

de rentabilidad.

3.

Presupuestar desde el inicio

(HBR, 2013) En consultoras, es mejor desarrollar y estudiar los objetivos para

desarrollar el presupuesto inicial. En otras palabras, si su margen de operacin
estndar es del 20%, es necesario realmente presupuestar 30%. Al hacerlo, el
peor escenario al menos no se tendr un impacto financiero y de lo contrario, tiene
un margen de operacin ligeramente superior.
4.

Colaborar con el cliente en definir las expectativas

Se deber ser proactivo para establecer los requisitos del proyecto, como parte del
proceso de colaboracin entre el cliente y el equipo interno.
(HBR, 2013) Todo el equipo debe entender la lista de requisitos, y que este es un
documento que el cliente tiene y puede referirse en el futuro. A medida que
comienza a producirse el efecto de distorsin del alcance, puede hacer referencia
al documento que ayud a crear, estableciendo expectativas acerca de cmo ser
el producto "objetivo".

15

Adems, tener reuniones semanales del estado se asegurar de que el cliente

sepa qu se est haciendo cada semana. Si preguntan sobre caractersticas
adicionales, usted ser capaz de realinear las expectativas con anticipacin.

II.

CONCLUSIONES

El papel del gerente de proyecto debe inicialmente conocer el acta de

constitucin para tener definido el tipo de cambios y en qu momento podrn ser
requeridos y sobre todo que estos cambios sean documentados y aceptados por
los interesados. No permitir que los cambios desven al proyecto de su lnea base
sino que estos sean complementarios, asi tambin debe de dejar claro el impacto
que los cambios que se lleven a cabo tendrn en el proyecto a nivel de tiempo,
costo y los recursos necesarios para implementar o aceptar los posibles cambios.
La principal causa de la corrupcin del alcance de los proyectos en la
manifestacin de "Baado en oro" y de "Complaciendo al cliente" fue que los
nuevos requisitos tenan gran impacto en el negocio del cliente.
Las manifestaciones de la corrupcin del alcance se comportaron de igual
forma.

16

Los cambios son inevitables pero debemos estar seguros de que son
controlados.
El registro de cambios y desviaciones es el que permitir realizar un anlisis de
los sucesos del proyecto, lo cual facilitar la implementacin de mejoras en el
proyecto y en proyectos futuros.
Hay que concentrar el esfuerzo en lo que se aprob para el proyecto e
involucrar a todos los miembros del equipo de desarrollo.
Debe trabajarse con el equipo el tema de la disciplina para evitar la
introduccin de cambios en el proyecto fuera de los procesos de gestin de
alcance.

III. BIBLIOGRAFA
McConnell,

Steve.

Classic

Mistakes

Enumerated.

stevemcconnell.com.

Consultado el 3 de mayo de 2010.

Montes de Oca, J. (2014). Comparacin de metodologas de gerencia de

proyectos Prince2 y PMOBok5. (Tesis indita de posgrado). Universidad Escuela
de Administracin de Negocios, Colombia.

Barato, J. (2013). Los Hbitos de un Director de Proyectos Eficaz. Madrid, Espaa.

Editorial Daz Santos.

17

Surech B. "Scope Creep Management". Project Management Software, Specialists

in Project Infrastructure. 2010.

Grupo de Tecnologas de la informacin y las Comunicaciones. 2005.

Disponible en:http://www.gtic.ssr.upm.es/encuestas/delphi.htm

HBR.

(2013).

Battle

Scope

Creep

in

Your

Projects.

Obtenido

de

https://hbr.org/2013/06/battling-scope-creep-in-your-p
Villanova University. (2013). Managing Scope Creep in Project Management.
Pennsylvania:

Project

Management

School.

Obtenido

de

https://www.villanovau.com/resources/project-management/project-managementscope-creep/#.WCD_V_krLIU

18