Busca en este sitio:
Twitter
. Soy Novato
. Soy Gerente de Proyectos
. Quiero ganar más
. Quiero mejorar a mi empresa
y sus proyectos
. Tengo experiencia, pero no soy experto
. Soy experto (o eso creo)
.
Contáctanos
Escríbenos a:
contacto@liderdeproyecto.com
Para información de cursos:
cursos@liderdeproyecto.com

Teléfono en México D.F:
+52 (55) 2652 4590


Aviso de privacidad
+
.
Humor del Líder

Problemas de comunicación
+
.
Glosario
Ven a conocer el glosario de administración de proyectos. Nuevas definiciones: Condiciones, Diagrama de flujo, Proceso de negocio, Producción, Secuencia.
+
.
Colaboradores

Conoce a los colaboradores de LiderDeProyecto.com. Tu puedes ser uno de ellos.
+
.
 
Artículos
 

Lidiando con un “Scope Creep” en proyectos de desarrollo de software

Por Linda Russell [ Acerca de la autora ]

Un Scope Creep es un riesgo significativo en proyectos de desarrollo de software. Ahora veremos por qué sucede y cómo evitar o mitigarlo.

¿Qué es un Scope Creep?

El desarrollo de un nuevo software surge generalmente como resultado de la identificación de una necesidad de un cliente, quien puede ser interno o externo a una organización. El paso siguiente es especificar cómo el software cumplirá con esa necesidad, específicamente, qué funcionalidad será desarrollada.

Lo anterior es el “scope” o alcance del proyecto. En esta fase los planes del proyecto están preparados y basados en la estimación para el desarrollo y entrega de una funcionalidad determinada, por lo que una fecha de finalización es acordada.

Pero, puede ocurrir que cuando comienza el desarrollo y parece que el proyecto está progresando de manera adecuada, el cliente se da cuenta que hay requerimientos adicionales que olvidó mencionarlos o elementos extras de funcionalidad que necesita. Frecuentemente, añadiendo estos suplementos generará que la duración de proyecto sea ampliada, omitiendo los plazos límites e incrementando los gastos; conduciendo al menoscabo del margen en el proyecto y potencialmente a la insatisfacción del cliente y pérdida de la credibilidad generada por una entrega tardía.

¿Cómo lidiar con un Scope Creep?

Es importante que una especificación funcional esté producida desde el principio, escrita en términos que el cliente pueda entenderla. Por ejemplo, un paseo por el proceso donde el software apoyará, tal vez ilustrado con una simulación a través de diapositivas, lo que ayudará a clarificar cómo trabajará el nuevo sistema desde el punto de vista del usuario.

La especificación funcional debe ser acordada y firmada por el cliente y debería incluir una Definición de Alcance. Esto expresa que solamente la funcionalidad, la cual está explícitamente descrita en la especificación está incluida en el alcance del proyecto y que algo no descrito está “fuera de alcance”.

Cuando posteriormente el cliente identifica elementos adicionales, dicha referencia es hecha en la especificación: ¿La funcionalidad requerida es descrita o aludida a:?. Si no lo es, el nuevo desarrollo está fuera de alcance.

El próximo paso es elaborar el impacto del desarrollo de la nueva funcionalidad: ¿Qué esfuerzo extra será requerido?, ¿Qué efecto tendrá sobre la totalidad de duración del proyecto?, ¿En qué costos adicionales se incurrirá y cómo afectará esto al margen del proyecto?.

                               

Si el impacto es insignificante, puede ser acordado para incluir la nueva funcionalidad en el proyecto existente, pero lo ideal debería ser la realización de la definición por escrito de una especificación revisada. El peligro aquí es que el cliente creerá que se ha sentado un precedente, por lo que puede pensar que futuras revisiones serán realizadas de la misma forma; por eso es importante comunicar las razones para permitir la revisión en esta instancia.

Es más probable que el desarrollo adicional genere retraso y/o costos extras. El cliente necesita estar conciente de las implicaciones de la revisión en términos del impacto de éstas sobre las escalas de tiempo y costos; y una especificación de las adiciones y cambios deberían escribirse (con la propia Definición de Alcance). Entonces será el cliente quien decidirá si está dispuesto a pagar más y si acepta la fecha final revisada del proyecto. Si está de acuerdo, la nueva especificación debería ser firmada como antes.

¿Realmente necesitamos una Definición de Alcance?

Uno puede pensar que escribir una especificación lo suficientemente detallada puede generar que la realización de la Definición de Alcance conlleve más tiempo (y costo) del que está garantizado por el valor del proyecto como un todo. Por ejemplo, si se tiene previsto que todo el proyecto tome únicamente unas pocas semanas y toma cinco días escribir una especificación detallada, un análisis costo/beneficio mostraría que no vale la pena hacerlo.

Si es el caso, hay que evaluar la probabilidad del riesgo (basándonos en el conocimiento del cliente y qué tan seguro se está de todos los requerimientos que han sido identificados) y el posible impacto del aumento en contingencia suficiente en las estimaciones de tiempo y costos para cubrir todo excepto la mayor parte de las revisiones principales a la especificación.


Esta página ha sido calificada como:
Califica esta página:   

Temas relacionados:
Certificación en Administración de Proyectos de Software

 


Liberando el valor escondido en su portafolio de proyectos.
Carlos Uriegas Avendaño
+
.
.
Quienes somos I Base de conocimiento I Apoyo y servicios profesionales I Carrera y desarrollo profesional I Material de apoyo I Productos y souvenirs I Comunidad I Contacto I Aviso de privacidad
© LiderDeProyecto.com - Todos los derechos reservados. PMBOK, PMP, Project Management Professional, Project Management Professional (PMP), PgMP, Program Management Professional (PgMP), PMI-RMP, PMI Risk Management Professional (PMI-RMP), CAPM, Certified Associate in Project Management (CAPM), PMI-SP, PMI Scheduling Professional (PMI-SP), THE PMI TALENT TRIANGLE and the PMI REP Logo are registered marks of the Project Management Institute. Capability Maturity Model® y CMM® son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon®. CMM® IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. MDA®, BPMN®, SysML®, MOF®, OMG® y UML® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada por IBM Corp.