Iniciación del proyecto y trabajos previos

  • José Ramón Rodríguez

    José Ramón Rodríguez

    Es consultor independiente en Dirección de Tecnologías de la Información y Gestión de Proyectos TIC, profesor de Sistemas de información y dirección de las TIC de la UOC y autor de artículos y libros sobre estas materias. A lo largo de su carrera profesional, ha alternado la actividad entre el sector privado y el sector público como directivo y consultor. Ha sido ejecutivo de empresas internacionales de servicios de sistemas de información y gerente de organización y sistemas de información en diferentes servicios públicos. Es licenciado en Filosofía y Letras, PDG del IESE y cuerpo técnico de la Seguridad Social. Su último libro es Gestión de proyectos informáticos: métodos, herramientas y casos, publicado por la editorial UOC.

  • Pere Mariné Jové

    Pere Mariné Jové

    Ingeniero superior en Informática (UPC), magíster en Gestión pública (UAB), DEA en Sociedad del conocimiento y de la información (UOC) y PMP del Project Management Institut. Es consultor de estrategias tecnológicas de negocio y de metodologías de dirección de proyectos. Ha trabajado como director de SI y director de proyectos en diversas organizaciones, públicas y privadas, tanto grandes como pequeñas, ha sido consultor y formador de metodologías de dirección de proyectos, externalización y calidad en los últimos años, así como colaborador externo desde el año 2001 en la UOC, en las asignaturas de GOPI y MGPI de las ingenierías de Informática, así como de Gestión de proyectos en el máster TIC, y en la UAB.

PID_00215825
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares del copyright.

Introducción

En los módulos anteriores hemos presentado el marco conceptual de la gestión de proyectos TIC, es decir, la terminología y definiciones que utilizaremos aquí, las etapas del ciclo de vida de los proyectos, las áreas de conocimiento o procesos de gestión que debe manejar el jefe de proyecto y el cuerpo metodológico que utilizaremos principalmente como referencia, el Project management body of knowledge (PMBOK). En este módulo y los siguientes, iremos siguiendo las diferentes etapas del ciclo de vida de gestión y cómo se aplican los procesos de gestión en cada una de ellas.
Figura 1. Etapas del ciclo de vida de proyectos TIC
Desde el punto de vista de la gestión de proyectos, la etapa de iniciación tiene como objetivo obtener un mandato claro y definido de comienzo (autorización) del proyecto: saber qué hay que hacer, por qué hay que hacerlo, para qué servirá, quiénes son las personas o departamentos afectados, interesados o que influirán en el proyecto, y cuáles son los límites iniciales de presupuesto y tiempo con los que contamos. Es deseable conocer también cómo se medirá el éxito y cuál es el valor o beneficio para el negocio que tiene el trabajo. Y alguien, que normalmente forma parte de la dirección de la empresa y es ajeno al proyecto en sí mismo, tiene que tomar formalmente la decisión de tirarlo adelante, tiene que dar su aprobación. Es también el momento de establecer a un alto nivel los órganos individuales y colectivos de gestión del proyecto.
Esto vale tanto para un proyecto nuevo, como para una fase importante o un sub-proyecto dentro de un proyecto mayor o para un proyecto contenido en una cartera o programa de proyectos.
Como hemos señalado en los capítulos anteriores, la gestión del alcance (el qué se hará y el qué NO se hará en el proyecto) y consecuentemente de los cambios a lo largo del trabajo, es probablemente el aspecto más crítico para el cumplimiento de los objetivos del proyecto. Por tanto, ya en esta etapa inicial, debe realizarse una primera aproximación de alcance, aprobada por la dirección, que se revisará y detallará exhaustivamente en la etapa de planificación.
Es importante recordar que la gestión de proyectos TIC es un proceso iterativo, donde a lo largo del ciclo de ejecución se monitorizan los progresos con relación a las definiciones iniciales y a los planes de trabajo, se analizan las desviaciones si es el caso, se proponen medidas correctoras, se proyecta el impacto de las desviaciones y las correcciones, se elabora un nuevo plan, etc.
Todo proyecto TIC fue un día un problema o una necesidad de la organización que se convirtió en una oportunidad de cambio y, a continuación, en una propuesta de proyecto, y que compitió con otras por la asignación de recursos. O, como dice Marchewka (2003) para los proyectos informáticos, "un sistema de información es un cambio organizativo planificado". Por tanto, aunque no forme parte estrictamente de la gestión del proyecto, es importante conocer (y tener acceso) a la documentación, razonamientos o al conocimiento de las situaciones que han llevado a la dirección de la empresa o de su departamento de organización y sistemas a impulsar un proyecto TIC y el valor concreto y medible para el negocio que se desea obtener. También nos referiremos brevemente en este módulo a estos trabajos previos de diagnóstico, conceptualización, elaboración del caso de negocio (business case) y selección de un proyecto TIC por parte de la dirección.

Objetivos

Al término del estudio de este módulo, deberéis ser capaces de conocer y aplicar el conjunto de procesos necesarios para la iniciación del proyecto, desde el punto de vista de su gestión y, más en concreto:

  1. Cómo se concibe inicialmente un proyecto, identificando problemas y oportunidades de la empresa y transformándolos en una idea o primer concepto de lo que será un proyecto.

  2. Cómo se realiza un estudio de viabilidad o caso de negocio (business case), para examinar si un proyecto es factible técnica, económica y organizativamente y qué beneficios o valor aporta.

  3. Cómo se prepara la documentación necesaria para la aprobación del proyecto y qué es el acta de constitución (project charter).

  4. Cómo se identifican las partes (departamentos o personas) que tendrán cualquier clase de influencia o impacto en el proyecto o que serán influenciados como consecuencia de su realización, y cómo se define inicialmente una estrategia para manejar sus expectativas y preocupaciones.

  5. Cómo se identifican los interesados, su influencia y su interés en el proyecto.

  6. Cómo se establece la definición inicial o documento inicial de alcance.

1.Etapas previas a la iniciación del proyecto

Un proyecto surge o debe surgir cuando se identifica un problema o una oportunidad en el negocio en cualquiera de las áreas de la empresa (mejorar el servicio al cliente, reducir el tiempo de desarrollo de un nuevo producto o los plazos de entrega de los proveedores, mejorar el control financiero interno, facilitar la identificación de nuevos talentos en la empresa y desarrollar los recursos humanos, automatizar los trámites de una administración pública, etc.) o al propio departamento TIC.
Un proyecto debería mejorar o transformar procesos de negocio para aumentar la ventaja competitiva de la empresa. No hay proyectos TIC, sino proyectos de negocio, que se apoyan de una u otra manera en herramientas TIC. Y al revés, hoy no se puede pensar en transformaciones de procesos de negocio sin tener en cuenta las tecnologías de la información y las comunicaciones.
Las razones más frecuentes por las que las empresas abordan proyectos TIC se resumen en la tabla 1.
Fuente: propia y Marchewka (2003)
Tabla 1
Principales razones para abordar proyectos TIC

  • Reducir costes.

  • Crear un nuevo producto o servicio.

  • Mejorar el servicio al cliente.

  • Mejorar las comunicaciones internas o externas.

  • Mejorar la toma de decisiones.

  • Disponer de mejor información y más rápidamente.

  • Crear o fortalecer las relaciones con proveedores, clientes y socios.

  • Mejorar o transformar los procesos.

  • Adaptarse a requisitos legales.
Por tanto, en el análisis y aprobación de nuevos proyectos, los criterios para la empresa no suelen ser de elegancia técnica o de actualización tecnológica, sino de impacto en los resultados y retorno de la inversión. Asimismo, cada vez más se emplean criterios propios de la gestión de proyectos, es decir, de la viabilidad o éxito del proyecto en sí mismo. Los factores concretos y métodos de evaluación y selección varían de una organización a otra.
En algunas ocasiones, las empresas estructuran globalmente esta fase dentro de un ejercicio formal de planificación estratégica de sus sistemas de información, de carácter plurianual, en el que se identifica toda la cartera de proyectos que se abordarán en un periodo.
Normalmente, en un primer momento, que podríamos llamar de diagnóstico y conceptualización, se identifica y documenta el problema u oportunidad de negocio que puede dar lugar a la realización de un proyecto. Esta iniciativa puede ser de un área funcional o de negocio o del propio departamento de sistemas. El diagnóstico y correcta identificación del problema son clave. Para esto, las empresas utilizan técnicas de identificación de problemas (por ejemplo, diagramas de causa y efecto, técnicas estadísticas, encuestas de calidad), generación de ideas (por ejemplo, lluvia de ideas o brainstorming, reuniones de grupo o focus groups) y priorización (por ejemplo, matrices de impacto, análisis de Pareto) y recurren a equipos de trabajo internos y consultores externos.

1.1.Análisis de viabilidad y caso de negocio (business case)

Este análisis inicial puede servir para identificar cualitativamente alternativas de acción, pero no es suficiente para que la dirección tome decisiones. Se requiere un estudio (más o menos detallado, según las características del proyecto y las circunstancias de la empresa) de la viabilidad técnica y económica y una primera estimación de objetivos, resultados esperados y costes para la organización. En los proyectos TIC, determinar el valor medible de un proyecto para la organización (o valor para el negocio), el coste total de la propiedad y el beneficio total de la propiedad de una inversión TIC no es nada sencillo y además todavía no está muy extendido. Las mayores dificultades acostumbran a ser encontrar métricas que permitan valorar el impacto y beneficios, por un lado, y recoger todos los costes e ingresos reales presentes y futuros de una inversión en TIC.
En todo caso, es importante completar los análisis cualitativos con análisis cuantitativos y elaborar alternativas potenciales de inversión donde se valore el coste de hacer y el coste de no hacer bajo diferentes escenarios. El análisis de alternativas debe basarse en modelos financieros, como el periodo de recuperación de la inversión, el punto en el que el proyecto recuperará la inversión realizada (punto de equilibrio), el cálculo de la ratio de retorno de la inversión, el valor actual neto del dinero a desembolsar o flujos de caja descontados, e incluso otros más sofisticados, como el impacto en el resultado operativo de la empresa (EBIDTA).
Todo esto no es tan exagerado. Muchos proyectos TIC representan una inversión millonaria y compiten con otros proyectos de inversión estratégica de la empresa en otra clase de activos a los que es costumbre desde hace tiempo demandarles esta clase de análisis. Y en las empresas cotizadas, muchos inversores analizan con lupa las decisiones de inversión de la dirección en proyectos TIC.
El análisis de viabilidad debe incluir criterios económicos y de negocio, pero también organizativos, técnicos y de gestión de proyecto. Un guión tentativo de un análisis simplificado de este tipo se presenta en la tabla 2.
Tabla 2
Guión de análisis de viabilidad

  • Resumen ejecutivo.

  • Identificación de la oportunidad. Descripción del problema.

  • Cualificación de la oportunidad. Evaluación inicial del potencial de mercado o mejora de las operaciones. Resultados que hay que obtener.

  • Evaluación inicial de la tecnología disponible y benchmarking de otras experiencias, si las hay.

  • Evaluación de capacidades propias u otras que se deban adquirir. Base tecnológica y recursos humanos.

  • Evaluación inicial de coste-beneficio.

  • Identificación de riesgos principales. Cualificación inicial.

  • Objetivos y contenidos del proyecto. Visión preliminar.

  • Evaluación inicial de tiempo y coste. Principales partidas.
Un modelo más completo de caso de negocio (business case) debería incluir la descripción de las alternativas y los resultados de su análisis bajo las métricas financieras y otras utilizadas.
En ocasiones, en este ejercicio inicial se involucran consultores o, al menos, la lista corta de proveedores de servicios informáticos de la empresa, lo que permite disponer de una visión externa complementaria y una primera valoración técnica y económica de los posibles contratistas. Los proveedores realizan también una primera cualificación de la oportunidad y de los riesgos.

1.2.Selección de proyectos

Según hemos visto, cualquier proyecto TIC que se eleve a la dirección, bien sea individualmente o como parte de un programa más amplio, debe cumplir varias condiciones:
a) Tiene que alinearse con las estrategias y objetivos de la organización.
b) Tiene que proporcionar un valor o beneficio de negocio que sea medible o verificable al terminar el proyecto.
c) Tiene que soportarse en métricas cuantitativas, particularmente financieras, que permitan obtener el retorno de la inversión, calculando todos los costes y beneficios de la inversión.
d) Debe demostrar la viabilidad técnica, organizativa y de gestión del propio proyecto.
Un resumen de estos criterios se muestra en la tabla 3.
Fuente: Rodríguez, García Mínguez y Lamarca (2007)
Tabla 3
Criterios para seleccionar proyectos informáticos
Criterios de negocio

  • ¿Qué valor añade el proyecto a nuestros clientes?

  • ¿Mejorará el proyecto nuestra posición frente la competencia, y por cuánto tiempo?

  • ¿Contribuye el proyecto a nuestras estrategias externas o internas?

  • ¿Cuál es la contribución del proyecto al resultado y cuándo se producirá?

  • ¿Recuperaremos la inversión incurrida? ¿Cuándo?

  • ¿Cómo percibirán el proyecto nuestros accionistas? ¿Y el público en general?

  • ¿Cuál es el riesgo de no ejecución en contenido, tiempo y costes? ¿Puede asumirlo la empresa en su conjunto?

Criterios de gestión de proyectos

  • ¿Están bien definidos los objetivos y resultados?

  • ¿Tiene un patrocinador claro en el comité de dirección? ¿Se han alcanzado acuerdos con los departamentos involucrados?

  • ¿Está claro el alcance? ¿Se han analizado los riesgos? ¿Son asumibles?

  • ¿Cuál es el plan de trabajo? ¿Cuándo tendremos los productos principales?

  • ¿Dispondremos del equipo con la dedicación y capacidades adecuadas? ¿Hay un jefe de proyecto capaz de llevarlo a cabo y dedicado completamente al proyecto?

  • ¿Existe la tecnología? ¿Está madura? ¿Tenemos las capacidades o podemos tenerlas a tiempo? ¿Hay proveedores cualificados?

Asimismo, no hay que ignorar los aspectos políticos, de oportunidad o personales que están presentes en cualquier organización (puede verse el capítulo 2 del manual de Olson y el libro de Pinto, entre otros).
Para comparar unos proyectos con otros, se usan métodos como los siguientes:

  • El screening, o revisión de los beneficios de un proyecto contra una lista de criterios elaborada por la empresa (por ejemplo, el esquema anterior de criterios para valorar proyectos informáticos se podría convertir fácilmente en una lista de control o checklist para una revisión tipo screening).

  • Los scoring, o métodos en los que se adjudican pesos a una serie de criterios y se valora la medida en la que cada proyecto presentado cumple los criterios definidos. Los métodos de scoring sirven para establecer prioridades dentro de una cartera de propuestas.

Como hemos venido comentado, las fronteras entre unas y otras fases sólo existen muchas veces en la teoría. Efectivamente, el resultado de estas fases previas es, en muchas ocasiones, la aprobación formal del proyecto por la dirección y la redacción de un mandato o acta de proyecto (project charter) que, según las metodologías (incluida la nuestra) pertenece propiamente a la iniciación del proyecto, según veremos a continuación.

2.Desarrollar el acta de constitución del proyecto

El primer proceso, desarrollar el acta de constitución del proyecto, tiene como objetivo documentar la autorización formal de inicio del proyecto y de cada una de las fases del mismo, a la vez que recoge y documenta las necesidades de negocio y las expectativas de los interesados que lo justifican. El acta de constitución del proyecto, project charter en inglés, podríamos decir que es el mandato del proyecto, es el "encargo" que se le hace al director o jefe del proyecto.
Fuente: PMBOK (2008)
Tabla 4. Desarrollar el acta de constitución del proyecto: entradas, herramientas y técnicas, y salidas del proceso
Desarrollar el acta de constitución del proyecto
Entradas
Herramientas y técnicas
Salidas

  • Petición de trabajo

  • Caso de negocio

  • Contrato

  • Factores ambientales de la empresa

  • Activos de procesos de la organización

  • Juicio experto

  • Acta de constitución del proyecto
Los proyectos son autorizados por un patrocinador (sponsor) externo a la dirección del proyecto, por una oficina de proyectos, por el gerente o comité ejecutivo de un portafolio o por otros tipos de organismos directivos. El patrocinador debe tener la autoridad necesaria para poder disponer de los recursos que el proyecto requerirá. La autorización incluye el nombramiento del director del proyecto, director que es recomendable que haya participado en la confección del acta con objeto de conocer ya el proyecto y participar en las primeras decisiones del mismo.
Para la elaboración del acta de constitución del proyecto, habrá que disponer de alguno de los siguientes elementos:

  • El enunciado del trabajo del proyecto (SOW): es una descripción narrativa de lo que se pide del proyecto, qué ha de incluir como mínimo, la necesidad de negocio que lo justifica, una descripción del alcance a alto nivel, así como la posible vinculación con los planes o desarrollos estratégicos de la organización.

  • Caso de negocio: como hemos explicado en el apartado anterior, este incorpora la información necesaria que justifica el proyecto. Este puede haber nacido por múltiples motivos, entre otros: una demanda del mercado, una solicitud de un cliente, una necesidad comercial, un adelanto tecnológico, un requisito legal, una necesidad ecológica o social.

  • Contrato: en el supuesto de que el cliente sea externo a la organización ejecutante, suele haber un contrato que ya concreta a alto nivel el proyecto y que por lo tanto es fundamental para confeccionar el acta.

Factores ambientales y activos de los procesos de la organización que guiarán en la forma en que se enfoca el proyecto, desde la simple plantilla del acta y la información histórica de como se ha tratado en otros casos similares, hasta las políticas e infraestructuras disponibles para la resolución del proyecto.
Para la confección del acta habrá que recurrir al juicio experto de los intervinientes, o de otros expertos de la organización con conocimientos de las buenas prácticas aplicables en este proceso. También se puede recurrir a otros expertos, tales como consultores externos, la PMO y otros.
Cabe recordar que hablamos del "proceso" de desarrollar el acta de constitución, por el hecho de que cada organización, aparte del documento del acta como tal, puede requerir otras tareas o actividades para iniciar un proyecto. Actividades que pueden ir desde la codificación del proyecto, el alta del mismo en el sistema contable, en el sistema de información de gestión de proyectos, la preparación de espacios físico y/o virtuales que habrán de usar los recursos del proyecto y un largo etcétera que cada organización crea en función de su cultura organizativa. A la vez, pueden incluir la recogida de una serie de informaciones complementarias que proponemos como mínimas para el acta.
La tabla 5 muestra el contenido típico mínimo del acta de constitución o project charter:
Tabla 5
Contenido mínimo del acta de constitución o project charter

  • El propósito o la justificación del proyecto: valor para el negocio.

  • Sus objetivos y los criterios de éxito (factores críticos de éxito).

  • Requisitos a alto nivel.

  • Descripción del proyecto a alto nivel.

  • Riesgos a alto nivel.

  • Resumen del cronograma de hitos.

  • Resumen del presupuesto.

  • Requisitos de aprobación del proyecto y quien lo aprueba y lo entrega.

  • El director nombrado, sus responsabilidades y nivel de autoridad.

  • Otros participantes o afectados por el proyecto y sus responsabilidades.

  • El patrocinador (o quien autoriza el proyecto) y su nivel de autoridad.
Preliminary project scope definition
La última edición (4.ª) del PMBOK ha eliminado de la etapa o proceso de iniciación la definición inicial del alcance (preliminary project scope definition) que nosotros mantendremos aquí y que nos parece básico para los proyectos de IT. Si no se quiere separar este proceso, el acta de constitución del proyecto debería incluir esta definición inicial del alcance.
Se puede decir que el acta de constitución del proyecto es como un contrato o un acuerdo entre el patrocinador o sponsor del proyecto (que acostumbra a ser un directivo general, funcional o el director de sistemas), que representa a la empresa y hace de cliente, y el director o jefe de proyecto que representa al equipo de trabajo (formado por el personal de la empresa o empresas contratistas y por personal del propio cliente) que hace de proveedor.
Cliente y proveedor
Es muy bueno mantener este compromiso explícito entre cliente y proveedor, aun en aquellos casos en los que el proyecto es interno a la propia organización y no participan en él contratistas externos. A la vez, es muy bueno que el personal de la propia empresa que participa como parte del equipo de trabajo se considere un proveedor más y no un cliente.
En la figura 1, se muestra un ejemplo de modelo de acta de constitución:
Figura 1
76527_m3_03.gif

3.Identificar a los interesados

Como ya se ha comentado, los interesados en un proyecto son todas las personas y organizaciones que se verán afectadas por el desarrollo del mismo, sea directamente, porque participan en alguna medida en él o indirectamente, porque de alguna forma les afectará en su funcionamiento. Este proceso del grupo de iniciación del proyecto busca identificarlos a todos y a la vez documentar una parte de la información que estos podrán aportar al proyecto, en concreto sus intereses, expectativas, participación, importancia e influencia.
El objetivo es identificar con la mayor brevedad posible todos los intereses y fuerzas que actúan en torno al proyecto, de manera que el director tenga los elementos suficientes y globales para poder enfocar mejor el proyecto y satisfacer al máximo las necesidades de los interesados, centrándose en el sponsor y el cliente. Pero también identificar ya al inicio posibles conflictos de intereses, que en ese momento se podrán gestionar y resolver con un menor impacto sobre el proyecto.
Este proceso se debería repetir periódicamente para asegurar que los datos y la estrategia adoptada se adecuan a los diferentes cambios que va sufriendo el proyecto. En este sentido, podría ser suficiente hacer este análisis al inicio de cada fase del proyecto, a la vez que revisamos el acta de constitución.
El proceso de identificar a interesados formará parte en general de las primeras reuniones o entrevistas con los clientes, y puede utilizar información del acta de constitución del proyecto, de los documentos del proyecto –en especial de los posibles contratos–, así como información sobre la organización: organigramas, procesos de trabajo, intervinientes y otros, utilizando procedimientos estandarizados, lecciones aprendidas o listas de interesados de la información corporativa o de proyectos anteriores.
Es bueno tener en cuenta que en toda organización existe un organigrama, relaciones y flujos de trabajo formales y otras de poder o de influencia que son informales. Ambas son importantes para el proyecto y las debemos tener en cuenta.
Para hacer esta identificación se usan básicamente dos técnicas, el juicio experto (cómo no), y el análisis de interesados, que consiste en recopilar y analizar de forma sistemática las informaciones sobre los interesados de manera que obtengamos los datos deseados. Este proceso sigue los tres pasos siguientes:
1) Identificación y registro de todos los interesados, de algunos se obtendrá la información directamente a través de documentos del proyecto, pero en la mayoría de los casos habrá que hacer entrevistas recurrentes para ir recopilando información a la vez que identificando nuevos interesados. En general, estas entrevistas no serán monográficas, sino que estarán relacionadas con otras tareas iniciales del proyecto.
2) Identificar y clasificar el impacto o influencia potencial de cada interesado, hay múltiples maneras de hacerlo, tales como matrices poder/interés, poder/influencia, influencia/impacto o modelos de prominencia (identificando grupos o clases de interesados).
3) Evaluar cómo podrán actuar los diferentes interesados de manera que podamos planificar una serie de estrategias para gestionarlos y mejorar el rendimiento del proyecto.
La siguiente figura muestra uno de los documentos que se puede usar para el análisis, o lo que se llama mapa de implicados, en el que se representa, por una parte su posición e influencia en el proyecto, y el nivel de cooperación, lo que nos permite diseñar diferentes tipos de estrategias.
Figura 2
Mapa de implicados
El proceso produce dos salidas fundamentales:

  • El registro de interesados, su rol formal e informal y su posicionamiento (positivo, negativo o neutro) ante el proyecto.

  • Una estrategia de gestión de los interesados. Esta persigue establecer unos modelos de relación que maximicen las influencias positivas y mitiguen las negativas. Esto puede incluir criterios de comunicación, consulta o aceptación específica de ciertos productos; criterios de aislamiento o ignorancia; un reparto de las relaciones entre el equipo de trabajo, etc.

Hay que decir que esta información sobre interesados puede incorporar información "sensible", y en este sentido, será uno de los pocos documentos del proyecto que el director puede considerar de uso estrictamente interno.
En todo caso, como señalan Pinto y Millet (1999), probablemente unos de los autores que mejor han tratado el lado humano de la implantación de sistemas de información, no se debe tener una visión negativa o prejuiciosa de "la política" dentro de las organizaciones y los proyectos. Es un hecho, un hecho legítimo, que el jefe de proyecto experto debe manejar de forma prudente y profesional, no perdiendo nunca de vista los intereses del cliente y del proyecto, tal y como están expresados en el acta de constitución del mismo. Lo que es completamente negativo es que el jefe de proyecto o la organización contratista haga política, o se acabe haciendo un lío y se lo haga a su cliente, intentando quedar bien con todo el mundo.

4.Definición inicial del alcance

Si el mandato o acta de constitución del proyecto (project charter) se enfocaba en el porqué de un trabajo y su relación con la organización en términos de objetivos de negocio, recursos e interesados, en la definición inicial del alcance (o definición del proyecto, como hemos llamado en una versión anterior de esta metodología (Rodríguez, García, Lamarca)), necesitamos mostrar por primera vez y con claridad qué se hace (y qué no se hace) y en qué productos se representa lo que se hará, qué resultados o entregables se obtendrán.
Aún más que otros procesos de la gestión de proyectos, la gestión del alcance es un producto evolutivo, iterativo y permanente a lo largo del ciclo de vida, y por tanto, en revisión continua, en función de los cambios, desviaciones y correcciones que va marcando la vida del proyecto.
Importancia de la definición inicial del alcance
Como hemos señalado, la 4.ª edición del PMBOK ha suprimido este proceso de la etapa o grupo de procesos de iniciación como proceso separado.
Sin embargo, la mayor parte de la literatura de gestión de proyecto TIC, las metodologías de las consultoras de implantación de proyectos TIC y nuestra propia experiencia, nos han demostrado que en este sector la falta o insuficiente definición inicial del alcance es una de las mayores fuentes de fracaso de los proyectos y una continua fuente de discusión entre proveedores y clientes.
Cynthia Snyder (project leader de la 4.ª edición de PMBOK, y por tanto poco sospechosa de desviacionismo) y Frank Parth señalan:
"La definición (inicial) de alcance es el eslabón de planificación entre el cliente y el jefe de proyecto, de manera que el jefe de proyecto sabe que hay una comunicación clara entre las necesidades, deseos y expectativas del cliente y el producto final que el jefe de proyecto está ayudando a crear."
Cynthia Snyder; Frank Parth (2007). Introduction to IT Project Management (pág. 96).
En un libro reciente de uno de los autores, basado en la versión anterior de esta metodología para la UOC, en la que se mantenía la "definición de proyecto" como una fase separada, se decía:
Ejemplo
"A lo largo de todo el ejercicio (de definición), es muy importante tener en cuenta la coincidencia (match) entre los objetivos últimos del cliente, tal como se han formulado en el mandato, y los objetivos o resultados del proyecto. Es frecuente que, a partir del mandato, el proyecto cobre una misteriosa vida propia, en la que se planean y fabrican resultados que no tienen mucho que ver con lo que al cliente realmente le preocupaba.
(...) la etapa de definición se ha convertido en el campo de batalla en el que se juegan los contratos y los éxitos y fracasos materiales de los proyectos, con grandes consecuencias económicas y legales. La respuesta del sector ha sido establecer requerimientos muy detallados (la definición cada vez se parece más al diseño) y criterios de decisión basados en el volumen de dedicación y el precio unitario. Cuando se hace así, es inevitable descender desde el nivel de hito al nivel de las actividades y proponer o requerir planes detallados de trabajo que todo el mundo sabe honestamente que no es posible establecer en este momento ni probablemente cumplir después, sin severos cambios en el alcance o desviaciones en el tiempo y coste y dolorosas renegociaciones."
J. R. Rodríguez; J. García Mínguez; I. Lamarca Orozco (2007). Gestión de proyectos informáticos: métodos, herramientas y casos (pág. 66-67). Barcelona: UOC.
La fuente (input) principal para la elaboración de la definición inicial de alcance es el mandato o acta de constitución de proyecto, pero debe y puede utilizarse cualquier otra información disponible, así como entrevistas con el cliente, el sponsor y otros interesados. En definitiva, se trata de alinear el proyecto con sus necesidades y expectativas en lo concreto. La tabla 6 muestra un guión de contenidos típicos de una definición inicial de alcance.
Tabla 6
Contenido típico de la definición inicial de alcance

  • Objetivos del proyecto.

  • Requisitos y características del producto o servicio (por ejemplo, en el caso de servicios de telecomunicaciones).

  • Requisitos y entregables del proyecto.

  • Criterios de aceptación del producto o servicio.

  • Fronteras del proyecto o relaciones con otros proyectos.

  • Descomposición inicial del proyecto (EDT inicial).

  • Gestión de configuraciones, releases, etc.

  • Actualización de información contenida en el acta de constitución del proyecto, cuando proceda.

Obsérvese que algunos aspectos ya estaban presentes en el acta de constitución. Es lógico. Cuando hacemos la definición de alcance, podemos acotarlos, detallarlos o corregirlos. Muchos nos los volveremos a encontrar en las fases siguientes. Eso es la naturaleza iterativa y permanente de la gestión de proyectos, a la que PMBOK y otras metodologías conceden tanta importancia.
El aspecto más importante es la definición de objetivos, entregables y requisitos, por un lado, y la de hitos y una primera descomposición del trabajo.

  • Objetivos del proyecto son aquellos criterios cuantificables que debe cumplir el proyecto para considerarse exitoso. Pueden ser objetivos de negocio (eliminar tres puestos de trabajo, reducir los costes de facturación en un 8%), objetivos de proyecto (puesta en producción el día 3 de enero), objetivos de calidad del producto o servicio (cumplimiento del estándar XX de calidad del software) u otros.

  • Entregables son los resultados tangibles del proyecto. Normalmente son entregables de producción (un sitio web, una red local con sus switches, routers, circuitos y servidores) y entregables relacionados con el contenido de proyecto (documentación del sistema, manuales de usuario). Así como resultados relacionados con la gestión, el propio plan de proyecto, los informes de seguimiento, las peticiones de cambios, etc.

  • Requisitos (en este proceso y en esta acepción) son las condiciones para la aceptación de un entregable o de un servicio (por ejemplo, sujeción a ciertos estándares legales, técnicos, de calidad, definidos por la propia compañía o por un estándar externo).

  • Hitos (lo desarrollaremos más ampliamente cuando expliquemos la planificación) son aquellos estados intermedios por los que el proyecto debe pasar para alcanzar los objetivos finales (por ejemplo, el diseño funcional antes que el diseño técnico y la construcción).

  • También en esta fase se realiza una primera descomposición de la estructura del trabajo o estructura de distribución del trabajo, EDT (work breakdown structure, WBS) a alto nivel. EDT son las partes más pequeñas en las que rompemos un proyecto para hacerlo más manejable, sea por componentes, por fases del ciclo de vida de producción, por geografías o cualquier otro criterio. Muchas veces se hace coincidir con los hitos, lo que facilita su seguimiento. El resultado o salida de una EDT es un entregable.

En definitiva, la definición inicial del alcance es la pieza que une los procesos de iniciación (el qué se hará) con los procesos de planificación (el cómo se hará). Por tanto, es necesariamente ambigua y controvertida. Sin embargo, es imprescindible para el jefe de proyecto, porque le permite establecer por primera vez un diálogo en los términos concretos del trabajo a realizar con el cliente y los interesados, por un lado, y con el equipo de proyecto, por el otro, por lo cual, le proporciona un contexto utilísimo para la planificación, el control y la comunicación del trabajo en las etapas siguientes.

5.Establecer la organización para la gestión del proyecto

En esta etapa, establecemos también los órganos colegiados e individuales para la gestión del proyecto a un alto nivel.
Este proceso se desarrolla en el módulo "El lado humano de la gestión de proyectos" con más detalle.
El producto de este proceso es el organigrama del proyecto que se puede presentar por separado o integrado en el acta de constitución.
Frecuentemente, el acta de constitución (project charter) del proyecto incluye la definición inicial o preliminar de proyecto, el mapa de interesados y los órganos de dirección y participantes en el proyecto (figura 1, pág. 17).

6.Resumen

Desde el punto de vista de la gestión de proyectos, la etapa de iniciación tiene como objetivo obtener un mandato claro y definido de autorización del proyecto: saber qué hay que hacer, por qué hay que hacerlo, para qué servirá, quiénes son las personas o departamentos afectados, interesados o que influirán en el proyecto, y cuáles son los límites iniciales de presupuesto y tiempo con los que contamos. Es deseable conocer también cómo se medirá el éxito y cuál es el valor o beneficio para el negocio que tiene el trabajo. Y alguien, que normalmente forma parte de la dirección de la empresa y es ajeno al proyecto en sí mismo, tiene que tomar formalmente la decisión de tirarlo adelante, tiene que dar su aprobación.
Un proyecto surge o debe surgir cuando se identifica un problema o una oportunidad en el negocio, en cualquiera de las áreas de la organización (mejorar el servicio al cliente, reducir el tiempo de desarrollo de un nuevo producto o los plazos de entrega de los proveedores, mejorar el control financiero interno, facilitar la identificación de nuevos talentos en la empresa y desarrollar los recursos humanos, automatizar los trámites de una administración pública, etc.).
Un proyecto debería mejorar o transformar procesos de negocio para aumentar la ventaja competitiva de la empresa. No hay proyectos TIC, sino proyectos de negocio, que se apoyan de una u otra manera en herramientas TIC. Y al revés, hoy no se puede pensar en transformaciones de procesos de negocio sin tener en cuenta las tecnologías de la información y las comunicaciones.
En las etapas previas a la iniciación del proyecto, se analiza su viabilidad y el retorno de la inversión. Para ello se prepara un caso de negocio (business case), en el que se comparan todos los ingresos con todos los costes y se analizan, con diferentes clases de medida, los beneficios que se obtendrán y el tiempo de retorno de la inversión incurrida. Eso permite también comparar unos proyectos (sean en TIC o en otras áreas) con otros y tomar decisiones a la dirección de la empresa.
Los procesos que comprende la etapa de iniciación de la gestión de proyectos son tres:
1) Desarrollar el acta de constitución (o mandato, o project charter, en inglés) del proyecto.
2) Identificar a los interesados.
3) Desarrollar la definición preliminar de alcance (o simplemente, definición del proyecto).
A éstos se puede añadir, si se quiere formalizar por separado, la preparación del organigrama para la gestión del proyecto.
Frecuentemente, el acta de constitución o mandato de proyecto (project charter) ya incluye todos estos componentes.
El acta de constitución representa la autorización formal del proyecto por parte del sponsor o patrocinador, normalmente un miembro de la dirección ajeno al proyecto. Es un documento sencillo, en el que se establecen los problemas y objetivos de negocio que se desean resolver, los objetivos y resultados del trabajo a alto nivel y cómo se medirá su éxito y las condiciones de aprobación del resultado. Se muestran también las condiciones económicas (presupuesto) y temporales (calendario) y se nombra al director de proyecto y a los participantes de primer nivel.
La identificación de interesados es el proceso de registrar a todos los componentes de la organización que tienen alguna clase de influencia en el proyecto, entender su grado de influencia y el nivel de cooperación que necesitaremos de ellos, y establecer de forma preliminar las estrategias para manejar sus expectativas. La identificación de interesados nos permite también abordar el proceso de toma de requisitos en las fases posteriores del trabajo.
La definición preliminar del alcance (o definición del proyecto a secas) puede formar parte del acta de constitución o bien presentarse como un proceso y un documento por separado. En todo caso, es el lugar donde se establece el contenido del proyecto (el qué hay que hacer), los entregables o resultados parciales, los hitos (o estados intermedios por los que pasa el proyecto) y la gestión de configuraciones (versiones, releases, etc.). Es una etapa intermedia, el eslabón que une la aprobación del proyecto con la planificación detallada, que abordaremos en el módulo "Planificación del proyecto".