Planificación del proyecto

  • 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_00215830
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

El acta de constitución del proyecto (o project charter) puede considerarse el documento que establece la iniciación formal y oficial del proyecto. Es allí donde se autoriza o aprueba el trabajo, se nombra al responsable del proyecto y se le autoriza a utilizar los recursos de la organización u otros ajenos. Es también el lugar donde se explican los objetivos últimos de negocio que se desean conseguir, el porqué del proyecto. Seguidamente, en la definición inicial del alcance (o 'definición' sin más) del proyecto se establecen por primera vez los objetivos detallados, lo que llamamos el alcance (lo que se hará y lo que no se hará), los productos que se obtendrán y la descomposición inicial del proyecto en partes o líneas de trabajo menores, que dan lugar a entregables parciales (que hemos llamado EDT). La definición inicial del alcance es el eslabón que enlaza los objetivos de negocio y de cliente con un proyecto TIC acotado y con objetivos y productos específicos. Es también, por lo tanto, el enlace entre la etapa o el grupo de procesos que hemos llamado de iniciación y los de planificación.
Sea como sea, después de la aprobación y definición, el paso siguiente en el ciclo de vida de un proyecto es la planificación detallada del mismo (figura 1). Después de entender muy bien qué hay que hacer y por qué hay que hacerlo, el objetivo de la planificación es asegurar que se obtienen los objetivos acordados en tiempo, calidad y coste, guiar al equipo de trabajo y la comunicación con el cliente a lo largo de la ejecución del proyecto. Se trata de establecer cómo se hará el proyecto, poderlo explicar y predecir su evolución.
Figura 1. Ciclo de vida del proyecto
Este módulo explica la importancia de planificar correctamente un proyecto, y la de hacerlo orientándolo siempre a los objetivos y requisitos fijados en las etapas precedentes. La planificación es, más que una etapa, una necesidad inherente a cualquier proyecto. La planificación establece el mapa de ruta que hay que seguir en el proyecto, y permite orientar y ordenar el trabajo de todo el equipo para conseguir los resultados perseguidos.
El método que presentamos a continuación permite determinar, en un enfoque de arriba abajo y a partir de los objetivos más generales del proyecto, los pasos y estados intermedios que conviene conseguir para alcanzar las actividades y tareas que se consideran necesarias en cada paso y los recursos que se requieren para realizarlos.
Veremos que, en la práctica, el ejercicio de planificación es una especie de zoom que nos va llevando de lo general a lo particular y del de las tareas a la visión global de los objetivos del proyecto y del cliente. Los buenos directores de proyecto han desarrollado con años de práctica esta habilidad de tener la visión global y a la vez conocer el detalle y hacer el camino de vuelta.
Con la referencia de PMBOK, según hemos visto, incorporamos la idea de un ejercicio de planificación y replanificación iterativo y permanente a lo largo de todo el proyecto, de manera que la ejecución y el seguimiento y control del proyecto nos va dando elementos para revisar y mantener vivo el plan. En segundo lugar, PMBOK aporta una visión estructurada del conjunto de áreas o ámbitos de trabajo (las áreas de conocimiento), que tiene que contener el plan y que normalmente aparecen dispersos o son olvidados en otras metodologías o en la práctica, en particular los temas de comunicación, calidad, gestión de riesgos, recursos humanos o administración.
Recordemos finalmente que la gestión de proyectos TIC (y por tanto, los grupos de procesos de planificación dentro del proyecto) es algo diferente, complementario, más amplio y común comparado con las metodologías de producción (sean el desarrollo de sistemas, el mantenimiento de aplicaciones, la implantación o gestión de servicios de telecomunicaciones, el diseño de aplicaciones multimedia o cualquier otro), aunque en muchas de estas metodologías comienza a producirse una confluencia o una integración con los principios de la gestión de proyectos. Corresponde al director de proyecto, de acuerdo con las prácticas y el contexto de la empresa cliente y frecuentemente de su propio entorno de trabajo, definir cuáles son las metodologías de producción a utilizar y cómo y dónde se producen las interacciones entre los procesos de gestión de los proyectos y los procesos de producción de cada producto o servicio determinado.

Objetivos

Al término del estudio de este módulo, tendréis que ser capaces de conocer y aplicar el conjunto de procesos necesarios para la planificación de un proyecto TIC, y más en concreto:

  1. Entender la importancia de la planificación de un proyecto, los diferentes tipos de planificación y el enfoque de la planificación orientada a objetivos, en particular el concepto de hito.

  2. Qué procesos componen la etapa o grupos de procesos de planificación, cuál es su estructura típica, técnicas y herramientas y los principales productos que se obtienen. El jefe de proyecto tiene a su alcance un conjunto de instrumentos (como una 'caja de herramientas'), que debe seleccionar y aplicar para cada proyecto, según su tamaño, tipología, etc.

  3. Conocer en profundidad las herramientas y productos de la planificación en las tres áreas clave (llamadas líneas de base o baselines de la gestión de un proyecto TIC:

    • La planificación detallada del alcance.

    • La planificación de tiempos y la elaboración del calendario de proyecto.

    • La planificación de costes y la elaboración del presupuesto de proyecto.

  4. Disponer de un conocimiento suficiente del resto de las áreas de conocimiento que deben incluirse en la planificación, con el alcance y profundidad que se determine en cada caso y según el tipo de proyecto:

    • La planificación de la calidad.

    • La planificación de los recursos humanos.

    • La planificación de la comunicación y gestión de las expectativas del cliente.

    • La planificación de riesgos.

    • La planificación de la administración y gestión de compras y contratos.

1.¿Qué es un plan de proyecto?

Planificar es determinar qué hay que hacer, quién lo hará, en qué tiempo y con qué recursos, para cumplir un objetivo. El plan de proyecto es la herramienta principal, el cuaderno de bitácora, que utiliza un gestor de proyecto para asegurar la consecución de los objetivos del mismo.
Un plan de proyecto se puede considerar:

  • Un mapa de ruta estructurado que establece todas las actividades que hay que hacer para alcanzar los objetivos de negocio.

  • Una definición de los tiempos y recursos –tecnológicos y de negocio– necesarios para completar el trabajo.

  • Un mecanismo para monitorizar avances, controlar el alcance y gestionar el proyecto para asegurar los resultados finales dentro del marco del tiempo y presupuesto definidos.

  • Un medio para comunicar los progresos y comprometer a los participantes del proyecto.

Un resumen de las ventajas que ofrece la planificación estructurada de un proyecto informático se muestra en la figura siguiente.
Figura 2. Características de un proyecto planificado
Fuente: Rodríguez, García, Lamarca (2007)
Planificar proyectos es, en definitiva, estructurar y describir las actividades requeridas para alcanzar los objetivos del proyecto hasta su conclusión, teniendo en cuenta las responsabilidades y recursos requeridos en cantidad, tipología y experiencia. Además, la planificación permite mejorar la calidad, ser eficiente y mejorar las perspectivas del proyecto a largo plazo. Finalmente, pero no en último lugar, el plan es un instrumento de comunicación y diálogo con el cliente y dentro del equipo de trabajo.
La planificación es un proceso iterativo y permanente que ocurre a lo largo de todo el ciclo de vida de la gestión de proyectos y que se realimenta de los procesos de ejecución, seguimiento y control, que permiten y obligan a adaptar el plan a la realidad de la ejecución.

1.1.Contenidos del plan

El plan de un proyecto debe contemplar los elementos siguientes:

  • Los objetivos y los resultados que se esperan del proyecto, de manera que permita la evaluación del éxito o fracaso del mismo, tal como se han descrito en los capítulos anteriores.

  • Los hitos principales del proyecto, coincidentes con puntos de decisión, entregables, finalización de etapas, etc. Una definición más detallada de hito se establece en los apartados siguientes del capítulo.

  • Los mecanismos de control del alcance del proyecto, y de gestión de cambios en éste.

  • La involucración de los distintos agentes participantes en el proyecto, sus roles y responsabilidades.

  • La definición de las actividades del proyecto, es decir, las tareas o grupos de tareas de las que se compone, los recursos técnicos y humanos necesarios y el resultado o hito que debe obtenerse mediante la realización de estas actividades.

  • El calendario de trabajo, con los tiempos de realización según la fecha de inicio y la fecha de finalización de cada una de las actividades y la de cada uno de los hitos.

  • La organización y el equipo asignado al proyecto, con la matriz de roles y responsabilidades para los diferentes hitos y actividades.

  • El presupuesto del proyecto, con las estimaciones de inversión y coste presupuestadas a partir del consumo de recursos, su previsión de evolución a lo largo del tiempo de duración del proyecto y la previsión de beneficios esperados.

  • El sumario de las asunciones realizadas sobre los riesgos identificados previamente a la implantación del proyecto, su posible impacto sobre el plan de proyecto y el plan de gestión de estos riesgos.

  • La calidad de los trabajos realizados, según los resultados funcionales y operacionales esperados y la definición de las condiciones y principios de aceptación de los mismos.

La cuarta edición de PMBOK (2008), identifica dentro del grupo de procesos de planificación hasta nueve áreas, que se muestran en la siguiente tabla:
Fuente: PMBOK, 4.ª edición (2008)
Tabla 1
Los procesos de planificación, según el PMBOK
1) Plan de gestión de proyecto
2) Plan de gestión del alcance
2.1) Recogida de requisitos
2.2) Definición detallada del alcance
2.3) Creación de la EDT
3) Plan de gestión del tiempo
3.1) Definición de actividades
3.2) Secuenciación de actividades
3.3) Estimación de recursos para las actividades
3.4) Estimación de duración de las actividades
3.5) Elaboración del calendario
4) Plan de gestión de costes
4.1) Estimación de costes
4.2) Elaboración del presupuesto
5) Plan de calidad
6) Plan de recursos humanos
7) Plan de comunicación
8) Plan de gestión de riesgos
8.1) Plan de gestión de riesgos
8.2) Identificación de riesgos
8.3) Análisis cualitativo de riesgos
8.4) Análisis cuantitativo de riesgos
8.5) Plan de respuesta frente a los riesgos
9) Plan de administración y compras

1.2.La planificación orientada a objetivos

Existe la tendencia a planificar las actividades o bloques de actividades de un proyecto y construir el plan por agregación de abajo arriba (bottom up), es decir, desde las tareas y actividades hasta los productos. La planificación orientada a objetivos es un enfoque metodológico de arriba abajo (top down) de planificación y gestión de proyectos, dirigido a obtener resultados y, por lo tanto, se centra en tener siempre presente la orientación de los objetivos (goal directed project management, GDPM) que se persiguen en el trabajo, y a partir de ahí bajar hasta el nivel de los productos a obtener, las líneas de trabajo o productos parciales en los que el trabajo se descompone (EDT) y seguidamente, las actividades y tareas a realizar.
La base de la planificación orientada a objetivos es definir antes el "qué debe conseguirse" que el "cómo se debe conseguir". El plan de hitos es el plan lógico del proyecto y el instrumento de diálogo con la dirección. El plan de actividades es el plan físico y el instrumento de diálogo dentro del equipo de trabajo. Como señalan Andersen y otros (2003), el plan de actividades no debe llevarse a cabo hasta que no es estrictamente necesario.
En los siguientes apartados, analizaremos los procesos de trabajo de planificación tomando como referencia metodológica la que sugiere el PMBOK. Sin embargo, y para ponernos en acción y no perder el hilo conductor de 'lo que hay que hacer en realidad', seguidamente proponemos la secuencia física de actividades necesaria para la elaboración del plan proyecto. Por tanto, para la elaboración del plan:
1) En primer lugar, deben entenderse y revisar con el cliente los objetivos últimos del proyecto, tal como se han definido en el mandato o acta de constitución del proyecto y en la definición inicial del alcance (qué hay que hacer y por qué). A veces, como hemos mencionado en el módulo anterior, la definición inicial, el mapa de interesados y la definición de roles y responsabilidades se incorpora al acta de constitución.
2) Para completar esta definición, debemos recoger de los interesados cuáles son sus requisitos, discutirlos con el cliente para asegurar que encajan dentro del mandato de proyecto y de la definición inicial y establecer, si procede, las prioridades.
3) En ese momento, podemos realizar una definición detallada del alcance, o revisar, si fuese el caso, el alcance inicial.
4) A partir de estos objetivos, se deben identificar los estados intermedios, o hitos, que deben ser alcanzados para avanzar en el logro de los objetivos finales del proyecto, y el nivel de dependencia o relación que hay entre estos hitos. Los hitos normalmente se corresponden con productos o líneas de trabajo que darán lugar a resultados o entregables intermedios. A esta distribución de la estructura del trabajo le llamamos EDT.
5) En este nivel, debemos establecer ya qué personas son responsables de la consecución de cada hito y de su aprobación, dentro del cliente y del equipo o, dicho de otra manera, la estructura de responsabilidades por la consecución de los hitos.
6) Los hitos y EDTS pueden descomponerse entonces en actividades y tareas que son necesarias para alcanzar el hito y, de nuevo, las relaciones y dependencias que existen en cuanto a las actividades. PMBOK y otras metodologías llaman a esta fase definir las actividades.
7) Seguidamente, se ordenan las actividades en su secuencia de realización, en qué orden deben realizarse y cuáles pueden realizarse en paralelo.
8) En este momento, se estima el tiempo (esfuerzo, carga o cantidad de trabajo) requerido para la realización de cada actividad.
9) Esto nos permite establecer el calendario o línea de base de tiempo, todavía inicial o provisional.
10) Puede valorarse entonces el tipo de recurso necesario para realizar una tarea determinada y la carga de trabajo que requiere. De esta manera podemos hacer una estimación de recursos y perfiles, y su dedicación.
11) La dedicación y coste de los recursos humanos y otros recursos técnicos nos permite preparar el presupuesto de ejecución. El presupuesto constituye la línea de base de coste del proyecto, todavía inicial o provisional.
12) También en este momento, establecemos las responsabilidades por cada actividad, dentro del equipo de trabajo.
13) Una vez establecidas las líneas de base del proyecto (alcance, tiempo y presupuesto), podemos establecer los planes complementarios de calidad, recursos humanos, comunicación y administración del proyecto.
14) Pero los recursos que necesitamos pueden no estar disponibles, o no estarlo en el momento en que los necesitamos. O pueden aparecer otras limitaciones a la hora de considerar los estándares de calidad, las necesidades de comunicación y gestión de las expectativas del cliente o la disponibilidad o costes de los proveedores de recursos técnicos o subcontratistas. El plan de trabajo, calendario y presupuesto deben revisarse con arreglo a los recursos y capacidades de los que realmente dispondremos.
15) A continuación se examinan los riesgos y se prevé el nivel de contingencias o reservas necesario para paliar los riesgos.
16) Una vez revisado el plan, se coloca en un calendario definitivo y se prepara el presupuesto de ejecución definitivo.
17) El plan de proyecto, calendario y presupuesto deben discutirse en profundidad con el cliente (y eventualmente, también dentro del departamento o empresa proveedora) para asegurar su comprensión, compromiso y asunción por parte de todos. O revisarse, en el nivel de los hitos, las actividades, los recursos o los planes complementarios, si eso es necesario.
18) También en esta fase, y muy especialmente, debe confrontarse el plan definitivo con los objetivos y necesidades contenidas en la definición de proyecto, es decir, con el mandato de proyecto y la definición inicial de alcance.
Puede verse que la preparación del plan, en sí misma, tiene una naturaleza compleja e iterativa, que nos obliga a revisarlo y discutirlo conforme avanzamos en la secuencia de actividades.
Este planteamiento más físico y secuencial y a menudo más fácil de entender se muestra en la figura siguiente (aunque ya se ve que algunas de las actividades pueden hacerse en paralelo y otras son iterativas).
Figura 3. Secuencia de preparación del plan

2.Procesos de la planificación. La integración del plan

Seguidamente, adoptaremos el enfoque metodológico propuesto por el PMBOK en su 4.ª edición, convenientemente adaptado a las profesiones TIC, y matizado por nuestra experiencia profesional, la consulta de otros autores (en especial, aquellos que toman también como referencia el PMBOK) y los aspectos básicos del método de gestión de proyecto orientado a objetivos, el cual, como venimos comentando, nos parece especialmente útil para mantener la conexión entre los objetivos del proyecto y los objetivos de negocio, para mantener un diálogo práctico y sencillo con el cliente sobre el progreso del trabajo y para vincular al personal del cliente en la realización del proyecto, anticipando esa cosa que ahora se llama "gestión del cambio".
Según vimos en el módulo "Componentes de la gestión de proyectos: las áreas de conocimiento", PMBOK se estructura en un conjunto de áreas de conocimiento que se aplican de forma variable y según el juicio experto del director de proyecto a lo largo del progreso del ciclo de gestión del proyecto. Precisamente, el director de proyecto es el responsable de la preparación del Plan de gestión de proyecto, que establece qué procesos de gestión se aplicarán a un proyecto determinado e incorpora los elementos principales de los diferentes planes parciales. Los componentes del proceso de preparación del Plan de gestión de proyecto se presentan en la figura siguiente.
Figura 4. Componentes del proceso de preparación del Plan de gestión de proyecto
Fuente: PMBOK (2008)
Los principales inputs para la preparación del plan son el acta de constitución del proyecto (el mandato que marca la iniciación formal del trabajo, en respuesta a una necesidad de negocio), la identificación de interesados (quién tiene algo que ver o que decir en el proyecto) y la definición inicial del alcance (qué hay que hacer y qué productos se tienen que obtener).
Esto no es una formalidad. Lo más importante cuando se planifica (y también cuando se ejecuta) el proyecto, es entender muy bien cuáles son los objetivos que se desean conseguir, con qué nivel de detalle (alcance) y calidad y, si ya se ha acordado de antemano, de cuánto tiempo y presupuesto disponemos. Todo esto se ha de establecer en la definición del proyecto. Antes de preparar el plan, las siguientes preguntas deben estar muy bien contestadas.
Preguntas que hay que contestar antes de empezar a preparar el plan

  • ¿Cuál es la finalidad de poner en marcha el proyecto?

  • ¿Qué hay que haber conseguido al final del proyecto que no se tenga actualmente: cuáles son los productos (entregables) del proyecto?

  • ¿Hay que hacer o entregar algo más, aunque no se haya expresado formalmente?

  • ¿Hay algo que esté específicamente excluido del alcance?

  • Las fronteras del proyecto: ¿están claras? ¿cómo afectan otros proyectos al nuestro, o al contrario?

  • Asunciones o restricciones del proyecto: cosas que suponemos que pasarán o no pasarán.

  • Problemas significativos que afectarán al proyecto.

  • Condiciones específicas de ejecución que ha pedido el cliente (por ejemplo, aportación de recursos, trabajar en su casa, relacionarse de una manera o de otra con la organización, etc.).

Fuente: R. Newton (2006). Project management step by step. How to plan & manage a highly successful project. Harlow: Prentice Hall Business.
El plan es una responsabilidad principal del director de proyecto y se basa en su propio juicio y experiencia. Él debe decidir (o proponer o consensuar, según su estilo de dirección y la práctica de su compañía y la del cliente) qué método de producción se adoptará (cuál es el ciclo de vida del proyecto desde el punto de vista del producto), qué procesos, herramientas y técnicas de gestión son más útiles en cada fase del proyecto, cuál será el ciclo de reporting y qué documentos se producirán.
Todo esto no es trivial. Hay una tendencia a hacer las cosas como las hemos hecho siempre o según las costumbres de la casa o del cliente. Aunque hay proyectos y clientes parecidos, ninguno es igual, y el director de proyecto está obligado a pensar cada vez cuál será la mejor aproximación, diseñarla a medida y discutirla con el equipo (al menos las personas más senior, que serán responsables de hitos o EDT y con el cliente).
Los temas clave de este proceso son:

  • Las líneas base de alcance, coste y tiempo y los planes para gestionar cada una de estas dimensiones y manejar los cambios.

  • El organigrama de proyecto y la matriz de roles y responsabilidades.

  • El plan de comunicación con el cliente y las partes interesadas.

  • El plan de gestión de riesgos.

  • El plan de gestión de configuraciones, versiones, etc.

  • El resto de los planes complementarios o subsidiarios, en función de la importancia o prioridad que tengan en cada trabajo.

Desde el punto de vista de la planificación, insistamos de nuevo, el esquema lógico de trabajo nos conduce desde los objetivos (del cliente, del proyecto), a los hitos (estados intermedios por los que pasa el proyecto para alcanzar los objetivos), y de los hitos a las actividades (tareas necesarias para completar los hitos), según se muestra en la figura 5.
Figura 5. Estados de planificación desde el punto de vista lógico
Fuente: Rodríguez, García, Lamarca (2007)

3.Planificar el alcance

La gestión del alcance del proyecto es acaso el proceso más crítico de toda la gestión del proyecto, como hemos dicho. Es donde se producen las mayores desviaciones y, a menudo, absolutos fracasos, en el contenido (qué quería el cliente), el tiempo y los costes. Y desde luego, en la satisfacción de clientes y usuarios y, a menudo, en su repercusión pública (la respuesta de los accionistas, en la empresa privada; penalizaciones o impacto negativo en la prensa y la opinión, en el sector institucional).
Los procesos de gestión del alcance, en la definición del PMBOK, son "los que se requieren para asegurar que el proyecto incluye todo el trabajo requerido, y sólo el trabajo requerido, para completar el proyecto con éxito. Gestionar el alcance del proyecto se refiere fundamentalmente a definir y controlar lo que está incluido y lo que no está incluido en el proyecto" o, como hemos dicho tantas veces, lo que se hará y lo que no se hará.
En la etapa o grupo de procesos de planificación, la planificación del alcance incluye tres procesos:
1) La recogida de requisitos, es decir, la definición y documentación de las necesidades que, a juicio de los interesados, permitirán cubrir los objetivos del proyecto.
2) La definición detallada del alcance, es decir, la descripción detallada del proyecto y de los productos (entregables) que se obtendrán.
3) La definición de hitos y la distribución de la estructura del trabajo (EDT), es decir, subdividir el conjunto del trabajo y sus entregables en partes o componentes menores.
Recordemos de nuevo que una cosa es el alcance del producto (es decir, las cosas, funcionalidades, características, que el producto o servicio tiene que proporcionar al cliente) y otra cosa es el alcance del proyecto (el trabajo que hay que hacer para construir o entregar ese producto o servicio, y los trabajos asociados al propio producto, tales como documentación, formación, gestión del cambio, etc.). Muchos de los problemas de una inadecuada gestión del alcance provienen de confundir lo uno con lo otro y de no definir las responsabilidades de cada cosa. Un producto se considera acabado cuando cumple los requisitos del producto tal como se definieron en el momento en que debieron definirse (que no siempre es el inicio del proyecto, porque no existen los elementos suficientes para hacerlo). Un proyecto se considera acabado cuando se han cumplido las previsiones establecidas en el plan de proyecto. Son dos cosas bien distintas.

3.1.Recogida de requisitos

Si la inadecuada gestión del alcance estaba en las principales causas de fracaso de los proyectos, según el Standish Group y otras fuentes, a su vez la causa principal de fracaso en la gestión del alcance es que los requisitos se han tomado mal o que éstos cambian continuamente a lo largo del proyecto.
Ejemplo
Snyder y Parth (2007) citan un estudio empírico desarrollado en un gran proyecto de la fuerza aérea norteamericana donde se analizaron las fuentes de fallos (bugs) en el software desarrollado. Según este estudio, el 41% de los errores se debían a problemas con los requisitos, seguidos del 28% de errores de código. El resto de las causas no eran relevantes.
Para la industria del desarrollo de software, la ISO-9000-3 declara: "Para proceder con el desarrollo de software, el proveedor debería tener un conjunto de requisitos funcionales completo y sin ambigüedades. Estos requisitos deberían incluir todos los aspectos necesarios para satisfacer las necesidades del comprador. Entre ellos, y como mínimo, los siguientes: rendimiento, seguridad, confianza, seguridad y privacidad. Estos requisitos deberían ser documentados con la suficiente precisión para permitir su validación durante la aceptación del producto".
Ya se ve que hay muchos tipos de requisitos, de muchos niveles y procedentes de muchas fuentes y partes interesadas. No todos son iguales, ni tienen la misma importancia para el proyecto, ni son asumibles en el alcance, presupuesto y calendario iniciales acordados con el cliente. Es básico recordar esto continuamente y hacérselo recordar al cliente/comprador.
Igual que los objetivos, los requisitos deberían cumplir los principios llamados SMARTT:

  • Specific: específicos, sin ambigüedades, ni descripciones difusas.

  • Measurable: cuantificables, tanto como sea posible.

  • Agreed: acordados con los interesados y, en caso de conflicto, con el comprador o director del proyecto por parte del cliente.

  • Realistic: conseguibles dentro de las limitaciones técnicas, de alcance, tiempo y calendario.

  • Traceable: que sea posible su trazabilidad o seguimiento y evaluación del logro, y que se pueda validar su consecución.

  • Testable: esto es especialmente clave, que se pueda probar su consecución internamente y por el usuario en el momento de la operación.

Para finalizar, cada requisito debería ser completo (que no necesite otros requisitos posteriores) y consistente (que no sea contradictorio con otros o estar potencialmente sujeto a cambios permanentes). Estos dos criterios valen para cada criterio por separado y para todos juntos.
El proceso de toma de requisitos, según PMBOK, se representa en la figura 6.
Figura 6. Componentes del proceso de toma de requisitos según PMBOK
Fuente: PMBOK (2008)
Hay muchos tipos de requisitos: funcionales, técnicos, de rendimiento, de integración, de look-and-feel e interfaz de usuario, operacionales, de verificación o control interno, relacionados con la implantación, relacionados con los procesos, la organización o la gestión del cambio, los relacionados con la legalidad, seguridad o privacidad, además de todos los requisitos industriales o de robustez del producto (confiabilidad, mantenibilidad, escalabilidad, sostenibilidad del proveedor o del producto, etc.).
El PMBOK, por su carácter muy general, no resulta muy relevante y útil para una toma de requisitos informada en proyectos TIC. Es más útil para el alumno y el practicante utilizar otros estándares (por ejemplo, para empezar, la ISO 9001) o, aún mejor, cuerpos de conocimiento existentes en las industrias específicas, como el IIBA (International Institute of Business Analysts) en Estados Unidos o el Atlantic Systems Guild en el Reino Unido, para las industrias del software.
La matriz de trazabilidad de requisitos
PMBOK sugiere una herramienta útil y recomendable para cerrar esta sección. Se trata de la matriz de trazabilidad de requisitos, mediante la cual relacionamos en una tabla de doble entrada cada requisito con los productos intermedios o finales que se irán elaborando a lo largo del proyecto. Esta tabla permite también priorizar, en caso de conflicto, la importancia de unos requisitos frente a otros, por ejemplo:

  • Requisitos comparados con objetivos de negocio.

  • Requisitos comparados con objetivos del proyecto.

  • Requisitos comparados con hitos, productos y EDT.

  • Requisitos comparados con diseño.

  • Requisitos comparados con construcción.

  • Requisitos comparados con test.

  • Requisitos de alto nivel comparados con requisitos de detalle.

  • Etc.

3.2.Definición detallada del alcance

Efectivamente, es el hecho de disponer de requisitos detallados, de calidad, priorizados, acordados y 'trazables' lo que nos permite transformar la definición inicial del alcance o definición del proyecto sin más, que realizamos en la etapa de iniciación en una definición operable, accionable, que podemos convertir en un plan.
Normalmente, ni el cliente ni la empresa de servicios para la que trabajamos nos admitirá un contrato subordinado a la toma de requisitos de detalle, ni internamente dará un mandato a un director de proyecto con esos condicionantes. La realidad es así. Necesitamos un presupuesto inicial, un calendario inicial y un alcance inicial para empezar a trabajar. Pero para poder planificar el proyecto, necesitamos una definición de requisitos mucho más precisa.
Otra diferencia es que, en el nivel de definición inicial, normalmente trabajamos a nivel de proyecto, y no necesariamente hemos realizado una selección o aprobación definitiva de un producto o de un modo de producirlo. En el nivel de la definición detallada propia de la planificación, ya estamos en el nivel de los productos, qué producto se construirá o implantará y cómo se construirá.
La definición detallada del alcance, por lo tanto, es un producto no muy diferente de la definición inicial, pero sí más refinado, preciso y detallado y que incorpora una descripción del producto.
El proceso de definición detallada del alcance, tal como se presenta en el PMBOK, se muestra en la figura 7.
Figura 7. Componentes del proceso de definición detallada del alcance
Fuente: PMBOK (2008)
Entre las herramientas y técnicas destacables, merece llamar la atención sobre el análisis de productos (en aquellos proyectos que incorporan como entregable un producto, ya existente, por ejemplo un ERP, o compuesto de otros, por ejemplo, una base de datos relacional) y sobre el análisis de alternativas. En este último caso, la creatividad es importante: dentro de las limitaciones de tiempo y dinero, muchas veces se trata de encontrar maneras de hacer el proyecto que permitan alcanzar los mismos resultados de una manera más eficiente o más rápida.
La definición detallada del alcance incluye los siguientes productos:

  • Descripción actualizada del producto, servicio o resultado y, frecuentemente como anexo, la documentación de requisitos.

  • Criterios de aceptación de los productos.

  • Entregables del proyecto, sean productos, servicios, componentes del proyecto o material complementario (por ejemplo, documentación).

  • Exclusiones del proyecto. Muchos directores de proyecto o compañías de servicio no se atreven a incluir por diferentes razones este apartado que resulta extremadamente crítico. Es una descripción argumentada de lo que no se hará y por qué, que ayuda de forma extraordinaria a gestionar las expectativas de clientes e interesados.

  • Limitaciones y asunciones. Son las condiciones organizativas, de calendario o de presupuesto, bajo las cuales se realizará el proyecto y, en su caso, las condiciones para su modificación. Actualmente, muchos proyectos se hacen bajo presupuestos cerrados, pero se establecen condiciones bajo las cuales el presupuesto puede revisarse. O, al contrario, se hacen 'por administración' (horas dedicadas), pero se establecen unos productos mínimos que deben obtenerse y unas condiciones para sustituirlos.

  • Hitos. Son los estadios o condiciones intermedias por los que el proyecto debe pasar para alcanzar sus objetivos finales. Muchas veces, pero no siempre, están vinculados a la descomposición del proyecto en partes menores (EDT o WBS), a la que nos referiremos a continuación.

  • Las responsabilidades por los hitos. Es la asignación de roles y responsabilidades en el nivel de hitos, es decir, identificar quién o quiénes son responsables de la consecución de cada hito y que otros miembros del equipo o partes interesadas del cliente participan y con qué rol o nivel de responsabilidad.

El documento "Definición detallada del alcance" es uno de los que hemos considerado básicos para la gestión de proyecto. Un formulario indicativo de cómo prepararlo se facilita en el caso ejemplo.
3.2.1.El Plan de hitos
El concepto de hito no existe en PMBOK ni en otras metodologías y procede del enfoque goal directed project management (GDPM). Tampoco en este nivel se acostumbran a establecer las responsabilidades. En nuestra opinión, hacerlo aquí facilita la relación y el diálogo entre la parte de negocio (y en particular, el sponsor del proyecto) y el equipo de proyecto (que suele tener un gran peso técnico), de una forma sencilla, visual y comprensible, antes de entrar en tecnicismos, detalles y complicadas herramientas de gestión. También permite visualizar todos aquellos componentes "ajenos" al proyecto en sentido estricto (los de gestión del cambio, que se dice ahora) sobre los que el cliente tiene que actuar para asegurar el éxito del trabajo. Finalmente, establecer hitos, si se relaciona con los criterios de comprobación de entregables, no deja lugar a dudas: las cosas están o no están, se han hecho o no se han hecho.
Los objetivos finales de un proyecto guían la definición de sus estados intermedios, los hitos. Para ser efectivos, los hitos deben tener las características siguientes:

  • Deben reflejar el qué y no el cómo.

  • Deben ser fáciles de leer y entender para la dirección.

  • Deben ser puntos de decisión.

  • Deben ser concretos y medibles.

  • Deben ser relevantes y limitados en número.

  • Deben ocurrir en periodos de tiempo manejables.

  • Deben señalarse las dependencias con otros hitos.

Una regla sencilla es escribir los hitos de manera que reflejen un estado que hay que alcanzar y las condiciones para verificar que se han alcanzado. Pueden verse algunos ejemplos en la tabla 2.
Rodríguez, García, Lamarca (2007)
Tabla 2
Ejemplos de formulación de hitos

  • Cuando se ha presentado el plan detallado de trabajo.

  • Cuando el entorno de desarrollo está disponible.

  • Cuando se han realizado las pruebas de usuario.

  • Cuando se ha preparado el plan de formación.

  • Cuando se ha subido el sistema a producción.

  • Cuando se ha aprobado el nuevo proceso de trabajo.

  • Cuando se ha comunicado el nuevo servicio.

  • Cuando se han habilitado las instalaciones.
Estos hitos se pueden representar de manera gráfica mediante la utilización de herramientas de apoyo como Microsoft Project y Open Project, en la cual los principales hitos del proyecto aparecen representados bajo la forma de rombos.
Figura 8. Planificación en MS Project de un proyecto de implantación de una solución del portal del ciudadano
Rodríguez, García, Lamarca (2007)
3.2.2.Matriz de roles y responsabilidades
La definición de hitos en el proyecto debe ir acompañada de la definición de roles y responsabilidades para cada uno de los mismos. La definición de roles y responsabilidades implica designar para cada hito:

  • Quién es el responsable de la ejecución de cada hito.

  • Quién toma las decisiones, sólo o juntamente con otros.

  • Quien gestiona los recursos y controla el progreso del trabajo.

  • Quién debe ser informado.

  • Quién debe ser consultado.

  • Quién debe participar.

  • Quién debe dar apoyo o dotar de infraestructura al equipo.

  • Quién asegura la calidad de los resultados.

En el nivel de hitos es muy importante establecer las responsabilidades del nivel directivo y del personal del cliente, no sólo las del equipo de trabajo o, en su caso, los subcontratistas.
Ved también
En este material, hemos creído que es más claro presentar todos los aspectos relacionados con la organización y los recursos humanos en un módulo final y más extenso, en lugar de presentarlo a lo largo de la metodología. Allí (módulo "El lado humano de la gestión de proyectos") encontrará el alumno una descripción y formularios detallados de este y otros instrumentos.

3.3.Estructura de descomposición del trabajo (EDT)

Según el PMBOK, crear la estructura de descomposición del trabajo (work breakdown structure o WBS), es el proceso de subdividir el trabajo y los entregables del proyecto en componentes más pequeños y manejables. Se trata por lo tanto de una descomposición jerárquica y orientada a productos. Idealmente, se trata de dividir un producto grande en otros más pequeños, que se llaman paquetes de trabajo (work packages). Cada paquete de trabajo puede ser más fácilmente costeado, controlado y colocado en un calendario.
Por ejemplo, en un proyecto de construcción e implantación de software a medida (siguiendo la metodología típica de desarrollo estructurado a lo largo del ciclo de vida, system development life cycle), podríamos hipotéticamente descomponer el total en los siguientes paquetes:

  • La gestión del proyecto.

  • La toma de requisitos.

  • El diseño de detalle.

  • La construcción.

  • La integración.

  • Las pruebas.

  • La implantación.

Si el proyecto es suficientemente grande, podríamos seguir descomponiendo cada paquete en otros menores, por ejemplo, el diseño podría incluir:

  • Planificación del diseño.

  • Diseño lógico.

  • Diseño físico.

  • Especificaciones de seguridad.

  • Especificaciones de interfaz con otros programas.

  • Especificaciones de conversión de datos.

  • Revisiones de usuario.

  • Revisiones de personal técnico.

  • Revisiones de documentación.

En cambio, en proyectos de infraestructura y telecomunicaciones, es frecuente seguir un procedimiento de abajo arriba (bottom-up), donde primero recogemos todos los elementos o componentes que el proyecto tiene que incluir y a continuación los reunimos en paquetes. Podemos ver este modelo en la tabla 3.
Snyder y Parth (2007)
Tabla 3
Estructura de descomposición del trabajo en un proyecto de despliegue de una red LAN/WAN
1) Recoger requisitos
1.1) Requisitos de usuario
1.2) Requisitos de las estaciones de trabajo
1.3) Requisitos de los servidores
1.4) Requisitos de la red
1.4.1) Routers
1.4.2) Switches
1.4.3) Circuitos
1.4.4) Cableado
1.5) Periféricos
1.5.1) Impresoras
1.5.2) Faxes
1.5.3) Escáneres
1.5.4) Copiadoras
2) Comprar los equipos
Mismos componentes que 1.4. y 1.5.
3) Instalar los equipos
Mismos componentes que 1.4. y 1.5.
4) Test
4.1) Tests unitarios
4.2) Test del sistema (LAN)
4.3) Test de integración (WAN)
5) Gestión de proyecto
5.1) Iniciación y kick-off
5.2) Planificación
5.3) Ejecución, seguimiento y control
5.4) Documentación
5.5) Control de cambios
5.6) Cierre
Hay muchas maneras de hacer la descomposición: por fases del ciclo de producción, por productos a entregar, por subproyectos, incluso por despliegue territorial o por oficinas o plantas del cliente, etc. El Project Management Institute (PMI) ha publicado un libro de estándares que proporciona guías para la elaboración de EDT.
Los únicos consejos que vale la pena dar son dos, de sentido bastante práctico:
1) No dejar la descomposición tan arriba que el proyecto se convierta en inmanejable, imposible de asignarle recursos, costes y responsabilidades; no bajar tan abajo que el coste del control se convierta en insoportable.
2) Vincular tanto como sea posible las EDT a los productos e hitos. Eso hace más fácil la comprensión y diálogo con el cliente y con el equipo y la orientación de unos y otros al resultado. Muchos productos intermedios o actividades auxiliares de tipo técnico no interesan a nadie al final del día.

4.Planificar el tiempo

Tiempo y coste son los dos ámbitos por excelencia de la planificación.
Si uno examina los procesos de PMBOK, los grupos de procesos o áreas de conocimiento de tiempo y coste se concentran en la etapa de planificación del proyecto (cuyo seguimiento y control se persigue, obviamente, después). Para muchos directores de proyecto, tiempo y coste se convierten también en una obsesión, que pasa por desgracia por encima de los objetivos del proyecto, la gestión del alcance y la calidad del trabajo y, sobre todo, la satisfacción del cliente.
Los procesos comprendidos en este proceso son los siguientes, según la presentación que hace de ellos PMBOK:
1) Definir las actividades, es decir, identificar las acciones específicas que deben desarrollarse para producir los resultados parciales y finales del proyecto. Como hemos dicho antes, los objetivos se convierten en hitos y entregables, y los entregables y EDT se convierten ahora en actividades. Las actividades, a su vez, se desglosan en tareas.
2) Secuenciar las actividades, es decir, identificar y documentar las relaciones y el orden de realización de las actividades definidas.
3) Estimar los recursos para las actividades, es decir, estimar el tipo y cantidades de recursos humanos (tiempo de personas), equipamiento, materiales o suministros necesarios para realizar las actividades. De todos estos recursos, el más importante en los proyectos TIC es el tiempo (o tiempo equivalente) de personas de diferente tipo y cualificación. Esfuerzo es la carga o cantidad de trabajo necesario para completar una tarea.
4) Estimar la duración de las actividades, es decir, establecer de modo aproximado el número de periodos de trabajo (tiempo equivalente en horas, jornadas, semanas) para completar las actividades individuales con los recursos estimados anteriormente.
5)Establecer el calendario o cronograma de trabajo, es decir, analizar y relacionar la secuencia de actividades, su duración, los requisitos y disponibilidad de recursos y las limitaciones de agenda y calendario de proyecto, para crear el calendario de trabajo.
Es importante ver que todas estas acciones, en apariencia discretas y ordenadas, se interrelacionan, y aún más en proyectos complejos, con muchos subproyectos y en entornos de recursos escasos, donde determinados perfiles no están disponibles cuando se necesitan. Cuando todo esto se sitúa en un calendario, si se producen variaciones en una actividad o grupo de actividades, afectan a todo el conjunto o a algunas actividades críticas del conjunto, de manera que parte del trabajo de ejecución es un ejercicio continuo de replanificación, demanda y reubicación de recursos. Esto consume muchísimo tiempo y energía del director de proyecto.
PMBOK y otras metodologías presentan de forma separada el conjunto de procesos, técnicas y herramientas necesarias para la planificación del tiempo y preparación del calendario y que el director de proyecto puede usar según su conveniencia y el tamaño y complejidad del proyecto. Una visión general del proceso de planificación del tiempo en la cuarta edición de PMBOK se presenta en la figura siguiente.
Figura 9. Visión general del proceso de planificación del tiempo en PMBOK
Fuente: PMBOK (2008)
Sin embargo, en nuestra opinión esta aproximación no ayuda fácilmente a contestar a la pregunta habitual del director de proyecto: "¿Y ahora qué hago?". De manera que, para el mejor manejo del alumno y su aplicación práctica en los proyectos más comunes, utilizaremos aquí una aproximación secuencial extraída de un manual reciente preparado por uno de los autores (Rodríguez, García, Lamarca, (2007)).

4.1.Planificar las actividades

La planificación de las actividades y tareas es un proceso que se deriva de la definición de los hitos del proyecto y, por lo tanto, hasta este momento no se aborda cómo actuar para conseguir los objetivos del mismo.
Los hitos son situaciones, productos, estadios del trabajo. Las actividades son acciones necesarias para alcanzar los hitos. Las tareas son acciones dentro de cada actividad.
La manera más habitual de representar un plan de actividades es utilizar un diagrama de Gantt.
El diagrama de Gantt
El diagrama de Gantt muestra el tiempo en el eje de abscisas, mientras que en cada línea del eje de ordenadas se disponen todas las actividades que forman el proyecto. En la parte izquierda se escribe el nombre de las actividades, mientras que en la parte derecha se marca una línea inicial desde la fecha del inicio hasta la fecha de finalización de cada actividad.
En el ejemplo que se exponía de portal de servicios al ciudadano en Internet del apartado anterior, las actividades principales del proyecto identificadas constituyen el lanzamiento y el arranque del proyecto, el análisis de requisitos, el diseño funcional y el diseño técnico del sistema, la construcción del prototipo y la construcción e implantación del portal. Estas actividades se muestran en la representación del gráfico de Gantt de MS Project en los encabezados en negrita de la figura 10.
Uso de MS Project y Project Server
MS Project es una herramienta muy intuitiva y actualmente está integrada con el resto de las aplicaciones de MS Office. Además, si utilizáis Project Server, podréis agregar otros documentos, compartir la información del proyecto con el equipo o el cliente y publicar información en la web.
Figura 10
Rodríguez, García, Lamarca (2007).
Sin embargo, estas actividades son muy generales y en la planificación del proyecto se necesita un mayor detalle en las tareas. Las actividades se desglosan en tareas y grupos de tareas. En el ejemplo que nos ocupa, la actividad de diseño funcional del portal supone tareas como el diseño de la estructura y navegación del portal, el diseño de los flujos de trabajo, el diseño de la apariencia gráfica (look and feel), el diseño de los productos y servicios, etc. Asimismo, el diseño técnico contempla el diseño de las especificaciones por contenido y servicio, el detalle de la arquitectura técnica y seguridad, el diseño de interfaces, etc. Las tareas se visualizan con barras más gruesas azules en la representación de MS Project.
Es bueno volver a planificar cada grupo de actividades, al comienzo de cada nuevo hito. Es probable que durante la realización del hito anterior hayan aparecido variables que aconsejen abordar el trabajo siguiente de forma diferente y con una diferente distribución de recursos.
El proceso es un trabajo de descomposición sucesiva, donde el problema habitual es decidir hasta qué nivel de detalle es conveniente llegar.
Como regla general, el nivel de detalle necesario es aquel que facilita la ejecución del trabajo y la comunicación con el cliente y el equipo de trabajo. También es el que necesitamos para la estimación del esfuerzo y el presupuesto. Algunos consejos complementarios:

  • Cada actividad individual no debería suponer una carga muy grande de trabajo, por ejemplo, un total de 10 a 15 días/hombre.

  • Debería ser fácilmente observable y evaluable si la actividad ha sido completada o no.

  • Debería poderse hacer un control de calidad del resultado de la actividad.

En proyectos TIC, la experiencia y uso de metodologías específicas para cada tipo de proyecto facilitan la preparación del plan de actividades y la estimación de esfuerzos.

4.2.Estimación de esfuerzos

Efectivamente, para todo el mundo esta es la parte que parece más complicada. Es difícil hacer una estimación precisa del esfuerzo que un proyecto requiere, en especial si se trata de cosas que no se han hecho antes, si incluyen actividades o equipos de naturaleza muy diferente o si tienen muchos componentes de integración. La estimación de esfuerzos tiene mucho más de arte que de ciencia y, como todas las artes, se aprende con la experiencia más que con los libros. Entretanto, preguntar al que sabe o comparar con otros proyectos similares puede ser de ayuda.
Lo primero que debe tenerse en cuenta es que en esta etapa estamos estimando cuál es la carga o cantidad de trabajo necesario normalmente para hacer una actividad (el nivel de tiempo o esfuerzo requerido), no cuándo la completaremos en el calendario del proyecto (la duración estimada).
Una misma actividad, con una misma estimación de esfuerzo, puede ser completada antes o después dependiendo del número de recursos dedicados, las demoras o tiempos muertos o las dependencias con otras actividades.
La unidad de tiempo (insistimos: esfuerzo) que utilizamos para las estimaciones dependen normalmente del tipo y tamaño de proyecto. Un proyecto se puede estimar en horas, días, meses o años/hombre. Normalmente, la unidad días/hombre es útil para proyectos de diferente tamaño.
El nivel de esfuerzo de un proyecto depende de las actividades a desarrollar y es independiente de la secuencia en la que realicemos las actividades o del equipo de proyecto. Pero el calendario y el coste, como veremos en los apartados siguientes, dependen de esas y otras variables. Es muy importante, para planificar y presupuestar el proyecto, tener en cuenta estas distinciones de concepto.

4.3.Secuencia y duración del trabajo

Si descomponemos un proyecto en cinco hitos y cada hito en cuatro actividades y cada actividad en cinco tareas, en teoría podríamos empezar todas las tareas a la vez y el proyecto duraría tanto como la tarea más larga. Pero la práctica no tiene nada que ver con esto. Existen dependencias o relaciones entre actividades, que obligan a realizarlas en un cierto orden. No todas las actividades pueden hacerse en paralelo, aunque esto sería lo ideal. En segundo lugar, los recursos no son ilimitados, en el equipo hay un número limitado de personas que no pueden hacer todas las cosas a la vez. Algunas actividades tienen que esperar a que un miembro del equipo de trabajo esté libre.
Ya se ve que las fases de la planificación del proyecto, que hemos presentado linealmente hasta ahora, son en buena medida iterativas e interrelacionadas. Se descomponen las actividades, se examina la carga de trabajo, se ve qué actividades se pueden hacer en paralelo o en serie, se mira el equipo disponible, se reexamina el orden, se revisan las posibilidades de optimizar el proceso, se calculan y recalculan los costes y la duración para que sean aceptables para el cliente y para la empresa. Se discute internamente y con el cliente.
Entre las dependencias, es importante identificar las que no están bajo nuestro control, las que son externas al proyecto. En determinadas circunstancias, un proyecto puede ir más rápido poniendo más recursos en aquellos temas que están bajo nuestro control. Esto no ocurre con aquellas actividades o dependencias externas.
La planificación de las actividades y tareas para alcanzar un hito en un proyecto y la definición de sus interdependencias permiten al gerente establecer cuál es el camino crítico; es decir, la cadena de actividades que determinan la duración global mínima de un proyecto. Cada retraso en completar una actividad en el camino crítico resultará en un retraso en la finalización general del proyecto.
Estas técnicas se conocen como técnicas de análisis de red.
El camino crítico (CPM) y el PERT
El camino crítico es la cadena de actividades críticas desde el principio del proyecto hasta su finalización.
El método del camino crítico provee una vía para identificar fácilmente la forma más rápida de completar el proyecto en el tiempo, a partir de la duración estimada de las actividades. El método permite identificar y analizar qué actividades constituyen cuellos de botella. El input para el método del camino crítico es una lista de cada actividad, su duración esperada, y aquellas actividades que inmediatamente la preceden. La precedencia inmediata significa, en este caso, que las actividades predecesoras deben ser completadas antes de que la actividad sujeta pueda empezar, y no existen otras actividades entre éstas y sus predecesoras.
El método del PERT (técnica de revisión y verificación de programas) es una modificación del método del camino crítico, en la que se puede considerar adicionalmente la incertidumbre (varianza) en la duración de una actividad. Se requieren tres niveles de duración de actividades (mínimo, más probable, y máximo). El tiempo mínimo es relativamente fácil de estimar, ya que corresponde al tiempo de actividad que se requeriría si todo fuera bien. La dificultad está muchas veces en encontrar el tiempo máximo. El PERT fue creado por la U.S. Navy en los años cincuenta, y responde a una limitación obvia del método del camino crítico. Sin embargo, no se utiliza con asiduidad en la práctica de proyectos de sistemas y, cuando se usa, una estimación a la ligera de los inputs de tiempos puede hacer que las desviaciones en el cálculo sean mayores que las del método del camino crítico original, por lo que sólo se recomienda en ciertas situaciones concretas en las cuales las estimaciones son muy fiables.

4.4.Distribución del trabajo y recursos necesarios

Una vez establecido en detalle lo que hay que hacer, cómo se hará y el nivel de esfuerzo requerido, ya se está en condiciones de determinar la cantidad de recursos necesarios y sus características, y de establecer el presupuesto de costes del proyecto.
El plan de trabajo de un proyecto incorpora a la tabla los recursos que se requieren y la duración estimada del trabajo, así como la contribución de cada miembro del equipo: qué capacidades, habilidades, experiencia y formación se requieren; cuánta gente de cada tipo de capacidad o formación o experiencia; cuánto cuestan o cuánto cobran; hay presupuesto para eso.
Como ya dijimos, una cosa son las necesidades y otra cosa son las disponibilidades y la capacidad del proyecto para costearlo. Una cosa es el plan inicial o teórico de distribución del trabajo y otra cosa es cómo quedará después de confrontarlo con la realidad.
Vale la pena dialogar entre las partes o miembros del equipo a la hora de preparar la distribución del trabajo y asignar tareas y responsabilidades. Este diálogo, como siempre, tiene al menos dos partes: el diálogo entre el cliente y el jefe de proyecto, y el diálogo entre el jefe de proyecto y cada miembro del equipo. Ese diálogo debe asegurar la comprensión y aceptación del compromiso por todos los participantes.
La dedicación del jefe de proyecto debe figurar en el plan y no se debe subestimar. Muchos proyectos requieren una dedicación completa de una persona para el trabajo de gestión. En otros, esa responsabilidad es compatible con su dedicación a actividades o tareas técnicas dentro del proyecto.
Para las actividades de diseño del portal del ciudadano del ejemplo que venimos utilizando, la tabla 4 muestra la distribución de las tareas y la tabla de responsabilidad y perfiles profesionales del equipo asignados a cada tarea.
Fuente: Rodríguez, García, Lamarca (2007)
Tabla 4. Ejemplo de distribución del trabajo y lista detallada de tareas y asignaciones en el diseño del nuevo portal de servicios de un municipio
Tareas
CF
US
AS
AP
GP
DG
Duración
Unidad
Desarrollo e implantación del portal
 
 
 
 
 
 
 
 
 
Diseño del portal
 
 
 
 
 
 
 
 
 
 
Análisis de requisitos
R
P
I
P
 
 
10
días
 
 
Especificación funcional
R
P
I
P
 
 
5
días
 
Diseño funcional
 
 
 
 
 
 
 
 
 
 
Diseño funcional de la estructura del portal
R
P
C
P
 
I
20
días
 
 
Diseño funcional de los productos y servicios
R
P
C
P
 
I
20
días
 
 
Diseño de los flujos de trabajo (content workflows)
R
P
C
P
 
I
20
días
 
 
Diseño de los procesos web
R
P
C
P
 
I
20
días
 
 
Diseño de la navegación
R
P
C
P
 
I
10
días
 
 
Diseño gráfico look and feel
P
P
D
C
 
R
15
días
 
Diseño técnico
 
 
 
 
 
 
 
 
 
 
Detalle de la arquitectura técnica y seguridad
C
C
R
C
I
 
10
días
 
 
Diseño técnico de especificaciones por servicio
C
C
P
R
I
C
35
días
 
 
Diseño de las interfaces
C
C
P
R
I
C
10
días
 
Lanzamiento prototipo
 
 
 
 
 
 
 
 
 
 
Construcción del prototipo
R
P
P
R
P
P
5
días
 
 
Pruebas del prototipo
R
P
P
R
P
P
3
días
GP = Gerente de proyecto
CF = Consultor funcional
US = Usuario
AS = Arquitecto de sistemas
AP = Analista programador
PR = Programador
DG = Diseñador gráfico
R = Responsable
P = Participa
C = Es consultado
I = Es informado
D = Está disponible
S = Da apoyo
Una vez detalladas las tareas a un nivel que permite la distribución del trabajo, se establece la asignación de cada tarea a los diferentes perfiles y su dedicación estimada. El esfuerzo y la estimación de capacidades necesarias de cada tipo de recurso (en jornadas/hombre) para cubrir cada una de las tareas que mostrábamos en el ejemplo anterior se muestran en la tabla 5. En caso necesario, para una misma tipología profesional se planifica más de un recurso destinado a la tarea.
Tabla 5. Estimación de dedicaciones requeridas (jornadas/hombre) para cada categoría profesional
Tareas
CF
US
AS
AP
GP
DG
Duración
Unidad
Desarrollo e implantación del portal
ción del portal
 
 
 
 
 
 
 
 
 
Diseño del portal
 
 
 
 
 
 
 
 
 
 
Análisis de requisitos
20
20
 
10
 
 
10
días
 
 
Especificación funcional
10
10
 
5
 
 
5
días
 
Diseño funcional
 
 
 
 
 
 
 
 
 
 
Diseño funcional de la estructura del portal
40
20
5
20
 
4
20
días
 
 
Diseño funcional de los productos y servicios
40
20
5
20
 
4
20
días
 
 
Diseño de los flujos de trabajo (content workflows)
40
20
5
20
 
1
20
días
 
 
Diseño de los procesos web
40
20
20
20
 
 
20
días
 
 
Diseño de la navegación
20
10
10
10
 
5
10
días
 
 
Diseño gráfico look and feel
10
5
5
5
 
20
20
días
 
Diseño técnico
 
 
 
 
 
 
 
 
 
 
Detalle de la arquitectura técnica y seguridad
4
2
20
10
 
 
20
días
 
 
Diseño técnico de especificaciones por servicio
20
10
10
70
2
2
35
días
 
 
Diseño de las interfaces
6
6
10
20
1
2
10
días
 
Lanzamiento prototipo
 
 
 
 
 
 
 
 
 
 
Construcción del prototipo
5
1
5
10
10
5
5
días
 
 
Pruebas del prototipo
3
3
3
6
6
3
3
días
GP = Gerente de proyecto
CF = Consultor funcional
US = Usuario
AS = Arquitecto de sistemas
AP = Analista programador
PR = Programador
DG = Diseñador gráfico
 
Una de las mayores causas de desviación en la gestión de proyectos es la incorrecta estimación inicial de recursos para la realización de actividades. Se han escrito muchas reglas sobre la estimación de tiempos y recursos en proyectos TIC. No existen, a nuestro juicio, recetas mágicas sobre este aspecto más que las que ya se han dado con carácter general. Desafortunadamente para los recién iniciados, en una parte importante las capacidades de estimación se van adquiriendo con la experiencia de los años. Sin embargo, sí se puede efectuar una serie de recomendaciones que creemos que pueden ser útiles para estimar proyectos informáticos complejos.
Fuente: Rodríguez, García, Lamarca (2007)
Tabla 6. Recomendaciones para la estimación de recursos y tiempo en un proyecto informático

  • Constan todas las actividades que permiten completar un hito.

  • Existen resultados claros y observables para cada actividad.

  • Cada hito no debería descomponerse en más de 10 actividades. Cada actividad no debería suponer más de 10 a 15 días/hombre de trabajo.

  • No asumáis que si una persona necesita completar un trabajo en diez días, diez lo podrán hacer en un día. El tiempo y los recursos no siempre son intercambiables.

  • Foco: no asignéis muchas tareas en el mismo periodo de tiempo a una misma persona o la misma persona a varios proyectos. No asignéis a varias personas para hacer la misma cosa.

  • Nunca planifiquéis los recursos asumiendo una productividad del 100% en el trabajo. Usad un máximo del 85%, y reconoced que un 15% puede ser tiempo improductivo. Tened en cuenta los periodos vacacionales, las bajas laborales y los imponderables en vuestras estimaciones.

  • Planificad al mejor profesional para las tareas más complejas, y si le sobra tiempo asignadle las demás.

  • Identificad las actividades que consumen más recursos, que involucran a más personas y en departamentos diferentes y que ocupan más tiempo en el calendario. Planificad éstas con más detalle, dejando márgenes de tolerancia y acordando compromisos con las partes.

  • Reducid el número de interdependencias entre las actividades al mínimo posible, de manera que el camino crítico sea el más corto posible.

  • Procurad, siempre que sea posible, que las actividades más importantes para completar un hito no estén en el camino crítico.

  • Reservad tiempo suficiente para la toma de decisiones del cliente y para la revisión y evaluación de los entregables y resultados intermedios.

  • Dejad espacios libres en el calendario.
El ''zoom'': Planificación a largo plazo y planificación a corto plazo
En varias partes de estos materiales hemos hablado de la habilidad del buen director de proyecto para pasar de la visión global al detalle y para elevarse sobre el detalle y tener la visión global del trabajo. Hemos usado la metáfora del 'zoom'; otros le llaman el 'helicóptero'.
Suponed que estáis planificando un viaje para vuestras próximas vacaciones: queréis visitar en coche distintas ciudades del litoral mediterráneo teniendo en cuenta que saldréis de Barcelona y acabaréis en Roma. Seguramente, vuestra primera preocupación es buscar alojamiento para cada ciudad y encontrar la mejor ruta de comunicación entre cada una de las mismas. Sin embargo, lo más probable es que no indaguéis la ruta entre el hotel y un museo de la ciudad que visitáis, hasta el momento en el que lleguéis a la ciudad.
Igualmente, en la planificación de proyectos informáticos el equilibrio entre la planificación macroscópica o a largo plazo (el objetivo final y los grandes hitos) y la visión microscópica o a corto plazo (el detalle de las actividades y tareas a realizar inmediatamente) es muy importante.
Un buen jefe de proyecto sabe hacer el 'zoom' entre la planificación y control de lo inmediato, sin perder de vista el alcance global del trabajo. El gerente de proyectos informáticos que cree que puede planificar las tareas de una mañana de trabajo con exactitud, a seis meses vista, seguramente se está equivocando, o está invirtiendo esfuerzos con un retorno muy poco probable. A buen seguro, cuando llegue el sexto mes de trabajo, su plan de actividades estará ya en su cuarta o quinta versión de su MS Project, y reconocerá que su plan inicial era poco realista.
Para el gerente de proyecto, la clave en la concreción de su plan de proyecto es delimitar o vislumbrar hasta dónde llega lo que algunos autores han denominado el horizonte del proyecto (Gauge); es decir, hasta dónde (qué hito, qué entregable, qué tiempos, qué presupuesto, etc.), de una manera realista, se puede concretar en este momento y con la información disponible el detalle del plan de actividades de un proyecto.
En definitiva, la combinación de una buena planificación general del proyecto (hitos, responsables, actividades de primer nivel, recursos necesarios) con una concentración eficiente del esfuerzo de planificación detallada al principio de cada etapa o cada nuevo hito es uno de los factores críticos de éxito de un proyecto.
Fuente: adaptado de Rodríguez, García y Lamarca (2007).

4.5.Preparación del calendario definitivo

En esta fase, cerramos el círculo o los círculos de la planificación. Ponemos en el calendario el plan de trabajo real, teniendo en cuenta los recursos disponibles y las restricciones de tiempo y de coste; examinamos los riesgos y establecemos el nivel de contingencias para desviaciones o incumplimientos que pueden producirse; lo revisamos todo, para ver si existen oportunidades de optimización del proceso o actividades que hemos olvidado. Y finalmente, lo discutimos con el cliente y, en su caso, con nuestra propia organización.
4.5.1.Calendario de hitos
Volvemos al inicio. Los hitos son los elementos que nos permiten conocer y comunicar el progreso del proyecto. Normalmente, son estados en los cuales se producen entregables parciales que deben ser aprobados por el cliente. También será el momento de revisar la planificación y de establecer planes más detallados para el trabajo que nos queda por hacer. Ahora ya estamos en condiciones de poner fechas que indiquen la realización de cada hito. Las fechas para completar las actividades pueden variar. Las fechas de entrega o de consecución de hitos deberían variar lo menos posible.
En el ejemplo que venimos presentando, el calendario de hitos sería el siguiente
Fuente: Rodríguez, García, Lamarca (2007)
Tabla 7. Calendario de hitos
Hito
Fecha
1) La disponibilidad del entorno de desarrollo y de pruebas.
18 de marzo
2) La aprobación de especificaciones, la aprobación de los diseños funcionales y técnicos.
22 de abril
3) La aprobación del prototipo.
22 de abril
4) La aprobación del sistema en el entorno de pruebas.
27 de mayo
5) La aceptación en el entorno de producción.
1 de julio
6) La aprobación de la formación completa de usuarios y la documentación técnica de operación del sistema.
1 de julio
7) El arranque de la nueva plataforma de portal.
7 de julio
4.5.2.Calendario completo
El calendario completo, o al menos por EDT, debe incluir el detalle que se requiera en cada caso de actividades, tareas, su duración, las interdependencias, las fechas de obtención de los productos, etc. Microsoft Project, Open Project y otras herramientas permiten seguir todo el ciclo de planificación de tiempo y recursos y además su representación gráfica (aunque muchas veces, tan sólo se están usando como una herramienta de presentación).
El calendario completo es la herramienta habitual de trabajo a nivel del equipo y para el detalle de las actividades y tareas.
Uso de MS Project
De forma simplificada, la manera de trabajar con MS Project sería la siguiente:
1) Introducir la fecha de inicio del proyecto.
2) Establecer los periodos laborables y los festivos.
3) Crear una lista de tareas sobre la parrilla.
4) Organizar las tareas por etapas o fases, aplicando el botón de sangrado.
5) Determinar los vínculos o dependencias entre las tareas. Podréis utilizar al asistente.
6) El asistente permite también establecer fechas límite y asignar recursos y costes.
7) MS Project permite crear diagramas de Gantt (se crea automáticamente mientras se va trabajando sobre la parrilla), diagramas PERT, calcular la línea base de tiempo y el camino crítico.
Fuente: Alfons Bataller (2010). La gestió de projectes. Barcelona: UOC.
M. Andrés Gay; E. Yebes López (2007). Project 2007. Madrid: Anaya Multimedia

5.Planificación de costes

El grupo de procesos de planificación de costes incluye la estimación y valoración de los costes de todos los recursos que estarán involucrados en el proyecto (en proyectos TIC, particularmente los recursos humanos) y la preparación del presupuesto.
En la práctica, estos procesos interaccionan con los del grupo anterior (estimación de tiempo) y a menudo se preparan conjuntamente. Debido al peso que tienen los costes de personal en la mayoría de los proyectos TIC, tiempo y dinero en la gestión de proyectos son dos maneras de mirar la misma cosa. Y también, como en el caso anterior, son procesos iterativos y permanentes, que se revisan y adaptan con la ejecución y seguimiento del proyecto.
Para la preparación del Plan de costes, se han de tener en cuenta muchos factores, que normalmente dependen del tipo y tamaño del proyecto, de las características de los recursos que participan y de la organización en la que se trabaja. Los más importantes son:

  • La base u objetivo de la medición. Lo más habitual y recomendable es hacerlo al nivel de las EDT, o sea, de las partes o paquetes de trabajo en que hemos dividido el proyecto. Es frecuente y recomendable establecer una cuenta de coste, al menos interna, por EDT, a la que se irán 'cargando' los costes reales incurridos.

  • Una segunda decisión es hasta qué nivel de descomposición llegamos (grupos de actividades, actividades, tareas...), que dependerá principalmente de la experiencia de la organización (y de lo bien que estén documentadas sus 'bases de conocimiento') o del jefe de proyecto o de la clase de trabajo. En todo caso, mientras que la planificación de alcance tiene una visión más estratégica y de arriba abajo (top-down), la planificación de tiempos y costes tiene una dimensión más operativa y táctica y de abajo arriba (bottom-up).

  • Las unidades de medida, que dependen del tipo de recurso. En el caso de los recursos humanos, normalmente se adjudica un coste, precio o tarifa objetivo por unidad de tiempo (hora, día, semana) por persona. En el caso de recursos técnicos, es recomendable disponer de las tarifas o listas de precios para las estimaciones iniciales, y solicitar de varios proveedores su mejor presupuesto.

Estimación ascendente del coste
La estimación ascendente de los costes del proyecto se deduce del consumo de tiempos y recursos en la ecuación siguiente:
Coste = dedicación de recursos * tiempo * coste unitario de tiempo
El cálculo se aplica partiendo del cálculo de dedicaciones estimadas para cada una de las tareas asignadas a los miembros del proyecto y los costes unitarios de trabajo de cada uno de los profesionales.
A estos costes debe incorporarse el conjunto de costes de sistemas (consumibles, licencias de HW y SW, comunicaciones, etc.), los costes de recursos físicos (espacios, materiales, etc.) y otros costes generados por el proyecto (dietas, desplazamientos, formación, alquileres etc.).
Las empresas de servicios establecen tarifas o precios unitarios para cada categoría profesional, por hora o por día, en los que están imputados los costes laborales, la productividad de los recursos, los gastos generales de la empresa y el margen de beneficio. En los departamentos de informática internos o que prestan servicio a diferentes departamentos de la empresa en diferentes clases de proyectos, es deseable establecer un sistema similar de valoración del trabajo. Incluso en muchas empresas existen sistemas de facturación interna, mediante la cual se 'cargan' al negocio los costes de sus proyectos.

  • El nivel de precisión de las estimaciones, u orden de magnitud (rough order of magnitude, o ROM), que acostumbra a ser muy alto al comienzo del proyecto (¡de hasta un 50%! en la etapa de iniciación) y se va acotando a medida que el proyecto avanza (entre un 10% y un 20% cuando se prepara el Plan de costes).

  • El nivel de reservas o contingencias necesario para cubrir las incertidumbres (los riesgos) del proyecto. Puede variar de un proyecto a otro, en función del plan de riesgos establecido, al que dedicamos otro apartado en este módulo.

  • Los umbrales de desviación o variaciones aceptables sobre la línea base de coste, fuera de los cuales deberemos hacer sonar alarmas y tomar decisiones mayores respecto al tiempo, alcance, calidad, etc.

  • Los formatos de presentación del presupuesto y de los informes o reporting internos y al cliente, que dependen del tipo de organizaciones (la nuestra y la del cliente) para las que trabajamos.

Pero la planificación de costes no sirve únicamente para la preparación y control posterior del presupuesto (y sus desviaciones), sino para analizar el rendimiento o valor aportado por el proyecto, globalmente y en cada momento. Para ello existen diferentes técnicas. El Project Management Institute ha desarrollado la técnica del valor ganado (earned value management), de la que presentamos un resumen en otro módulo de este material.
Dependiendo del tipo de proyecto y del tipo de análisis que el cliente requiera, es conveniente tener en cuenta varios aspectos adicionales:

  • La estimación de costes de proyecto debería cubrir TODOS los costes en los que se incurrirá, también los costes de calidad, comunicación, formación del equipo, etc.

  • La estimación de costes también debería cubrir los costes en los que incurrirá el cliente por causa del proyecto o, al menos, presentarlos en el capítulo de asunciones y limitaciones de la definición de alcance.

  • Los costes de un proyecto (en especial, si incluye el desarrollo o instalación de un producto) deberían incluir todos los costes presentes y FUTUROS, incluidos los de mantenimiento, evolución, formación, etc., en definitiva, lo que se conoce como coste total de la propiedad (total cost of ownership).

En los textos de ingeniería de sistemas de información y en las metodologías específicas para cada tipo de proyectos, es posible encontrar modelos y guías para la estimación de costes de los proyectos informáticos. Para Boehm, uno de los clásicos en ingeniería de construcción de software, existen siete métodos diferentes de estimación, que se muestran en la tabla siguiente.
Fuente: adaptado de Boehm (1981)
Tabla 8. Modelos de estimación de costes en proyectos informáticos
1) La utilización de modelos algorítmicos que dan una estimación del coste en función de un número determinado de variables que influyen en el mismo.
2) El juicio experto en proyectos similares, que aprovecha la opinión de profesionales que han liderado proyectos similares.
3) La analogía con otro proyecto parecido que sea comparable con el que se plantea.
4) La utilización de los recursos disponibles, en la cual lo que limita el coste es el volumen de recursos de los que se dispone en cada etapa.
5) El precio ganador, en el que la estimación de los costes no se realiza en función de las cargas de trabajo, sino de las condiciones del mercado y la competencia.
6) La estimación global descendente (top-down), en la que se intenta fijar un coste general del proyecto a partir de sus características principales (tamaño, complejidad, dificultad técnica, calidad y fiabilidad, etc.).
7) La estimación ascendente a partir de la desagregación de las actividades en tareas.
Normalmente, para la estimación de costes en las fases de aprobación y definición, incluso en el nivel de la planificación de hitos, se utiliza cualquiera de los seis primeros. Sin embargo, para la estimación de costes en la planificación de actividades (planificación operativa), el método más preciso y realmente indispensable es el de estimación ascendente (de abajo arriba, es decir, desde la tarea que se debe realizar).
A la lista anterior, podríamos añadir la técnica de los tres puntos, que se utiliza en paralelo al cálculo del PERT (que hemos comentado al presentar el método del 'camino crítico'). Se trata de utilizar tres estimaciones (el coste más probable, el cálculo más optimista y el cálculo más pesimista, y calcular la media simple o la media ponderada de las tres.
Ejemplo
Honestamente, no es posible conocer el coste preciso de un proyecto hasta que se realiza la planificación de tareas para cada hito. Como señalan Andersen y otros:
"En realidad, una fecha de finalización vinculante sólo puede establecerse si se conocen todas las actividades que deben ejecutarse, la gente que estará involucrada en el trabajo y todas las condiciones que pueden afectar al proyecto. Para saber todas estas cosas, debería haber transcurrido la mayor parte del proyecto."
Por desgracia, salvo proyectos rarísimos que se parecen como dos gotas de agua, no es posible establecer la planificación de actividades para cada hito y por lo tanto, la distribución de recursos y el coste, hasta que se tiene que abordar la realización de un hito. Por eso es aconsejable siempre que sea posible descomponer el trabajo en tantas fases (EDT, en estos materiales) e hitos como sea posible, establecer la planificación de actividades al comienzo de cada hito, y no comprometer una estimación definitiva de recursos y un calendario hasta ese momento y para cada fase fase o hito.
Con esta observación, no estamos animando a una planificación laxa y poco comprometida. La planificación sirve sobre todo para estar seguro de que el proyecto progresa adecuadamente y de que se construyen las bases correctas para cumplir los resultados en tiempo y recursos. Simplemente apelamos a construir un diálogo realista sobre qué cosas son razonables prometer y en qué momento, y disponer de alternativas cuando el plan se desvía por diferentes razones.
Fuente: Rodríguez, García, Lamarca (2007).

5.1.El presupuesto

A pesar de todo, y con todas las limitaciones y cauciones del caso, cada día las compañías toman decisiones pequeñas, medianas y multimillonarias basadas en sus mejores estimaciones (y en la confianza de que si las cosas van mal, será posible renegociar con el cliente el presupuesto, o que su dependencia respecto al proveedor será tan grande que la renegociación sobre una relación desigual será inevitable) y por tanto, preparan y presentan presupuestos, cuyo formato y nivel de detalle dependen, como hemos dicho, de las exigencias del cliente y de la práctica de cada organización.
La figura 11 presenta un formato más o menos típico de presentación de un presupuesto de desarrollo de software.
Figura 11. Formato de presentación de un presupuesto

6.Planificar la calidad

La calidad es un concepto a menudo malentendido, por esta razón, es muy necesario que, sea cuales sean las normas de calidad que queramos incluir en el proyecto, éstas sean explicitas y las hablemos con el cliente para consensuarlas. En el entorno TIC, por el hecho de ser una ciencia inmadura y en constante evolución, no resulta sencillo definir estos criterios de calidad, el ejemplo más claro está en la construcción de software. A pesar de existir una norma ISO de calidad del software, la ISO-9126, hoy por hoy no es fácil encontrar empresas que la utilicen ni interna ni externamente. Eso hace que en muchos casos, las "opiniones" de unos y otros sobre "qué es un software de calidad" sean diferentes, con los problemas derivados al mismo tiempo de validar el producto. A menudo la sorpresa del jefe de proyectos es enorme cuando el cliente responde después de una entrega de un aplicativo. En cualquier caso, habiendo o no normas específicas (ISO-9126, IEEE, CMM, SPACE, etc.) hay criterios y principios generales de calidad que son perfectamente aplicables a un proyecto TIC (ISO-9001, EFQM, TQM, y otros).
Como decíamos, hay que definir y acordar (o aconsejar si fuera el caso) con el cliente cuáles son los criterios de calidad que pesan más en cada proyecto, y por supuesto, una vez identificados, producir un producto donde estos criterios queden plenamente satisfechos, esto quiere decir que la calidad tiene que quedar impregnada en el proceso de producción de los entregables del proyecto, y por eso la necesidad de un plan de calidad que, una vez identificados, ajuste los niveles de trabajos de los diferentes equipos a los criterios acordados con el cliente.
La calidad tiene una segunda componente tanto o más relevante que la comentada, la calidad percibida o "satisfacción del cliente", o dicho de otro modo, que el producto resultante le sea útil para aquello que requería y que él lo perciba de esta manera. No es suficiente un producto perfectamente producido y ajustado a criterios de calidad "técnicos", hace falta también que el producto sea "válido", que sirva. Para conseguirlo, es necesario identificar bien claramente las expectativas funcionales del cliente y convertirlas en requisitos tangibles y producibles. Si podemos hacer esta conversión, habremos ganado mucho en el camino de obtener una "solución para el cliente", y no solo un producto para el cliente.
Planificar la calidad implica identificar qué normas son relevantes para el proyecto y determinar cómo satisfacerlas. Se creará el Plan de gestión de calidad, que describe cómo implementa el equipo de dirección de proyecto la política de calidad de la organización. El Plan de gestión de calidad forma parte del Plan de gestión del proyecto y es habitual que en el plan se definan herramientas como las métricas de calidad y las listas de control o checklist.
Hay un dicho con respecto a la calidad que dice que la "no calidad cuesta dinero" (por el retrabajo, insatisfacción, etc. que provoca), pero también se tiene que tener claro que "la calidad cuesta dinero", no es lo mismo producir un programa con una tasa de errores del 0,3 por cada 100 puntos función, que del 0,2. ¿Qué necesita el cliente? Si producimos al 0,2 y no es necesario, estaremos malgastando recursos, si producimos al 0,3 y se necesita el 0,2, el cliente se quejará. Esta idea es aplicable a cualquiera de los entregables de todo proyecto, incluyendo los de gestión, ¿qué información sobre seguimiento del proyecto necesita, muy detallada o poco detallada? Tenemos que saber ajustarnos a lo que realmente es necesario y útil para el cliente con un coste asumible en el proyecto.
La figura 12 muestra un cuadro sinóptico de los que se denominan "costes de la calidad".
Figura 12. El coste de la calidad
Fuente: PMBOK (2008)
En la planificación de la calidad hay que tomar decisiones con respecto a los costes de calidad hacia las características del proyecto, manteniendo un equilibrio entre el coste de implementar un determinado nivel de calidad y los beneficios que aportará al haberlo hecho. La calidad se refiere tanto a los entregables de gestión y a los de producto, como a los del producto final. El patrocinador y los usuarios finales valorarán la calidad del proyecto.
En todo caso, en proyectos de una cierta dimensión, cuando el cliente lo pide, cuando el hecho de tenerlo puede significar una ventaja competitiva o cuando el hecho de trabajar con calidad simplemente nos ahorre costes posteriores de no conformidades, corrección de defectos y frustraciones del cliente y del equipo, vale la pena disponer de un plan de gestión de la calidad del proyecto. Este plan determinará:

  • La misión, objetivos, alcance y enfoque de calidad dentro del proyecto.

  • La organización. Todo el mundo es responsable de la calidad, pero unas personas pueden tener un papel especial de seguro o verificación dentro o fuera del equipo de trabajo y también por parte del cliente (usuarios, personal técnico, etc.).

  • Los procesos de seguro, seguimiento y control de la calidad, en especial los mecanismos de pruebas (testing) de los que hablaremos a continuación, y los mecanismos de no conformidad y corrección.

  • Las métricas o unidades de medición que hay que utilizar en cada caso.

El PMBOK, los estándares industriales (ISO y otros) y sobre todo los libros de gestión de la calidad, ofrecen todo un abanico de herramientas que se pueden usar para la preparación del plan de calidad y para su gestión posterior.
En los proyectos TIC, en particular en los de desarrollo de software a medida y los de instalación de productos existentes en el mercado (sean de hardware, software o comunicaciones), el plan y la gestión de las pruebas es la parte más importante del plan de calidad. Una explicación detallada de los contenidos y procesos de calidad de los productos y de los planes de pruebas excede el alcance de este material, pero vale la pena recordar algunas lecciones aprendidas con la práctica que presentamos en la tabla siguiente.
Fuente: adaptado de Snyder y Parth (2007)
Tabla 9. Lecciones aprendidas del testing

  • Cuando prepares el plan de proyecto (tiempo y costes), nunca subestimes el plan de pruebas, y si las cosas van mal, nunca recortes tiempo y costes de pruebas.

  • De todo lo que tienes que probar, lo más importante son los requisitos funcionales, en especial, aquellos considerados críticos en la definición del alcance, los que resuelven los problemas de negocio del cliente y de los usuarios.

  • La única manera de hacer las pruebas técnicas es hacer pruebas de carga.

  • La gestión de configuraciones y versiones es un apartado fundamental de la gestión del alcance y de la gestión de cambios. No es un tema técnico menor.

  • Cuando se corrigen los errores, se tienen que volver a testear y así sucesivamente.

  • Nunca hagas pruebas en el entorno de producción. Invierte lo que haga falta en un entorno de pre-producción sólido y suficiente. Es una inversión bien utilizada.

  • Se tiene que testar todo, empezando por lo pequeño y siguiendo hacia arriba: cada funcionalidad, cada programa, las interfaces, los programas de migración y conversión, la integración completa, los planes de continuidad, seguridad y recuperación, los planes de seguridad y protección de datos, etc., y se tienen que testar los datos.

  • El test es un trabajo técnico y especializado: es bueno tener especialistas propios, contratar especialistas externos y utilizar herramientas automáticas o semi-automáticas. Organiza el trabajo de testing: pon a su cargo a un administrador o supervisor que esté disponible 24 horas.

  • Es vital involucrar a los usuarios clave (y eventualmente a los usuarios finales) que han participado en la definición de requisitos en las pruebas de usuario y aprovechar las pruebas para ganar aceptación, consenso y transferir el conocimiento. Incluir pruebas de disponibilidad para operar (operational readiness) en situaciones de normalidad. Haz pruebas también con usuarios normales.

  • Haz un plan separado de migración y conversión de datos (o interfaz con los sistemas legacy si fuera el caso) y empieza cuanto antes mejor. No lo dejes para el final. No lo subestimes. No lo escondas al cliente. No recortes dinero de aquí.

  • Antes de comprar y pagar un producto comercial, también lo tienes que testar.
Las normas ISO

  • Norma ISO 9126 (1991). Software Engineering Product Quality

  • Norma ISO 12207 (1996). Software Life Cycle Processes

  • Norma ISO 9001 (2000). Quality Management System

Fuente: www.iso.org

7.Planificar los riesgos

En todo proyecto hay riesgos y éstos podrán conducir a una crisis en el proyecto. Esta frase puede parecer excesivamente dramática, pero es la realidad de la dirección de proyectos. Presuponer que, porque un proyecto es pequeño, sencillo o que ya hemos hecho otros parecidos otras veces, no hay que preocuparse de los riesgos, es una mala idea y trabajar de esta manera, una mala práctica. Como en otras áreas de conocimiento que ya hemos comentado, el director del proyecto debe analizar los riesgos; después del análisis, puede decidir no gestionar ninguno, dado que no está bastante justificado dedicarle tiempo y dinero, pero esta decisión tiene que venir de un estudio suficientemente objetivo de la realidad del proyecto y de su contexto.
El problema fundamental de la gestión de riesgos está en la incertidumbre asociada a los propios riesgos; en general, es difícil disponer de información suficiente y válida como para eliminar esta incertidumbre.
De hecho, la cuarta edición del PMBOK (2008), ha desarrollado aún más el área de conocimiento de gestión de los riesgos.
Aquí propondremos una visión más práctica y simplificada, dentro de la cual hemos separado la planificación de riesgos en cuatro pasos o procesos diferentes y consecutivos.
Figura 13
El objetivo final de la planificación es formalmente sencillo pero complejo de alcanzarlo realmente: identificar los riesgos relevantes del proyecto e incorporar las acciones necesarias para afrontarlos con éxito.

7.1.Planificar la gestión de los riesgos

Planificar es el proceso que permitirá obtener el plan para la gestión de los riesgos, o dicho de otro modo, de qué manera se gestionarán los riesgos del proyecto.
La planificación de la gestión de los riesgos asegura que el nivel, el tipo y la visibilidad de los riesgos son adecuados a la importancia del proyecto, a la vez que una planificación cuidadosa ayudará a realizar un proceso de gestión más exitoso, cabe recordar el alto grado de subjetividad asociado a los riesgos.
Los planes de gestión de riesgos se materializan a menudo como sistemas estandarizados en muchas organizaciones y empresas de servicios TIC, pero esta práctica no tiene que hacernos perder de vista que cada proyecto es diferente y se debe reflexionar sobre la idoneidad de los sistemas estandarizados por el proyecto en curso. En general en un plan de gestión de riesgos encontraremos:

  • Metodología a utilizar.

  • Roles y responsabilidades de los miembros del equipo hacia los riesgos.

  • Presupuesto, recursos destinados a la gestión.

  • Calendario, cada cuándo se revisarán los riesgos a lo largo de la vida del proyecto.

  • Categorías o grupos de riesgos, que servirán para realizar una sistemática identificación de éstos.

  • Normas sobre cómo calcular la probabilidad e impacto, que servirán para objetivizar en alguna medida la forma en que el director de proyecto evaluará los riesgos.

  • Normas sobre la matriz de probabilidad e impacto, cómo ubicar cada riesgo, cuáles considerar, etc.

  • Tipo de tolerancias permitidas.

  • Plantillas para los informes de riesgos.

  • Métodos de seguimiento y control.

7.2.Identificar los riesgos

El siguiente paso en el proceso consiste en identificar los riesgos que pueden afectar al proyecto y documentar sus características, generando el "Registro de riesgos", que se irá complementando y revisando en procesos posteriores.
Para efectuar esta identificación, es bueno que, en la medida de lo posible, participen todos los interesados, fundamentalmente el director y su equipo de trabajo, pero también el sponsor, el cliente y otros interesados pueden aportar información relevante sobre riesgos. La identificación de riesgos es un proceso que se tendrá que ir repitiendo periódicamente dado que los riesgos, dependiendo de un conjunto de factores internos y externos al proyecto, con el tiempo van cambiando; por eso, el proceso de control de riesgos incorporará también como objetivos la identificación de nuevos riesgos.
¿Cuáles son los factores que amenazan la capacidad de entrega de los objetivos que se han prometido? El punto inicial es la incertidumbre de no saber qué puede pasar. Es otra manera de decir que muchos aspectos de los proyectos no se pueden predecir, aunque hacemos todos los esfuerzos por controlarlos.
Desde el punto de vista de los procesos de gestión del proyecto, las áreas más comunes de incertidumbre son:

  • Estimaciones de coste: con respecto a las probabilidades de cumplimiento y las limitaciones de presupuesto.

  • Estimaciones de tiempo: con respecto a las probabilidades de cumplimiento o no de fechas.

  • Ámbito: Empezando por las hipótesis del proyecto, que son una fuente importante de riesgo, también los entregables y los paquetes de trabajo (EDT) pueden ser fuente de riesgos en función de la capacidad para definir claramente el trabajo, y las probabilidad de que aparezcan cambios en el alcance del proyecto.

  • Interesados, especialmente claves para la definición del alcance.

  • Planes de gestión de costes, cronograma, calidad, con respecto a determinadas exigencias o márgenes que los planes pueden aportar.

  • Recursos: cantidad, calidad, disponibilidad, responsabilidad, etc. de los recursos asignados al proyecto.

  • Documentación del proyecto.

La tabla 10 resume algunos de los factores más comunes de riesgo en proyectos TIC, desde el punto de vista del contenido del proyecto.
Fuente: Rodríguez, García, Lamarca (2007), modificado
Tabla 10. Riesgos de proyecto más frecuentes

  • Falta de entendimiento con los usuarios.

  • Escasez de interlocutores y personal del cliente.

  • Requisitos excesivos o muy poco detallados.

  • Continuos cambios de requisitos.

  • Errores de los productos.

  • Personal del equipo de trabajo no formado en las metodologías o en el producto.

  • Errores de rendimiento técnico.

  • No se cumplen los calendarios.

  • No se corrigen o no se toman las acciones presentadas por el equipo.

  • Elevada rotación del equipo propio o del cliente.
Esta identificación se puede ayudar con plantillas, listas, estudios, entrevistas, otros proyectos, tormentas de ideas, DAFO, lecciones aprendidas, juicio de expertos y otros, en definitiva, estructura y conocimiento de la organización (factores ambientales y activos).

7.3.Realizar el análisis cualitativo de riesgos

El siguiente paso es cualificar la magnitud de los riesgos identificados. Este es un proceso costoso, que ayuda a limitar adecuadamente la lista de problemas potenciales.
Con la cualificación conseguiremos priorizar los riesgos identificados, en general sobre la base de combinar la probabilidad y el impacto de estos riesgos, de modo que nos centraremos en los riesgos más prioritarios, dejando el resto como riesgos desconocidos.
En esta priorización interviene la probabilidad de ocurrencia del riesgo y el impacto del mismo sobre los objetivos del proyecto (costes, cronograma, alcance, calidad, etc.), pero también pueden utilizarse otros factores, como el plazo para resolver el riesgo, las tolerancias de la organización ejecutante, las repeticiones posibles del riesgo y otros. Volvemos a reiterar que a menudo estas evaluaciones tienen un carácter subjetivo y en este sentido es cuando cobran un gran valor las normas y criterios que la organización haya definido para la gestión de riesgos de cara a suavizar esta subjetividad.
Es bastante habitual que la concreción de este análisis se plasme en una matriz de P/I (probabilidad vs impacto), con colores diferentes para cada una de las zonas que quedarían definidas como más prioritarias (alta probabilidad e impacto) o menos prioritarias (baja probabilidad e impacto), la priorización, así como los criterios, alimentarán y actualizarán el registro de riesgos que será una entrada a los procesos posteriores.
Un modelo de matriz se presenta en la figura 14.
Figura 14. Matriz de valoración cualitativa de riesgos
Rodríguez, García, Lamarca (2007).

7.4.Realizar el análisis cuantitativo de riesgos

Este proceso consiste en analizar numéricamente el efecto de los riesgos identificados respecto de los objetivos del proyecto.
Éste es un proceso que se da muy raramente en nuestro entorno TIC por falta de cultura en la gestión de riesgos, pero también de disciplina, o de la disposición de datos válidos para poder hacerlo, lo que le hace perder cualquier sentido al análisis.
En el mundo del desarrollo del software se acostumbran a utilizar medidas y estándares de fiablidad, disponibilidad y seguridad, que se pueden aplicar para el análisis cuantitativo de los riesgos.

7.5.Planificar la respuesta a riesgos

Una vez identificados, evaluados y priorizados los riesgos, por aquellos que son más importantes, habrá que desarrollar opciones y acciones para mejorar las oportunidades y minimizar las amenazas a los objetivos del proyecto. Estas acciones pueden requerir la asignación de recursos económicos y humanos, modificar el cronograma, o el propio plan de gestión del proyecto, para lo que es habitual asignar una persona responsable, que gestionará las respuestas al riesgo y la propia evolución del mismo.
Ya se ha comentado, pero es muy importante, que las respuestas tienen que ser acordes a la importancia del riesgo, y al mismo tiempo, ser realistas, negociadas con todo el equipo y estar disponibles en el momento necesario. A menudo se pueden aplicar varios tipos de respuestas, y hará falta que el director de proyecto seleccione las más adecuadas para cada proyecto. Igualmente, las organizaciones pueden disponer de información suficiente sobre las respuestas posibles y su aplicabilidad, sea de forma sistematizada o como información histórica de otros proyectos.
Las respuestas a riesgos se suelen clasificar según el enfoque que toman.
a) Para el caso de riesgos negativos se habla de cuatro tipos de respuestas:

  • Evitar, cambiando el plan del proyecto de manera que se elimine la amenaza.

  • Transferir, en este caso no se elimina el riesgo, se encarga a una tercera persona o a una organización el hacerle frente.

  • Mitigar, sean acciones preventivas para mitigar la probabilidad de que pase, o de contingencia para mitigar el impacto.

  • Aceptar, cuando no es posible diseñar respuestas efectivas o éstas no son rentables.

b) Para riesgos positivos o de oportunidad serían:

  • Explotar, para asegurarse de que la oportunidad se hará efectiva, modificando el plan del proyecto.

  • Compartir, de forma que a un tercero, más preparado para hacerlo, se le asigna todo o una parte de la oportunidad.

  • Mejorar, de modo que se actúa sobre la probabilidad o el impacto, para incrementar lo que efectivamente ocurra, o el beneficio cuando pase.

  • Aceptar, cuando no se hacen acciones concretas pero se tienen en cuenta por si finalmente sucede.

Además, se pueden planificar determinadas respuestas, que se llaman de contingencia, y que se harán efectivas únicamente en caso de que determinadas señales o indicadores apunten a que se pueda producir el problema. En estos casos se tiene que definir detalladamente cómo se hará el seguimiento y control de los disparadores.
Dentro de la planificación de costes, tal como hemos visto, se habrán establecido las reservas para hacer frente a estas contingencias, que se utilizarán, se mantendrán o se reducirán, según el avance del proyecto. La contingencia debe ser considerada parte del proyecto hasta que el tiempo y los avances del mismo no demuestren que el riesgo y la incertidumbre se han reducido o han desaparecido. En este momento, las partidas reservadas para contingencias tienen que volver al presupuesto general del proyecto. Por esto, el plan de contingencia debe ser revisado a lo largo de todos los procesos.
Algunos consejos prácticos
1) Normalmente, a partir del análisis de riesgos en el que se identifican las áreas de riesgo, el nivel de riesgo en cada caso y la probabilidad de ocurrencia, el plan de contingencia incluirá acciones de varios tipos:

  • Posibles reasignaciones de recursos a las áreas de mayor riesgo.

  • Variaciones en el plan de actividades, en particular desvincular actividades del camino crítico.

  • Variaciones en el plan de hitos.

  • Incremento de los recursos.

  • Posibles variaciones en el alcance.

  • Variaciones en la fecha de entrega del producto final.

2) Como puede verse, en teoría el plan de contingencias se elabora siempre de abajo arriba (bottom-up) y comienza por las acciones de menor impacto en el proyecto. Es decir, va desde las reasignaciones de recursos hasta las variaciones en el alcance o las fechas de entrega. El último recurso consiste siempre en variar el contenido (alcance) del trabajo, el presupuesto o la fecha de entrega, según cuáles sean las restricciones en las condiciones acordadas.
3) Normalmente, en la práctica, deben elaborarse planes de contingencias en el momento de la planificación de hitos, y planes más precisos en el momento de la preparación del plan de actividades para cada hito. Una desviación en una actividad requiere alguna acción de contingencia normalmente menor. Una desviación en un hito requiere siempre disponer y activar el plan de contingencias.
4) Un plan de contingencias muy detallado consume mucho tiempo y probablemente no es muy efectivo. Lo mejor es, teniendo en cuenta el análisis de riesgos realizado con anterioridad, concentrarse en los hitos y actividades de cierto tamaño y de mayor riesgo. También es útil hacer el plan de contingencias de detalle en el momento en que es necesario, es decir, cuando tenemos una información más precisa y un riesgo más probable y cercano.
5) La contingencia es una disciplina bastante artística y basada en el criterio y experiencia del jefe de proyecto. Si tenemos información suficiente y sabemos lo que hay que hacer y lo que normalmente pasará, no necesitamos mucha contingencia. Si no, necesitamos contingencia, pero el ejercicio de obtener información y detalle sobre la contingencia probablemente eliminará el riesgo a un coste exagerado y enervará a todo el mundo. Normalmente, un proyecto o un hito pequeño y conocido necesitará una contingencia del 10 por 100 del tiempo y el presupuesto. Un proyecto o un hito grande y de gran incertidumbre deberá cargar con una contingencia de entre el 30 y el 50 por 100. Eso es lo realista y sensato, de momento.
6) Como el resto de las acciones de planificación en esta fase, el plan de contingencias es un instrumento de diálogo honesto y constructivo con el cliente, que debe reconocer el nivel y alcance de los riesgos, acordar las acciones contenidas en el plan y tomar las decisiones para su activación. Asimismo, el diálogo sobre riesgos y contingencias debe incluir las consecuencias económicas y contractuales para las dos partes.
En nuestra experiencia, como compradores o como proveedores de servicios informáticos, de entre todos los componentes de la planificación y gestión de proyectos, uno de los que presentan en la práctica peor calidad o simplemente no se hacen son los planes de contingencias. Incluso cuando existe una planificación y control de riesgos del proyecto, cuando se produce un fallo o una desviación, la tendencia natural es pensar que se recuperará en una actividad o una etapa siguiente, con un mayor esfuerzo del equipo y con la experiencia aprendida. Si el problema se repite o el retraso se mantiene en las fases siguientes, se suele insistir en el mismo tipo de solución o, como mal menor, se supone que existe un "colchón" en las estimaciones que soportará el retraso incurrido. Nada de esto suele ser cierto y no disponer de planes de contingencias y activarlos en su momento conduce a situaciones embarazosas, reparto de culpas, dolorosas renegociaciones, clientes insatisfechos, equipos frustrados y, en el límite, proyectos fallidos o abandonados. ¡Siempre hay que tener un plan B y una previsión para contingencias! Eso es ser realista y responsable. Otra cosa es irresponsable y suicida.
Fuente: Rodríguez, García, Lamarca (2007)

8.Otros componentes de la planificación

La planificación puede incluir también los planes de:

  • recursos humanos,

  • comunicación y gestión de interesados,

  • administración de compras y contratos.

Profundizaremos en el estudio de los dos primeros en el módulo, "El lado humano de la gestión de proyectos".
Con respecto al de Administración de compras y contratas, está muy ligado en la práctica a aspectos de contexto legal, administrativo y financiero, que pensamos que supera el contenido de un material como éste.

9.Resumen

Una vez iniciado (aprobado) el proyecto, la planificación es el mapa de ruta que debe guiar la ejecución. La planificación es un trabajo permanente e iterativo: a lo largo de la ejecución, controlamos el progreso y rendimiento del trabajo comparándolo con la planificación inicial y refinimos la planificación.
Si en la etapa de iniciación conocíamos el 'porqué' del proyecto (mediante su aprobación, que figura en el acta de constitución), conocíamos las partes interesadas (registro de interesados) y sabíamos 'qué' había que hacer (la definición o definición inicial del alcance), el plan define el 'cómo' lo haremos: cuáles serán los procesos, técnicas, herramientas y documentos que utilizaremos para ejecutar y llevar a buen puerto el encargo.
No todos los proyectos requieren la misma cantidad y tipología de herramientas de planificación, control y documentación. Depende de su tamaño y complejidad. Corresponde a la dirección del proyecto, de acuerdo con su experiencia, la base de conocimientos de la empresa y las exigencias del cliente, determinar en cada caso el instrumental que se utilizará. El plan de gestión de proyecto resume el enfoque e instrumental que se adoptará en el proyecto y la integración entre los diferentes planes parciales.
Los elementos más críticos de la planificación son la planificación del alcance (qué se hará y qué no se hará), el tiempo de duración y el presupuesto. Estos tres elementos representan la línea base del plan y se representan en un documento base de alcance, un calendario o cronograma base y un presupuesto base de proyecto. Estos tres elementos son imprescindibles en cualquier plan de proyecto y son imprescindibles para la ejecución y su seguimiento posterior.
Otros procesos o planes complementarios son el plan de calidad, el plan de recursos humanos, el plan de comunicación, el plan de gestión de riesgos y el plan de administración y compras.

9.1.Planificar el alcance, tiempo y coste

Para completar la definición del alcance, debemos entender primero los objetivos de negocio y de cliente, tal como se recogieron en el acta de constitución, y los objetivos y entregables de proyecto a alto nivel tal como se recogieron en la definición inicial de alcance. Seguidamente, debemos recoger de los interesados cuáles son sus requisitos, discutirlos con el cliente para asegurar que encajan dentro del mandato de proyecto y de la definición inicial y establecer, si procede, las prioridades, para seguidamente realizar la definición detallada del alcance. La mayor parte de los fracasos de proyecto se producen por una deficiente planificación y gestión del alcance y, dentro de esto, una deficiente toma de requisitos funcionales.
A partir de estos objetivos, se deben identificar los estados intermedios, o hitos, que deben ser alcanzados para avanzar en el logro de los objetivos finales del proyecto, y el nivel de dependencia o relación que hay entre estos hitos. Los hitos normalmente se corresponden con productos, líneas de trabajo intermedias o paquetes de trabajo que son más fáciles de manejar. A este proceso le llamamos estructura de distribución del trabajo (EDT). En este nivel, debemos establecer ya qué personas son responsables de la consecución de cada hito y de su aprobación, dentro del cliente y del equipo o, dicho de otra manera, la estructura de responsabilidades por la consecución de los hitos y los paquetes de trabajo (EDT). Lo más práctico es que a cada paquete de trabajo le corresponda un entregable y a cada entregable, un hito, y que del entregable y del hito sea responsable una sola persona.
Los hitos y EDT pueden descomponerse entonces en actividades y tareas que son necesarias para alcanzar el hito y, de nuevo, las relaciones y dependencias que hay en lo que se refiere a las actividades. PMBOK y otras metodologías llaman a esta fase definir las actividades. Seguidamente, se ordenan las actividades en su secuencia de realización, en qué orden deben realizarse y cuáles pueden hacerse en paralelo. Esto nos permite establecer el calendario o línea de base de tiempo. Es importante analizar las dependencias, separar las que son externas al proyecto, y establecer en todo caso las que están en el camino crítico para completar un entregable y las que no.
En este momento, se estima el tiempo (esfuerzo) requerido para la realización de cada actividad. Puede valorarse entonces el tipo de recurso necesario para realizar una tarea determinada y la carga de trabajo que requiere. De esta manera podemos hacer una estimación de recursos y perfiles, y su dedicación. En la mayoría de los proyectos TIC, salvo en los que son puramente de adquisición e instalación de infraestructura, los recursos humanos constituyen la mayor parte del esfuerzo y del coste. Con la estimación de coste de recursos humanos, materiales y otros, podremos preparar el presupuesto de ejecución. El presupuesto constituye la línea de base de coste del proyecto.
También en este momento, establecemos las responsabilidades por cada actividad dentro del equipo de trabajo, nuestro y del cliente.
En la práctica, los procesos de planificación de alcance, tiempo y coste están interrelacionados, unos afectan a los otros y deben irse haciendo y revisando de forma conjunta.
En los proyectos TIC es habitual trabajar con presupuestos y calendarios cerrados y por tanto, habrá que establecer aproximaciones de esfuerzo, duración y coste sin disponer de toda la información. Es importante la experiencia del director de proyecto, la experiencia y documentación de la empresa en proyectos análogos y el uso de métodos cuantitativos de estimación. Así como para la planificación del alcance es aconsejable una aproximación de arriba abajo (top-down), para la estimación de esfuerzo y coste es aconsejable la planificación de abajo arriba (bottom-up), a partir de las tareas y actividades a desarrollar. Asimismo, es conveniente añadir al coste una magnitud de reservas, mayor cuanto menos conozcamos el alcance detallado de los productos a obtener o más lejos estemos del producto final.
El plan de proyecto, calendario y presupuesto deben discutirse en profundidad con el cliente (y eventualmente, también dentro del departamento o empresa proveedora) para asegurar su comprensión, compromiso y asunción por parte de todos. O revisarse, en cuanto a los hitos, las actividades, los recursos o los planes complementarios, si fuera necesario. También en esta fase, y muy especialmente, debe confrontarse el plan definitivo con los objetivos y necesidades contenidas en la definición de proyecto, es decir, con el mandato de proyecto y la definición inicial de alcance.

9.2.Calidad y riesgos

Alcance, tiempo y coste son los aspectos troncales de la etapa o grupo de procesos de planificación. Sin embargo, dependiendo del tipo de proyectos, y con un nivel de formalización menor o mayor, los planes de calidad, recursos humanos, comunicación, riesgos y administración y compras son cada vez más importantes. En este módulo hemos presentado algunas nociones generales de los planes de calidad y riesgos.
En los proyectos TIC, calidad del proyecto y del producto que el cliente obtendrá se mezclan y se interrelacionan, y por lo tanto, es inevitable remitirse a las normas y estándares de la industria sobre cada tipo de producto y a las que establece el propio cliente o la empresa para la que trabajamos. En todo caso, la calidad tiene siempre varias dimensiones: el cumplimiento de los objetivos y requisitos acordados, la conformidad con unas normas o estándares y, finalmente, pero no en último lugar (!), la satisfacción o calidad percibida por el cliente. El plan de calidad tiene que manejar las tres. La última, la calidad percibida o subjetiva, tiene que ver con la comunicación y gestión de expectativas y de situaciones del propio cliente.
La calidad tiene un coste que debe confrontarse con los costes de la no calidad, para encontrar un punto de equilibrio. En todo caso, en proyectos que involucran el desarrollo o parametrización de productos de software, los costes de no conformidad por reparación de errores, repetición del trabajo y frustración de los equipos y del cliente son razón suficiente para realizar una inversión proactiva en calidad. Hemos llamado la atención especialmente sobre la inversión necesaria y las cualidades de las pruebas (testing) y la necesidad de involucrar a los usuarios.
Algo parecido o aún más contundente puede decirse de la planificación y gestión de los riesgos. Un riesgo es un acontecimiento incierto que puede tener un impacto sobre el proyecto. Se trata por tanto de identificar las posibles fuentes de riesgo, estimar la probabilidad de que el riesgo ocurra, estimar su impacto sobre el proyecto y preparar planes de acción y planes de contingencia (y las reservas económicas asociadas) ante esa eventualidad. Cualquier cosa menos ignorarlos.