Gestión de proyectos

  • Ramon G. Sedó

  • Laura Benítez García

  • Eugènia de Vilar Font

  • Jordi Folch Mola

PID_00214569
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.

Índice

Introducción

La gestión de un proyecto es uno de los principales factores que determinarán su éxito o fracaso. Por ello definiremos qué es un proyecto y de qué elementos se compone.
Describiremos una metodología genérica para la dirección de proyectos y veremos cómo aplicarla a proyectos multimedia.

1.El proyecto y la gestión de proyectos

Dos buenas definiciones de proyecto son las aportadas por J. P. Lewis, y Gido y Clements:

"Un proyecto es un trabajo singular con unas fechas definidas de inicio y finalización, una especificación clara del objetivo o alcance de la tarea, un presupuesto preestablecido y, habitualmente, una organización temporal que se desmantela cuando termina el proyecto."

J. P. Lewis (1995). Planificación, programación y control de proyectos. Barcelona: Ediciones S.

"Un proyecto es un intento por lograr un objetivo específico mediante un juego único de tareas interrelacionadas y el uso efectivo de los recursos."

J. Gido; J. P. Clements (1999). Administración exitosa de proyectos. International Thomson Editores.

Con estas dos definiciones y otras aportadas por otros teóricos, como J. Pereña, podemos extraer las principales características de un proyecto:
  • Es singular: no se repite, es único.

  • Tiene un inicio y un fin.

  • Presenta unos objetivos claros.

  • Tiene un juego (único) de tareas interrelacionadas.

  • Requiere un uso efectivo de los recursos.

  • Cuenta con un presupuesto preestablecido.

  • Tiene una organización temporal que termina al finalizar el proyecto.

  • Es dinámico, está en continua evolución.

  • Es irreversible, ya que la toma de decisiones va marcando la evolución del proyecto y, la mayoría de las veces, estas decisiones son irreversibles (una vez tomadas, ya no se puede volver atrás).

  • Cuenta con un componente de riesgo, dadas las planificaciones estimadas con las que se mueve.

  • Tiene un cliente, que puede ser interno (de la misma empresa) o externo, pero siempre hay un cliente que encarga el proyecto.

Los factores esenciales que componen un proyecto son los siguientes:
1) La duración (timing) del proyecto
Los proyectos tienen una fecha de inicio y una fecha de terminación o final. Los proyectos interactivos no suelen tener una duración excesiva (entre dos y nueve meses). Los proyectos se inician cuando el cliente autoriza y acepta la propuesta de proyecto, en la que presentamos el presupuesto y los recursos que van a ser necesarios. Un proyecto finaliza cuando hemos alcanzado los hitos u objetivos de la propuesta. El factor tiempo es uno de los puntos críticos en el desarrollo de productos interactivos; hay que cumplir con los plazos (parciales o totales) de finalización de las tareas o subtareas previstas.
Antes de alcanzar el objetivo y/o fecha final, el proyecto puede tener fechas intermedias importantes (llamadas hitos o fechas clave) en las que deben concretarse partes o características del producto, que se denominan entregables. Cada entregable o fecha clave alcanzada con éxito y a tiempo ayuda a cumplir con la temporalización establecida para el proyecto global y dentro del presupuesto asignado.
2) El esfuerzo o los recursos personales y materiales necesarios para la realización del proyecto
Los proyectos desarrollan o implican una serie de tareas relacionadas entre sí. Para llevar a cabo estas tareas son necesarios recursos personales o humanos (la gente que va a participar en la realización del proyecto) y recursos materiales (aquellas herramientas de hardware, software u otros elementos físicos, como puestos de trabajo, material de oficina, etc.).
3) Los objetivos para conseguir un producto único (singular)
Un proyecto se realiza para alcanzar unos objetivos y/o obtener unos resultados, pero también son importantes los objetivos parciales o intermedios. El público al que va destinado el producto o servicio y los objetivos que se pretende conseguir con su materialización deben guiar a todo el equipo durante el proceso de creación de un producto interactivo. En un proyecto queremos alcanzar un objetivo en un plazo de tiempo y dentro de un presupuesto previsto y, por supuesto, limitado.
Los proyectos que abordaremos siempre serán únicos (en cuanto al equipo, el cliente, el producto resultante, el tiempo...), independientemente de nuestras experiencias profesionales y laborales. Por ello el producto fruto de ese proyecto será un producto singular, y su singularidad marcará significativamente el proyecto.

1.1.Ejemplos de proyectos

Para entender mejor todo esto, vamos a ver unos cuantos ejemplos de lo que sí que es un proyecto y de lo que no lo es.
Sí que es un proyecto
  • La construcción de un edificio.

  • La elaboración de una campaña de marketing y promoción.

  • El diseño y la elaboración de la colección "Otoño" de una marca de ropa.

  • La construcción de un campus virtual.

  • La producción de un largometraje.

Incluso dentro de un mismo proyecto puede haber subproyectos. En el caso de la construcción de un edificio, por ejemplo, puede haber los subproyectos siguientes, realizados por empresas y equipos de proyecto diferentes:
  • Subproyecto de cimentación (hacer los cimientos del edificio; tiene su propio inicio y su propio fin, sus objetivos y su equipo de trabajo y tareas propias).

  • Subproyecto de construcción de la vivienda (una vez hechos los cimientos, otro equipo de trabajo, con su calendario, sus tareas y sus objetivos, construye la vivienda).

  • Subproyecto de ajardinamiento (otra empresa puede desarrollar este proyecto, que también tiene sus propias fechas de inicio y fin, y un equipo y una planificación totalmente propios).

  • Subproyecto de decoración (un equipo puede dedicarse a diseñar la decoración del interior del edificio).

Estos subproyectos pueden entenderse como grupos de tareas dentro de una planificación global del proyecto "Construcción de un edificio".
Vistos estos ejemplos de lo que sí que es un proyecto, vamos a ver otros de actividades que no son proyectos y que, por lo tanto, no se pueden gestionar con las mismas pautas de gestión que un proyecto.
No es un proyecto
  • El mantenimiento de un portal de Internet (no tiene fecha de finalización; no tiene unos objetivos finales que culminarán en un producto o servicio concreto; tiene unas tareas cíclicas, no cambiantes...). Dentro del mantenimiento a veces pueden surgir proyectos, como la incorporación de un nuevo servicio en el portal, por ejemplo, de compra electrónica, que sí que se puede tratar como un proyecto.

  • La actividad comercial de una tienda (también incorpora diversas personas y tiene objetivos, pero no tiene fecha de finalización ni debe terminar con un producto concreto, por lo que no se debe gestionar como un proyecto).

  • El día a día de un programa de televisión (en este caso sería proyecto toda la fase de diseño del programa, en la que sí que habría fechas de inicio y fin, y unos objetivos muy concretos que culminarían con el diseño de un producto, el programa; una vez que este proyecto de creación del programa hubiera finalizado, la gestión debería cambiar, porque ya no nos hallaríamos ante un proyecto).

1.2.Proyectos multimedia

Vistas las características principales de los proyectos en general, vamos a analizar qué es exactamente un proyecto multimedia y qué características especiales tiene respecto a otros tipos de proyectos.
Como veremos, hay muchísimos tipos de proyectos multimedia y, por este motivo, las pautas de gestión no son siempre las mismas, como tampoco es el mismo el perfil profesional del equipo o del jefe de proyecto. A pesar de esto, existen unas características específicas de los proyectos multimedia que es importante analizar.
Si nos basamos en las definiciones anteriormente aportadas, podemos decir que un proyecto multimedia es un trabajo singular realizado dentro del sector de la industria multimedia que, como todo proyecto, tiene un carácter único, un inicio y un fin, unos objetivos claros y un juego de tareas interrelacionadas para llevarlo a cabo.
El resultado final de un proyecto multimedia es un producto (llamémosle aplicación, sistema o título) cuyas características básicas son la multimedialidad y la interactividad. Normalmente, el objetivo básico de estos proyectos multimedia es ofrecer contenidos y servicios a usuarios concretos. Así, por multimedialidad entendemos que el producto resultante del proyecto maneja diversos media de distinto carácter (texto, fotografía, ilustración, grafismo, audio, vídeo o animación) y que la aportación de contenidos y servicios se hace a partir de la combinación de todos estos media. Por interactividad entendemos la capacidad que tiene el sistema que estamos generando de interactuar con la persona que lo usará, con el usuario. El usuario da "órdenes" o "requerimientos" al sistema y éste le responde (y al revés). De hecho, por esto hablamos de usuarios cuando nos referimos a proyectos multimedia, y no de "espectadores", porque usan el sistema, no sólo lo miran.
Otra de las características de un proyecto multimedia es que toda la "materia prima" que maneja acaba transformándose, en última instancia, en información digital. Esto implica que, obviamente, para el manejo de toda esta información se necesitará una infraestructura de hardware y software que nos posibilite transformar y manejar según nuestras necesidades específicas toda la información digital. Por este motivo, la mayoría de los miembros del equipo de un proyecto multimedia necesitan conocer y hacer un buen uso de las nuevas tecnologías (desde trabajar con ordenador hasta saber cómo afecta a la organización el hecho de trabajar en una red informática).
Por otra parte, el mercado multimedia es una industria multisectorial, en la que intervienen tipos de empresas muy diferentes, como editores, empresas de hardware y de software, empresas de redes, el sector del diseño gráfico, distribuidores, etc. Esto hace que el proyecto multimedia necesite profesionales de sectores muy distintos y que, a su vez, el jefe de proyectos deba tener una visión muy clara de las características y las tendencias de la industria en la que se mueve.
1.2.1.Tipología de los proyectos multimedia
Una posible tipología de los proyectos multimedia se puede realizar a partir del soporte que tendrá el sistema o la aplicación multimedia objeto de desarrollo en el proyecto. Internet, intranet, aplicaciones para dispositivos móviles, aplicaciones para Smart TV, productos multimedia disponibles para su consumo en varias plataformas en línea, accesibles desde diferentes dispositivos, entre otros.
El soporte del sistema multimedia que debemos desarrollar en un proyecto condiciona totalmente el tipo de proyecto que realizaremos. Las características de estos proyectos son tan diferentes que marcarán muchísimo el tipo de equipo humano y material que necesitaremos y, sobre todo, el resultado final del proyecto y su distribución.
Fijémonos en que, aunque son tipos de proyectos diferentes, todos tienen en común que manejan información multimedia digital y que son sistemas interactivos. Aparte, todos los ejemplos cumplen los requerimientos que permiten que los califiquemos como proyectos (tienen un inicio y un final y unos objetivos muy concretos; a la vez, todos son proyectos únicos, irrepetibles, que dan respuesta a una necesidad muy concreta de un cliente).

1.3.Tipología de proyectos

Una vez explicado lo que es un proyecto y, en concreto, qué es un proyecto multimedia, vamos a ver, de forma breve, los tipos de proyectos que hay. En función del tamaño de un proyecto o del tipo de cliente, las características de éste serán diferentes y, por lo tanto, la gestión que del mismo deberemos hacer también variará.
1.3.1.En función de su dimensión
Cuando hablamos de dimensión de un proyecto nos referimos a la cantidad de horas en total que se necesitan para llevarlo a cabo. No hemos de confundir dimensión de un proyecto con dimensión de una aplicación. Cuando nos referimos a la dimensión de una aplicación hablamos de la cantidad de información que hay en ésta, lo que se acostumbra a contabilizar en páginas o media.
A continuación, presentamos una posible clasificación de los proyectos en función de su dimensión. Esta clasificación, realizada por Tom Mochal en su Ten step project management process, está bastante estandarizada:
Tipos de proyectos en función de su dimensión

Dimensión

Horas de producción

Proyecto pequeño

1-250 horas

Proyecto medio

251-2.500 horas

Proyecto grande

Más de 2.500 horas

1.3.2.En función del cliente
Otra posible clasificación de los proyectos se puede hacer en función del cliente.
76529_m2_02.gif
Proyectos internos
Por cliente interno entendemos un departamento de nuestra propia empresa que nos encarga la realización de un proyecto.
Características de los proyectos internos

Mayor flexibilidad

Los proyectos internos tienen variaciones, especialmente en cuanto a su flexibilidad de planificación. Normalmente la fecha de entrega no es tan rígida, ya que si entran proyectos nuevos y urgentes, que a los directivos de la empresa les interese priorizar, dejaremos el proyecto interno en espera o stand by, para acometer el proyecto externo urgente. Una vez finalizado éste, podremos reemprender el proyecto interno.

Mayor proximidad con el cliente

Los proyectos internos también tienen la característica de proximidad con el cliente. Esto permite al jefe de proyecto poder contrastar la evolución del proyecto con mucha regularidad con el cliente y que éste vaya validando las distintas etapas. Aparte, al trabajar en la misma empresa que el cliente, el equipo de desarrollo del proyecto tiene más claro el marco de comunicación corporativa en el que se mueve y los objetivos del cliente.

Mayor flexibilidad con el presupuesto

Aunque en muchas grandes empresas los departamentos tienen sus propias partidas presupuestarias y actúan como micro-empresas dentro de la empresa madre, si durante el desarrollo del proyecto surgen imprevistos (un presupuesto mayor al esperado en una subcontratación, una necesidad imprevista de compra de un software concreto, etc.), hay más posibilidades de que se sea más flexible en el presupuesto si el proyecto es interno y, también, es menos probable que se apliquen sanciones de presupuesto por demora en la entrega.

Proyectos externos
En el sector multimedia, la mayoría de proyectos acostumbran a ser externos, a no ser que se trabaje en las condiciones descritas en los proyectos internos (en el Departamento Multimedia de una gran empresa). Cuando el cliente es una empresa o particular de fuera de nuestra empresa que tiene una necesidad específica y que nos encarga un proyecto para dar respuesta a su necesidad, nos hallamos ante un proyecto externo.
Los proyectos externos no tienen las facilidades descritas en los internos (flexibilidad en el calendario y en el presupuesto), pero, a cambio, el margen de ganancia que podemos aplicar en el presupuesto es mayor.

1.4.El triángulo de la gestión de proyectos

La gestión de proyectos comprende la planificación, la coordinación y el seguimiento de las tareas. La persona que realiza esta gestión es el administrador, director o jefe de proyecto.
La coordinación de las tareas en algunos proyectos es tan crucial, que si no se llevan a cabo dentro del calendario previsto, se puede poner en riesgo el proyecto completo. Los jefes de proyecto han de ser capaces de considerar los proyectos de manera global y planificarlos de forma coordinada. Una planificación correcta permitirá reconocer los puntos críticos, los cuellos de botella y los espacios de inactividad, de tal modo que el jefe de proyecto pueda dirigir al equipo hacia la consecución eficaz de los objetivos.
El concepto básico que todo jefe de proyecto debe manejar es el referente al triángulo de la gestión de proyectos. Se trata de tener muy claro desde un principio cuál es el alcance del proyecto, el tiempo requerido y los recursos/presupuesto necesarios para completarlo.
Triángulo de la gestión de proyectos
Triángulo de la gestión de proyectos
Estos son los tres parámetros básicos con los que tendrá que lidiar el administrador de proyectos y que, al final, determinarán en gran medida el grado de éxito o fracaso del proyecto.
En todo proyecto, grande o pequeño, hay que identificar claramente cuál es su alcance, es decir, cuáles son los requerimientos que se han de satisfacer para conseguir los objetivos. Sobre la base de esta información, podemos determinar cuántos recursos (gente, herramientas, presupuesto...) necesitamos para poder desarrollarlo. Pero esto dependerá del tiempo en el que se requiera completar el proyecto.
Habitualmente, uno de los vértices del triángulo es fijo y los otros dos tienen una influencia inversa entre ellos. Si tenemos disponibilidad de recursos, podremos reducir el tiempo. Si no hay presión de tiempo, podremos disponer de menos personal y recursos para completar el proyecto. Por último, si se nos da flexibilidad en cuanto al alcance que hay que cubrir, podremos reducir tiempos y/o recursos para el proyecto.
El éxito de un proyecto dependerá en gran medida de la flexibilidad que tengamos en la gestión de estos tres factores. El cliente del proyecto puede restringir dos de ellos, pero nunca los tres. Difícilmente sería viable un proyecto con fecha límite, con recursos limitados y con un objetivo o alcance no negociable, y en caso de que el proyecto se llevara a cabo, muy probablemente el nivel de calidad del producto terminado habrá quedado comprometido.
Para conseguir ejecutar correctamente el proyecto y, por lo tanto, para alcanzar los objetivos fijados en el tiempo fijado y con los recursos fijados, el jefe de proyecto debe saber combinar correctamente el alcance, el coste y el tiempo de los que dispone. Iniciar un proyecto con un plan de trabajo irreal es la mejor fórmula para fracasar en la gestión de un proyecto.

1.5.Factores de éxito de un proyecto

Los factores que hay que controlar en un proyecto y que, bien gestionados, pueden ser la clave de su éxito son los siguientes:
  • Alcanzar los objetivos fijados

    Debemos marcar objetivos para cada etapa del proyecto y controlar que estos objetivos se van alcanzando. Si cumplimos los objetivos de las diversas etapas, tendremos más posibilidades de que, una vez finalizado el proyecto, se hayan cumplido los objetivos generales.

  • No superar los costes

    Los costes son la cantidad que hay que pagar por el proyecto, cantidad que se ha convenido con el cliente. A menudo, si la entrega del proyecto se retrasa puede haber sanciones en el importe que le queda al cliente por pagar. Otro factor que puede hacer superar los costes pactados es pagar más a los miembros del equipo de lo que se ha estimado en el presupuesto o comprar hardware o software que no estaba previsto. Si el proyecto incluye una subcontratación, también es importante tener el presupuesto de las tareas subcontratadas cuando realizamos el presupuesto general.

  • Cumplir con el calendario programado

    Durante la realización de un proyecto es muy importante seguir el calendario planificado al inicio. Como veremos más adelante, en la parte dedicada a la planificación del proyecto, en según qué tareas es aún más importante no retrasarnos, porque ello significará un retraso en la entrega final del proyecto y, por lo tanto, un fracaso en la planificación. Hemos de tener en cuenta que el retraso en una tarea determinada (por ejemplo, en la elaboración de los gráficos) puede retrasar todas la tareas que van a continuación (no podemos integrar hasta que no tengamos terminados los gráficos; no podemos hacer pruebas hasta que no hayamos integrado, etc.). El jefe de proyecto, por lo tanto, debe llevar un riguroso seguimiento del calendario.

  • Mantener al cliente satisfecho

    Este objetivo es fundamental. Si el cliente no está contento, querrá decir que no hemos dado respuesta a sus necesidades y, por lo tanto, el proyecto habrá fracasado. Para evitar que el cliente muestre su insatisfacción ante el proyecto en una fase avanzada del mismo, es importante que vaya viendo muestras de cómo avanzan las distintas tareas, como veremos más adelante. Hemos de tener una comunicación proactiva con el cliente, "obligarlo" a que se comunique con nosotros y a que haga un seguimiento para validar los distintos avances del proyecto.

Ejemplo
Situándonos en un ejemplo de proyecto multimedia, imaginemos que uno de los objetivos que nos hemos marcado en la etapa de diseño de interfaz es que el aspecto visual de la aplicación se realice en función de la imagen corporativa de la empresa/cliente. Si no conseguimos este objetivo, por más que los objetivos de las etapas siguientes sí que los alcancemos (en la parte de programación o contenidos textuales, por ejemplo), no habremos alcanzado los objetivos generales, con lo que el cliente no estará contento. El proyecto habrá fracasado sólo porque en una de sus etapas no se cumplieron los objetivos.

2.Habilidades para la gestión de proyectos

A continuación, vamos a ver las doce habilidades básicas para que la gestión de un proyecto culmine en su realización exitosa. Existen otras habilidades necesarias en la gestión de un proyecto, como el liderazgo, la escucha y una buena retroalimentación.
Algunos de los aspectos de la administración de proyectos, como definir el proyecto y administrar situaciones, pueden aplicarse en todos los proyectos. Otros, como el manejo de la documentación y las métricas, cobran mayor importancia en proyectos de gran envergadura.

2.1.Definición del proyecto

Antes de iniciar el proyecto, es indispensable que se haya entendido el trabajo que se ha de realizar y que los responsables, tanto de la ejecución del proyecto como quienes recibirán los resultados del mismo, tengan una visión clara de los resultados esperados, en duración, costes, cargas de trabajo y beneficios.
Ya se trate de un proyecto grande o pequeño, la definición de su alcance es herramienta vital para que el jefe de proyecto o los comités respectivos, en caso de que existan, puedan tomar decisiones en las etapas administrativas que se mencionarán más adelante. Las decisiones tomadas en esta etapa del proyecto marcarán el éxito o el fracaso del mismo.
Cuanto más grande sea el proyecto, mayor será la importancia de dejar esta información explícitamente estipulada. El resultado de esta actividad debe ser un documento titulado "Definición del proyecto", que ha de incluir la información mencionada en el primer párrafo.
Al final de esta etapa, se debe tener un documento que refleje el alcance y la expectativa del proyecto, cómo se medirá, quién llevará a cabo esta medición y cuánto costará. Este documento habrá de estar aprobado por todos los miembros involucrados, ya que tratar de buscar consenso sobre estos temas en un proyecto que ya ha arrancado es extremadamente difícil.

2.2.Planificación del trabajo

En la etapa de planificación se determina cómo se va a realizar el trabajo. Esto implica elaborar un plan para el trabajo. Pueden usarse distintos medios para la planificación, desde una hoja de papel para un proyecto pequeño, hasta soluciones sistematizadas, como el Microsoft Project, u otras herramientas, muchas de ellas disponibles como servicio en línea multiplataforma.
Aquí os recomendamos unas cuantas:
1. Gantt Project
Es una aplicación fácil de utilizar para entornos Windows y MacOSX. Se puede definir la jerarquía de tareas y dependencias, diagramas de Gantt, informes en PDF y HTML, importación y exportación desde Microsoft Project y gráfico de carga de recursos.
2. Planner
Aplicación que trabaja sobre todas las fases del ciclo de vida de un proyecto, incluyendo la gestión del proyecto, requisitos, riesgos y pruebas. Gráficos dashboards y herramientas colaborativas, como por ejemplo compartición de documentos, foros de discusión y calendarios.
76529_m2_06.jpg
3. TaskJuggler
Programa potente diseñado para el sistema operativo Linux que permite controlar tareas, recursos y costes. Genera diagramas de Gantt estéticamente muy buenos. Tiene una interfaz sencilla e intuitiva. Incorpora alarmas de riesgos en tiempos. Además, cuenta con plantillas que permiten no empezar de cero. Con licencia GPL.
4. DotProject
http://www.dotproject.net/
Aplicación web basada en PHP que incluye módulos para compañías, proyectos, tareas (con diagramas de Gantt), foros, ficheros, calendario, contactos, ayuda de escritorio, soporte multilenguaje, módulos con permiso y themes. Funciona en Windows y Linux. Con licencia GPL.
5. Phprojekt
Es una aplicación modular para la coordinación de grupos de trabajo y el uso común de información y documentos vía internet o intranet. Está basada en un sistema de archivos que funciona en Windows y Linux. Soporta varios tipos de base de datos (Oracle, MySQL, Informix, etc.). Tiene una estructura modular, diferentes niveles de privilegios, veinticinco lenguajes soportados, skins y API para la inclusión de otros servicios. Con licencia GPL.
6. GanttPV
Es una aplicación fácil y sencilla de instalar que funciona en Windows, MacOSX y Linux. Permite definir tareas y establecer dependencias entre ellas, diagramas de Gantt, identificar y asignar recursos para las tareas, priorizar tareas, monitorizar totalmente el proyecto y, además, scripting con Python. Con licencia GPL.
7. NetOffice
Es una aplicación web de control del tiempo. Permite compartir información sobre equipos, proyectos y tareas. Permite un control desde cualquier punto con conexión a internet. Permite obtener una gama amplia de gráficos de diferentes tipos.
8. Trac
Es una aplicación minimalista web de control de proyectos. Está basada en tecnología wiki. Siempre tendremos disponible una línea de tiempo en la que se representa cada uno de los proyectos incluidos. Permite crear enlaces, tareas, ficheros y páginas wiki. Resulta una buena aproximación si estamos empezando.
9. Open Workbench
Es una aplicación que funciona en Windows y permite establecer un calendario sólido de gestión de proyectos. Permite definir proyectos, dependencias, tareas, crear, editar y borrar calendarios, gráficos de Gantt en un entorno muy amigable.
10. KPlato
Aplicación que funciona en Linux. Incluida dentro del KOffice Project. Permite diagramas de Gantt, vista de recursos, gestión de tareas, elaborar un resumen, calendarios, dependencias, cuentas asociadas a costes, etc. No incluye visión de la red.
Podéis encontrar otras herramientas en estos enlaces:
Si no se cuenta con una plantilla para el plan de trabajo, se recomienda seguir la metodología de análisis estructurado descendente. Siguiendo esta metodología, el proyecto se divide en tareas que, a su vez, son desglosadas en subtareas más detalladas. Esta secuencia se repite hasta que se obtiene un nivel de detalle suficiente como para que el proyecto sea comprendido en su totalidad. Se recomienda tener cuidado con el nivel de detalle, porque partir el proyecto en componentes exageradamente pequeños puede ocasionar altos costes de ineficiencia, tanto en realización como en mantenimiento.
Una recomendación es usar una fracción de la duración total del proyecto.
Una vez que se tiene la lista de actividades, el paso siguiente es estructurar la dependencia de las mismas. No todas se pueden desarrollar al mismo tiempo. Cuando se haya culminado este proceso de dependencias, se pasa a asignar los recursos a cada una de las actividades. Estos recursos incluyen personal, dinero y elementos requeridos.
Se recomienda tener en cuenta sólo seis horas hábiles por día laborable y dejar el tiempo restante para ajustes en la planificación del proyecto. Si el cálculo de tiempos carece de margen, suele ser necesario ajustar cronogramas y fechas, lo que genera una sensación de descoordinación que suele desmotivar al equipo de trabajo.

2.3.Administración de contratos

Hay dos temas fundamentales en la administración de un contrato:
  • la entrega de los resultados (entregables) y

  • el cumplimiento de las fechas para estas entregas.

Para ambos se establecen criterios y requerimientos que permiten controlar su cumplimiento.
Con frecuencia se olvida que el contrato es un documento legal regido por el código de comercio de cada país. De la misma manera, se convierte en necesidad saber si existen penalizaciones por incumplimiento de calendario de entregas parcial o total del proyecto y, si se definen entregables, conocer exactamente su definición y el soporte en el que serán facilitados.

2.4.Administración de proveedores

Durante el transcurso del proyecto, la relación con los proveedores puede llegar a variar mucho. Esta variación va estrechamente ligada al avance del proyecto. Habitualmente, al inicio del proyecto no suele haber contratiempos: el cliente acaba de contratar a quienes ha considerado la mejor opción en un proceso de selección y el proveedor acaba de adquirir un nuevo cliente.
Una vez iniciado el proyecto, pueden detectarse diferencias de criterios y de alcances para los entregables. En la administración de contratos y en el proceso de contratación no siempre queda totalmente definida la relación con el proveedor y sus obligaciones.
Igualmente, es imperativo establecer cómo se manejarán los incumplimientos, normales hasta cierto punto, entre lo programado inicialmente y lo que realmente entrega el proveedor. Hay dos tipos de incumplimientos:
  • el de especificaciones o función requerida, y

  • el de tiempos.

Dependiendo de su envergadura, un proyecto puede llegar a tener varios proveedores que interactúan. Se deben definir también los mecanismos de asignación de responsabilidades, de tal manera que no haya lugar a rebotar de un proveedor a otro la solución a un problema.

2.5.Administración del plan de trabajo

Hasta aquí ya se tiene definido el proyecto y planeado el trabajo. Los entregables del proyecto hasta ahora son los siguientes:
  • la definición del proyecto,

  • el plan de trabajo,

  • el contrato y

  • el manual de administración del proyecto.

El plan de trabajo es sólo un entregable. Describe lo que hay que hacer, el orden del trabajo, el esfuerzo requerido y quién está asignado a qué tarea, pero sólo representa al mejor estimado para completar el trabajo que queda por hacer en un momento dado de un proyecto.
Cuanto más complejo es el proyecto, más cambios se presentan en el plan de trabajo con el transcurso del tiempo. El gestor de proyecto deberá revisar los planes de trabajo de forma permanente (semanalmente como mínimo) y determinar el estado actual del mismo.
Se hace indispensable el uso de la gestión proactiva, de tal manera que se identifiquen las actividades que haya que cumplir a corto plazo para, partiendo de esta base y de su impacto dentro de los cronogramas y los objetivos del proyecto, hacer los ajustes necesarios con el fin de que los objetivos se cumplan. Cualquier cambio en los cronogramas, los criterios de aceptación y los objetivos establecidos los deberá resolver un comité de cambios. Ha de quedar claro para todos los involucrados en el proyecto que estos cambios afectan al alcance del contrato, por lo que no se pueden asumir unilateralmente. Las peticiones de cambio deben analizarse, hay que evaluar el impacto y el riesgo que supone aceptarlas y tomar las decisiones adecuadas al respecto.

2.6.Administración de situaciones

Una situación se presenta cuando un problema puede llegar a impedir o impide el progreso del proyecto y no puede ser resuelto por el gerente del proyecto y su equipo sin ayuda externa.
Cuando se presenta este tipo de situaciones, no queda más alternativa que resolver el problema. Se recomienda la aplicación de técnicas de manejo de situaciones, que tiene dos componentes.
El primero es tener un proceso que permita encontrar estas situaciones y traerlas a la luz, determinar su impacto en el proyecto, evaluar las alternativas y conseguir a las personas que permitan tomar la mejor decisión dadas las circunstancias. Este proceso debe formar parte del proceso general de administración del proyecto y ha de estar definido antes de empezarlo.
El segundo componente es aplicar técnicas de solución de problemas para resolver estas situaciones. Esto incluye el entendimiento de herramientas como los diagramas de espina de pescado, los diagramas de Pareto y los análisis de causa y efecto. Conocer estas herramientas permite que el equipo entienda la razón del problema, determine acciones disponibles y decida qué alternativa habría que tomar.
Es importante tener en cuenta que tener un proceso para resolver situaciones no es lo mismo que tener la habilidad para resolverlas exitosamente. En algunos casos, hay mejores alternativas y el trabajo del grupo de proyecto es encontrarlas y aplicarlas. En otros casos, no hay una buena solución para estas situaciones, por lo que habrá que tomar la decisión que menos daño haga o la "menos mala" de las alternativas.

2.7.Administración del alcance

El alcance de un proyecto describe los límites del mismo y lo que el proyecto va a entregar, qué información se necesita y qué partes de la organización se verán afectadas.
La administración de cambios en el alcance se inicia con la definición de qué es un cambio de alcance. Si el gestor del proyecto no ha definido bien el alcance inicial, será tremendamente difícil administrar este alcance durante el proyecto. El propósito de la administración de cambios en el alcance es proteger la viabilidad de la definición del proyecto, ya definida y aprobada. Cuando se definió el proyecto, también se definieron y se estipularon las expectativas de resultados. Durante la vida del proyecto es normal que se requieran ítems diferentes o adicionales a los incluidos en la definición original del proyecto. Debe quedar claro para todas las partes que cumplir estos nuevos requerimientos con los mismos recursos de la definición anterior es prácticamente imposible. Por lo general, los cambios conllevan mayores costes y atrasan la obtención de los resultados, dos temas que impactan directamente en las posibilidades de éxito o fracaso del proyecto.
La aprobación de los cambios en el alcance debe ser efectuada conjuntamente entre los clientes y los proveedores del proyecto, ya que ésta es la única manera de que se asignen los recursos adicionales necesarios y de que se ajusten las expectativas de los involucrados. Es habitual que, al añadir un cambio que introduzca una funcionalidad no prevista en el alcance original, se descarte alguna de las funcionalidades secundarias del proyecto, si no se pueden asignar más recursos o no se puede modificar el tiempo de finalización.
Uno de los principales problemas que aparecen al gestionar el alcance del proyecto es que se aceptan cambios pequeños que a simple vista no afectan mucho al proyecto y se infravalora el efecto conjunto de muchos cambios pequeños.

2.8.Administración de riesgos

El riesgo es una situación futura que existe fuera del control del proyecto y que puede tener un impacto negativo sobre el resultado del proyecto si se llega producir.
Administradores reactivos esperan a resolver la situación cuando ésta suceda. Los administradores proactivos tratan de identificar y resolver problemas potenciales antes de que ocurran.
Los proyectos pequeños, por su corta duración, no dan mucha cabida al surgimiento de problemas. Por el contrario, los proyectos grandes son propensos a problemas que no tardan en aparecer. En la gestión del proyecto deben identificarse todos los riesgos posibles, hay que determinar la probabilidad de los mismos y se ha de analizar el impacto en el proyecto, si ocurren.
Una vez identificado el riesgo que se quiere administrar, hay cinco alternativas de acción posibles:
  • No hacer nada. No se hará nada si se determina que el efecto sobre el proyecto es despreciable ante la ocurrencia del riesgo o que no hay nada que se pueda hacer para atenderlo.

  • Realizar un seguimiento. Se hará un seguimiento del riesgo de modo que se pueda determinar la probabilidad de que se dé o no con el transcurso del tiempo. Si aparentemente aumenta la probabilidad de que ocurra ese riesgo a medida que pase el tiempo, se atenderá en ese momento.

  • Evitar el riesgo. Se trata de eliminar la condición que podría causar el problema.

  • Trasladar el riesgo. En algunos casos es factible que la administración del riesgo sea asignada a otra entidad o a una tercera parte que no sea la administración del proyecto.

  • Mitigar el riesgo. En la mayoría de los casos ésta es la medida que se acaba tomando. Si se ha detectado un riesgo, puede desarrollarse un plan para garantizar que ese riesgo no se produzca o que, si lo hace, su impacto sea despreciable.

Al igual que con la administración del alcance, no hay nada malo en que haya riesgos en un proyecto. No se pretende que un proyecto no tenga riesgos. Lo que importa es la respuesta que se les dé a los mismos. Si se ignoran los riesgos, se convertirán en situaciones y se tendrán entonces menos opciones para su solución.

2.9.Administración de la comunicación

Ésta es una de las actividades críticas en un proyecto, además de ser fundamental en la administración de los objetivos y para los receptores de sus beneficios.
Hay dos niveles de comunicación en un proyecto. Todos los proyectos deben comunicar el estado del mismo. Adicionalmente, si el proyecto es complejo o más grande, se necesita un nivel más sofisticado de comunicación, y ese nivel estará definido en un plan de comunicaciones.
Las reuniones de estado y el informe de estado del proyecto es donde se estipula el avance del proyecto, los problemas, las actividades cumplidas, la revisión del flujo de caja y la proximidad de los entregables. Por lo general, se define un informe con formato estándar en el que se resume el avance y se alerta sobre posibles problemas.
Cuando el proyecto es de gran envergadura, se requiere un plan de comunicaciones que no sólo informe sobre el proyecto, sino que ayude en la implementación del cambio.
La comunicación se debe gestionar de forma proactiva. Además, ha de estar planificada y ser ejecutada para garantizar la buena comunicación entre los principales actores del proyecto: el cliente y los proveedores.

2.10.Administración de la documentación

La administración de la documentación es una de esas actividades que los jefes de proyecto dan por sentadas hasta que se ven inundados en papel. Para proyectos pequeños no hay necesidad de establecer todo un sistema administrativo, pero en la medida que el alcance del proyecto aumente, se hará necesario tenerlo.
Aunque es una de las tareas que puede ser asistida por tecnologías como un repositorio documental, estas herramientas pueden ser difíciles de administrar e incorporan mayores problemas al proyecto.
Debe decidirse cómo se codificarán los documentos, qué tipos de documentos se quieren almacenar, por cuánto tiempo, en qué formato y cómo se clasificarán. Independientemente de si se decide organizar la documentación según la fuente de la información o por su objeto, lo realmente importante es que se defina qué tipo de clasificación se utilizará.
Si los proyectos tienen una envergadura suficiente, es recomendable usar un sitio web dentro de la intranet de la empresa para almacenar esa información, de modo que ésta esté publicada y sea accesible en todo momento.

2.11.Administración de la calidad

La calidad de un proyecto se mide por lo cerca que están de cumplirse las expectativas y los entregables para el cliente. Por lo tanto, el objetivo central del equipo del proyecto es tratar de cumplir e incluso exceder los requerimientos del cliente. Hay una tendencia a equiparar calidad con el mejor material, el mejor equipo y cero defectos. Sin embargo, en la mayoría de los casos, el cliente ni espera ni puede costear una solución perfecta.
Uno de los propósitos del control de calidad es detectar errores lo antes posible en la vida del proyecto y disminuir así su impacto, tanto económico como en tiempo de realización del mismo.
Para poder administrar la calidad, hay que obtener una definición correcta de la expectativa del cliente. Esta definición se realiza mediante la cuantificación de algo que originalmente se percibe como subjetivo. Se debe determinar la calidad en función de un número de características que puedan ser definidas de modo tangible, y luego ver cómo se mide cada una de ellas.
La medición de la calidad debe ser un proceso continuo. Una de las técnicas habituales para efectuar este proceso de modo efectivo es el uso de los denominados círculos de calidad.
Un círculo de calidad es un grupo de trabajo conformado por personas que realizan tareas similares y que, con una periodicidad regular, se reúnen para identificar las causas de los problemas de sus trabajos con el fin de proponer soluciones a dichos problemas.
Una de las técnicas más empleadas en el control de calidad es el uso de listas de comprobación de pasos o funcionalidades (en el caso del desarrollo de software) para garantizar que el producto se entrega completo y que funciona correctamente.

2.12.Administración de las métricas

Obtener las métricas de un proyecto es la habilidad de manejo de proyectos más sofisticada y se puede convertir en la más difícil. Por lo general, las métricas son difíciles de definir y recopilar, razones por las que se ignoran o se manejan en forma inadecuada.
Se deben definir métricas básicas que permitan medir el esfuerzo, el coste y los tiempos de terminación. También se han de incluir métricas que determinen el grado de satisfacción de los requerimientos del cliente y el cumplimiento de sus expectativas. Dependiendo de los resultados, hay que aplicar los correctivos pertinentes.
Para fijar las métricas para el proyecto, se sugiere identificar los criterios de éxito en términos de entregables y ejecución, determinar cómo medir tanto el logro final como el avance, seleccionar un número apropiado de métricas y recoger la información. Es de vital importancia colocar parámetros de comparación mediante la definición de metas o hitos, ya que las métricas por sí solas no dicen mucho.
En general, este proceso es de poca importancia para proyectos pequeños, ya que no hay tiempo para recopilar los valores y menos para analizarlos y aplicar correctivos.

3.La planificación

Para gestionar un proyecto de forma eficaz y eficiente, necesitamos planificarlo correctamente. La planificación detallará los objetivos y/o los resultados del proyecto, el modo de conseguirlo y los recursos humanos y materiales que necesitamos para llevarlo a cabo. Toda esta información la plasmaremos en el plan de producción, un documento básico para el desarrollo y la ejecución del proyecto. Este documento es fundamental para apoyar al jefe del proyecto y a su equipo durante la ejecución del mismo.
Una vez aprobada la propuesta, el plan previo se detallará mucho más e incluirá las tareas asignadas a los diversos miembros que componen el equipo de trabajo y la identificación de hitos. El documento de la planificación (plan de producción) debe estar al alcance de cualquier persona implicada en el proyecto y no sólo del jefe, de modo que si se produce alguna modificación, actualización o cambio se puedan tomar las medidas pertinentes y todos los componentes del equipo estén enterados.
Antes de entrar a hablar propiamente de la planificación de un proyecto, es muy importante tener claras las etapas principales de su producción. Si un jefe de proyecto no tiene claras estas etapas y las actividades principales que se desarrollan dentro de ellas, difícilmente podrá hacer un plan de trabajo eficaz.

3.1.Etapas de un proyecto web

En la producción de una aplicación multimedia para la web intervienen muchas actividades que se deben realizar de forma cronológicamente sucesiva, ya que muchas de ellas no pueden empezar hasta que otras estén terminadas. Antes de entrar en la concreción de todas las actividades, es necesario tener una idea general de las etapas por las que se pasa en la producción del proyecto. Básicamente, estas etapas son las siguientes:
76529_m2_04.gif
1) Definición de proyecto
Es la etapa en la que se concreta en qué consiste el proyecto. El documento resultante es el de definición del proyecto. Normalmente se considera que esta fase es previa a lo que es el proyecto propiamente dicho.
Generalmente, esta fase finaliza con la firma, por las dos partes, del contrato.
2) Plan de trabajo
Una vez concretada la definición del proyecto, se empieza a trabajar propiamente en el mismo. Antes de nada, es importante planificar todo el desarrollo. Por este motivo hay una etapa intermedia que se debe tener en cuenta entre la definición del proyecto y el inicio de su producción, que es la del plan de trabajo.
3) Diseño
Una vez planificado el proyecto sobre las líneas generales que se han pactado en su definición, se empieza a diseñar exactamente cómo será. Cuando nos referimos a diseño, no debemos cometer el error de pensar sólo en diseño gráfico. Diseñar una aplicación multimedia o un sitio web es concretar todo lo que se hará con respecto a sus contenidos, el nivel formal (gráfico) y el nivel técnico. Por este motivo, en esta etapa se realizan tres análisis distintos:
  • Análisis de contenidos. Se decide toda la estructura de contenidos, servicios y funcionalidades.

  • Análisis formal. Se concreta la interfaz gráfica.

  • Análisis técnico. Se decide la solución técnica que se debe adoptar para el proyecto y la estructura orgánica de la aplicación en el ámbito de programación.

Durante esta etapa, se elaboran los distintos guiones que se van a utilizar en la etapa siguiente: la de desarrollo.
4) Desarrollo
A partir de todo lo decidido en la etapa de diseño, en esta etapa de desarrollo se concreta, se hace realidad el proyecto. Se elaboran todos los gráficos y los otros elementos multimedia, se construyen las páginas HTML y las bases de datos, se escribe toda la programación, etc.
5) Comprobación
Una vez finalizada la etapa de desarrollo, tenemos el proyecto terminado, pero en una versión provisional. Para validarlo se debe testar, es decir, probar que realmente funciona. La comprobación puede ser de distintos tipos:
  • Comprobación técnica. Se comprueba que la aplicación o la web funciona en todos los sistemas operativos y/o softwares y/o configuraciones para las que se ha realizado.

    La verificación técnica deberá comprobar que el producto multimedia funcione correctamente en todos los dispositivos, plataformas y sistemas operativos en los que pueda ser consultado.

    En este sentido, hay que tener en cuenta, ampliando el ejemplo de verificación técnica que encontraréis, los datos siguientes sobre navegadores, sistemas operativos y dispositivos más utilizados:

  • Comprobación de funcionalidad. Se mira que la aplicación funcione bien: que todos los enlaces sean correctos, que cada objeto tenga asignado su comportamiento, que los elementos multimedia estén donde deben estar, etc.

  • Comprobación con usuarios. En proyectos grandes es importante probar la aplicación con una muestra real de usuarios con un perfil similar a los usuarios en los que hemos centrado el diseño. Este tipo de comprobaciones deben realizarlas profesionales con perfiles relacionados con la interacción persona/ordenador o con el diseño centrado en el usuario.

Todas estas comprobaciones no tendrían sentido si, posteriormente, no se cambiasen los aspectos que se ha visto que no funcionan correctamente.
Por otra parte, a pesar de que la comprobación se considera como una etapa posterior al desarrollo, se debe entender que a lo largo del desarrollo las pruebas son una acción que hay que aplicar sistemáticamente. Cuando un diseñador construye una página HTML y hace el preview o vista previa, de hecho, está probando y comprobando esa página. Otra forma de ir comprobando el proyecto a lo largo del desarrollo es enseñar lo que se está haciendo a los compañeros del equipo de trabajo para que valoren si se entiende, si funciona bien, etc.
6) Explotación/implementación
Una vez terminada la etapa de comprobación y hechos todos los cambios oportunos, se da la producción por terminada. En este punto entra la etapa de explotación o implementación.
Hablamos de implementación cuando nos referimos a proyectos con un alto componente de ingeniería informática y en los que se introducirán en un sistema que ya funciona.
Ejemplo de implementación
Por ejemplo, si el proyecto consistía en una aplicación para una intranet, una vez realizado lo implementaremos en la intranet.

4.Metodología de planificación de un proyecto

No existe una metodología única para planificar un proyecto. Cada jefe de proyecto tiene sus propios trucos a la hora de llevar a cabo el plan de trabajo. A pesar de ello, es bueno utilizar una propuesta metodológica para construir el plan de trabajo a partir de las técnicas que más se acostumbran a utilizar.
Se debe tener en cuenta que en los proyectos pequeños se puede trabajar con una planificación mínima, pero que en proyectos medianos y grandes es totalmente imprescindible hacer, antes de empezar el desarrollo del proyecto, una planificación exhaustiva.
Una vez tomada la decisión de poner en marcha el proyecto y obtenida la autorización formal del cliente, los pasos que se han de seguir son los siguientes:
1) Diseño de un plan de trabajo
2) Distribución del trabajo entre los recursos disponibles
3) Presentación del calendario y planificación para la aprobación formal
4) Inicio de la ejecución o desarrollo del plan de trabajo
Las actividades básicas implicadas en la planificación de un proyecto son las siguientes:
  • Identificar las tareas o subtareas y sus dependencias.

  • Representar las tareas y dependencias mediante un diagrama para poder determinar la secuencia de tareas más eficaz.

  • Estimar el grado de esfuerzo requerido en horas, días o semanas en función de la dimensión del proyecto y la duración de cada tarea y subtarea.

  • Identificar los recursos y la disponibilidad (tiempo, cómo y cuándo).

  • Especificar los hitos u objetivos parciales.

  • Elaborar una lista de los "entregables", muchos de los cuales coincidirán con los hitos.

  • Presentar la planificación obtenida para su aprobación formal.

Gestión de proyectos
Algunas veces se plantea si las horas empleadas por el jefe de proyecto deben incluirse en la planificación. La recomendación es que las horas de gestión de un proyecto deben incluirse en la planificación, porque estas horas se extienden desde el inicio hasta el final del proyecto y se trata de un recurso valorable que debe formar parte del presupuesto global bajo la forma de sueldo del jefe de proyecto. Sin embargo, no siempre es recomendable que todas las tareas del jefe de proyecto se plasmen explícitamente en la planificación, puesto que son de muy diversa índole y difícilmente cuantificables. Se suele calcular que el jefe de proyecto debe dedicarle al mismo aproximadamente un 20% de su duración total. Por ello es habitual asignar al jefe de proyecto una tarea genérica de gestión de proyectos.
Las principales herramientas de planificación de las tareas y las subtareas son las siguientes:
  • La estructura de descomposición del trabajo (EDT). Es una estructura exhaustiva, jerárquica y descendente formada por los entregables que se habrán de realizar en un proyecto. La EDT es una herramienta muy común y crítica en la gestión de proyectos.

  • El diagrama de Gantt. Muestra el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo del tiempo total del proyecto.

  • El gráfico PERT (program evaluation and review technique). Es un método para analizar las tareas involucradas en un proyecto dado, el tiempo necesario para completar cada tarea y las dependencias entre ellas, y para identificar el tiempo mínimo necesario para completar el proyecto total.

4.1.Definición de los recursos necesarios para alcanzar los objetivos

Antes de iniciar un proyecto es necesario averiguar con exactitud cuáles son los objetivos que hay que alcanzar. Al definir un proyecto, Hallows sugiere unas cuantas preguntas básicas:
  • ¿Están definidos los "entregables" del proyecto? Los entregables son los resultados, los hitos, los productos parciales o totales de un proyecto. Son la prueba de que el equipo del proyecto está trabajando. Los equipos mal gestionados se concentran más en la producción de un entregable parcial que en el propio entregable final; la solución está en definir con precisión lo que hay que hacer y mantenerse en la misma línea para alcanzar los objetivos deseados.

  • ¿Está definido el ámbito del proyecto? Debemos realizar un esfuerzo para determinar el grado de esfuerzo necesario para cubrir todos los aspectos de un proyecto, y a menudo usaremos todas las herramientas que tengamos a nuestro alcance (representación gráfica).

  • ¿Está determinado el modo en el que los entregables serán revisados y aprobados? Debemos asegurarnos desde el inicio del proyecto de que todo el mundo está de acuerdo con los objetivos que hay que alcanzar y, por lo tanto, con los medios utilizados para revisar y aprobar cada tarea, del equipo e incluso del jefe de proyecto.

4.2.Revisión de la definición del proyecto

El primer paso fundamental cuando empezamos a desarrollar el plan de trabajo de un proyecto es revisar la definición del proyecto que hemos pactado con el cliente. Es importante hacer esta revisión para asegurarnos de que se entiende exactamente en qué consiste el proyecto, qué es lo se debe producir. Igualmente, la definición de proyecto nos dará los parámetros de calendario en los que debemos movernos.
En los proyectos grandes es muy útil que la definición del proyecto contenga una descripción muy completa del mismo. A veces se acostumbra, antes de entrar propiamente en la fase de planificación o diseño del plan de trabajo, a hacer una primera planificación aproximada, que el cliente validará junto con el resto de la información relativa a la definición del proyecto.

4.3.Tareas y subtareas

El desarrollo del plan de trabajo de un proyecto significa tener unas pautas en el camino que hay que seguir para alcanzar los resultados y estructurar una correcta y eficaz división del trabajo. Para que el desarrollo del plan sea un éxito, una de las claves es mantener informados de la evolución del proyecto a todos los implicados. Fomentar la implicación de todos los participantes en el proyecto aumentará la credibilidad del jefe de proyecto y del proyecto en sí.
¿Qué quieren saber los clientes? Los clientes quieren saber el estado del proyecto para ver si se respeta el calendario y el presupuesto pactados. También quieren conocer la probabilidad de que nos excedamos en tiempo y gastos y, en general, anticiparse a cualquier problema que pueda surgir. El cliente no quiere sorpresas y bastará, según la duración del proyecto, con un informe semanal o quincenal (en el caso de proyectos grandes).
El desarrollo del plan de trabajo supondrá llevar a cabo el proyecto en forma de muchas tareas y subtareas (tareas subordinadas a las tareas). El principal reto del jefe de proyecto será averiguar la relación existente entre ellas (si son dependientes o no) y coordinar de forma eficiente y rentable cómo y cuándo se van a ejecutar (secuencia).
Por último, el diseño de un buen plan (que tenga en cuenta todos los aspectos del proyecto, los sucesos críticos, las tareas y las subtareas asociadas y la coordinación del conjunto) depende en gran parte de las experiencias anteriores, la nuestra y la de otros jefes de proyecto. Una buena estrategia pasaría por considerar el proyecto como un conjunto y dividirlo después en distintas fases. No resulta complicado detectar las principales e identificar desde ellas las tareas y las subtareas asociadas.

4.4.Estimación de tiempos dedicados a las actividades

Una vez que tenemos la totalidad de las actividades que contiene el proyecto, es decir, una lista con todo el trabajo que debemos realizar detallado al mínimo, debemos hacer una estimación del tiempo que creemos que se destinará a cada actividad.
En los primeros proyectos, siempre es un problema hacer un cálculo estimado de las horas que se puede tardar en hacer una determinada actividad. En estos casos, podemos tener en cuenta las técnicas siguientes, que nos ayudarán a estimar la duración de las actividades:
  • Historial previo

    Si hemos trabajado en algún proyecto similar en el pasado, miraremos los documentos generados para el plan de trabajo para ver cuánto habíamos previsto que se dedicaría y cuánto se dedicó finalmente a las distintas actividades de ese proyecto del pasado.

  • Analogía

    Aunque no se haya hecho una actividad exactamente igual, quizás se haya trabajado en un proyecto que tuviera una actividad similar a ésta cuya duración estimamos ahora.

  • Ratio

    Podemos aplicar esta técnica cuando hayamos realizado una actividad similar a ésta cuya duración estimamos ahora en un proyecto de otra dimensión.

  • Opinión de un experto

    En muchas ocasiones se debe acudir a un experto interno o externo (la primera vez que se usa una nueva tecnología). Este experto nos puede dar pistas del tiempo que se puede tardar en realizar determinada actividad.

  • Adición de horas de contingencia

    Se usa para reflejar la incertidumbre o el riesgo asociado a las estimaciones. Si tenemos una actividad no muy bien definida, podemos incluso añadir una contingencia del 50%. Si la actividad está muy clara, podemos añadir una contingencia del 10%. En casos de proyectos muy similares a otros ya realizados, a las tareas se les puede aplicar esta contingencia del 10%.

  • Adición del tiempo de gestión de proyecto

    En general, el 15% de las horas que se dedican a un proyecto deben ser de horas de gestión.

  • Estimaciones en horas

    La primera estimación de duración que asignamos a una tarea la realizaremos en horas, ya que es la mejor forma de tener una dimensión clara de lo que podemos tardar en realizarla. Posteriormente, estas horas las transformaremos en tiempo (en función de cuántas personas realizan la tarea, con qué jornada laboral, etc.).

Una vez que, utilizando todas las técnicas de estimación y los propios conocimientos tecnológicos que tiene el jefe de proyecto, se hayan decidido las horas que se van a dedicar a cada actividad (de forma estimada), en la lista de actividades que se ha generado previamente se debe añadir el tiempo de cada actividad.
Cuando tengamos la duración de todas las actividades, se calculará el tiempo aproximado que se dedicará a la gestión. Se acostumbra a calcular que se dedican a la gestión aproximadamente entre un 10% y un 15% del total de horas de producción del proyecto (sobre todo en los proyectos medianos y grandes). Esto no implica que toda la gestión la realice el jefe de proyecto. Los responsables de áreas también pueden llevar a cabo parte de estas tareas de gestión.
Con tiempo dedicado a la gestión no nos referimos sólo a la creación y la gestión del plan de trabajo. Las reuniones con el cliente y con los responsables de área, el control de los guiones y del avance del proyecto, etc. también son actividades propias de la gestión del proyecto.

4.5.Relaciones y dependencias entre actividades

Una vez que tenemos claras las actividades del proyecto y sus duraciones estimadas, debemos ver las relaciones que hay entre estas actividades. Lo imprescindible es delimitar todas las precedencias.
Por precedencias entendemos las actividades que es necesario que estén terminadas antes de que se empiece otra. Para ello, deberemos hacernos, para todas las actividades, la pregunta siguiente: "Para empezar esta actividad, ¿necesitamos que estén terminadas previamente otras?" En caso afirmativo, miraremos cuáles y las marcaremos como precedencias de la actividad en concreto.
Tipos de tareas que incluye la planificación según sus dependencias:
  • Tareas paralelas. Pueden llevarse a cabo al mismo tiempo sin obstaculizar el proyecto. Pueden tener diferentes fechas de inicio y terminación.

  • Tareas dependientes. Son aquellas que no pueden empezar hasta que no ocurra algo que está previsto, es decir, tareas o subtareas que no se inician hasta que una o varias tareas previas no se han terminado.

  • Tareas predecesoras. Son aquellas tareas que deben acabarse antes de que se pueda empezar la siguiente.

  • Hitos. Consisten en la finalización de tareas, pero no requieren forzosamente tiempo o presupuesto ni llevan siempre asociado un entregable. Los hitos son importantes para los miembros del equipo del proyecto, ya que marcan el camino que hay que seguir y los logros parciales. Además, permiten que el equipo sepa que el proyecto progresa según lo previsto.

4.6.Aprobación de la planificación

Una vez finalizada la planificación, es recomendable ponerla en común con el cliente y con el resto de proveedores, si los hubiera, para que todas las partes implicadas den su aprobación. El objetivo es llegar a un consenso sobre los distintos hitos intermedios, las fechas de los entregables y los compromisos adquiridos.
Un factor muy importante de la buena marcha del proyecto es la implicación del cliente. Algunas de las tareas del proyecto dependen de datos, documentación o información que debe proporcionar el cliente o de decisiones que ha de tomar sobre el mismo (aprobación de la funcionalidad, de la interfaz gráfica, de la interactividad, etc.). Por ello, el conocimiento de cuándo debe entregar la información o de en qué momento se espera que tome una decisión es vital para la buena marcha del proyecto.
Igual de importante es la implicación de los proveedores. Si en el proyecto participan distintos proveedores, acordar su implicación es clave para garantizar el cumplimiento de la planificación del proyecto.

4.7.La puesta en marcha

Tras la planificación detallada de un proyecto y su revisión, pasamos a su ejecución o puesta en marcha. El plan de producción se consultará para seguir la secuencia de tareas y para asignar las mismas a los distintos participantes (o componentes del equipo de trabajo).

5.Seguimiento del proyecto

Tras la puesta en marcha de un proyecto hay que gestionar el plan de trabajo. Aunque parezca contradictorio, dado el trabajo que conlleva hacer una planificación, si no la vamos adaptando a la realidad a medida que avanza el proyecto, se convierte en una herramienta inútil.

5.1.El seguimiento y el control de un proyecto

Una vez iniciado el proyecto, la principal tarea del jefe de proyecto es evaluar y gestionar el progreso del mismo. Un director o jefe de proyecto eficaz es aquel que examina todas y cada una de las tareas y las subtareas llevadas a cabo hasta el momento, el progreso realizado en el tiempo previsto, el solapamiento de tareas y cómo encajan entre ellas, qué modificaciones se deben efectuar y cómo deben aplicarse, los problemas que pueden ir surgiendo, el control del presupuesto y la motivación de los empleados.
Veamos en una lista una serie de responsabilidades:
  • Anotar o registrar cualquier variación respecto al desarrollo y la planificación de un proyecto.

  • Modificar la descripción de las tareas según las necesidades y a medida que progrese el proyecto. Cuando el proyecto se desvíe, hay que corregir de inmediato cualquier tarea manteniéndose dentro de los límites de tiempo y presupuesto.

  • Acompañar a los miembros del equipo, trabajar con ellos, construir un ambiente de equipo, ofreciendo críticas y alabanzas, escuchándolos y dotándolos de responsabilidad.

  • Controlar el ámbito del proyecto y asegurarse de que se emplean los recursos necesarios.

  • Asegurarse de que se superan eficazmente los obstáculos.

  • Mantener buenas relaciones con nuestros superiores y el cliente, informándolos, evitándoles las sorpresas y estando pendientes de sus reacciones.

5.2.El plan de trabajo, una herramienta viva

La planificación de un proyecto es una herramienta que nos sirve para organizar el trabajo y el equipo, pero siempre sufre modificaciones. Para que sea útil, debemos ir actualizando este plan de trabajo a medida que avanza el proyecto. Es recomendable gestionar el plan de trabajo como mínimo una vez a la semana. Cuando lo hagamos, debemos identificar qué actividades se han completado durante la semana y actualizar el plan para que se vea claramente que están terminadas.
Cuando hacemos revisión del plan de trabajo, debemos indicar de forma clara aquellas tareas en las que hay algún problema y aquellas otras que han requerido menos tiempo del previsto, ya que pueden influir en tareas dependientes.

5.3.Actividades problemáticas, camino crítico

Cuando hagamos la revisión, tenemos que ver si hay actividades que deberían estar terminadas pero que no lo están, y cómo afecta este retraso al desarrollo global del proyecto.
En estos casos, el jefe de proyectos debe hablar con los miembros del equipo que están asignados a estas actividades para ver qué pasa y cuál es el origen del retraso. Puede pasar que haya ocurrido un problema o que la estimación fuese errónea. Junto a las personas implicadas se debe determinar cuánto tiempo adicional se necesitará para completar la actividad y habrá que actualizar el plan de trabajo en función de este tiempo añadido.
Una vez actualizado el plan de trabajo, se evaluará si las modificaciones suponen algún cambio considerable en la duración y el coste originales. Probablemente deberemos recortar el tiempo que se dedicará a alguna actividad futura para que cuadre el plan de trabajo con la fecha de finalización fijada.
La metodología más utilizada para este fin es el método del camino crítico (1) . El método del camino crítico representa gráficamente las actividades y sus dependencias mediante un grafo.
Un grafo representa gráficamente un conjunto de puntos (llamados nodos) unidos por líneas (denominadas aristas). Los grafos permiten estudiar las interrelaciones entre actividades que se encuentran en interacción, de manera que los nodos representan las actividades y las aristas, las dependencias entre ellas.
Ejemplo de grafo de camino crítico
Ejemplo de grafo de camino crítico
No solamente se llama camino crítico al método, sino también a la serie de actividades, contadas desde la iniciación del proyecto hasta su terminación, que no tienen flexibilidad en el tiempo de ejecución, por lo que cualquier retraso que sufriera alguna de esas actividades de la serie provocaría un retraso en todo el proyecto.
Conocer el camino crítico permitirá gestionar adecuadamente los posibles retrasos y nos permitirá saber el margen del que disponemos para corregirlos.

5.4.Resultados y tareas de un proyecto

Una de las dificultades en relación con la consecución de los objetivos en un proyecto es centrarse en exceso en las tareas que hay que realizar en lugar de en los resultados que se han de conseguir. Un buen jefe de proyecto debe tener siempre la vista puesta en el final desde el inicio del proyecto. De este modo, todas las actividades del proyecto estarán relacionadas desde el principio con el resultado buscado y todas las decisiones que se tomen se tomarán con más probabilidad de alcanzar el final deseado.
El resultado de un proyecto es cuantificable, debe alcanzarse en un período determinado de tiempo y con un coste específico. Por eso un buen método de trabajo será partir de la fecha límite del proyecto y trabajar hacia atrás hasta el presente, determinando las tareas y las subtareas que se deben llevar a cabo.

6.El presupuesto

Si bien es cierto que durante todas las fases del proyecto se debe tener muy presente que el objetivo de cualquier empresa es satisfacer las expectativas del cliente con un producto adecuado y de calidad, no hay que olvidar que ese trabajo tiene que generar unos beneficios económicos para la empresa. Por esta razón es necesario saber encontrar el mejor balance entre el servicio ofrecido y el coste que representa.
Es conveniente tener en cuenta que la expresión "cliente que satisfacer" es tan válida para empresas que realizan servicios para terceros, como para aquellas que desarrollan trabajos para la propia empresa, ya sea porque se trata de proyectos internos o porque esa empresa distribuye directamente sus productos. Lo importante es que, en cualquiera de los casos, es necesario mantener unos estrictos controles: de calidad, de calendario y económico.
La mayoría de temas económicos se suelen tratar antes del propio inicio del proyecto, es decir, durante la realización del presupuesto para el cliente, o en los primeros pasos del mismo, pero cualquier incidencia en el proyecto puede tener repercusiones directas o indirectas sobre cuestiones económicas.
A continuación, recordaremos el concepto de presupuesto. Veremos por qué se realiza y describiremos algunas de sus tipologías. También analizaremos algunos de los factores que deben tenerse en cuenta cuando hacemos un presupuesto.

6.1.Qué es un presupuesto

Por definición, uno de los elementos que caracterizan un proyecto es que dispone de un presupuesto preestablecido. Por lo tanto, es importante delimitar exactamente qué significa la palabra presupuesto en el contexto de un proyecto.
El presupuesto de un proyecto es la cantidad económica que las partes (cliente y proveedor) pactan para la realización de un producto o servicio determinado –es decir, el coste que tendrá para un cliente la realización del proyecto en cuestión por parte de un proveedor concreto y en un límite de tiempo determinado.
El documento de presupuesto es el documento que debe entregarse al cliente y en el que se describen las tareas implicadas en la realización de un proyecto y que conducen a la presentación de una cantidad económica.

6.2.Necesidad del presupuesto

El objetivo de la elaboración de un presupuesto es el de tener una cantidad económica de referencia aceptada por los actores implicados en un proyecto.
En la mayoría de los casos el cliente solicita al proveedor una estimación del coste global que va a suponer la obtención del producto o servicio, y en raras ocasiones, a no ser que haya una relación de confianza entre las partes, se facturará por horas o por jornadas. La fórmula de cobro por horas se suele utilizar para trabajos puntuales o fácilmente cuantificables y tarificables (2) (...).
El cobro por jornadas normalmente se realiza para tareas de duración media, como por ejemplo ciertas acciones esporádicas de actualización o mantenimiento de materiales, como podría ser la modificación de la programación de una página web.
Como se ha comentado, existen ciertos casos cuantificables en los que es tan posible trabajar con presupuestos globales como hacerlo por unidad (3) , pero el resultado esperado es el mismo: tener una cantidad económica de referencia.

6.3.Tipos de presupuestos

De acuerdo con el origen de un presupuesto, podemos determinar varias tipologías de documentos de presupuesto: en función su origen, de su estado, de su filosofía, de su duración, de su destino, de su ámbito... En realidad, se trata de una referencia, ya que se podrían determinar tantas categorías como criterios nuevos pudiéramos establecer.
Documentos de presupuesto según su origen
  • A solicitud del cliente. El cliente solicita el documento para tomar la decisión final, por lo que éste debe ser impecable, tanto desde el punto de vista formal como de su contenido. En muchas ocasiones no se dispone de una cantidad de referencia proporcionada por el cliente, por lo que proveedores distintos pueden presentar presupuestos (cantidades económicas) realmente muy diferentes.

  • Para calificarse. No lo solicita el cliente, pero el proveedor sabe o intuye sus posibles necesidades. Por lo tanto, este tipo de presupuesto se presenta con intención de despertar el interés del cliente.

  • Como documento interno. No lo solicita el cliente, pero se elabora como elemento de control y de gestión interno ante un proyecto. Este tipo de presupuesto sería aplicable a casos en los que el cliente únicamente está interesado en la cantidad económica.

  • Acceso a un concurso. El cliente establece un concurso, con lo que los proveedores interesados presentan su oferta. Normalmente, en los organismos y las entidades de carácter público los concursos se publican en los boletines oficiales correspondientes. En ellos las necesidades suelen estar definidas por un pliego de prescripciones y las cantidades económicas estarán totalmente acotadas.

Documentos de presupuesto según su estado
  • En revisión. Cuando el documento se encuentra en el proceso de revisión, ya sea interno (en la propia empresa) o externo (por parte del cliente).

  • Definitivo. Si ya está aceptado y validado internamente y por el cliente.

Documentos de presupuesto según su filosofía
  • Cerrado. No existen márgenes para ampliaciones ni variaciones económicas.

  • Abierto. Se establecen unos márgenes de referencia, pero con posibilidades de ampliación por acuerdo mutuo.

Documentos de presupuesto según su duración
  • Limitado. Se conoce de antemano su duración y la nula posibilidad de continuidad futura.

  • Prorrogable. Se determina un tiempo a partir del cual se puede renegociar el contrato o prorrogar la validez del presupuesto. No se prevé la posibilidad de un contrato de presupuesto para un proyecto "indefinido", pues cada proyecto tiene una duración finita en el tiempo.

Documentos de presupuesto según su destino
  • Versión interna. Es la versión del documento de presupuesto con las hipótesis de los diferentes escenarios económicos y la expresión de los márgenes comerciales. Será la utilizada para decidir qué opción se presentará al cliente.

  • Versión para el cliente. Es el documento destinado a ser entregado al cliente y en el que se presentan cantidades finales.

Documentos de presupuesto según su ámbito
  • Global. Si el presupuesto afecta a todo el ámbito de actuación de las compañías implicadas (ámbito geográfico, de sector económico...).

  • Local o sectorial. En el caso de que el acuerdo afecte únicamente a sectores localizados de alguna de las empresas implicadas.

Como hemos comentado, las posibilidades para elaborar clasificaciones son prácticamente ilimitadas. Aquí hemos querido presentar algunas de las opciones más comunes.

6.4.Factores que hay que tener en cuenta en un presupuesto

Al elaborar un presupuesto, siempre compensa estimar los recursos económicos necesarios al alza. Los motivos son los siguientes:
  • Por mucha información que se tenga, no todo se habrá tenido en cuenta.

  • A pesar de lo precisos que sean los cálculos, del margen de tolerancia o del tipo de obstáculos que se hayan previsto, es posible que nos quedemos cortos en las estimaciones.

  • En un ambiente comercial, social y tecnológico en continuo cambio, tendremos que incluir en el presupuesto un espacio ampliable para hacer frente a los gastos adicionales que se presenten.

Como conclusión:
  • El presupuesto debe ser flexible y ha de tener un margen destinado a considerar posibles errores de estimación a la hora de planificar.

  • El presupuesto puede ser un poco más amplio de lo que indiquen nuestros mejores cálculos.

  • El impacto acumulado por calcular a la baja el tiempo necesario puede disparar el coste del proyecto.

A la hora de calcular el coste económico es fundamental:
  • Evitar la tendencia a calcular a la baja el tiempo que necesitan los miembros del equipo para efectuar un trabajo.

  • No olvidar los presupuestos de los subcontratados o externos. Si trabajan con una tarifa fija, será fácil de calcular, pero ¿qué ocurre con el tiempo empleado en reuniones con el subcontratado, el seguimiento de su trabajo, las tareas administrativas, las llamadas telefónicas y los correos electrónicos?

  • Solicitar ayuda a todo el equipo; no calcular únicamente desde la propia competencia.

  • Durante un proyecto sobrevendrá más de una crisis (pagar un coste desorbitado por un recurso, trabajar horas extras, buscar ayuda externa...) y hay que estar preparados para ello.

6.4.1.Modelos para la elaboración de un presupuesto
Para elaborar el presupuesto podemos utilizar alguno de los modelos siguientes:
  • Presupuestar de arriba abajo

    Desde este enfoque, se sondea a la dirección de la empresa y se realiza una búsqueda masiva de antiguos proyectos con características similares al actual. Se recopilan los gastos asociados a cada fase, las tareas y las subtareas. Para afinar un poco más, el jefe de proyecto involucra a los miembros del equipo y consigue su estimación del tiempo (y de los costes) de las tareas y las subtareas específicas. Por último, se corrige la estimación inicial y se presentan los datos a la dirección, teniendo en cuenta un margen de seguridad en la elaboración de los presupuestos.

  • Presupuestar de abajo arriba

    Tras elaborar la planificación, el equipo de desarrollo se reúne para estimar el presupuesto requerido para cada tarea y subtarea incluida en el proyecto. Se supervisan los cambios entre tareas desde que se inicia el proyecto para seguir elaborando y contrastando el presupuesto, que deberá someterse a la aprobación de la dirección de la empresa. A medida que el proyecto avanza y el equipo progresa, las tareas se resuelven de forma más eficaz, la productividad es mayor y los costes, menores. La implicación es una buena técnica de gestión, ya que el conocimiento de cada uno de los pasos nos da lo necesario para elaborar un presupuesto.

    Este modelo de cálculo tiene muchas ventajas (recopilar gastos de forma precisa y detallada), pero también riesgos, ya que si no se incluyen los gastos de todos los elementos, el presupuesto se saldrá del margen.

  • Presupuestar de arriba abajo y de abajo arriba

    Combinar las dos técnicas es el enfoque más eficaz para la elaboración de un presupuesto. Requiere reunir todos los datos de dirección y solicitar la contribución de los miembros del equipo para ajustar las estimaciones adecuadamente.

Independientemente del enfoque empleado, hay que tener en cuenta la diferencia que hay entre la jornada laboral y las horas que se trabajan realmente. Ningún miembro del equipo estará ocho horas en productividad constante. De ahí que haya que añadir un 10% o un 15% más a las estimaciones presupuestarias en previsión del tiempo necesario para completar las tareas.

Bibliografía

Abadal, Ernest (2004). Gestión de proyectos en información y documentación. Gijón: Trea.
Bataller, Alfons (2010). La gestió de projectes. Barcelona: Editorial UOC.
Daccach, J. C. (2008). "Administración de proyectos". Delta Asesores. Disponible en: http://www.deltaasesores.com
Gido, J.; Clements, J. P. (1999). Administración exitosa de proyectos. International Thomson Editores.
Gutiérrez Martínez, José María (2005). Planificación y gestión de proyectos informáticos. Alcalá de Henares: Universidad de Alcalá.
Horine, Greg (2010). Manual imprescindible de gestión de proyectos. Madrid: Anaya Multimedia.
Lewis, J. P. (1995). Planificación, programación y control de proyectos. Barcelona: Ediciones S.
Miranda Miranda, Juan José (2012). Gestión de proyectos: identificación, formulación, evaluación financiera, social, ambiental. Bogotá: MM Ediciones.
Mochal, T. (2000). Ten step project management process. Disponible en: http://www.TenStep.com
Pardo, Alejandro (2014). Fundamentos de producción y gestión de proyectos audiovisuales. Pamplona: EUNSA.
Pereña Brand, J. (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.
Serer Figueroa, Marcos (2010). Gestión integrada de proyectos. Barcelona: Edicions UPC.
Williams, Meri (2009). Introducción a la gestión de proyectos. Madrid: Anaya Multimedia.