Sunteți pe pagina 1din 5

Dirigir efectivamente el alcance de un proyecto

Por Csar A. Portillo, PMP


ualquiera que haya ledo alguna vez literatura sobre direccin de proyectos, seguramente sabe lo importante que es definir y controlar apropiadamente el alcance del proyecto. El problema con el alcance es que puede ser ms difcil de gestionar de lo que se piensa. Dichas dificultades pueden surgir por ejemplo, de un vendedor que trata de complacer a su cliente prometindole ms entregables en el proyecto; o de un director quin le agrega entregables al proyecto sin consultarlo con el equipo del proyecto; o de un integrante del equipo tcnico que decide ampliar el alcance sin consultarlo con el equipo; o, de un cliente que se da cuenta o decide que necesita cambios en el alcance. En el mundo real, es de esperar que ocurran cambios al alcance durante el ciclo de vida de la mayora de los proyectos. Los cambios al alcance que se implementan luego de que comenz el trabajo, tendrn un efecto mayor sobre el cronograma y el costo del proyecto, que los cambios que se implementan durante la fase de inicio o planificacin; por lo tanto, es de suma importancia que se defina bien el alcance del proyecto antes de comenzar el trabajo. En el caso de que se necesiten cambios al alcance luego que el trabajo del proyecto haya comenzado, los interesados (especialmente el patrocinador, el cliente, y el equipo) deben entender exactamente cmo el alcance adicional va a impactar las fechas de entrega (el cronograma) de los entregables del proyecto y sus recursos (el costo). El propsito de este artculo es ayudar al lector a definir mejor el alcance del proyecto, dar ejemplos de algunas de las dificultades que se encuentran al dirigir el alcance del proyecto, y las consecuencias y recomendaciones para tratar dichas dificultades. Sin embargo, primero necesitamos definir qu es el alcance del proyecto. El Dr. Harold Kerzner (2006) lo define como: la suma de todos los entregables necesarios del proyecto. Esto incluye todos los productos, servicios, y resultados. (p. 406). La Cuarta Edicin de La Gua de los Fundamentos para la Direccin de Proyectos (Gua PMBOK) define el alcance del proyecto como: El trabajo que se debe realizar para entregar un producto, servicio, o resultado con las caractersticas y funciones especificadas (p. 444). Mediante estas dos definiciones vemos que el alcance del proyecto incluye todo el trabajo y los entregables que se necesitan para completar el proyecto.

Los cambios del alcance del proyecto pueden impactar el cronograma y los costos del proyecto de modo diferente dependiendo de cundo se implementen los mismos durante el ciclo de vida del proyecto.

Durante el inicio del proyecto, cuando se est desarrollando el alcance, cualquier agregado al alcance tendr el menor impacto en el cronograma o en el costo del proyecto, dado que an no se han terminado las estimaciones del cronograma y del costo y no ser necesario desechar ningn trabajo. Durante la fase de planificacin, los cambios al alcance tendrn un mayor impacto sobre el cronograma y el costo porque probablemente requerirn que se planifique ms. Esta planificacin adicional precisar ms recursos 1

Centro de Conocimiento del PMI | www.PMI.org/latam | 2010 Csar A. Portillo

humanos y tiempo extra para realizarle los ajustes al plan. La planificacin adicional tambin puede incluir un anlisis adicional de un sistema informtico, cambios a los planos de ingeniera, y compras adicionales, entre otros. Todas esas tareas le agregarn un costo al proyecto y provocarn demoras en el cronograma. En un proyecto, una vez que su trabajo ha comenzado, y luego en su ciclo de vida, los cambios al alcance aumentarn dramticamente su costo y las demoras del cronograma. Otro impacto negativo de los cambios al alcance es el impacto sobre la motivacin del equipo. En mi experiencia, los cambios que se hacen tarde en el ciclo de vida del proyecto, pueden crear sentimientos negativos dentro del equipo, lo cual puede tener un efecto perjudicial en la dinmica del equipo as como en su motivacin, trabajo en equipo, y en la organizacin en general. A continuacin hay algunos ejemplos de esto: Unos aos atrs, en una pequea compaa nacional de seguros, acept una posicin en una oficina de direccin de proyectos (PMO, por sus siglas en ingls) que recin se haba establecido. En dicha posicin, mis responsabilidades eran dirigir los programas y proyectos estratgicos, ser mentor para los directores de proyectos principiantes, y ayudar a desarrollar los procesos de direccin de proyectos a travs de toda la organizacin. Uno de mis desafos ms importantes en la organizacin fue definir y contralar el alcance, dado que los empleados crean que el ciclo de vida de cada proyecto inclua cambios de alcance que se hacan tarde, ningn proyecto terminaba a tiempo, y los costos de los proyectos no surgan de estimaciones precisas del trabajo que se necesitaba para completarlos. Los empleados tambin crean que todo el trabajo del proyecto era frustrante, y que todas las tareas del proyecto necesitaran ser hechas al menos dos veces. Cules eran los orgenes de estos problemas? La raz de estas dificultades era una definicin y un control pobre del alcance. Antes de establecer la oficina de direccin de proyectos, cuando en la organizacin se iniciaban y planificaban proyectos, solo se invitaba a unos pocos gerentes a las reuniones de inicio,

planificacin, o monitoreo y control; y slo a ellos se los consultaba sobre los proyectos. Excluir a interesados importantes durante las reuniones de inicio, planificacin, monitoreo y control provoc que se omitieran requisitos de alcance que eran necesarios. Por ejemplo, durante un proyecto de informtica para corregir un problema de un sistema de facturacin en el estado de Arizona en USA, solo se invitaba a los gerentes a asistir a las reuniones de planificacin; tambin se dejaba de lado de estas reuniones a aquellas personas quienes procesaban los formularios de facturacin. Al no tener un programador o un experto en facturacin que estuviera familiarizado con el sistema en cuestin, haca que el alcance del proyecto no incluyera todo el trabajo que se necesitaba para completar el proyecto. Al final, se comenzaba el proyecto varias veces pero no se completaba porque haba que volver a planificarlo y a rehacer cosas varias veces, y la alta gerencia congelaba los proyectos dado que se necesitaban los recursos en otra parte. Se trabaj sobre este proyecto varias veces por unos aos sin mucho avance. Luego de que se estableci la PMO, yo reinici este proyecto y me asegur de incluir y consultar a todos los interesados. El resultado final fue que el equipo complet el proyecto con xito en menos de dos meses. Esto no se logr fcilmente, dado que haba muchos otros desafos dentro de la cultura de la organizacin; sin embargo, el incluir a todos los interesados durante el inicio, la planificacin, y el monitoreo y el control del proyecto le permiti al equipo del proyecto completar el proyecto segn lo planificado. Otro desafo que tena la organizacin era controlar el alcance una vez que se haba analizado el trabajo y que ste ya haba comenzado. Los gerentes de la organizacin vean a los proyectos como una oportunidad para arreglar los problemas sin incluir en sus presupuestos el costo para corregir esos problemas. Por ejemplo, se inici un proyecto de mantenimiento de un sistema para actualizar el software que generaba las cotizaciones de las polticas de automviles de Nueva York, USA, dependiendo del ao, del modelo (un sistema de 2

Centro de Conocimiento del PMI | www.PMI.org/latam | 2010 Csar A. Portillo

tasacin), y de la marca. Este sistema terminara incluyendo trabajo para corregir el sistema de tasacin de otros estados tambin! Si el patrocinador del proyecto o cualquier otro interesado quera tratar tambin con otros problemas relacionados al sistema de tasacin, al comienzo del proyecto se debera haber analizado el trabajo necesario para corregir esos problemas y el patrocinador lo debera haber aprobado. Sin esta aprobacin del patrocinador, el trabajo del proyecto debera incluir solo el trabajo necesario para actualizar el sistema de tasacin de Nueva York. En esta organizacin sin embargo, los gerentes a menudo le pedan a los empleados de informtica que trabajaran en tareas que trataran con problemas de otros sistemas. Desde la perspectiva de los gerentes, el hecho de tener a los empleados informticos trabajando en otros incidentes conocidos durante el proyecto, les ahorrara dinero (por ejemplo, sus propios presupuestos) dado que de todos modos se estaba trabajando en el sistema. Como no se haba hecho ningn anlisis del trabajo que se agregaba al sistema, los cambios al sistema creaban otros problemas dentro del mismo que se deban corregir. Esto no solo creaba mucha frustracin al agregar trabajo sino que tambin demoraba los proyectos y le sumaba costos al mismo. Una vez que se implement la PMO y se hicieron respetar sus polticas para limitar el trabajo del proyecto en el alcance del mismo, los proyectos se completaron ms a tiempo, los costos se redujeron un 60% aproximadamente, y los empleados estaban menos frustrados. Qu pasa si quienes piden los cambios son los patrocinadores o el cliente? En mi opinin, esto pasa tpicamente por dos razones: (A) El equipo del proyecto no se comunic efectivamente con el cliente para recopilar los requisitos necesarios, y/o 2) cambi el entorno del proyecto y los cambios al alcance eran necesarios. Aqu hay otro ejemplo: trabaj en una organizacin que disea y construye centros de datos. Algunos de los problemas en esta organizacin eran que los centros de datos estaban siendo comercializados y vendidos por un vendedor, el equipo del proyecto no opinaba o casi

no lo haca respecto de la factibilidad del proyecto, y la comunicacin entre el cliente y el equipo era inefectiva. El escenario era el siguiente: se vendi un centro de datos a un cliente y se deba entregar el producto final dentro de 22 semanas. El vendedor prometi los entregables XYZ. La alta gerencia dise los contratos pero en la planificacin del proyecto no se incluy al equipo. En este caso, no se hicieron preguntas sobre los requisitos del proyecto ni se pensaron antes de firmar el contrato, lo cual result en un alcance del trabajo que era incompleto. Para corregir esas deficiencias del alcance, la alta gerencia muy a menudo estuvo de acuerdo en hacer cambios al alcance del proyecto luego de que ya se haba hecho el anlisis y la planificacin del mismo, y a menudo, luego de que ya haba comenzado el trabajo. Ya sabemos lo que pasa en los cronogramas y en los costos de los proyectos debido a cambios tardos en el alcance, asique no voy a repetir los resultados aqu. Otra fuente de cambios al alcance hechos en forma tarda eran los que solicitaba el cliente; algunos de esos cambios se deban a una definicin pobre del alcance y de su planificacin (como se mencion antes), o se deban a cambios en el entorno de negocios del cliente. El cliente solicitaba cambios al alcance del proyecto, la gerencia ordenaba esos cambios sin consultar con el equipo, y no se consideraban los efectos que los mismos tendran sobre el cronograma y el costo del proyecto. En esta organizacin, la alta gerencia y el cliente no eran la nica razn de los cambios tardos al alcance. Por ejemplo, los integrantes del equipo de ingeniera implementaban a menudo cambios al alcance en forma tarda cuando el cliente les peda algo o debido a limitaciones tecnolgicas. Dichos cambios tambin se implementaban sin ser informados al resto del equipo o sin haberles realizado un anlisis apropiado, ambos impactaban negativamente al proyecto. Este entorno disfuncional de proyectos, como vimos en el ejemplo de la compaa de seguros, provoc proyectos que se entregaron tarde, habiendo excedido su presupuesto, y con una fuerza de trabajo muy descontenta. Por ello, 3

Centro de Conocimiento del PMI | www.PMI.org/latam | 2010 Csar A. Portillo

qu podemos hacer nosotros (directores de proyectos y/o programas) para asegurar que el alcance del proyecto est bien definido para minimizar los cambios tardos durante el ciclo de vida del proyecto, y para asegurar que los interesados entienden el impacto que tienen los cambios al alcance?

A continuacin se presenta un resumen de las actividades que deberan conducir a asegurar que se define bien el alcance del proyecto para eliminar, o para reducir drsticamente, los cambios al alcance luego de que se haya planificado. En el caso de que sean necesarios cambios del alcance luego de la planificacin, inclu qu se debe hacer para gestionar adecuadamente los cambios al alcance.

Recomendaciones

2. Asegurarse de que el equipo del proyecto, el patrocinador y el cliente, estn de acuerdo con los entregables. 3. El acta de constitucin del proyecto debera incluir una lista completa de tareas y de entregables que estn fuera del alcance del proyecto. 4. Asegurarse de que toda esta informacin se actualiza en el acta de constitucin del proyecto. 5. Asegurarse de que el patrocinador, el cliente, y el equipo, firman el acta de constitucin del proyecto. 6. Asegurarse de que se desarrolla un plan de proyecto preciso.

Durante la ejecucin del proyecto


1. Asegurarse de no realizar trabajo que est fuera del alcance del proyecto. 2. Asegurarse de que las solicitudes de cambio al alcance del proyecto se comunican efectivamente al cliente y que ste las entiende. 3. Si un miembro del equipo, un gerente, o un cliente solicita cambios, asegurarse de que estos cambios se analicen bien, que se expliquen todos los impactos que tendrn sobre el proyecto, y que lo firme el patrocinador y/o el cliente. 4. Asegurarse de que el acta de constitucin del proyecto, y el plan, reflejen los cambios aprobados al alcance, los cuales muy probablemente incluirn cambios al cronograma, a los recursos, y a los costos. 5. Si la alta gerencia demanda que se implementen cambios al alcance que se haban rechazado, discuta el incidente con el patrocinador y pdale ayuda. Ponga lo mejor para resolver esta situacin y asegrese de que todos los interesados entiendan los efectos que tendrn en el proyecto los cambios solicitados. 6. En el mundo real, hay veces que la alta gerencia ordena que se implementen cambios al alcance, sin importar el impacto en el proyecto; en esos casos, Ud. tiene dos opciones: 4

Durante el inicio del proyecto


1. El proyecto debera ser patrocinado por un ejecutivo o una persona de la alta gerencia cuyo trabajo sea eliminar las piedras del camino que puedan tener impactos negativos sobre el equipo del proyecto y sus entregables. 2. Asegurarse de que se incluyen a todos los interesados cuando se desarrolla el acta de constitucin del proyecto, y que se desarrolla el alcance preliminar. 3. Asegurarse de que se entienden los requisitos del proyecto lo mejor posible. Estos requisitos evolucionarn durante la planificacin del proyecto, pero un mejor entendimiento durante la fase de iniciacin facilitar la definicin del alcance durante la fase de planificacin. 4. Desarrollar el acta de constitucin del proyecto.

Durante la planificacin del proyecto


1. Asegurarse de responder las preguntas que tiene el equipo del proyecto sobre aspectos tcnicos, entregables, y sobre el cronograma.

Centro de Conocimiento del PMI | www.PMI.org/latam | 2010 Csar A. Portillo

(1) pedir que lo asignen a otro proyecto o que lo saquen del proyecto, lo cual sera una opcin bien difcil en la economa de hoy; o (2) implementar los cambios pero solicitar que el gerente que lo solicita apruebe por escrito los cambios y los efectos sobre el proyecto.

Project Management Institute. (2008). Cuarta Edicin. La Gua de los Fundamentos para la Direccin de Proyectos (Gua PMBOK ). Newtown Square, PA.

Los cambios al alcance del proyecto tendrn un impacto sobre el cronograma y/o los recursos del proyecto. Este impacto puede aumentar dramticamente cuanto ms tarde se pidan los cambios en el ciclo de vida del proyecto. Como personas que practicamos la direccin de proyectos y como profesionales, es crtico minimizar los cambios al alcance, especialmente una vez que comenz el trabajo. Para hacerlo, tenemos que desarrollar lo ms exactamente posible el alcance del proyecto, lo cual se puede lograr asegurando de involucrar a todos los interesados que participarn en las tareas; respondiendo a todas las preguntas, alcanzando un acuerdo sobre el alcance del trabajo y los entregables, documentando este alcance, y asegurndose de que no se realizar trabajo que est fuera del alcance del proyecto. Si un alto gerente le fuerza para que realice cambios al alcance, asegrese de analizar todos los efectos que tendrn estos cambios sobre el proyecto, y asegrese de obtener la firma, del gerente que los solicita, en el formulario de solicitud de cambios

Conclusin

Cesar A. Portillo tiene ms de 13 aos de experiencia en direccin de programas y proyectos en las industrias de manufactura, transporte, seguros, y tecnologas de la informacin, as como en trabajo en equipo, comportamiento y cambio organizacional, calidad y Lean SixSigma. Tiene un ttulo universitario en sistemas de informacin y negocios, y una maestra en tecnologas de la informacin. Es titular de la certificacin PMP y est certificado como Gerente Certificado en Calidad y Excelencia Organizacional por la Sociedad Americana de Calidad, as como es Cinturn Verde Certificado de ASQ Six Sigma. Adems, en Baker College Center for Graduate Studies, en Flint, Michigan, USA es candidato en el doctorado en administracin de negocios con una concentracin en desempeo y cambio organizacional. Lo puede contactar a cesarportillo@sbsglobal.net.
Artculo traducido del original en ingls titulado Effective project scope management en la Biblioteca Virtual del PMI (PMI Virtual Library) de www.PMI.org Si tiene alguna sugerencia de mejora de esta traduccin al espaol puede enviarla a LASpanishNews@pmi.org

Sobre el autor

Referencias

Kerzner, H. (2006). Project management: A systems approach to planning, scheduling, and controlling. Hoboken, NJ: John Wiley & Sons, Inc.

Centro de Conocimiento del PMI | www.PMI.org/latam | 2010 Csar A. Portillo