Barra Superior

PMOinformatica.com
La oficina de proyectos de informática
La web sobre gerencia de proyectos de informática, software y tecnología.
Síguenos en:     

lunes, 19 de noviembre de 2012

Los cambios de alcance en los proyectos de informática

Imagen de: Picasa Web Albums
En un entorno tan dinámico como el de los tiempos actuales, todo proyecto está expuesto a la posibilidad que ocurran cambios de alcance durante su desarrollo.

En proyectos de informática está prácticamente asegurado que una vez que el cliente vea el producto se requerirán “ajustes” respecto al diseño original, además, la necesidad del área de negocio podría variar desde el inicio del proyecto hasta su entrega.

En este artículo se discute los distintos tipos de cambios de alcance que puede enfrentar un proyecto de informática, los posibles impedimentos para negociarlos con el cliente y los peligros representados en los mismos.

Además se expresan una serie de pasos que se pueden seguir para gestionarlos con el cliente.

Gestión de cambios de alcance independientemente del enfoque de desarrollo de software

Independientemente de si se está aplicando un enfoque de desarrollo ágil o un enfoque predictivo tradicional, siempre existe la necesidad de manejar las expectativas del cliente en cuanto a los cambios que solicite.

Bajo un enfoque de desarrollo ágil, los cambios se manejan al final de la iteración, si el número de iteraciones es finito y se desea incluir nuevas funcionalidades o modificar las existentes es necesario reemplazarlas por otras de menor prioridad en la lista de funcionalidad por desarrollar (Backlog), si esto no es posible (el cliente necesita todo lo que está en el Backlog), es necesario agregar iteraciones adicionales, resultando en mayor tiempo y presupuesto.

En un enfoque predictivo tradicional, los cambios, luego de valorarse, deberán evaluarse en función de su impacto sobre el proyecto previamente definido, si implica mayor tiempo o costo esto deberá aprobarse y si no se cuenta con presupuesto (o no se puede mover el tiempo), deberá descartarse alguna otra funcionalidad del alcance.

Como se puede ver en ambos casos (Ágil o Tradicional predictivo), todo cambio siempre tendrá un impacto en alcance, tiempo o costo, y esta expectativa es necesario manejarla con el cliente.

Cambios en la funcionalidad

Los cambios que resultan de menor complejidad para negociar con el área usuaria son los de funcionalidad, pues está claro que se está solicitando algo adicional.

Pero cuidado, existen dos posiciones extremas que suelen adoptar los desarrolladores de software, una posición es la de aceptar y desarrollar absolutamente todo lo que el usuario les diga, resultando en inversión de mayor tiempo y costo. La otra posición extrema es solicitar cambios de alcance por todo, inclusive por cambios menores de configuración, textos en mensajes, entre otros.

En aras de preservar la buena relación entre el área de Tecnología de Información y el área de negocio es recomendable adoptar una posición no extremista respecto a este asunto, definiendo umbrales o niveles de tolerancia sobre cambios cuando el producto es sometido a revisión.

Otra alternativa para evitar los cambios y el retrabajo es someter el producto a revisiones continuas por parte del usuario, tal como lo establecen metodologías tradicionales de Prototipos o los nuevos enfoques de desarrollo ágil.

Es necesario definir esto desde el principio, para que el área usuaria tenga las expectativas claras en que, por ejemplo, puede solicitar cambios en los textos de mensajes, pero no puede solicitar un módulo adicional no identificado previamente en la fase de análisis.

Cuidado con el “Scope Creep”

Sin descargo de lo dicho anteriormente, debe tenerse cuidado con los ajustes menores al producto. Por ejemplo, en el caso de un mensaje de texto en una pantalla software, solicitar cambiar un texto de una pantalla parecería no tener mucho impacto, pero ¿Qué sucede si el usuario revisa los textos de las más de 300 pantallas de una aplicación y solicita cambios sobre todas?, ¿seguiría teniendo un impacto menor sobre el proyecto?, posiblemente no.

¿Y qué ocurriría si estos cambios no se solicitan todos en un mismo período?, sino a lo largo de varios meses, ¿Cuándo identificaríamos que tenemos un cambio de alcance?, ¿Podríamos negociar con el cliente un cambio de alcance al final del proyecto?, posiblemente no.

Como se mencionó anteriormente, lo mejor es definir niveles de tolerancia para estos cambios, que evalúen no solamente cada solicitud de cambio individual sino la agregación de las mismas, de esta forma se puede manejar con anticipación la expectativa del cliente, señalándole por ejemplo que si continúan solicitando los ajustes a la tasa actual, sería necesario solicitar un cambio de alcance en un tiempo dado.

Cambios técnicos

Los cambios de alcance de naturaleza técnica son más difíciles de negociar con los usuarios finales que los cambios de funcionalidad.

Por ejemplo, que sucedería si somos un desarrollador externo y al principio del proyecto el área de TI nos dijo que existían una serie de servicios para acceder a una aplicación, realizamos nuestra estimación bajo ese supuesto, pero luego se descubre que los servicios no existen y deben desarrollarse.

Claramente es una funcionalidad adicional a desarrollar, pero, ¿es asignable el cambio de alcance al usuario?, no necesariamente. El usuario podría decir que es un aspecto técnico no relevante para ellos y el área de TI podría decir que es responsabilidad del proyecto identificar la totalidad del alcance técnico a desarrollar.

En el caso del alcance técnico, los cambios de alcance tienen mucha menor probabilidad de aceptación, por lo que lo mejor es la prevención, validando el diseño técnico de la solución en el sitio (por ejemplo inspeccionando y realizando pruebas sobre estos servicios), antes de comprometer la estimación.

Establecer procedimientos de cambios de alcance

Independientemente del enfoque de desarrollo de software aplicado (ágil o predictivo), es una buena práctica tener un procedimiento de revisión de cambios de alcance previamente acordado con los distintos involucrados en el proyecto, tanto del área usuaria como de otros interlocutores de áreas técnicas.

Dicho procedimiento debería contemplar como mínimo lo siguiente:

  • Solicitud de cambio: Establecer quien realiza solicitudes de cambio, cual es el canal de comunicación apropiado y bajo que formato. Es importante evitar que se hagan solicitudes directas a los desarrolladores (por ejemplo durante un Product Review) y que estos tengan que dar respuesta inmediata.
  • Análisis y valoración: El equipo revisa la solicitud y determinar el esfuerzo (por ejemplo en horas) y la posible planificación (Fecha). Es importante revisar su impacto sobre duraciones y costos previamente establecidos.
  • Determinar si es un cambio menor: Si el cambio está dentro de umbrales previamente establecidos, este puede ser aprobado de forma expresa, por ejemplo por el desarrollador en sitio o por el Gerente del Proyecto. Si por el contrario, el cambio excede un umbral, puede establecerse en el procedimiento que lo debe aprobar el comité.
  • Comité de cambios: Un comité integrado por miembros del equipo, del usuario y otros involucrados debe revisar la solicitud ya valorada por el equipo. Aquí deben tomarse decisiones, se extiende el plazo (por ejemplo se agrega otra iteración), se incrementa el presupuesto para incorporar personal adicional, o se intercambia por otro componente del alcance no desarrollado aún que tenga el mismo valor. Este comité es quien aprueba los cambios.
  • Ejecución del cambio: Sólo después que se han cumplida la aprobación, bien sea por vía expresa o por la vía de comité de cambio, se procede a desarrollar el cambio de alcance.

Para el caso de enfoques de desarrollo ágiles, este procedimiento está inmerso en el proceso, por lo general la solicitud se realiza durante la revisión del Producto, para luego valorar y aprobar (o rechazar) el cambio al inicio de la próxima iteración durante la fase de planificación de la misma. Para el caso de enfoques predictivos, puede adoptarse un procedimiento de control de cambios, como por ejemplo el establecido por el “Project Management Institute” (PMI) en el área de conocimiento de Gestión Integrada.

¿Qué ocurre en situaciones cuando el tiempo apremia porque la fecha de entrega esta próxima?, pues debe hacerse de forma expedita, posiblemente valorándolo el mismo día y discutiéndolo lo antes posible en una teleconferencia.

Conclusión

¿Y qué opina usted?, ¿Qué recomendaría para gestionar los cambios en los proyectos?, ¿Cómo manejaría la negociación y relación con el cliente?. Le invitamos a participar en el foro de discusión del blog de “La Oficina de Proyectos de Informática” y a suscribirse al blog por los distintos canales, incluyendo lista de correo electrónico, al Twitter @PMOInformatica y página de Facebook .


¿Interesado en libros sobre gestión de proyectos?






















PMP Exam Prep 7th Edition
Autor: Rita Mulcahey
>> España (amazon.es)
>> Latinoamérica (amazon.com)
Como implantar una
oficina de gestión de proyectos
Autor: Antonio Alonso Gonzalez
>> España (amazon.es)
>> Latinoamérica (amazon.com)
Project 2010 paso a paso
Autor: Carl Chatfield
>> España (amazon.es)
>> Latinoamérica (amazon.com)
Gestión de Proyectos Informáticos
Autor: Brice-Arnaud Guerin
>> España (amazon.es)
>> Latinoamérica (amazon.com)



25 de Octubre 2012: Los Productos de la semana. >>Ver Productos de la Semana
19 de Octubre 2012: Los Productos de la semana. >>Ver Productos de la Semana
Octubre 2012: Más buscados en desarrollo ágil. >>España >>Latinoamérica
Octubre 2012: Más buscados en gestión de proyectos. >>España >>Latinoamérica
Sección de productos Amazon. >>Visítala


Otros artículos en “La Oficina de Proyectos de Informática”

Gerencia de Proyectos

>> Gestión de Proyectos: 5 tareas clave para dirigir la fase de ejecución

>> 5 preguntas y respuestas sobre la identificación de riesgos

>> Como hacer el seguimiento de los riesgos en proyectos

>> Plantilla para la Gestión de Riesgos en proyectos: Actualización Octubre 2012

>> Plantilla para documentar Lecciones Aprendidas

>> Como hacer el seguimiento de los riesgos en proyectos

>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?

>> Las reuniones de trabajo: más productividad, menos reuniones

>> El patrocinador (Sponsor) del proyecto: Rol que debe asumir y lo que no debe hacer

>> Como lidiar con implicados (stakeholders) problemáticos

>> Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)

>> Las preguntas que debe hacer al encargarse de un proyecto de Tecnología de Información (TI) en ejecución

>> Diseño y desarrollo de software en proyectos Fastrack: Como minimizar los riesgos

>> 10 actividades críticas a incluir en todo plan de desarrollo de un software

Gestión de desarrollo de software

>>10 actividades críticas a incluir en todo plan de desarrollo de un software

>> Los pasos para resolver incidentes en el período de estabilización de un desarrollo de software

>> Ambientes de pruebas integrales de software: Buenas prácticas

>> Ambientes de desarrollo de software: Buenas prácticas

>> Algunas prácticas de desarrollo de aplicaciones web para asegurar calidad, mantenibilidad, escalabilidad y seguridad

>> Herramientas de software para gestión de proyectos de desarrollo ágil

>> Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)

>> Las preguntas que debe hacer al encargarse de un proyecto de Tecnología de Información (TI) en ejecución

Desarrollo ágil, Scrum y Test Driven Development

>> 5 Preguntas y respuestas sobre el Feature Driven Development (FDD)

>> Test Driven Development (TDD): 9 retos para su implementación y cómo hacerles frente

>> Plantillas Scrum: historias de usuario y criterios de aceptación

>> El “Test Driven Development” (TDD): Desarrollo y pruebas de software bajo Scrum

>> Scrum de Scrum: Desarrollo ágil para grandes proyectos

>> 5 métricas de desempeño para proyectos de desarrollo ágil y Scrum

>> Herramientas de software para gestión de proyectos de desarrollo ágil

>> El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos

>> Los Programas de Certificación del Scrum Alliance

>> Preguntas y respuestas sobre Scrum Alliance

>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?

>> Metodologías de desarrollo ágil

Otros temas

>> Habilidades interpersonales cada vez más demandadas en los profesionales de Tecnologías de Información

>> Las Habilidades y Conocimientos más buscados en el área de Tecnología de Información (TI)

No hay comentarios :

Publicar un comentario en la entrada

Pmoinformatica.com," La Oficina de Proyectos de Informática ", es un participante en el Programa de Servicios de Amazon Associates LLC, un programa de publicidad de afiliación diseñado para proporcionar un medio para que sitios web puedan ganar honorarios por la publicidad y enlaces a amazon.com y amazon.es.