Creepeando el Scope

19 Nov

Un proyecto es un viaje que nos invita a recorrer diferentes etapas durante la producción de un producto o servicio y la correspondiente gestión de la producción. Durante estos caminos, deberemos cuidarnos de amenazas que pueden surgir. Para esto, deberemos primero aprender a reconocerlas y luego a disponer de un grupo de herramientas que nos permitan reaccionar y gestionar dichos riesgos.

Los proyectos, idealmente, comienzan por deseos de un grupo de entusiastas sponsores y usuarios en realizar o impulsar un grupo de actividades que conduzcan a lograr unos objetivos que permitan satisfacer alguna necesidad.

La base sobre la cual se sustenta un proyecto es el denominado Alcance del Proyecto (Project Scope). Esto es, ¿que vamos a hacer? ¿cuales son los objetivos que esperamos lograr con este proyecto?. Esta lista de objetivos deberia ajustarse para responder una nueva pregunta: ¿esto que QUEREMOS hacer, PODREMOS hacerlo teniendo en cuentas las restricciones de COSTOS, TIEMPOS, RECURSOS que tenemos impuestas?. Los requerimientos para los cuales me contesté que NO, entonces deberiamos sacarlos del alcance planificado.

Restricciones, bien bien, alli comienza el dilema. Al comenzar a definir el alcance, solemos definir una lista de los requerimientos (funcionales, no funcionales, etc) que el proyecto debe satisfacer. Este listado se confecciona y acuerda por un grupo de interesados entre los cuales estan los usuarios, sponsores y por otro lado el Director de Proyecto y el equipo técnico. Cuando este grupo de interesados define el alcance de forma sesgada, éste sufre consecuencias que afectarán el exito del proyecto. Estas consecuencias podemos resumirlas en las siguientes:

  • Requerimientos “Flacos”: las especificaciones no quedan claras en cuanto a que debe hacer el proyecto. Los tiempos avanzan, el equipo avanza cumpliendo lo que tiene claro pero dejando sin hacer los huecos funcionales que no fueron definidos. Aqui se avanza pero sin tener una clara perspectiva de que se esperar lograr.
  • Requerimientos “Gordos”: las especificaciones son excesivamente detalladas o contemplan aspectos extras que exceden la descripcion respecto a una verdadera necesidad del proyecto.
  • Requerimientos Dinamicos: Las especificaciones cambian constantemente sin que se pueda estabilizar la lista de requerimientos inicial y el detalle de cada uno de estos.
  • Requerimientos Innecesarios: Se incorporan requerimientos en pos de dotar al sistema de funcionalidades innecesarias para el proyecto. Aqui se busca embellecer los requerimientos con features que el cliente no desea.

Estos cuatro puntos representan posibles riesgos que afectan a la etapa de definición de requisitos y planificacion del alcance.

El punto 3 de las anomalias referidas a los requerimientos, se denomina Scope Creep. Este termino se refiere a los cambios descontrolados en el alcance de un proyecto que ya ha comenzado. El SC conduce no solo al retraso del proyecto sino tambien nos hace incurrir en mayores costos, a degradar la calidad en pos de poder cumplir con todo, y al desgano del equipo cuando las cosas no salen como fueron planeadas. El SC muchas veces es producto de una excesivo entusiasmo (o viveza) de los usuarios y sponsores que piden mas de lo que se acordó esperando que los proveedores puedan hacer mas de lo que dijeron que podrian.

El poder controlar el SC a veces viene con la experiencia que pueda tener un PM, pero no obstante, pudiendo detectar esta situacion, cualquier PM podria, al menos identificar que está ante ese problema y disponer de algunos tips para ponerse en guardia frente a la amenaza. Algunos de estos tips son:

De listado de requerimientos

1) Definir una linea base de requerimientos. Realizar un analisis completo de los requerimientos. Esto es importante ya que contra este analisis se evaluará si estamos corrompiendo el alcance o no. Aqui es importante definir una lista bastante estable de funcionalidades y cada una de ellas con el peso exacto (ni flacas ni gordas). Este documento sirve al PM para saber la cantidad de requerimientos acordados, la frecuencia con la cual aparecen los nuevos cambios y poder evaluar el impacto si se considera aceptarlos.

Del control de los requerimientos

2) Determinar un control de cambios solido. Definir un mecanismo para controlar (ojo, controlar no es negar por negar) los cambios que se desean realizar sobre la lista del punto anterior. Ese mecanismo permitirá tener una única puerta de entrada para los cambios. Dependiendo de los proyectos esta puerta puede ser giratoria o blindada (;-).

3) Asociar costos con cada cambio propuesto. Muchas veces los clientes piden cosas porque creen que no representan costo alguno. Si podemos darles a conocer, por cada cambio solicitado, cual es el costo del mismo (en materia de retraso del proyecto, inversion de dinero, etc), los clientes pensarán dos o mas veces antes de solicitar cambiar algo. En resumen, si logramos demostrarles como el cambio solicitado altera las restricciones impuestas o aprobadas por ellos, podrán analizar mas claramente si dicho cambio se justifica o no.

4) Encolar (no negar) los requerimientos. Puede que el cliente quiera igualmente incurrir en costos por el cambio que desea. Aqui, es mas conveniente recibir el cambio, priorizarlo y encolarlo segun la prioridad en la lista de requerimientos a implementar, habiendo antes el cliente entendido que el proyecto trabaja en fases y que pronto vendrá la correspondiente fase donde se desarrolle ese requerimiento.

5) No sea un “Yes man”. La importancia de decirle que “si” a un cliente es critica cuando estamos vendiendo un proyecto. Una vez acordado el inicio y comenzada la fase de desarrollo si continuamos con esa filosofia de decirle que “si” a todo, aunque agreguemos features al producto, estamos afectando a otras variables que intervienen en la ejecucion del proyecto, como son los tiempos y los costos. Aqui entonces, o no modificamos nada (o lo minimo y necesario) o el cliente acepta las consecuencias y aprueba las consecuencias.

6) Saber cuando hacer sonar la alarma: Es importante tambien notificar a managers y gerentes con informacion clave (que hace el cambio, costos, beneficios e impacto en el schedule). El objetivo aqui es lograr el conocimiento de los sponsors del proyecto para trabajar en definir si se acepta el cambio o no.

Del acuerdo de los requerimientos

7) Obtener el acuerdo por parte de los clientes. De alguna forma es importante obtener el consenso de los clientes para poder luego considerar el diseño e implementación de un requerimiento. Pero tambien es cierto que dichos clientes son reacios a colocar alguna firma que cierre la especificacion en un instante determinado ya que tampoco ellos pueden estar seguros de lo que estan solicitando. Para ello entonces deberemos buscar posibilidades para lograr dicho acuerdo sin necesidad de que nuestro cliente sienta que lo estamos hostigando para que nos cierre algo.

De la Gestion de los requerimientos

8 ) Implementar una buena herramienta de gestion de requerimientos. Estas herramientas ademas de permitir la gestion de la linea base de un proyecto, permiten que otros interesados (desarrolladores, analistas) accedan a los requerimientos y puedan consultarlos y analizarlos.

9) Estar siempre atento a la posibilidad de Scope Creep. Mantenerse alerta ante cada posibilidad de un cambio o agregado de feature. Estos son los tipicos eventos que pueden conducir al scope creep. Aunque uno sea el mejor project manager, puede que no pueda evitar el scope creep, simplemente porque existen condiciones que no pueden manejarse con los tips anteriores (o con ningun tip!). Ante esas situaciones tenemos o la posibilidad de irnos a otro proyecto o de continuar buscando minimizar los impactos negativos. El costado positivo de un proyecto con scope creep es que el PM aprende dia a dia como lidiar con los requerimientos fuera de control. Las lecciones aprendidas que pueda extraer de esos proyectos seran de muchisimo utilidad en futuros proyectos.

10) Considerar prácticas de Proyectos agiles. Los proyectos agiles permiten reducir el impacto del scope creep a partir del concepto de iteracion.

  • Proyectos tipicos: Especificacion funcional detallada al inicio, grandes documentos de requerimientos, cronograma y entregas cada 3 meses, 6 meses, etc.
  • Proyectos agiles : Especificacion funcional general  al inicio, especificacion detallada por iteracion, documentos mas pequeños, entregas cada 2 semanas.

Los proyectos agiles disminuyen la ansiedad del usuario ya que en cada iteracion se van entregando pequeñas porciones operativas del producto, las especificaciones son mas pequeñas y por lo tanto mas facil el acuerdo de que debe hacerse y en las ventanas de tiempo (las iteraciones) es factible freezar los requerimientos para que el cliente no los modifique.

En conclusion, los proyectos se planifican para cumplir con un alcance determinado. Si este alcance no esta estable y debe crecer o modificarse de forma frecuente, el no considerar el impacto en las restricciones iniciales conducirá al proyecto a resultados no deseados por los diferentes interesados.

Saludos,  Gastón

Basado en: http://www.gatherspace.com/static/scope_creep.html

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: