Unido M Adminproyectos.pdf

Módulo 1 Conceptos de la administración de proyectos.

1. Conceptos de la administración de proyectos 1.1 ¿Qué es un proyecto? Las definiciones del concepto de Proyecto son numerosas, y muchas de ellas están vinculadas a la tipología específica o ámbito de actuación en la que se desarrolla una determinada actividad profesional. La palabra PROYECTO suele ser usada por lo general en diferentes sentidos. Por un lado se suele hablar de proyecto en el sentido de una idea o intención: “…tengo el proyecto de hacer un crucero el año que viene….”. Otra acepción muy comúnmente usada es la que se da en el mundo de la arquitectura o la ingeniería de obra, el proyecto como el plano: “…pidió que le alcance el proyecto…” o “… el arquitecto ha preparado diferentes proyectos para la casa….”. Una tercera acepción tiene que ver con toda la documentación correspondiente a los análisis previos de algo que se piensa ejecutar, “…prepararé un proyecto y discutiremos el documento…” En cualquiera de los casos la definición es correcta aunque aún nos queda una cuarta acepción para esta palabra que resume el concepto que tomaremos para abordar la materia, y es la de Proyecto como trabajo: “el desarrollo del proyecto avanza según lo planeado….” Tomando como referencia el diccionario de la Real Academia Española de la Lengua encontramos las siguientes acepciones en las que se define 1

proyecto como: “designio o pensamiento de ejecutar algo” y como “conjunto de escritos, cálculos y dibujos que se hacen para dar idea de cómo ha de ser y lo que ha de costar una obra de arquitectura o de ingeniería”. Si nos centramos en la primera definición podemos observar un aspecto creativo e intelectual del proyecto, aunque aún en el mundo de las ideas, mientras que la segunda hace referencia a una naturaleza documental. No obstante todo esto, en el ámbito de la Dirección y Gestión de proyectos, las definiciones más habituales del término proyecto hacen pie en los aspectos de utilización y control de los recursos (humanos, materiales, intelectuales, financieros, otros.) y a las actividades que se llevan adelante para conseguir el producto objeto del proyecto. A continuación, introduciremos y revisaremos algunas de las definiciones más habituales de proyecto, relacionadas con su dirección y gestión: Una de las definiciones más completa es la que proporcionó J. Rodney Turner en su "Handbook of Project-Based Management" ya que incorpora los elementos que son básicos para la comprensión de lo que es un proyecto: “Un proyecto es una acción iniciada por la empresa en la que recursos humanos, financieros y materiales se organizan de una nueva forma para acometer un trabajo único, en el que, dadas unas especificaciones y dentro de unas limitaciones en costo y tiempo, se intenta conseguir un cambio beneficioso definido por unos objetivos cualitativos y cuantitativos”. El Project Management Institute (PMI) establece la siguiente definición: "proyecto es un esfuerzo temporal encaminado a crear un producto o servicio único" (PMBOK, 2004). Según el PMI, todos los proyectos presentan una serie de características comunes, como el hecho de ser desarrollados por personas, estar condicionados por recursos limitados, y ser planificados, ejecutados y controlados desde este punto de vista. Una definición simple pero a la vez muy completa de proyecto y que tomaremos como base es la siguiente: “Un proyecto es un trabajo singular con unas fechas definidas de inicio y finalización (calendario), 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. Lewis.

2

1.2 Atributos de un proyecto A los efectos de la materia vamos a enfocar el concepto haciendo hincapié en los siguientes atributos:    

es un trabajo tiene un objetivo único o singular tiene un tiempo limitado tiene un presupuesto acotado

Siempre que esas características se cumplen estamos hablando de “proyecto”.

1.2.1 Proyectos y procesos Los proyectos son llevados a cabo por organizaciones que generan trabajo, este trabajo puede llevarse a cabo en la modalidad de proyecto o de proceso. Un proyecto se diferencia de otros tipos de trabajos fundamentalmente es su carácter de “única vez”, es decir, por más que pueda ejecutar muchos proyectos similares, este es único y diferente en sus condiciones y producto final, no es repetitivo, ni rutinario. En principio podría pensarse que un proyecto es igual que el resto de operaciones que desarrollan las organizaciones. Sin embargo, hay aspectos en los proyectos, puestos de manifiesto en la definición anterior que los diferencian claramente de otros tipos de trabajo que se desarrollan por proceso. Para comprender mejor repasemos estas diferencias en el siguiente cuadro: Proyecto

Proceso

Muere al finalizar

No muere, no termina

Objetivo particular, ejecutados por única vez Repetitivos, secuenciales, ordinarios

Revolucionarios (cambios importantes)

El tiempo no está acotado, existe para perdurar en el tiempo. Evolutivo (mejora continua)

Equipos variables

Equipos relativamente estables

Los recursos entran y salen en la medida que son requeridos

Los recursos están disponibles por más tiempo Todo está mayormente definido, menos riesgos

Tiempo determinado, acotado.

Mucha incertidumbre, más riesgos

Tabla 1.1: Proyectos vs. Procesos

3

Si pensamos en actividades que puedan llevarse a cabo como proyecto podemos mencionar: la construcción de un puente, el desarrollo e implementación de un determinado software, en ambos casos estamos refiriendo a actividades que tienen objetivo único y presupuesto y tiempo acotados. Por otra parte si queremos pensar en trabajos que naturalmente se realizan por proceso podemos mencionar: la fabricación en serie de un producto, un determinado modelo de auto por ejemplo, o la administración de bases de datos.

1.2.2 Administración de proyectos La administración de proyectos es el conjunto de actividades que deberá llevar adelante el Gerente del Proyecto para conseguir los objetivos planteados. La Administración de Proyectos es una disciplina de gestión que existe y se implementa desde tiempos milenarios, pero su consolidación como materia de estudio proviene principalmente de los países anglosajones. Es probablemente por esta razón por lo que el término "Project Management" se ha convertido en el modo en que nos referimos a esta disciplina aún traspasando las fronteras de la lengua inglesa. A esto se suma el hecho de que la institución más difundida a nivel mundial en esta materia es el Project Management Institute (PMI). El PMI es una institución sin fines de lucro que ha sido fundada en 1969 en EEUU por y para profesionales de dirección de proyectos. Desde su fundación hasta nuestros días su crecimiento ha sido tal que le ha permitido convertirse en la principal organización profesional sin fines de lucro en administración de proyectos. Actualmente cuenta con más de 200.000 miembros en más de 125 países. Entre sus principales objetivos podemos mencionar que brinda apoyo profesional a los Project Managers mediante:  Establecer y mantener actualizados los estándares de administración de proyectos.  Actualización permanente: Cursos, Seminarios y Conferencias.  Exposiciones y Foros.  Certificación.  Bibliografía y Publicaciones.

4

 Grupos de interés especial.  Bolsa de trabajo.  Reconocimiento del gerenciamiento de proyectos como una disciplina profesional.  Proveer contactos interdisciplinarios El estándar de procesos definidos por el PMI, el PMBOK (Project Management Body Of Knowledge) ha sido adoptado como norma ANSI y está siendo referenciado por la OSI. y adoptado por organizaciones profesionales reconocidas mundialmente, como el IEEE. La certificación profesional que el PMI otorga - PMP (Project Management Profesional) cada vez es más reconocida y demandada en la industria por empresas y profesionales como garantía de idoneidad del profesional a nivel mundial. El PMI define el “Project Management” como: “la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto, a efectos de satisfacer o exceder las necesidades y expectativas de los stakeholders del proyecto". A los efectos de esta Asignatura usaremos estos términos con el mismo significado: Gerenciamiento, Gestión o Administración de Proyectos. La Administración de Proyectos implica balancear y a menudo negociar:  demandas de recursos  requerimientos de stakeholders  necesidades y expectativas Habrás notado en este punto que se ha introducido un nuevo concepto, el de “stakeholder”. No traducimos este término por no encontrar una traducción que verdaderamente refleje lo que este término significa en todo su espectro: Un stakeholder es cualquier individuo u organización involucrado, afectado o con intereses en el proyecto.

1.2.3 Funciones de la dirección de proyectos. La dirección de proyectos se logra mediante la aplicación e integración de los procesos de dirección de proyectos de inicio, planificación, ejecución, seguimiento y control, y cierre. El director del proyecto es la persona responsable de alcanzar los 5

objetivos del proyecto. La dirección de un proyecto incluye:  Identificar los requisitos  Establecer unos objetivos claros y posibles de realizar  Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costos  Adaptar las especificaciones, los planes y el enfoque a las diversas inquietudes y expectativas de los diferentes interesados. Una buena forma de describir la tarea de un Project Manager es plantear que él se ocupa de “hacer que las cosas ocurran”. Nótese que no estamos hablando de hacer las cosas, sino, más bien de hacer que ocurran, vale decir que su visión será general y no particular o de detalle puesto que es él quien debe organizar y enlazar las partes. Otro aspecto de relevante importancia es el hecho de que el Administrador de Proyecto tiene la importante misión de cuidar y balancear la “triple restricción”. Llamamos triple restricción a las tres dimensiones básicas en torno de las cuales gira el proyecto: Alcance, Tiempo y Costo. (Ver Figura 1.1). Claramente una mejora en una de las tres dimensiones perjudica alguna de las otras, por lo que será función del Director de Proyecto tomar las decisiones apropiadas en función de las necesidades del proyecto y las expectativas de los stakeholders. ¡Un verdadero desafío! Aún así, a muchos nos gustan los desafíos y estamos dispuestos a afrontarlos. La figura 1.1 ha sido creada por la autora para mostrar la triple restricción a la vez que se destaca lo que el autor considera que es el “verdadero objetivo del proyecto”. Comúnmente definimos el objetivo del proyecto en términos de lo que debe lograrse a nivel de producto final. Sin embargo, a un Administrador de Proyectos no se le paga por el solo hecho de lograr las cosas, sino que debe lograrlas en un tiempo y con un costo determinado.

Figura 1.1 - La triple restricción y el “verdadero” objetivo del proyecto - Ing. Iris Gastañaga

6

Así llegamos al punto en que podemos decir que el objetivo final del proyecto será lograr el producto del proyecto en tiempo y presupuesto, y es particularmente este punto el que hace que la administración de proyectos requiera tanta atención. Un hecho a destacar es que la importancia de las funciones de dirección y gestión varía a lo largo de las fases del proyecto. Es evidente que la construcción de un objeto involucra más recursos (humanos, materiales y financieros) que su definición y diseño. Por tanto, el "Project Management" es más importante en las fases constructivas (ejecución de una instalación, fabricación de un producto, construcción de una obra) que en las fases creativas (diseño, estudio de soluciones o anteproyecto), y no sólo por la mayor dificultad que supone gestionar un mayor volumen de tareas o de recursos, sino por la implícita repercusión económica que conlleva cada una de las decisiones adoptadas. En las fases creativas, las labores de dirección y gestión se limitan fundamentalmente al entorno del equipo del proyecto o al del departamento de diseño, mientras que en las constructivas involucran materiales, maquinaria, operarios, proveedores, subcontratistas. Es decir, tanto las habilidades de dirección de proyectos como las técnicas de gestión tienen más aplicación y resultan más necesarias cuanto más avanzado se encuentre el desarrollo del proyecto (véase 1.2). Sin embargo, debe tenerse en cuenta que las modernas tendencias en gestión de proyectos proponen transferir un mayor esfuerzo a las fases de diseño conceptual o básico, con objeto de minimizar los errores de diseño (que pueden llegar a convertirse en costosos errores constructivos).

Figura 1.2: Nivel de recursos involucrados en el desarrollo de un proyecto

7

Así mismo, cada vez se da mayor importancia al desarrollo de trabajo en equipo y a la colaboración entre grupos multidisciplinarios, lo que a su vez genera que se ponga mayor énfasis en las habilidades de dirección y motivación de recursos humanos. Con el objeto de facilitar la gestión, los directores de proyectos o la organización pueden dividir los proyectos en fases, con los enlaces correspondientes a las operaciones de la organización ejecutante. El conjunto de estas fases se conoce como ciclo de vida del proyecto. Muchas organizaciones identifican un conjunto de ciclos de vida específicos para usarlos en todos sus proyectos, según su tipo “Las fases del proyecto son divisiones dentro del mismo proyecto, donde es necesario ejercer un control adicional para gestionar la conclusión de un entregable mayor. Las fases del proyecto suelen completarse de manera secuencial. Pero en determinadas situaciones de un proyecto pueden superponerse. Por su naturaleza de alto nivel, las fases del proyecto constituyen un elemento del ciclo de vida de un proyecto. Una fase del proyecto no es un grupo de procesos de dirección de proyectos.” (PMBoK, 4º Edición, PMI). Cuando hablamos de la construcción de un sistema, es fundamental entender la diferencia entre proyectos, medios que produce y producto obtenido mediante esos medios por el proyecto: • Productos: Son aquellos bienes o servicios que la organización fábrica o vende conforme señala su misión. Los productos generan ingresos y de esta manera se cumple el objetivo del proyecto. • Medios: Se requieren para producir productos. Pueden ser equipos, diseño de productos, hardware, software, redes de distribución, gestión de procesos o grupos organizados de personas. • Proyectos: Son iniciados por las organizaciones para producir, construir, mantener o renovar medios de producción. Son el vehículo, coherente con el alcance del trabajo y la organización del mismo, requerido para producir medios o elementos de producción.

1.3 Factores que restringen el éxito del proyecto Muchos pueden ser los factores que restringen el éxito de los proyectos. Para tratar este tema recurriremos al autor Steve Mc Connell, quien ha desarrollado una lista con los 36 errores clásicos que se cometen en los proyectos de sistemas. A esta lista, Mc Conell le llama “errores clásicos” y los clasifica en 4 categorías:

8

1.3.1 Errores relacionados con las Personas: 1 - Motivación débil 2 - Personal mediocre 3 - Empleados problemáticos incontrolados 4 - Hazañas 5 - Añadir más personal a un proyecto retrasado 6 - Oficinas repletas y ruidosas 7 - Fricciones entre los clientes y los desarrolladores 8 - Expectativas poco realistas 9 - Falta de un promotor efectivo del proyecto 10 - Falta de participación de los implicados 11 - Falta de participación del usuario 12 - Política, antes que desarrollo 13 - Ilusiones

1.3.2 Errores relacionados con el Proceso: 14 - Planificación excesivamente optimista. 15 - Gestión de riesgo insuficiente. 16 - Planificación insuficiente 17 - Abandono de la planificación bajo presión 18 - Fallos de los contratados 19 - Pérdida de tiempo en el inicio difuso 20 - Escatimar en las actividades iniciales 21 - Diseño inadecuado 22 - Escatimar en el control de calidad 23 - Control insuficiente de la directiva 24 - Convergencia prematura o excesivamente frecuente 25 - Omitir tareas necesarias en la estimación 26 - Planificar ponerse al día más adelante 27 - Programación a destajo.

1.3.3 Errores relacionados con el Producto: 28 - Exceso de requerimiento. 29 - Cambio de las prestaciones. 30 - Desarrolladores meticulosos. 31 - Tiras y aflojes en la negociación. 32 - Desarrollo orientado a la investigación.

9

1.3.4 Errores relacionados con la Tecnología: 33 - Síndrome de la panacea 34 - Sobreestimación de las ventajas del empleo de nuevas herramientas y métodos. 35 - Cambiar de herramientas a mitad del proyecto. 36 - Falta del control automático del código fuente.

1.4 Ciclo de vida de un proyecto Podemos plantear los trabajos del Proyecto desde dos miradas; la primera es el ciclo de vida de proyecto que se necesita hacer para hacer el trabajo y la segunda es el ciclo gestionar el proyecto. Los proyectos tienen comienzo, medio y fin. Este dato puede parecer evidente, pero si se trabaja en gestión de proyectos, el momento del ciclo vital en que se encuentra será de la mayor importancia, ya que influirá sobre lo que deberá hacer y sobre las opciones que se le presentarán. Para facilitar la gestión, los directores de proyectos o la organización pueden dividir los proyectos en fases, con los enlaces correspondientes a las operaciones de la organización ejecutante. El conjunto de estas fases se conoce como ciclo de vida del proyecto. Muchas organizaciones identifican un conjunto de ciclos de vida específico para usarlo en todos sus proyectos.

1.4.1 Fases de un Proyecto Ahora bien, es momento de pensar entonces, que etapas o fases corresponden a un proyecto. Si bien esto depende mucho del tipo de proceso y del tipo de proyecto que se está llevando adelante, podemos decir que todo proyecto tendrá al menos una Fase de Inicio, una o más Fases Intermedias y una Fase Final.

Figura 1.3: Fases del Proyecto - PMBoK PMI – 2004

10

La transición de una fase a otra dentro del ciclo de vida de un proyecto generalmente implica y, por lo general, está definida por alguna forma de transferencia técnica. Generalmente, los productos entregables de una fase se revisan para verificar si están completos, si son exactos y se aprueban antes de iniciar el trabajo de la siguiente fase. No obstante, no es inusual que una fase comience antes de la aprobación de los productos entregables de la fase previa, cuando los riesgos involucrados se consideran aceptables. Esta práctica de superponer fases, que normalmente se realiza de forma secuencial, es un ejemplo de la aplicación de la técnica de compresión del cronograma denominada ejecución rápida. No existe una única manera, que sea la mejor, para definir el ciclo de vida ideal de un proyecto. Algunas organizaciones han establecido políticas que estandarizan todos los proyectos con un ciclo de vida único, mientras que otras permiten al equipo de dirección del proyecto elegir el ciclo de vida más apropiado para el proyecto del equipo. Asimismo, las prácticas comunes de la industria a menudo conducen a usar un ciclo de vida preferido dentro de dicha industria. Los ciclos de vida del proyecto generalmente definen:  Qué trabajo técnico se debe realizar en cada fase (por ejemplo, ¿en qué fase se debe realizar el trabajo del arquitecto?).  Cuándo se deben generar los productos entregables en cada fase y cómo se revisa, verifica y valida cada producto entregable.  Quién está involucrado en cada fase (por ejemplo, la ingeniería concurrente requiere que los implementadores estén involucrados en las fases de requisitos y de diseño).  Cómo controlar y aprobar cada fase. Las descripciones del ciclo de vida del proyecto pueden ser muy generales o muy detalladas. Las descripciones muy detalladas de los ciclos de vida pueden incluir formularios, diagramas y listas de control para proporcionar estructura y control. La mayoría de los ciclos de vida de proyectos comparten determinadas características comunes:  En términos generales, las fases son secuenciales y, normalmente, están definidas por alguna forma de transferencia de información técnica o transferencia de componentes técnicos.  El nivel de costo y de personal es bajo al comienzo, alcanza su nivel máximo en las fases intermedias y cae rápidamente cuando el proyecto se aproxima a su conclusión. La Figura 1.4 ilustra este patrón.

11

 El nivel de incertidumbre es el más alto y, por lo tanto, el riesgo de no cumplir con los objetivos es más elevado al inicio del proyecto. La certeza de terminar con éxito aumenta gradualmente a medida que avanza el proyecto.  El poder que tienen los interesados en el proyecto para influir en las características finales del producto del proyecto y en el costo final del proyecto es más alto al comienzo y decrece gradualmente a medida que avanza el proyecto. La Figura 1.4 ilustra este hecho. Una de las principales causas de este fenómeno es que el costo de los cambios y de la corrección de errores generalmente aumenta a medida que avanza el proyecto.

Figura 1.4: Influencia de los Stakeholder a lo largo del tiempo - PMBoK PMI – 2004

Aun cuando muchos ciclos de vida de proyectos tienen nombres de fases similares y requieren productos entregables similares, muy pocos ciclos de vida son idénticos. Algunos tienen cuatro o cinco fases, pero otros pueden tener nueve o más. En una misma área de aplicación pueden darse variaciones significativas. El ciclo de vida del desarrollo de software de una organización puede tener una única fase de diseño, mientras que otro puede tener fases separadas para el diseño arquitectónico y el detallado. Los subproyectos también pueden tener distintos ciclos de vida de proyectos. Por ejemplo, una empresa de arquitectura contratada para diseñar un nuevo edificio de oficinas participa primero en la fase de definición del propietario, mientras hace el diseño, y luego en la fase de implementación del propietario, mientras da soporte al esfuerzo de construcción. El proyecto de diseño del arquitecto, sin embargo, tendrá su propia serie de fases, desde el desarrollo conceptual, pasando por la definición e implementación, hasta llegar a la conclusión. El arquitecto puede,

12

inclusive, tratar el diseño de los edificios y el soporte a la construcción como proyectos separados, cada uno con su propio conjunto de fases.

1.4.2 Áreas de Conocimiento de la Gestión de Proyectos Una vez se ha procedido a delimitar los conceptos de dirección y gestión de proyectos, resulta interesante establecer qué funciones y aspectos cubre esta función. Uno de los enfoques más sistemático y estructurado sobre el “Project Management” es el denominado “Cuerpo de conocimientos” que ha elaborado el PMI1. Según éste, la dirección y gestión de proyectos abarca nueve grandes áreas, que seguidamente se enumeran:

Figura 1.5: Áreas de Conocimiento del Project Management - PMBoK PMI – 2004

A efectos de su estudio, el PMI define nueve Áreas de Conocimiento que un Project Manager debe dominar para convertirse en un buen Administrador de Proyectos que a continuación se explican:  Integración del proyecto: Estudia las necesidades de coordinación entre los diferentes elementos del proyecto. Para ello resulta fundamental la planificación global del proyecto, el seguimiento de su desarrollo, y el control de los cambios, a lo largo del diseño, planificación y ejecución del proyecto. Es decir, comprende todos los procesos necesarios para asegurar que los distintos elementos del proyecto van a ser coordinados adecuadamente.  Alcance del proyecto: Tiene por objetivo asegurar que todos los trabajos necesarios para terminar el proyecto con éxito sean previstos y considerados. Debe analizarse el ciclo de vida completo del proyecto.

1

PMBoK: Project Management Body of Knowledge (PMI, 2004)

13

Comprende los procesos de planificación, definición, verificación y control de cambios en el alcance.  Tiempos del proyecto: Trata de conseguir que el proyecto termine en el plazo establecido. Incluye la definición de las actividades, su ordenación, la estimación de la duración de las actividades, el desarrollo de las mismas y el control del cumplimiento del programa del proyecto.  Costos del proyecto: Tiene como objetivo asegurar que el proyecto se concluya dentro del presupuesto aprobado. Necesita la planificación de recursos, estimación de costos, cálculo de costos y control de los mismos.  Calidad del proyecto: Incluye los procesos necesarios para asegurar que el proyecto cubrirá las necesidades y especificaciones para las que fue desarrollado. Consta de planificación de la calidad, aseguramiento de la calidad y control de la misma.  Recursos Humanos del proyecto: Su objetivo es optimizar el aprovechamiento de la labor de las personas comprometidas en el proyecto. Requiere estudiar la organización de dichas personas, su selección y contratación, y la dirección del funcionamiento del equipo.  Comunicaciones en el proyecto: Su objetivo es facilitar la adecuada generación, recepción, difusión, almacenamiento y archivo último de la información del proyecto. Requiere la planificación de comunicaciones, la distribución de información, la elaboración de informes, así como la documentación necesaria para el cierre administrativo del proyecto.  Riesgos del proyecto: Tiene como objetivo identificar los factores de riesgo del proyecto, analizar sus posibles repercusiones, y preparar la respuesta ante los mismos. Requiere definir las causas de riesgo, cuantificar su impacto, desarrollar las respuestas ante los riesgos existentes, y controlar la implementación de las respuestas previstas.  Adquisiciones en el proyecto: Estudia los procesos necesarios para adquirir bienes y servicios fuera de la organización donde se desarrolla el proyecto. Requiere la planificación de los aprovisionamientos, la selección de los proveedores, la elaboración y tramitación de las ofertas y contratos, y el cierre de los mismos. Estudia las compras, los proveedores y las contrataciones. Basta con enumerar estas grandes áreas, para comprender el enorme campo de conocimientos que abarca la dirección y gestión de proyectos.

14

1.5 Influencias organizacionales. La realización de una gran mayoría de proyectos requiere de la participación de diferentes actores, lo que se traduce en la necesidad de crear una organización, que además deberá ser orientada a satisfacer los objetivos del proyecto. En la medida que los participantes adquieren experiencia en una tipología de proyectos, y en especial la adquieren sus responsables, las formas de organización que adopta el grupo vendrán dadas en gran parte por estas experiencias de éxitos y fracasos anteriores y, en función de ellas se ordenarán y asignarán los recursos y tareas, intentando reproducir las prácticas satisfactorias y descartando las negativas. Cuando un proyecto se inicia, se generan ciertas expectativas, referidas no sólo a sus efectos en cuanto al logro de los objetivos técnicos, sino que también se consideran los resultados que su realización tendrá sobre los participantes, las organizaciones y el medio ambiente. Cada una de las personas que trabaja y se dedica total o parcialmente al desarrollo de un proyecto espera que de su trabajo individual o colectivo se obtengan beneficios que cubran al menos parte de sus necesidades y aspiraciones. Del mismo modo que las personas, las empresas que participan en un proyecto también esperan resultados que se traduzcan en beneficios, que no siempre serán directamente de carácter económico. Como veremos, para la realización de un proyecto concurren distintos elementos, factores y entidades que generan las fuerzas que impulsan las actividades traduciéndose en resultados que tienen una cierta aleatoriedad. Cualquier proyectista tiene claro que los resultados no se obtienen de la mera aplicación de una ecuación o una fórmula que garantice cierto nivel de resultados, ya que son muchas las variables exógenas e incontrolables que afectan el transcurso del proyecto en cualquier momento a través de sus fases.

1.5.1 Los Proyectos y la estructura organizacional Describiremos con el nombre de estructura organizacional a la distribución y combinación de las distintas actividades de una empresa u organismo, con vistas a asegurar el desarrollo de los objetivos que le han sido atribuidos y tratando de garantizar una dirección y gestión eficaces. Así mismo, entendemos que una organización es un sistema sociotécnico, en el cual, como vemos en el gráfico siguiente, intervienen factores sociales y técnicos que, correctamente balanceados, optimizan los resultados.

15

Figura 1.6: La Organización como sistema socio – técnico

La definición de la estructura organizacional supone decidir en qué unidades y órganos principales conviene descomponer la institución a fin de permitir la consecución de las misiones y objetivos establecidos sin que, al mismo tiempo, se caiga en un sobredimensionamiento de recursos. Cada órgano o unidad de la estructura se dotará de un conjunto de medios humanos y materiales destinados a cumplir una misión permanente, bien definida, con fronteras razonablemente claras y de modo que un jefe pueda tomar toda la responsabilidad por él. Normalmente, el conjunto de los órganos que forman la estructura de una empresa o entidad se representa gráficamente mediante organigramas, que permiten tener una visión clara de los órganos existentes y de las relaciones jerárquicas que existen entre ellos. Estos conceptos son familiares a cualquier profesional de la organización por lo que su comprensión no presenta mayor dificultad. Sin embargo, estas definiciones nos plantean alguna dificultad cuando debemos referirnos a “proyectos”. Si pensamos que una unidad se caracteriza por tener una misión permanente con medios humanos adecuados para cumplir esa misión y, por tanto, dotados también de una fuerte estabilidad estaremos en una simple contradicción con la esencia temporal de los proyectos y su característica de estructuras de recursos cambiantes. Por todo ello, es conveniente estudiar las implicaciones de los proyectos sobre la estructura organizacional de la empresa y hasta qué punto un determinado tipo de estructura facilita o dificulta la gestión de los proyectos. Desde el punto de vista de la gestión de proyectos, podemos hacer una clara distinción en diferentes tipos de organizaciones: 16

▪ Organizaciones funcionales, en las que el personal está estructurado atendiendo al principio de la especialización, es decir según sus conocimientos en unidades funcionales que actúan de forma independiente del resto, con un superior al que deben responder e informar. ▪ Organizaciones proyectizadas, donde la empresa se estructura en grupos multidisciplinares que tienen plena responsabilidad sobre un proyecto concreto. Estos grupos son dirigidos por un director de proyecto y su morfología cambia en función de la cantidad y tipología de proyectos. ▪ Organizaciones matriciales. Representan un híbrido entre las dos estructuras anteriores ya que ambas se superponen para dar lugar a una tercera en la que cada individuo depende de dos superiores: el director del proyecto en el que participa y el director del departamento (área funcional) en el que se encuentra. Si la dependencia del primero es mayor se habla de estructura matricial fuerte y en caso contrario de estructura matricial débil.

1.5.1.1 Organización funcional, vertical o piramidal Es la organización más extendida en las empresas industriales y de servicios. Su organigrama se compone de unidades funcionales dependientes de la alta dirección y compuestas de divisiones o secciones que se encargan de las actividades concretas que les son asignadas. Cuando se enfrentan a un proyecto, el trabajo se reparte entre cada una de dichas unidades que constituyen grupos autónomos con escasa comunicación e interacción con el resto de áreas correspondiendo la dirección del proyecto a aquel departamento que en cada fase posea una mayor responsabilidad. Este tipo de organizaciones funciona con eficacia en los casos en los que haya que realizar funciones específicas y de ellas, sólo una es la principal, por lo que no existe mezcla de muchas disciplinas. Sin embargo serán poco adecuadas para la ejecución de proyectos, por tratarse éstos de actividades interdisciplinares.

17

Ventajas √ Relaciones de autoridad y reporte más claras √ Aprovecha mejor la especialización (genera background especializado) √ Grupos de personas homogéneos √ Fuerte tendencia a la excelencia técnica √ Mejor aprovechamiento de los medios humanos. √ Requiere menor cantidad de personal técnico. √ Ofrece al personal una mayor variedad de trabajo, al involucrarse en proyectos diferentes. √ La agrupación de especialistas permite compartir y transferir experiencias.

Desventajas √ Fronteras disciplinarias √ Dificultad para trabajar influencia/satisfacción cliente √ Oportunidades de desarrollo limitadas para PM √ El PM depende de su influencia personal √ Barreras por procesos jerárquicos de decisión √ Barreras por procesos jerárquicos de comunicación √ “fuerte foco en el entregable, antes que en el proyecto” √ Dilución de responsabilidades entre los departamentos. √ Problemas de coordinación. √ Se presta mayor atención a los problemas técnicos en detrimento de la coordinación y planificación √ Respuesta lenta. √ Los objetivos del departamento se anteponen a los globales del proyecto

Tabla 1.2: Ventajas y Desventajas de la Organización Funcional

Organización funcional

Figura 1.7: La Organización Funcional y la Gestión de Proyectos

18

1.5.1.2 Organización proyectizada Es el tipo de organización más reciente y se encuentra más desarrollado en el sector servicios que en el industrial. En él no existen las áreas funcionales tradicionales sino los denominados equipos de proyecto encargados de la realización de un proyecto concreto. Cada equipo lleva adelante un proyecto por vez, excepto en circunstancias especiales en que pueden desarrollar varios proyectos a la vez siempre que se precisen técnicas similares y se encuentren en distintas etapas de su desarrollo, para evitar los desequilibrios en la asignación de carga de trabajo. En proyectos de gran envergadura es frecuente la agrupación del personal por disciplinas o especialidades con técnicos de proyecto responsables de cada una de ellas. Ventajas

Desventajas

√ El rol del PM es fuerte √ Personal administrativo asignado full time √ Espacios de trabajo comunes (war room) √ Responsabilidades claras √ Foco en el negocio y el cliente √ Mejor relación con el cliente √ Mayor capacidad de decisión √ Control directo sobre todas las actividades del proyecto. √ Reducción de los problemas de coordinación. √ Responsabilidades definidas y centralizadas en el director del proyecto. √ El director de proyecto dispone de información actualizada en todo momento.

√ Menor “identidad profesional” √ Liderazgo ejercido por no -técnicosespecializados √ Menor autoridad de los gerentes funcionales √ Foco en trabajos administrativos, antes que en los técnicos √ “Foco en los procesos, antes que en entregables” √ Aumento de costes debido a la duplicidad de funciones. √ Necesidad de personal adicional. √ Los especialistas asignados a un proyecto muy largo pueden quedar desfasados tecnológicamente. √ Es difícil reemplazar un miembro del equipo ya que posee conocimientos muy específicos.

Tabla 1.3: Ventajas y Desventajas de la Organización Proyectizada

19

Organización por proyectos

Figura 1.8: La Organización Proyectizada y la Gestión de Proyectos

1.5.1.3 Organizaciones matriciales. Las dos formas de organización anteriores constituyen dos extremos entre los que se establece un abanico de situaciones intermedias. En ellas conviven dos grandes áreas: una estructurada en equipos de proyecto y otra en unidades funcionales. El personal técnico que integra estas dos áreas es el mismo pero la dirección no lo es. Una característica fundamental de este tipo de organizaciones es que se viola uno de los principios de gestión y organización considerado inmutable desde los tiempos históricos de Taylor y Fayol: el principio de unidad de mando, según el cual «todo subordinado debe responder a uno y solo un jefe». En este caso, cada individuo responde dos jefes: el gerente funcional y el gerente de proyecto (a quien informar y de quien recibir instrucciones), lo cual podría desembocar en una estructura conflictiva. La manera de resolver este inconveniente es definir sin ambigüedad el campo y la 20

responsabilidad que corresponden a cada área. Por ejemplo: el gerente funcional toma las definiciones de cómo se hacen las cosas aquí, mientras el Gerente de Proyecto toma las definiciones de Que se hace hoy para el proyecto. Habitualmente el director de cada unidad funcional asigna el personal a cada proyecto y controla la calidad técnica del trabajo efectuado por sus subordinados, mientras que el director del proyecto como máximo responsable del mismo fija el contenido, alcance y calidad global y además se encarga de realizar la planificación, programación y presupuestos. Elementos de vital importancia para el buen funcionamiento del proyecto son los coordinadores de cada unidad funcional asignados a cada proyecto que son los interlocutores habituales de los directores de proyecto. Entre sus funciones está la de establecer los procedimientos técnicos, programaciones y presupuestos definitivos en cada una de sus áreas. Ahora bien, ante un conflicto de órdenes, sería lógico preguntarse: ¿a quién responderá el subordinado? ¿Al Gerente Funcional o al Gerente de Proyecto? Para responder esta pregunta podemos hacer nuevas reflexiones y cuestionamientos: ¿quién define su escala en la organización?, ¿quién decide los permisos y las vacaciones? ¿Quién seguirá siendo su jefe cuando el proyecto finalice? En este punto podemos imaginar la respuesta: es el Gerente Funcional quien tiene más poder (al menos formal) sobre el individuo. Vemos así que el gran problema de este tipo de estructuras para la gestión de proyectos es la falta de autoridad directa del Gerente del proyecto que debe suplirla con el ascendiente que le proporcionan sus cualidades de liderazgo, basado éste en su experiencia, habilidades personales de motivación, persuasión y negociación, amplitud de visión, entre otros.

21

Ventajas √ El project manager mantiene control ( a través de los gerentes de línea) sobre todos los recursos, incluyendo los costos y el personal √ Pueden establecerse políticas y procedimientos específicos para cada proyecto √ Respuesta rápida ante cambios, conflictos y necesidades de cada proyecto √ El costo de las personas es menor al ser compartida en diferentes proyectos √ Cada persona tiene un puesto cuando el proyecto termina √ Mejor balance entre tiempos, costos y resultados √ Autoridad y responsabilidad están compartidas √ Separación entre la dirección técnica y la gestión administrativa del proyecto. √ Permite disponer de una reserva de especialistas en los grupos funcionales. √ La existencia de una comunicación fluida posibilita respuestas rápidas tanto a los deseos del cliente como a las necesidades de la organización. √ Evita que el personal se quede desfasado en su campo a la vez que amplía su conocimiento de otros campos.

Desventajas √ Flujo multidimensional de trabajo e información √ Doble dependencia √ Cambio continuo de prioridades √ Dificultad inicial para establecer políticas y procedimientos √ Gerentes de línea pueden tener sesgos hacia sus propios objetivos √ Las personas desarrollan roles con mayor grado de ambigüedad respecto a la organización funcional √ Requiere un nivel superior de dirección que arbitre en los litigios que pudieran surgir entre las dos fuentes de autoridad. √ Necesita un sistema de información y comunicaciones eficaz para evitar que se adopten las soluciones de aquel jefe que tenga un mayor peso en la organización. √ Hay que equilibrar los objetivos de coste y plazo (director proyecto) con los de calidad técnica (director funcional).

Tabla 1.4: Ventajas y Desventajas de la Organización Matricial

Si bien este tipo de organización “funciona” como matriz, en la práctica se presenta con el típico organigrama. La importancia del director de proyecto en la toma de decisiones dentro de estas organizaciones es muy variable ya que puede ser un simple asesor de la dirección general, puede ser un coordinador reservando el poder de decisión al director funcional (estructura matricial débil) o tener el control y la capacidad de decisión sirviéndose del director funcional para asesorarse en las cuestiones estrictamente técnicas (estructura matricial fuerte).

22

Así podemos definir 3 tipos o grados en la organización matricial: • Fuerte • Balanceada • Débil

Organización matriz fuerte

Figura 1.9: La Organización Matricial Fuerte y la Gestión de Proyectos

23

Organización matricial débil

Figura 1.10: La Organización Matricial Débil y la Gestión de Proyectos

Organización matriz balanceada

Figura 1.11: La Organización Matricial Balanceada y la Gestión de Proyectos

24

Tabla 1.5: Características de las Organizaciones según su tipo según PMI

No hay estructuras organizacionales buenas o malas; sino organizaciones apropiadas o inapropiadas para cada proyecto.

1.5.2 La gestión del proyecto y la figura del director de proyecto. La principal responsabilidad del director del proyecto, está en gestionar el equipo y su trabajo es entregar los resultados prometidos. Suya es la responsabilidad de liderazgo para crear el clima adecuado. La importancia de la figura del director del proyecto queda claramente expresada en un párrafo de un informe del Departamento de Defensa de los EEUU sobre el proyecto STARS de investigación sobre la reutilización de software que dice: "El director del proyecto juega el papel más importante en la Ingeniería del Software y su soporte. La diferencia entre el éxito o el fracaso -entre un proyecto que se desarrolla en fecha y en presupuesto, o uno retrasado y sin control de costos- es, a menudo, una función de la eficacia de ese director". Las funciones principales de un director de proyectos son: 1. Planificar el trabajo que debe realizarse para alcanzar los objetivos 25

definidos. 2. Organizar el equipo de trabajo que realizará el proyecto. 3. Implantarlo asignando trabajo al personal. 4. Controlar el progreso. 5. Liderar el equipo de personas.

1.6 Procesos de la gestión de proyectos. 1.6.1 El Problema de la Construcción de Software. Hasta aquí hemos estado hablando de la disciplina de gestión de proyectos, vamos a focalizar ahora en la particularidad del desarrollo de proyectos de software. La construcción de software requiere de dos aspectos de fundamental importancia, por un lado debe seguirse un determinado “proceso”, implementando un conjunto de actividades prediseñadas y con resultados definidos, y por otro lado, se lleva adelante un “proyecto” que pone todos estos procesos en un marco de restricciones de tiempo y costo con vistas a la creación de un producto nuevo y singular. •El Proceso dice “que” y “como” •El Proyecto dice “quien” y “cuando”

1.6.2 Proceso de desarrollo de software El proceso de construir un producto de software es a la vez una actividad de resolución de problemas. El proceso de desarrollo de software es el conjunto de actividades organizadas que permite la transformación de una necesidad (problema) en un software (solución automatizada) que satisface esa necesidad. La solución de un problema mediante Ingeniería de Software es una actividad de modelización que comienza con el desarrollo de modelos conceptuales (no formales) y los convierte en modelos formales, que son los productos implementados. Estas dos actividades de modelización trabajan a niveles distintos: el nivel del problema o necesidad (nivel conceptual o de dominio de aplicación), y el nivel de la solución implementada sobre computadora (o nivel formal). Cuando hablamos de modelo conceptual estamos trabando al nivel del Dominio del problema, es decir el nivel en el cual se plantea el punto de vista de quien tiene el problema o necesidad. Cuando mencionamos el 26

nivel de la solución estamos ubicados en la perspectiva de la implementación de ese mismo problema en la computadora.

Figura 1.12: Modelo de Proceso de desarrollo de Software

Un modelo muy interesante es el que presenta Natalia Juristo Juzgado:

Figura 1.13: Proceso esencial de construcción de software (Fuente: Proceso Software, Natalia Juristo Juzgado, UPM, 2001)

Si analizamos la figura 1.13 podremos notar algunos aspectos importantes: con el modelo conceptual se puede determinar la validez de la solución: ¿representa el modelo lo que implica la necesidad del usuario?, mientras tanto el modelo formal debe ser analizado desde el punto de vista de la corrección: ¿funciona correctamente o según lo esperado? Planteada la construcción de software como una resolución de problemas, debe existir un proceso de resolución que se corresponda con el proceso básico de resolución de problemas expuesto en el apartado anterior.

27

En primer lugar acordaremos una definición de PROCESO: Un proceso define un Flujo de Actividades, las Actividades en sí mismas, los Roles que realizan dichas actividades y los Artefactos (in,out) que manipulan dichos Roles en la realización de las actividades para producir un resultado con agregado de valor. En términos generales, al primer paso, o definición del qué, se le denomina genéricamente Especificación de Requisitos y Análisis. A la decisión de cómo hacerlo se la conoce, en Ingeniería de Software, como Diseño del Sistema. A la realización de ese cómo se le llama Codificación. Posteriormente, a la verificación de la corrección del software se le denomina genéricamente Pruebas. Y, finalmente, hablaremos de las actividades necesarias para que el sistema entre “en producción” y pueda ser utilizado, estamos hablando de la Instalación. Además, cuando las soluciones a los problemas no son puntuales, sino que permanecen en el tiempo, al proceso de resolución debe añadírsele una última etapa de Mantenimiento.

1.6.3 El Proceso Software y el Ciclo de Vida. Se ha dicho que el problema planteado es la construcción de software, y que para resolver dicho problema se lleva a cabo un proceso de resolución, como cuando se trata cualquier otro problema. A dicho proceso de resolución se le ha dado el nombre de Proceso Software. Ahora bien, si el software obtenido tras el proceso es visto como el producto que sale del proceso, puede considerarse que cierta materia entra al proceso y se transforma a lo largo del mismo hasta obtener el producto deseado. Dicho de otro modo, el proceso software puede verse como una cadena de tareas. Estas cadenas estructuran la transformación que van sufriendo las entidades al pasar a través de una secuencia de acciones que forman cada actividad del proceso. Las cadenas de tareas son planes idealizados de qué acciones deben realizarse y en qué orden para producir qué artefactos e involucrando que roles. Con esta perspectiva, se pueden establecer los estados por los que va pasando el producto en el proceso: La entrada al proceso es una necesidad que, una vez estudiada, se convierte en una especificación de requisitos que, posteriormente, se transforma en un diseño del sistema, para pasar más adelante a ser un código y, finalmente, un sistema software completo e integrado. Este enfoque orientado al producto, focalizado en la transformación del producto, en lugar de en el proceso 28

que lo transforma, es lo que se llama Ciclo de Vida. Es decir, el ciclo que el producto software sufre a lo largo de su vida, desde que nace (o se detecta la necesidad) hasta que muere (o se retira el sistema). Finalmente, todo este proceso es implementado para cada producto en particular por medio de un proyecto, que requiere por ende una coordinación particular: “el gerenciamiento del proyecto” La Figura 2.5 muestra las relaciones entre Proceso, Ciclo de Vida y Gerenciamiento de Proyecto.

Figura 1.14: Relación Proceso/Ciclo de Vida/Proyecto

1.5.1 Los procesos del Gerenciamiento de Proyectos. Así como existe un conjunto de procesos que deben ejecutarse para construir el producto del proyecto, siendo la gestión del proyecto una disciplina hoy madura, también existe un conjunto de procesos que deben seguirse para aplicarla correctamente. Estos procesos corresponden a las diferentes áreas de conocimiento y pueden organizarse en 5 grupos fundamentales: • Iniciación • Planeamiento 29

• Ejecución • Control • Cierre

Figura 1.15: Grupos de Procesos del Project Management - PMBoK PMI - 2004

Nótese que hemos mencionado 5 “grupos” de procesos, lo cual no significa que solo sea 5 procesos, sino muchos más agrupados en estos 5 grupos. También es importante destacar que estos grupos de procesos se solapan, es decir que no se llevan adelante en forma secuencial como sucede normalmente con las etapas o Fases.

30

Módulo 2 Dimensiones Principales de la Gestion de Proyectos.

Unidad 2: Gestión del alcance del proyecto 2.1 Iniciación La iniciación es un proceso que se lleva adelante en los proyectos a efectos de lograr su lanzamiento temprano y efectivo. La mayor parte del tiempo que se pierde en los proyectos se pierde por el “síndrome de inicio difuso”. Nos referimos al tiempo que transcurre en los inicios del proyecto cuando los objetivos aún no son claros, el equipo no está formalmente consolidado y es más, en algunos casos no se ha definido quien será el líder del proyecto. La situación anteriormente descripta no es poco frecuente y debemos pensar que todo el tiempo que perdemos en el inicio es tiempo que nos va a faltar al final. Por todo ello es importante que podamos “empujar” sanamente el inicio del proyecto con medidas y definiciones muy claras. Nos proponemos: 1. Nombrar un PM formal y tempranamente. 2. Generar un Documento de Lanzamiento 3. Realizar la Reunión de Lanzamiento. Discutamos como lograr estos objetivos: 1. Nombrar un PM formal y tempranamente. Con el término PM referimos al Project Manager o Administrador del proyecto. Este deberá estar nombrado tempranamente. En muchas organizaciones suele ser frecuente que el PM se nombre cuando la mayoría de las definiciones han sido tomadas, el presupuesto ha sido cerrado y, frecuentemente los planes están definidos. Pedir al PM que se

1

responsabilice por todo ello sin haber sido parte de las definiciones y, más aún, sin conocer el verdadero espíritu del proyecto puede ser poco aceptable. Una situación como esta anticipa problemas y provoca pérdidas de tiempo. Por lo expuesto es natural la necesidad de lograr su nombramiento en forma temprana, pero no solo esto hemos planteado. También decimos que deseamos hacerlo formalmente. Con formalmente queremos decir por escrito y comunicado. 2. Generar un Documento de Lanzamiento El documento que cumple con este requerimiento es conocido normalmente como: “Project Charter”. Un Project Charter plantea el compromiso de la gerencia con el desarrollo del proyecto dando las pautas iniciales, lanzando el proyecto formalmente y nombrando al PM. Plantea como mínimo:     

los estímulos del proyecto. descripción del producto o servicio nombramiento del PM datos de clientes, reportes, restricciones equipo inicial de trabajo.

Todo esto emitido por autoridad de la organización y con la información de la que se disponga al momento de lanzar, es usual que refiera a otros documentos tales como el contrato, por ejemplo. 3. Realizar la Reunión de Lanzamiento. La Reunión de Lanzamiento, también conocida como kick off meeting, tiene por objeto materializar el compromiso de la dirección, el lanzamiento formal, el compromiso de las partes involucradas, con un hecho muy concreto que posibilite además el contacto y la llegada del mensaje inicial que se quiera dar. Permite además dar ánimo al equipo y transmitir las expectativas del proyecto.

2.2 Planificación del alcance Para poder avanzar con la Planificación del Alcance, se hará necesario que revisemos el concepto de Alcance:

2

El Alcance del Proyecto Seguramente tú usas el concepto “Alcance” en diferentes circunstancias y con diferentes significado. Vamos a revisar ahora el sentido en el que usaremos el concepto Alcance en esta materia. En el ámbito de los Sistemas, es usual utilizar el concepto de alcance con el significado de - conjunto de funcionalidades que un sistema debe cubrir Por ejemplo: el sistema será capaz de: registrar los datos de la compra, permitir la consulta de stock, entre otros. El significado descripto para la palabra Alcance en el párrafo anterior es correcto, aún cuando no es el sentido que le daremos en el ámbito de los proyectos. El ejemplo anterior describe el alcance del “producto de proyecto”, en este caso el sistema de software. En el ámbito de la gestión de proyectos debemos definir “alcance” desde un significado más acorde a las necesidades de la gestión. Acudiremos para ello a la definición que nos da el PMI: ALCANCE: son todos los trabajos, y solo los trabajos necesarios para completar el producto del proyecto. Esta definición se vuelve importante en la medida que nos permite una mirada desde los trabajos necesarios y no desde las prestaciones ofrecidas por el producto y esta será la base para la planificación del proyecto. Mientras el grado de cumplimiento del Alcance del producto se mide contra las especificaciones, el grado de cumplimiento de Alcance del Proyecto se mide contra el Plan.

La Declaración del Alcance Un Plan General del proyecto involucra actividades de planeación desde cada una de las áreas de conocimiento de la gestión del proyecto. El primer trabajo a realizar a la hora de efectuar el Plan del proyecto será por ende definir y acotar adecuadamente el Alcance. A efectos de Definir el Alcance, será necesario generar la “Declaración del Alcance”, estamos hablando de un documento que permita declarar con claridad lo que Si está incluido en el proyecto dejando muy claro lo que No incluye. Una buena declaración del Alcance (conocida también por su nombre en inglés, Scope Statement), se escribe en términos de sus Entregables, es decir los productos o subproductos que se generan a lo largo del proyecto.

3

Una buena definición de entregable debiera incluir los criterios de aceptación, es decir la descripción de las condiciones que deberá cumplir la entrega a efectos de ser aceptada por el stakeholder correspondiente. En este punto nos daremos cuenta que otro ítem importante será la definición del stakeholder clave para cada uno de los entregables. Finalmente suele agregarse otro punto importante a esta declaración: Los supuestos y restricciones. Entendemos por restricciones todos los factores que limitan las decisiones del equipo del proyecto, por ejemplo: “no se podrá contratar proveedores que no tengan certificación oficial de sus procesos”… este tipo de definiciones fija las condiciones que deberán tomarse en cuenta a la hora de planificar y ejecutar el proyecto. Los supuestos son todos los criterios y condiciones que se asumen como ciertos y válidos a la hora de ejecutar el proyecto. Dado que el proyecto se lleva adelante en un ambiente de permanente incertidumbre, es necesario fijar ciertas condiciones de estabilidad que permitan tomar decisiones y hacer las respectivas previsiones. Un ejemplo de supuesto sería: “se asume que, al momento de la instalación del sistema, el cliente habrá preparado el entorno de hardware y software según lo acordado en el punto xx del contrato”. “Cuando hay una pobre definición de alcance, los costos del proyecto serán probablemente más altos, debido a los cambios inevitables, interrumpiendo el ritmo del proyecto, aumentando los cronogramas y bajando la moral y productividad del equipo” (PMI - PMBOK)

La Estructura de Descomposición del Trabajo Llegados al punto en que el Alcance del Proyecto está definido en términos de sus entregables, es momento de comenzar a pensar en los trabajos que será necesario llevar adelante para cumplimentar estos entregables. Para lograr este objetivo se crea una Estructura de Descomposición del Trabajo (EDT) también conocida como WBS (por su sigla del inglés Work Breakdown Structure). Una EDT es un agrupamiento de elementos del proyecto, orientado a entregables, que organiza y define el alcance total del proyecto. Se trata de una estructura gráfica con forma de árbol invertido en la que se detalla todos los trabajos que componen cada entregable. Es importante entender que al crear una EDT no estamos creando una estructura de descomposición del producto en sus partes constitutivas,

4

sino que a cada parte la descomponemos en los trabajos necesarios para conseguirla. El objetivo de crear una EDT es poder visualizar “todos los trabajos” sin olvidar ninguno. En opinión de la autora la mayoría de los problemas de tiempo y presupuesto en los proyectos tienen su origen en una pobre definición del alcance, es decir en el hecho de haber detectado menos trabajo que el que luego efectivamente será llevado a cabo si se quiere completar los productos esperados. Una EDT puede tener diferente cantidad de niveles, según la magnitud y complejidad del proyecto y será la base de la planificación y la estimación de costos. Una EDT se usará también como herramienta de seguimiento del alcance del proyecto y será el elemento de enlace con los diferentes aspectos del proyecto así como también la base de toda negociación a futuro. Dependiendo del proyecto podrá opcionalmente tener un primer nivel que descompone en subproyectos o en fases para proyectos de gran envergadura. Lo esencial es que de un modo u otro se vea en los niveles superiores los entregables y en los inferiores los paquetes de trabajo. Visualmente una EDT se ve como sigue:

WORK BREAKDOWN STRUCTURE

Figura 2.1 - La Estructura de descomposición del Trabajo

5

Para la creación de una EDT se puede seguir los pasos que se detallan a continuación: 1. Identificar los principales entregables del proyecto 2. Crear un elemento por cada entregable 3. Decidir si se puede generar estimaciones de costo y duración adecuadas para este nivel de desagregación. 4. Identificar para cada elemento sus elementos constitutivos. 5. Verificar la descomposición repitiendo paso 3. 6. Responder al interrogante: ¿los ítems de menor nivel son necesarios para cumplir el ítem descompuesto? 7. Responder el interrogante ¿alcanza con los ítems de menor nivel para lograr el de nivel superior? 8. Repetir pasó 3 a 7 hasta lograr una descomposición satisfactoria. Habiendo completado la creación de la EDT tendremos una estructura jerárquica compuesta de: entregables, sub-entregables si son necesarios, y finalmente paquetes de trabajo. No debe olvidarse que siempre en niveles superiores hay entregables y en el último nivel hay paquetes de trabajo. Algunas de las ventajas de crear una EDT son las que se detallan a continuación: • Permite una representación visual del alcance total del proyecto • Permite crear una base de entendimiento entre los stakeholder del proyecto • Posibilita identificar todas las tareas a realizar • Facilita la estimación sobre la duración de las tareas • Es una base para la elaboración del presupuesto general del proyecto • Es una base para una contabilidad general del proyecto • Ayuda a elaborar el programa de trabajo • Permite contrastar rendimiento contra estimaciones • Facilita la asignación de responsabilidades • Da una idea de magnitud y complejidad del proyecto Una buena EDT puede acompañarse con un diccionario que describa cada paquete de trabajo incluyendo las estimaciones de esfuerzo, tiempo y costo.

2.3 Verificación del alcance La Verificación del Alcance es una actividad de vital importancia para asegurar el avance del proyecto y minimizar los conflictos por las entregas. Vamos inicialmente a definir el concepto de Verificación del alcance

6

Verificacion del alcance Es el proceso de obtener la aceptación formal del alcance completado del proyecto por los stakeholders. Resulta importante notar que estamos hablando de alcance “completado”, es decir que no nos referimos a aceptar que este es el alcance sino, más bien, a aceptar que estos son los productos entregables comprometidos. Otra importante observación es que la aceptación debe hacerse por el stakeholder correspondiente, en este punto seguramente nos preguntamos: ¿cuál es el stakeholder correspondiente? La respuesta a esta pregunta la tenemos en lo que planteamos al hablar de la Definición del Alcance cuando dijimos que debía haber criterios de aceptación y stakeholder clave, (puede rever el punto 2.2.2 La declaración del Alcance).

2.4 Control de cambio del alcance Es el proceso de asegurar que los cambios ocurren de manera ordenada y beneficiosa. Prestemos atención a que no se dice que los cambios no ocurran, sino que estén bajo control. El proyecto es naturalmente cambio, de modo que es lógico que los cambios ocurran. Una buena administración se ocupa de gestionarlos. Causas de cambios en el alcance  Un suceso externo  Un error u omisión al definir el alcance  Del producto  Del proyecto  Un cambio en el valor agregado El control de cambios implica asegurar que:      

Se detecta el cambio Se decide el cambio Se define que cambió, cuando, porqué Se implementa el cambio Se comunica el cambio Se documenta el cambio

7

También el Control de cambios incluye A) Influenciar los factores que crean cambios para asegurar que beneficien B) Determinar (darse cuenta) cuando se ha producido un cambio de alcance C) Gerenciar los cambios que ocurren

2.5 Caso para estudio Revise la lectura complementaria de este módulo: Anexo Estructura de Desagregación del Trabajo y analice el ejemplo simplificado de la figura 4, en la página 8. Tomando este ejemplo como base y los conocimientos que tiene sobre proceso de desarrollo de software plantea una EDT para el proyecto que se plantea a continuación: Una universidad necesita construir un nuevo software de administración de cursos que contemple un módulo de inscripciones, un módulo de administración de alumnos, un módulo de administración de docentes y uno de gestión académica. El proyecto parte de una especificación general y finaliza con el sistema funcionando y los usuarios capacitados.

8

Unidad 3: Gestión del tiempo del proyecto Antes de avanzar con el desarrollo de los aspectos relacionados al tiempo mencionaremos algunos factores que influyen en la administración del tiempo del proyecto: Factores de Éxito en la Administración del tiempo: • Personal competente y experimentado • Objetivos claramente definidos y acordados • Gerente de Proyecto y personal dedicado • Personal disponible a tiempo • Plan de proyecto completo • Cronograma interno detallado • Responsabilidad individual por cada entregable • Revisiones internas regulares • Seguimiento de la Lista de Ítems de acción • Problemas detectados tempranamente y resueltos • Revisión regular de las áreas de riesgos • Subcontratistas tratados como parte del equipo • Dependencias controladas y gerenciales Factores de Fracaso en la Administración del tiempo: • Gerente de Proyecto y equipo part-time • Personal en préstamo • Proyecto con escaso personal • Responsabilidades difusas • Plan Incompleto o sólo a nivel general • El Gerente de Proyecto supone progresos • El Gerente de Proyecto cede el control al cliente o subcontratista • El Gerente de Proyecto supone que las dependencias se están cumpliendo • El Gerente de Proyecto supone que los subcontratistas están cumpliendo • Los problemas son pospuestos o ignorados • No se detectan y gerencian los cambios en el proyecto La Administración de tiempos del proyecto incluirá los procesos necesarios para lograr que el proyecto se lleve adelante en los tiempos previstos.

9

3.1 Definición de las actividades Para poder llevar adelante una adecuada gestión de tiempos del proyecto será necesario hacer un correcto plan de tareas. Para ello deberemos, en primer lugar, hacer una clara y completa definición de actividades. Este proceso consiste en identificar y documentar las actividades específicas que deben ser efectuadas para producir los entregables identificados en la Estructura de Descomposición del Trabajo (EDT). El último nivel de la EDT contiene los “paquetes de trabajo”, estos serán los indicados para trabajar la descomposición. Un paquete de trabajo puede convertirse en una actividad del proyecto o bien puede descomponerse para mejor administración. Una vez definidas todas las actividades podremos comenzar a trabajar con la secuencia entre ellas.

3.2 Secuencia de las actividades Para poder lograr un cronograma realista y posible necesitaremos realizar un ordenamiento de las actividades previamente definidas. Para ordenar las actividades necesitaremos establecer secuencia. La secuencia surge por causa de que entre algunas actividades existen relaciones de dependencia: Dependencia: Relación de secuencia entre 2 actividades. Las dependencias entre actividades pueden ser de al menos dos tipos principales:  Hard Logic (obligatorias, mandatarias o de lógica dura). Tienen que ver con la naturaleza del trabajo, y son relaciones obligadas, es decir, una actividad no puede llevarse a cabo sin que la otra haya finalizado.  Soft Logic (discrecionales o de lógica blanda). Están dadas por decisión del planificador. Responden a usos y costumbres, buenas prácticas o conveniencia, para minimizar riesgos. Tenemos relaciones de este tipo cuando las dos actividades no necesariamente deben hacerse en secuencia.

10

Podemos agregar un tercer tipo de dependencia que es importante detectar:  Externas Dependencias relacionadas a factores externos. Son dependencias con otros sucesos o actividades externas al proyecto. No consume los tiempos y los recursos del equipo de proyecto pero condicionan las decisiones y el avance. Por otra parte toda dependencia genera también una relación de precedencia. Las precedencias plantean de qué forma son esas dependencias. Los tipos de Precedencias pueden clasificarse en las cuatro que siguen:

Figura 2.2 - Tipos de Precedencias

Importante: la mayoría de las dependencias son del tipo FC.

La implementación de las dependencias generará necesariamente un diagrama de red. Los diagramas de red de actividades pueden ser de dos tipos: • Con actividades en los nodos, también conocidos como AON por su sigla en inglés: Activity On Node

11

Figura 2.3 - Diagrama de Red con Actividades en los Nodos (AON)

 Con actividades en las flechas, también conocidos como AOA por su sigla en inglés: Activity On Arrow.

Figura 2.4 - Diagrama de Red con Actividades en las Flechas (AOA)

3.3 Estimación de la duración de las actividades El primer desafío para lograr la estimación del tiempo total re proyecto será estimar la duración de cada una de las actividades, es decir: lograr una predicción de cuál será la cantidad de jornadas laborales que insumirá cada actividad del proyecto. Inicialmente se calculará el esfuerzo. El esfuerzo es una medida de la carga de trabajo requerida para la actividad. El esfuerzo será medido en horas/hombre o en horas/máquina dependiendo de cuál sea el recurso más crítico. Lo normal en los proyectos

12

de sistemas es medir el esfuerzo en hs/hombre por ser este último el recurso más crítico y determinante en estos proyectos. Por ejemplo, podemos arribar a la conclusión de que una tarea puede llevarse a cabo en aproximadamente 80 hs/hombre. Estas 80 hs/h no estarán indicando aún cual es la duración de la actividad, sino cual es la carga de trabajo en términos de esfuerzo que se necesita aplicar. Esta será la primera medida necesaria para estimar ahora la duración de la actividad. A esta medida de esfuerzo le aplicaremos una determinada cantidad de recursos y una indicación de la jornada que cumplirán estos recursos (full time o ½ jornada, por ejemplo) y podremos con estos datos conocer lo que denominamos el tiempo de trabajo (working time) o duración neta de la actividad. Para el ejemplo, las 80 hs/hombre se ejecutarán con 2 recursos de jornada completa ( 8 hs. diarias) con lo que tendremos que la actividad se llevará a cabo en 5 días. La cantidad de recursos a aplicar a una actividad dependerá de la actividad misma, de las disponibilidades y de la experiencia. En cualquier caso habrá un punto de equilibrio que indique una cantidad máxima de recursos posibles a partir de la cual cualquier recurso extra, lejos de lograr disminuir el tiempo de la actividad, degradará la eficiencia. Cuando no se posee métricas de experiencias anteriores, se suele utilizar el método de la raíz cuadrada del esfuerzo, para buscar equilibrio entre cantidad de recursos y tiempo que tardará el proyecto. 36hs/h = 6 hs * 6 hombres Punto límite para agregar recursos a un trabajo en función de agilizarlo.

3.4 Desarrollo del programa Para desarrollar el programa de trabajo, también conocido como cronograma, deberemos aplicar estas duraciones a la red de actividades y colocar las restricciones de calendario correspondientes. Lo que estamos buscando ahora es la fecha de finalización de proyecto. En el camino calcularemos las fechas de inicio y fin de cada actividad, lo que determinará para cada una de ellas lo que conocemos como el tiempo transcurrido esperado (elapsed time).

13

Cuando hablamos de restricciones de calendario nos referimos a los días de trabajo del proyecto y de los recursos en particular. Con todos estos datos podremos llegar a calcular el camino crítico de la red. El desarrollo del cronograma es un proceso reiterativo en el que: • Se determina las fechas de principio y fin de todas las actividades del proyecto. • Por lo tanto se determina su duración total. • Las fechas que se definen deben ser realistas, ni pesimistas ni optimistas. Este trabajo se lleva a cabo normalmente ingresando los datos antes mencionados en un software que finalmente nos dará un diagrama de gantt del proyecto en base al análisis de la secuencia de las actividades, la estimación de su duración y los requerimientos y disponibilidad de los recursos.

Figura 2.5 - Diagrama de Gantt - Cronograma del proyecto

Los siguientes conceptos deberán ser tomados en cuenta durante este proceso:  Actividad o Tarea: trabajo que produce un entregable o resultado medible, con comienzo, fin y duración definidos.  Dependencia: relación lógica entre dos tareas.  Predecesora: la tarea anterior en la relación de dependencia.  Sucesora: la tarea siguiente en la relación de dependencia.  Flotación total: tiempo máximo que una tarea puede ser demorada sin que se demore el día final del proyecto.  Flotación libre: tiempo máximo que una tarea puede ser demorada sin que se demore el día de comienzo de la sucesora.  Camino crítico: secuencia de tareas en la que no hay flotación.

14

 Tarea crítica: la que debe ser realizada tal como fue programada para poder cumplir con el día final del proyecto.  ASAP: tarea a comenzar tan pronto como sea posible.  ALAP: tarea a comenzar tan tarde como sea posible. En este punto se recomienda trabajar con el documento:

3.5 Control del programa El programa de trabajo será un documento vivo que deberá llevarse controlado durante todo el transcurso del proyecto. Es de esperar que durante el desarrollo del proyecto algunos imprevistos se presenten y los tiempos esperados comiencen a retrasarse. Será función del director del proyecto mantenerse informado de estas situaciones, conocer como impactan sobre el proyecto y fundamentalmente tomar las decisiones pertinentes para corregir el rumbo e informar a los stakeholder apropiados. Una herramienta usual para llevar adelante esta tarea será el mismo software que se utilizó para construir el cronograma:

Figura 2.6 - Diagrama de Gantt - Control de Cronograma del proyecto

3.6 Caso para estudio Revise la lectura complementaria de este módulo: anexo Planeación y Control del proyecto mediante CPM y Pert. Tomando la EDT que desarrolló en el punto 2.5 desarrolle las actividades necesarias para llegar a un programa de trabajo, enumere los pasos que llevó adelante para lograrlo.

15

Unidad 4: Gestión de costos del proyecto Una de las dimensiones básicas del proyecto es el costo. Los proyectos cuestan dinero y usan recursos que podrían usarse en otra acción; por ello es importante para los directores de proyecto la comprensión de la Gestión de Costos del Proyecto. Revisemos algunos conceptos de costo: Una definición contable podría ser “es un sacrificio o la utilización de recursos para lograr un objetivo específico” Una definición de diccionario “Cantidad rendida a cambio de algo”. En cualquier caso estaremos hablando de la no disponibilidad de un recurso por haberlo afectado a un objetivo, esto necesariamente implica la necesidad de saber aplicar correctamente los recursos. Una buena gestión de costos incluye los procesos requeridos para asegurar que el proyecto sea cumplido dentro del presupuesto aprobado. Para lograrlo podremos realizar los siguientes procesos:

4.1 Planificación de los recursos La planificación de los recursos implica determinar qué recursos, en qué cantidades y cuándo van a ser utilizados para ejecutar las actividades del proyecto Debe responderse a las siguientes preguntas:  ¿Cuán difícil será realizar una tarea específica en el proyecto?  ¿Existe algo único en este alcance del proyecto que puede afectar a los recursos?  ¿Cuál es la historia de la organización en realizar tareas similares? ¿Se han realizado antes tareas similares? ¿Qué nivel de personal trabajó?  ¿Tendrá la organización gente, equipamiento y materiales que estarán disponibles y capacitados para realizar el trabajo?  ¿Tendrá que adquirir más recursos la organización para completar el trabajo?  ¿Tiene sentido realizar “outsourcing” de una parte del trabajo?  ¿Existen políticas organizacionales que pueden afectar la disponibilidad de recursos?

16

Respondiendo a estas preguntas podremos lograr una clara determinación y asignación de los recursos necesarios para llevar adelante el proyecto. Esta información deberá ser documentada. Es importante que la información sea bien declarada, esto puede hacerse con ayuda de software de gestión de proyectos, planillas de cálculo o cualquier otro documento que destinemos para este fin. En cualquier caso el objetivo será el mismo: conocer que recursos, en que cantidad y para cuándo deben estar disponibles. Esta información es de vital importancia para las áreas de la organización que deban encargarse de proveerlos.

4.2 Estimación de los costos Una vez que los recursos han sido claramente determinados es necesario estimar el costo de utilizar los recursos necesarios para completar las actividades del proyecto. Debe tomarse en cuenta que este proceso se puede realizar en diferentes momentos del proyecto y que, por ende, contará con más o menos información según el momento y finalidad. Diferentes tipos de estimaciones pueden definirse en función del momento en que esta se realiza: Tipo de estimación

Cuándo se realiza

Por qué se hace

Grado de aproximación

Orden de Magnitud

Muy temprano en el ciclo de vida del proyecto, a veces 3-5 años antes de la concreción del proyecto

Provee estimación de costos para decisiones de selección

"-25%, +75%"

Presupuestario (top down)

Temprano, Ej. 1-2 años antes de que se complete el proyecto

Coloca $ en el plan Presupuestario

"-10%, +25%"

Definitivo (bottom up)

A menos de un año de completar el proyecto

Provee detalles para "-5%, +10%" compras, costos actuales y estimados

Figura 2.7 - Tipos de estimaciones según el momento de cálculo

Debemos tomar en cuenta que una estimación es una predicción para la planificación, por lo que es de esperarse algún grado de desvío respecto de la realidad futura.

17

Otro aspecto a reforzar es que estamos hablando de estimar costos. El costo es una variable del proyecto. No es lo mismo que precio, el precio es una variable del negocio. Podremos aplicar diversos métodos de estimación. Mencionaremos algunos de ellos: Estimación por analogía: Una estimación por analogía se realiza comparando información de este proyecto con la de otro ya ejecutado y que cumpla al menos con dos condiciones: que sea verdaderamente similar o análogo en cuanto a su estructura y que se cuente con información de ejecución de ese proyecto. La estimación por analogía es un método solo aconsejable cuando estamos en fases tempranas y disponemos de poca información ya que no se espera con este método alta precisión. Estimación de ingeniería: este método se aplica cuando se cuenta con información detallada del proyecto y es de mucha precisión si es bien aplicado. La estimación de ingeniería requiere una EDT desagregada a bajo nivel y consiste en estimar cada uno de los paquetes de trabajo para luego por suma ascendente lograr la estimación de costos de los entregables finales. El principio que sustenta la efectividad del método es la descomposición a bajo nivel. Estimación Paramétrica: una estimación paramétrica puede hacerse cuando, como su nombre lo indica, contamos con parámetros y con algunos ratios y relaciones que permiten modelar el tipo de actividad o producto de la actividad que se está estimando. Ejemplo de ello es la estimación por puntos de función en el desarrollo de software. Cualquiera sea el método aplicado, se espera tener una estimación del costo de cada una de las actividades del proyecto.

4.3-Presupuestación de los costos Con este proceso se busca crear el “presupuesto del proyecto”. La presupuestación implica asignar las estimaciones individuales a las actividades cronogramadas a efectos de poder conocer cuáles serán las previsiones de costos a incurrir en cada periodo de tiempo. Podemos decir que lo que haremos es distribuir las estimaciones a lo largo del tiempo, lo cual indica que trabajaremos con las estimaciones y el cronograma.

18

Un presupuesto, usualmente se verá como sigue: Semana

Diseñar Construir Instalar Probar Total Acumulado

Costo Total Presupuestado 8 86 54 15 163

1

2 6

6 6

3 2 28 30 36

4 40 40 76

5 18 18 36 112

6

36 36 148

15 15 163

Figura 2.8 - Ejemplo de Presupuesto de costos del proyecto

Preste especial atención a la última línea del presupuesto, que refleja los acumulados totales hasta el momento. Es de importancia prestar atención a este aspecto que representa la cantidad de dinero o recursos que se habrán afectado hasta ese momento, y esa es la línea base de costos del proyecto. La línea base de costos del proyecto se usará para efectuar el control de avance. Usualmente se la representa con una curva S.

Figura 2.9 - Ejemplo de Presupuesto acumulado - Curva S

19

4.4 Control del costo El control de costos del proyecto comprende: • Influir en los factores que ocasionan cambios en la base de costos para asegurar que los cambios son beneficiosos. • Determinar cuándo se produce un cambio en la base de costos. • Gestionar los cambios reales cuando y como ocurran. A su vez, el control de costos incluye  Controlar el desarrollo de los costos, para detectar variaciones en el plan.  Garantizar que los cambios apropiados son reflejados con exactitud en la base de costos.  Prevenir que cambios incorrectos, inapropiados o no actualizados sean incluidos en la base de costos.  Informar a las entidades involucradas en el proyecto los cambios autorizados.  Lograr costos dentro de límites aceptables. Todo esto implica necesariamente:  La búsqueda de los “por qué” de las variaciones, tanto positivas como negativas.  Tener en cuenta que una respuesta inadecuada a variaciones de costo puede generar problemas de Cronograma, Calidad, Riesgo.  Que esté integrado con los otros procesos de control, control de cambios del alcance, control de cambios de cronograma, control de calidad, etc… La principal técnica para controlar los costos y el avance del proyecto es la Gestión del Valor Ganado. El valor Ganado es una técnica de control de proyectos que permite controlar su ejecución y avance a través del presupuesto y el calendario de ejecución. La técnica consiste en comparar el valor del trabajo realizado con el cronogramado hasta cierto momento del proyecto. Se diferencia de otras técnicas de control en que el avance no se mide por el solo transcurso del tiempo ni por la cantidad de trabajo realizada sino, más bien, por el real avance en términos de lo logrado en el proyecto. De este modo, se tiene una medida de cuánto trabajo se ha realizado, cuanto queda para finalizar el proyecto y extrapolando a partir del esfuerzo invertido en el proyecto, el director de proyecto puede estimar los recursos que se emplearán para finalizar el proyecto y el tiempo restante para su terminación.

20

Con esta técnica se puede hacer predicciones de cuánto tiempo tomará el proyecto para completarse si se mantienen las condiciones actuales a la vez que se puede proyectar cuanto terminará costando el proyecto si se mantiene la performance de administración de costos que se lleva hasta el momento.

Mediciones de Valor Ganado Para poder trabajar con Valor Ganado, es necesario contar con: • La estructura de tareas (WBS): una lista de todas las tareas y paquetes de trabajo del proyecto estructuradas de forma jerárquica. • Una serie de reglas para determinar objetivamente el grado de avance de cada tarea en términos de los productos logrados. • El cronograma de ejecución: un Diagrama de Gantt con el orden en el que se desarrollarán las tareas. • Una línea base del proyecto en términos de costos, o lo que es lo mismo, el presupuesto acumulado a lo largo del tiempo o Curva S. Las medidas centrales del Valor ganado son: • BCWS (Budgeted Cost of Work Scheduled) o PV (Planed Value).  Avance físico planeado a su valor presupuestado.  Suma de los costos estimados para las actividades cronogramadas hasta cierto momento. • BCWP (Budgeted Cost of Work Performed) o EV (Earned Value).  Avance físico realizado a su valor presupuestado.  Suma de los costos estimados para las actividades completadas hasta cierto momento. • ACWP (Actual Cost of Work Performed) o AC (Actual Cost).  Costo real incurrido.  Suma de los costos reales para las actividades completadas hasta cierto momento. Para comprender mejor, tomaremos un caso como ejemplo, en este caso se tiene un proyecto que está estimado en 6 meses para un total de 700 casos de uso a construir. Los casos de uso son la medida que se tomará para el avance. Los costos pueden verse en alguna medida monetaria, pesos por ejemplo. En el caso se plantea inicialmente los datos de lo planificado, seguidamente los datos de lo ocurrido realmente y finalmente los valores de las tres medidas que estamos presentando. Analiza el caso antes de avanzar haciendo los cálculos necesarios según lo que has visto en los párrafos anteriores:

21

Mes 1

ESTIMADO (PLAN) casos de uso Planeados Costo por casos de uso (en el mes)

Mes 2

50,00 5,50

100,00 5,50

275,00

825,00

45,00 6,40

95,00 6,06

Costo casos de uso Acumulado

288,00

BCWS ACWP BCWP

275,00 288,00 247,50

Costo casos de uso Acumulado REAL casos de uso Reales Costo por casos de uso (en el mes)

Mes 3

Mes 4

Mes 5

200,00 5,50

100,00 5,50

50,00 5,50

1925,00 3025,00 3575,00

3850,00

200,00 5,50

180,00 5,87

210,00 5,26

Mes 6

90,00 6,00

60,00 10,00

864,00

1920,00 3024,60 3564,60

4164,60

825,00 864,00 770,00

1925,00 3025,00 3575,00 1920,00 3024,60 3564,60 1760,00 2915,00 3410,00

3850,00 4164,60 3740,00

Figura 2.10 - Ejemplo de Valor Ganado

En el ejemplo se pueden observar las tres medidas que se mencionaron anteriormente, el BCWS muestra la Curva S original, es decir el presupuesto, el ACWP muestra el costo real incurrido, o sea lo que efectivamente se gastó independientemente del avance logrado, el BCWP, normalmente conocido como “valor ganado” muestra lo que efectivamente se hizo a valor de presupuesto. La razón del BCWP es poder mostrar los costos incurridos en términos de

22

“avance” del proyecto, evitando que podamos caer en el error de pensar que si se consumieron los recursos previstos el proyecto avanzó según lo esperado. A partir de esto se podrá hacer el análisis de avance real en términos de:

Índices:  SPI (Schedule Performance Index)  BCWP / BCWS  Indicador de eficiencia sobre cronograma.  Se usa para determinar en qué medida se ha realizado el trabajo programado.  CPI (Cost Performance Index)  BCWP / ACWP  Indicador de eficiencia sobre costos.

Proyecciones: • EAC (Estimate At Completion)  Presupuesto ajustado.  Proyección del costo al fin del proyecto basado en la performance real.  BAC / CPI  Donde BAC (Budget At Completion) es:

◦ ◦ ◦

Presupuesto original final El presupuesto original de costos, al fin del proyecto. El último y mayor valor del BCWS.

• TEAC (Time Estimate At Completion)  tiempo estimado necesario para completar el proyecto  SAC / SPI.  Donde SAC (Schedule At Completion) es:

◦

Tiempo estimado originalmente en que se va a concluir el proyecto, medido en días, meses, años, etc.

23

En el ejemplo que estamos viendo: Mes 1

ESTIMADO (PLAN) Casos de uso Planeados Costo por casos de uso (en el mes) Costo casos de uso Acum. REAL Casos de uso Reales Costo por casos de uso (en el mes) Costo casos de uso Acum. BCWS ACWP BCWP BAC SPI CPI EAC SAC TEAC

Mes 2

50,00 5,50 275,00

100,00 5,50 825,00

45,00 6,40

95,00 6,06

288,00

864,00

275,00 288,00 247,50 3850,00 0,90 0,86 4480,00 180,00 200,00

825,00 864,00 770,00 3850,00 0,93 0,89 4320,00 180,00 192,86

Mes 3

Mes 4

200,00 200,00 5,50 5,50 1925,00 3025,00

Mes 5

Mes 6

100,00 5,50 3575,00

50,00 5,50 3850,00

210,00 5,26

90,00 6,00

60,00 10,00

1920,00 3024,60

3564,60

4164,60

1925,00 1920,00 1760,00 3850,00 0,91 0,92 4200,00 180,00 196,88

3575,00 3564,60 3410,00 3850,00 0,95 0,96 4024,55 180,00 188,71

3850,00 4164,60 3740,00 3850,00 0,97 0,90 4287,09 180,00 185,29

180,00 5,87

3025,00 3024,60 2915,00 3850,00 0,96 0,96 3994,75 180,00 186,79

Para completar esta unidad analice el anexo: Introducción al Método de Valor Ganado

4.5 Caso para estudio En base a la EDT que desarrolló en el punto 2.5 y el programa de trabajo que desarrolló en el punto 3.6, realice la estimación de costos de uno de los entregables del proyecto y elabore su línea base.

24

Módulo 3 Los enlaces del proyecto, Recursos Humanos y Comunicaciones

5. Gestion de los Recursos Humanos del Proyecto 5.1 Planificación organizacional Uno de los problemas más importantes que encontramos en el proceso de gestionar un proyecto radica en la falta de una definición clara de roles y responsabilidades de las personas que forman el equipo de trabajo. El conjunto de personas que hacen de un proyecto un éxito o un fracaso es lo que se define como Recursos Humanos del Proyecto, ya que más que los problemas técnicos, una de las dificultades en los proyectos es la de comprender y administrar el comportamiento de la gente, ante lo cual se necesita de personal capaz de proponer soluciones para cada uno de los imprevistos que se pueden presentar. Encontrar un equipo de trabajo con la actitud y el perfil, ya sea para ser líderes o bien para ser proactivos en sus tareas, requiere de buena parte del tiempo del gestor de proyectos. Definir, comunicar y dejar claros los roles y responsabilidades del grupo de trabajo del proyecto es lo que se denomina Planificación de los Recursos Humanos del proyecto, siendo esta planificación la base de la formación y definición de los integrantes del equipo de proyecto. Una vez definidos los roles y responsabilidades se debe seleccionar de dónde se tomarán los recursos humanos. La planificación de los recursos humanos busca cumplir los siguientes fines: 1. Hacer uso de los recursos humanos de la empresa lo mejor posible, considerando las políticas de costos. 2. Lograr un buen clima de trabajo, considerando el potencial humano (individual y colectivo), y fijando políticas de promoción y de formación para lograr el aprovechamiento máximo del potencial disponible.

1

3. Suministrar de personal directivo, técnico y de cualquier otro tipo, necesario para llevar a cabo los objetivos de desarrollo planificados, priorizando el desarrollo potencial del personal existente con la antelación adecuada, antes de recurrir al mercado exterior salvo necesidad comprobada. 4. Conseguir la satisfacción del personal, al saber que es periódicamente valorado y tenido en cuenta para los puestos que se vayan creando o que queden vacantes, de superior responsabilidad. Las previsiones deben hacerse considerando al menos tres perspectivas: la perspectiva optimista, la pesimista y la media entre ambas, para tener previsto un amplio abanico de posibilidades y de acciones a tomar en todos los casos. Amplitud y flexibilidad son, desde luego, dos características esenciales.

5.2 Obtención de los recursos humanos necesarios Para obtener los recursos humanos necesarios para el proyecto será necesario:  

Definir las necesidades Obtener el equipo del proyecto.

Definición de las necesidades: El primer desafío al que nos enfrentamos es el de lograr una especificación de los recursos humanos requeridos. Esta especificación deberá contemplar al menos cuatro características:    

descripción del recurso. informe de capacidades y competencias requeridas. fecha cronológica en la que se requiere el recurso. tiempo durante el que será aplicado el recurso.

Las dos últimas características pueden verse como una ventana temporal. La disponibilidad del recurso para una ventana específica tiene que establecerse lo más pronto posible. Quien planifica debe comenzar evaluando el ámbito y seleccionando las habilidades técnicas que se requieren para llevar a cabo el desarrollo. Hay que especificar tanto la posición dentro de la organización (por ej.: gestor, ingeniero de software senior, programador, entre otros) como la especialidad (por ej.: comunicaciones, bases de datos, microprocesadores, entre otros).

2

El gestor debe estimar sus necesidades de personal a futuro, a fin de prepararse para llevar a cabo sus estrategias operativas, evaluando las posibles características de la oferta de trabajo, siendo este un proceso que puede realizarse de manera formal o informal. La demanda a futuro que experimenta una organización en el campo de los recursos humanos es esencial para la planeación de las políticas de empleo, sobre todo en lo referido a proyectos cuando el alcance, tiempos y costos ya se conocen. La demanda de recursos humanos en los proyectos se ve influida por muchos condicionantes que son función de los cambios en el entorno, en la organización y en la fuerza de trabajo. Estos factores aparecen durante todo el proceso de gestión del proyecto. El proceso de obtención del equipo de proyecto implica conseguir y asignar recursos humanos al proyecto. El equipo de proyecto podrá provenir de dentro de la organización para la cual se gestionará el proyecto o de fuera de la misma, en la forma de empleados contratados especialmente para el proyecto. En cualquier caso el trabajo del Líder de Proyecto será asegurarse que los recursos estarán disponibles y que posean las habilidades necesarias para la concreción de las actividades del proyecto para las que fueron asignados. Sin embargo, en la práctica, puede que no siempre se tenga control sobre la selección del equipo de proyecto. Aún en estos casos es importante lograr un involucramiento lo más temprano posible.

Obtención del Equipo de Proyecto Asignación previa, negociación, adquisición y equipos virtuales son las herramientas y técnicas utilizadas en la obtención del equipo de proyecto. Como Gestor de Proyectos tendrás que focalizarte en lograr los mejores talentos y conformar el mejor equipo, para ello deberás recurrir a la negociación constantemente. Seguramente tendrás que negociar con los mandos funcionales y con gerentes de diversos departamentos de la organización y en el caso de contratar un servicio de desarrollo de terceros, negociar para contar con las personas con mejores capacidades para las tareas previstas. Los puntos más importantes para tener en cuenta en la negociación son:  Conocer las necesidades del proyecto y su prioridad dentro de la organización  Ser capaz de expresar para que y por qué se necesita un determinado recurso  Entender que el área de RRHH tiene su propio trabajo y objetivos y que el proyecto puede no ser uno de ellos  No requerir los mejores recursos si no se los necesita realmente

3

 Ser capaz de probar, mediante el uso de las herramientas de gestión de proyectos, tales como diagramas de red o cronogramas, porqué necesita los mejores recursos, si es que los necesita  Utilizar la negociación como una oportunidad de descubrir lo que el área de RRHH necesita en orden de manejar sus propios recursos  Construir una relación con el experto en recursos humanos, tal que se pueda contar con él cuando se lo necesite.

5.3 El gerente de proyectos Gestionar el equipo y entregar los resultados prometidos es la principal responsabilidad del gerente de proyectos. Crear el clima de trabajo adecuado es su responsabilidad de liderazgo. La importancia de la figura del director del proyecto queda reflejada en un párrafo de un informe del Departamento de Defensa de los EEUU sobre el proyecto STARS de investigación sobre la reutilización de software que dice: "El director del proyecto juega el papel más importante en la Ingeniería del Software y su soporte. La diferencia entre el éxito o el fracaso -entre un proyecto que se desarrolla en fecha y en presupuesto, o uno retrasado y sin control de costos- es, a menudo, una función de la eficacia de ese director". El director del proyecto tiene las siguientes cinco funciones principales: 1. Alcanzar los objetivos definidos mediante la planificación del trabajo a realizar. 2. Definir y organizar al equipo de trabajo que realizará el proyecto. 3. Asignar trabajo al personal del equipo de proyecto. 4. Controlar el progreso. 5. Liderar el equipo de personas. Ahora nos centraremos en el liderazgo, la más abstracta de las cinco funciones. El liderazgo involucra: ▪ Motivar y recompensar: Es asegurar que todos los miembros del equipo conocen que su trabajo es apreciado y reconocido como se describió anteriormente. ▪ Mantener la perspectiva: Es importante mantener al equipo equilibrado. Los equipos que han trabajado juntos durante mucho tiempo caen en la trampa de convertirse en islas. Se manifiesta en que estos consideran a otros grupos como inferiores, siendo resistentes al cambio o influencias

4

externas, atribuyendo escaso rendimiento a los demás y de alguna manera sintiéndose aparte del resto de la organización. Aún el orgullo y espíritu de equipo fuerte puede ser contraproducente si se convierte en vanidad y retraimiento con lo que se puede producir una degradación del equipo. Es función del director del proyecto estar seguro de que el equipo mantiene su perspectiva. ▪ Animar al grupo a tomar decisiones: Significa conocer cuándo se deben tomar las decisiones en grupo y cuándo individualmente. Se ha demostrado que las decisiones de grupo no son necesariamente un reflejo de las opiniones individuales del grupo. Por ejemplo, un líder fuerte puede influir en el grupo para que este tome decisiones de alto riesgo para las cuales a nivel individual podrá no haber acuerdo. ▪ Supervisar y mantener el comportamiento del grupo: Es un importante papel del liderazgo. Los grupos pueden comportarse de una manera distinta a lo que sería característico de los individuos en el grupo. Explotar este potencial es importante para el líder. Bien estructurados, los equipos positivos pueden conseguir más que cualquier individuo. La inversa también es verdad. El comportamiento del grupo puede ser destructivo para el mismo grupo y para aquellos que dependen de su trabajo. El comportamiento irracional del grupo puede exceder a los actos individuales. ▪ Asegurar que todos ganan: Esto es esencial en la negociación del contrato a través del proceso de planificación y en la motivación del equipo.

El Estilo de los Directores de Proyecto Los directores de proyectos pueden adoptar diferentes estilos. Mencionaremos algunos estilos posibles, no sin antes aclarar que no hay un mejor o peor estilo, sino más bien habrá estilos más o menos adecuados al grupo, al proyecto y al momento particular.  Director: Este tipo de directores dicen al equipo qué deben hacer y cómo. Este estilo puede ser apropiado en ocasiones durante la ejecución y cierre del proyecto, es decir, cuando las especificaciones y diseño del producto han sido decididos y el diseño real está siendo gestado, de tal manera que se consiga la pronta terminación del proyecto y se obtenga el retorno de la inversión lo antes posible.

5

 Facilitador: Los líderes de este tipo permiten a los miembros del equipo autogestionarse. Se comportan como los miembros del equipo y se le consulta si se requiere. Este estilo suele ser más apropiado al comienzo del desarrollo o etapa de viabilidad de un proyecto o en proyectos de investigación.  Entrenador: Los directivos de este tipo instruyen y guían a los miembros del equipo en aquello que se debe hacer y cómo hacerlo. Se comportan como los miembros del equipo y se le consulta si se requiere. Este estilo es apropiado cuando el director tiene probada experiencia en el tema del proyecto y el equipo de trabajo respeta dicha experiencia.  Democrático: Los directores democráticos consultan a sus equipos y deciden entonces el mejor camino para actuar. Este estilo puede ser apropiado durante la viabilidad y planificación de las etapas del proyecto, cuando se quiere animar a las personas a contribuir con sus ideas.  Autocrático: Los directores autocráticos dicen al equipo qué deben hacer y cómo, sin tener en cuenta opiniones ni consideraciones del equipo. Este estilo rara vez tiene una respuesta eficaz a los problemas que pueden aparecer, ya que el equipo está aislado y no comparte las decisiones del director. Aún así es muy necesario en momentos de crisis y necesidad de respuestas rápidas, (cuando el barco se hunde no hay tiempo para reuniones democráticas)  Burocrático: Los directores burocráticos dirigen a través de reglas y procedimientos. Este estilo es habitualmente apropiado solamente en proyectos de bajo riesgo, para los cuales se esperan muy pocos cambios, ya que un a un directivo burocrático se le hace difícil responder rápidamente a estos. Ya mencionamos que no podemos aseverar que un estilo es mejor que otro, aunque, en el contexto de los proyectos puede ser apropiado hablar de algunos estilos que son “menos apropiados” que otros. Por ejemplo: un tecnócrata es una persona para la cual la ciencia es más importante que los resultados, los medios más importantes que los fines. Esta persona busca la solución ideal, en lugar de buscar una solución adecuada que satisfaga los requisitos de los clientes. Usualmente es incapaz de delegar, argumentando su falta de fe en el equipo del proyecto para alcanzar el resultado perfecto. El burócrata puede ser ineficaz en cuanto a su obsesión

6

por seguir los procedimientos, convencido de que el trabajo se ha realizado correctamente, aunque no sea eficaz. El vendedor es la persona que es muy buena promocionando el proyecto, pero no alcanzando resultados. Las tres características de estos - habilidad técnica, aplicación del mejor método y vendedor - son buenas si se aplican con moderación, pero se convierten en debilidades cuando se aplican en exceso como si fueran más importantes que el resultado del proyecto.

El Director de Proyecto Eficaz Los rasgos más característicos del líder eficaz son:  Habilidad para resolver problemas y orientación a los resultados: Los directores eficaces tienen usualmente una inteligencia por encima de la media, y son capaces de resolver problemas complejos analizando la situación actual y reconociendo modelos. La gestión de proyectos es una actividad de solución de problemas: La consecución del propósito del proyecto es un problema, así como la terminación de cada etapa de su ciclo de vida. Asimismo, los procesos de control también lo son. Sin habilidad para resolver problemas un director de proyectos estaría perdido. El proyecto no es terminar el producto por amor al trabajo, sino conseguir el fin deseado. Así, la solución a los problemas debería permitir alcanzar los objetivos planificados y el propósito definido, no necesariamente terminar el trabajo acordado inicialmente.  Energía e iniciativa: El director de proyecto debe tener también la habilidad de trabajar y gestionar bajo una presión considerable y constantes problemas. Todo ello requiere que el director sea enérgico y fuerte. Esta energía debe ser complementada con iniciativa para buscar la acción y resolver las tareas en el tiempo adecuado.  Seguridad en sí mismo: Los directores deben estar seguros de sí mismos respecto a que lo que están haciendo es correcto. Esto no significa que sean extrovertidos o impetuosos, sino que deben actuar de manera resolutiva, confiando en sus opiniones y juicios. Algunas veces, es mejor actuar basados en información incompleta, estando prestos a modificar la acción cuando se disponga de nueva información, que estar esperando por la solución perfecta, mucho más cuando de proyectos se trata. Los directores seguros de sí mismo también delegan en su equipo de proyecto, confían en la habilidad de sus miembros y en su propia habilidad para motivarlos. Algunas veces y

7

en especial en la industria de las Informática, los buenos técnicos son promocionados a posiciones directivas, pero son muy reacios a delegar ya que creen que pueden hacer el trabajo mejor que nadie, desarrollando actividades técnicas mientras que los miembros del equipo están parados y, consecuentemente, desmotivados.  Perspectiva: Los directivos necesitan ser capaces de mirar más allá del equipo y ver cómo encaja dentro de la organización como un todo. Esta necesidad de perspectiva, se extiende al trabajo del proyecto. El director debe ser capaz de moverse libremente a través de los niveles de la jerarquía y sobre todo, comprender sus niveles de detalle, cómo cumplen con sus objetivos y entender cómo éstos darán respuesta a las necesidades del proyecto.  Capacidad de Comunicación: Similarmente, los directores deben ser capaces de comunicarse a todos los niveles de la organización, y en todos los canales del proyecto (esto incluye canales formales e informales); deben ser embajadores del proyecto y convencer a la alta dirección para obtener su apoyo; deben ser capaces de hablar con sus interlocutores, directores funcionales y proveedores de recursos para obtener su cooperación; ser breves y capaces de motivar al equipo.  Habilidad negociadora: El plan del proyecto debe ser un contrato; es, en efecto, un contrato entre el director del proyecto (especificando lo que el director del proyecto y su equipo van a proporcionar a la organización) y los patrocinadores del proyecto (especificando el soporte que facilitarán para entregar los resultado contratados). Como todos los contratos, el plan de proyecto debe ser negociado y conciliado entre ambas partes. El director del proyecto debe valerse de su habilidad para negociar ya que no tiene línea de autoridad directa sobre los recursos como un director funcional. También, debe lograr y mantener el compromiso y cooperación de otras personas a partir de su habilidad para negociar y persuadir.

5.4 El equipo de proyectos Cuando se constituye el equipo de proyectos, el director del proyecto reúne a un grupo de personas y desarrolla en el grupo una personalidad o identidad, de tal manera que pueden trabajar conjuntamente utilizando un conjunto de valores comunes o normas para alcanzar los objetivos del proyecto.

8

El concepto de identidad percibido por el grupo es crítico para la formación del equipo: sin ella, el grupo de personas se mantendría como un conjunto de individuos aislados. Lo importante a la hora de crear un equipo de proyecto es el desafío de lograr que un grupo de personas que probablemente nunca han trabajado juntas antes, se reúnan y sean capaces de trabajar eficaz y rápidamente en algo nuevo. La novedad, unicidad, riesgo y transitoriedad son propiedades inherentes a los proyectos. El equipo recientemente constituido, al comienzo no ha percibido su identidad, careciendo de un conjunto de normas y valores para trabajar por lo que lleva tiempo el desarrollar esta personalidad y normas, lo cual atenta contra la consecución de los objetivos en tiempo. Los miembros de un equipo se deben identificar con dicho equipo y desarrollar un conjunto común de valores o normas, antes de que puedan trabajar juntos eficazmente como grupo. Este proceso de crear la identidad de un equipo y un conjunto de valores lleva tiempo y es uno de los factores responsables del “síndrome de inicio difuso”. El equipo normalmente pasa por cinco etapas en su desarrollo y camino al alto rendimiento que son:     

Formación Tormenta Normalización Rendimiento Despedida

 Formación: Los miembros del equipo llegan con un sentido de ansiedad y compromiso. Su motivación es alta al haber sido seleccionados para el proyecto y su eficacia moderada ya que están poco seguros unos de otros. Por lo general y muy a pesar de lo que normalmente se piensa, en esta etapa del proyecto la productividad es baja a pesar que el clima es muy bueno.  Tormenta: Conforme los miembros del equipo comienzan a trabajar juntos, encuentran que tienen discrepancias acerca de la mejor manera de alcanzar los objetivos del proyecto y diferentes modos de trabajar. Cada integrante necesita encontrar su lugar y estas diferencias pueden causar discusiones y conflictos en el equipo, lo cual hace que la eficacia y la motivación decaiga. Este es un momento propicio para que el director del proyecto pueda observar cómo se resuelven los conflictos e interacciones entre los miembros, a sabiendas de que es un proceso natural y hasta necesario para luego salir adelante.

9

 Normalización: Si la dirección es la apropiada y el equipo puede superar esta etapa es normal que los conflictos se ajusten y disminuyan. Esto se logra sobre la base de un proceso de negociación, compromiso y búsqueda de áreas de coincidencia. Como resultado, el equipo comienza a desarrollar un sentido de identidad y un conjunto de normas y valores comunes. Esto constituye una base sobre la cual los miembros del equipo pueden trabajar conjuntamente y la eficacia y la motivación comienzan a incrementarse.  Rendimiento: Una vez que el rendimiento alcanza un nivel adecuado, el equipo trabajará eficazmente durante el resto del proyecto. El director del proyecto tiene la responsabilidad de mantener este nivel de rendimiento si bien después de que el equipo ha estado trabajando mucho tiempo, sus miembros pueden comenzar a perder su eficacia. Si esto ocurre, el director puede necesitar cambiar la estructura o la composición del equipo.  Despedida: Cuando el proyecto llega al final, el equipo también se aproxima al final de su trabajo, esta situación crea nuevas ansiedades y esto es causa de alguna de las siguientes dos situaciones:  la eficacia puede incrementarse ya que los miembros del equipo hacen un último esfuerzo para terminar su trabajo.  la eficacia puede decaer, ya que los miembros del equipo perciben el final del trabajo y rompen las relaciones que habían establecido a la vez que se preparan para encarar otros desafíos perdiendo probablemente foco en este. El Director de proyecto deberá estar atento a esta circunstancia para alentar al equipo a estar atento a nuevas oportunidades a la vez que no descuidan el proyecto. Una vez constituido el grupo, el papel del director es asegurar que se continuará trabajando al nivel de eficacia máximo. El director del proyecto debe ser capaz de determinar la eficacia real del equipo. Esto puede ser evaluado analizando la forma en que el equipo consigue las metas acordadas y cómo se satisfacen las aspiraciones, necesidades y motivaciones a nivel individual y grupal. El líder del equipo y la gestión de línea de la organización deben asegurar que tanto los objetivos de la corporación como los personales se alcanzan. Si solamente se logran las metas corporativas, entonces con el tiempo se producirá una erosión de la eficacia y la moral seguidas de un desgaste del personal.

10

A menudo, sin embargo, es posible medir el logro de los objetivos solamente al final del proyecto con lo cual es muy tarde para tomar acciones correctivas, de aquí que sea importante obtener medidas que permitan juzgar la cohesión y la fortaleza de un grupo durante el proyecto. Existen ciertos indicadores de la eficacia del equipo, entre los que cabe destacar:  Asistencia: Bajo ausentismo, baja tasa de accidentes, enfermedad, interrupciones en el trabajo y rotación.  Claridad de objetivos: Los objetivos individuales se han definido, comprendido y alcanzado así como los objetivos del grupo. Cada miembro del equipo tiene un conocimiento claro del papel del grupo.  Calidad de producción: Alto compromiso con la consecución de objetivos; búsqueda de soluciones reales; solución de problemas críticos utilizando todos los conocimientos y capacidades.  Fuerte cohesión del grupo: Apertura y confianza entre los miembros del grupo, comparación de ideas y conocimiento, reuniones vivas y constructivas.

Grupos Existentes en el Equipo de Proyecto En cualquier contexto, pueden existir tres grupos distintos dentro de un equipo de proyecto:  Grupo primario: Es el conjunto de personas que trabajan codo con codo y se conocen en el grupo. En un proyecto suele haber un equipo permanente y otro a tiempo parcial.  Grupo secundario: Es mayor que el anterior y son las personas que tienen relación con las del grupo primario y contribuyen directamente a su trabajo, pero no son parte del equipo. Sin embargo, para que sean eficaces deben tratarse como pertenecientes al equipo de proyecto.  Grupo terciario: Son personas que tienen influencia sobre miembros de los equipos primario y secundario, o se ven afectados por el trabajo del proyecto, pero no contribuyen al mismo directamente con su trabajo. Este grupo se puede dividir en tres subgrupos:  los afectados por el trabajo del proyecto: comprenden a las personas que tienen una relación con el personal del primer o segundo grupo. Pueden ser familiares y amigos o grupos profesionales.  los afectados por la facilidad obtenida en un proyecto: son los que trabajan con el medio una vez entregado o son las personas

11

cuyas vidas cambiarán de una forma irreversible con el uso de ese medio.  los afectados por los productos fabricados con dicha facilidad: son los consumidores, las personas que adquieren los productos producidos. Algunas veces son usuarios, otras no. Las expectativas de todas estas personas deben ser gestionadas si se quiere verdadero éxito en el proyecto ya que tienen poder para hacerlo fracasar. Como ejemplo, consideremos un equipo que realiza un desarrollo de software. El equipo de desarrollo es el grupo primario. El grupo secundario es el departamento de sistemas al que pertenece ese equipo. El tercer grupo está constituido por asociaciones profesionales como el Colegio de Ingenieros Especialistas, otros desarrolladores dentro de la empresa, el comité de gestión de cambios y la administración (subgrupo l). Los usuarios constituyen el segundo subgrupo y sus familiares el tercer subgrupo.

Factores de Motivación del Equipo de Proyecto La mayoría de los proyectos se desarrolla dentro de organizaciones que entran dentro del esquema de gestión de proyectos del tipo matricial, por lo que la motivación del equipo de proyecto es fundamental para el gestor del proyecto.

Pero ¿Cómo se puede recompensar al personal del proyecto sin entender lo que los motiva? En el entorno de un proyecto, sin jerarquías funcionales, títulos, rangos, símbolos de poder y estado, no existen muchos de los factores que son vistos tradicionalmente como útiles para motivar al personal profesional. Los directores de proyecto deben buscar nuevos factores motivadores que sean válidos en ese entorno. Muchas personas se motivan por el desarrollo de su carrera, pero ya que no es posible juzgar dicho desarrollo por su posición jerárquica, dado el tipo de entorno en el que se mueven, debe medirse su propio progreso y aprendizaje dentro y a través de la organización. Muchas son las teorías de motivación pero indiscutiblemente no podemos hablar de este tema sin citar a la más difundida, la teoría de Maslow.

12

La Pirámide o Jerarquía de Maslow El psicólogo Abraham Maslow desarrolló dentro su la Teoría de la Motivación, una jerarquía de las necesidades que los hombres buscan satisfacer. Estas necesidades se representan en forma de una pirámide de cinco niveles:

Figura 3.1: Pirámide de Necesidades de Maslow

A efectos de comprender la teoría, debemos comprender sus postulados fundamentales:  Un ser humano tiende a satisfacer sus necesidades primarias  (más bajas en la pirámide), antes de buscar las de más alto nivel.  Un tipo de necesidad debe ser sustancialmente satisfecho antes que el siguiente aparezca.  Los niveles superiores pueden satisfacerse de modos más diversos que los inferiores. Por ejemplo, una persona no busca tener satisfechas de seguridad (por ejemplo, evitar los peligros del ambiente) si no tiene cubiertas sus necesidades fisiológicas, como comida, bebida, aire, etc. A continuación presentamos una breve descripción de los escalones de la pirámide de necesidades de Maslow.1

Necesidades fisiológicas Las necesidades fisiológicas son satisfechas mediante comida, bebidas, sueño, refugio, aire fresco, una temperatura apropiada, entre otras. Si todas las necesidades humanas dejan de ser 1

Extraído de http://www.webislam.com/articulos/34942-la_piramide_de_maslow.html 23-102013

13

satisfechas entonces las necesidades fisiológicas se convierten en la prioridad más alta. Si se le ofrecen a un humano soluciones para dos necesidades como la necesidad de amor y el hambre, es más probable que el humano escoja primero la segunda necesidad, (la de hambre). Como resultado todos los otros deseos y capacidades pasan a un plano secundario.

Necesidades de seguridad Cuando las necesidades fisiológicas son satisfechas entonces el ser humano se vuelve hacia las necesidades de seguridad. La seguridad se convierte en el objetivo de principal prioridad sobre otros. Una sociedad tiende a proporcionar esta seguridad a sus miembros. Ejemplos recientes de esa pérdida de seguridad incluyen Somalia y Afganistán. A veces, la necesidad de seguridad sobrepasa a la necesidad de satisfacción fácil de las necesidades fisiológicas, como pasó por ejemplo en los residentes de Kosovo, que eligieron dejar un área insegura para buscar un área segura, contando con el riesgo de tener mayores dificultades para obtener comida. En caso de peligro agudo la seguridad pasa delante de las necesidades fisiológicas.

Necesidades de amor, Necesidades sociales Debemos resaltar en este apartado que no se puede hacer equivalente el sexo con el amor. Aunque el amor puede expresarse a menudo sexualmente, la sexualidad puede en momentos ser considerada sólo en su base fisiológica.

Necesidades de estima, Necesidad de Ego Esto se refiere a la valoración de uno mismo otorgada por otras personas.

Necesidades del ser, Necesidades de Autoestima Es la necesidad instintiva de un ser humano de hacer lo máximo que pueden dar de sí sus habilidades únicas. Maslow lo describe de esta forma: "Un músico deba hacer música, un pintor, pintar, un poeta, escribir, si quiere estar en paz consigo mismo. Un hombre, (o mujer) debe ser lo que puede llegar a ser). Mientras las anteriores necesidades pueden ser completamente satisfechas, ésta necesidad es una fuerza impelente continua.

14

Muchas de estas motivaciones no son válidas en un entorno de proyectos. Sin embargo, la jerarquía de Maslow continúa proporcionando una base para los factores motivacionales. Muchas personas han pasado el punto en el que la propiedad es el primer aspecto a ser satisfecho en el trabajo y buscan satisfacer ahora la estima y la realización. Esto lleva a cinco nuevos factores para una motivación eficaz (Fuente: Planificación de Sistemas de Información, Adolfo Pérez García, UPM):     

Propósito Pro actividad Compartir beneficios Progresión Reconocimiento profesional

Propósito: Las personas tienen que creer en la importancia de su trabajo, y que contribuyen al desarrollo de la organización. Este sentido del propósito y la conexión entre el trabajo del proyecto y la misión de la organización corporativa, puede ayudar a vencer la incertidumbre de la dependencia dual en las estructuras matriciales.

Proactividad: Conforme se progresa en la carrera y ésta se hace menos clara y predecible, y los puestos directivos se ven lejanos, las personas quieren gestionar sus propias carreras. Haciendo énfasis en la consecución de los resultados, más que en el papel desempeñado, delegando en ellos la actividad profesional y evaluándolos a través de dichos resultados, da a los subordinados la oportunidad de tomar responsabilidades para su propio desarrollo. Más aún, si se permite a las personas elegir su siguiente proyecto como una recompensa por su buen rendimiento en el actual puede verse satisfecha esta necesidad.

Compartir beneficios: Permitir a las personas compartir la cultura de la iniciativa les animará a valorarla. Muchas organizaciones animan a sus empleados a resolver sus propios problemas y a tomar iniciativas para satisfacer los requisitos de sus clientes y permitir a sus empleados compartir los beneficios. El creciente número de trabajadores por cuenta propia también demuestra que muchas personas están tomando esta iniciativa, pero bajo su responsabilidad. Conforme las personas se acercan a la cima de la jerarquía de Maslow, comienzan a ser conscientes de la necesidad de su autorealización. Valoran entonces las oportunidades de incrementar sus posibilidades de

15

aprendizaje. Cada nuevo proyecto es una oportunidad para adquirir nuevas destrezas e incrementar la estima personal y auto-realizarse. Sin embargo, como ya se comentó, en las estructuras muy planas, las personas pueden tener menos hitos en su carrera por las que medir su progresión. La vara de medir que aún permanece es el dinero u otros símbolos de status dentro de la compañía.

Reconocimiento profesional: Otra medida de la realización es el reconocimiento profesional. Los ingenieros del software no quieren el anonimato del burócrata, quieren acumular méritos que contribuyan a su autoestima y a su realización. Los directores de línea son los responsables de asegurar que sus subordinados reciben el reconocimiento debido.

Teoría de la Motivación e Higiene de Herzberg Frederick Irving Herzberg fue un renombrado psicólogo que se convirtió en uno de los hombres más influyentes en la gestión administrativa de empresas. Es especialmente reconocido por su teoría del enriquecimiento laboral y la teoría de la Motivación e Higiene. Herzberg propone dos tipos de factores que influyen sobre la motivación en el trabajo, los factores de higiene (previenen la No satisfacción) y los factores de auténtica motivación (motivan). Los factores de higiene son factores que influyen negativamente sobre el trabajador y que, una vez corregidos, colocan a la persona en un nivel 0 de No insatisfacción. Son factores de higiene por ejemplo la política de empresa, la supervisión, el sueldo o el status en el trabajo. Contrariamente a lo que se pueda creer el sueldo, por ejemplo, no es un factor motivador, sino desmotivador, es decir, si una persona siente que está cobrando menos de lo que debería se siente insatisfecha y su motivación decae, por el contrario, si su sueldo es adecuado se siente conforme pero no necesariamente se motiva en exceso. Por ese motivo los factores de higiene, aunque no motivan propiamente, deben ser tratados para “limpiar” el entorno de trabajo o la situación del trabajador de forma que no se desmotive, mientras que los factores de motivación (como pueden ser el reconocimiento, la responsabilidad o un ascenso) son los que verdaderamente aumentan la motivación y ganas por cumplir un objetivo.  Factores de higiene  Seguridad.  Sueldo.  Relación con el supervisor.  Beneficios y servicios sociales.

16

 Factores de motivación  El trabajo en sí mismo  El Reconocimiento.  La Responsabilidad.  Progresión profesional.

Desarrollar el Equipo de Proyecto El desarrollo del equipo de proyecto tiene como finalidad lograr la cohesión del grupo de trabajo a efectos de lograr los mejores intereses del proyecto e incrementar el rendimiento del proyecto. Analicemos el concepto de confianza, una pregunta que deberíamos hacernos es si existe confianza en el proyecto. ¿El equipo siente que el Líder de Proyecto está trabajando por los mejores intereses del proyecto, de la organización y de ellos mismos o siente que solo está trabajando por sus intereses personales? La confianza debe ser ganada y mantenida desde el primer minuto que se incorpora cada miembro al equipo. Si no existe confianza en el Líder de Proyecto difícilmente el proyecto será exitoso, ya que el equipo no seguirá las indicaciones del Líder y el proyecto sufrirá las consecuencias. La mejor forma de lograr la cohesión de un equipo de proyecto es logrando su confianza y estableciendo y cumpliendo con un sistema claro de recompensas.

Capacitación del Equipo de Proyecto Cualquier capacitación o entrenamiento para los miembros del equipo de proyecto, con el objetivo de mejorar el rendimiento y las posibilidades de éxito del mismo, debería estar incluida en los costos del proyecto. El Project Manager debe buscar tales oportunidades, no solo para la ayuda y el buen ánimo de los miembros del equipo, sino también para lograr el decremento global de los costos y plazos por la mejora de eficiencia en el logro de los objetivos.

Reglas Básicas Las reglas básicas establecen expectativas claras acerca del comportamiento aceptable por parte de los miembros del equipo del proyecto. El compromiso con pautas claras desde las fases tempranas

17

reduce los malos entendidos y aumenta la productividad. El proceso de discutir las reglas básicas permite a los miembros del equipo descubrir valores que son importantes para unos y otros. Todos los miembros del equipo del proyecto comparten la responsabilidad de aplicar las reglas una vez establecidas.

Equipos Virtuales o Reubicación Los equipos de trabajo virtuales son aquellos cuyos miembros no se encuentran trabajando habitualmente en el mismo lugar físico, por lo que rara vez o tal vez nunca lleguen a conocerse personalmente. Es difícil para muchos gestores de proyecto dirigir esta tipología de equipos, debido a que es muy difícil conseguir la cohesión y el compromiso de equipo cuando los miembros no están por lo general cara a cara, creando conflictos, disminuyendo la productividad y otros impactos que afectan a los plazos y al costo del proyecto. En lo posible se debe conseguir que el equipo trabaje físicamente en el mismo lugar, siendo lo óptimo que todo el equipo trabaje inclusive en las mismas oficinas, logrando lo que se conoce como “war room” o la habitación donde se da la batalla del proyecto. La relocalización del equipo en un mismo lugar tiene efectos muy positivos ayudando a la comunicación, disminuyendo el impacto de los conflictos y mejorando la identidad de grupo del equipo de proyecto.

Reconocimientos y Recompensas Es necesario que los métodos de evaluación y los consiguientes reconocimientos y recompensas sean conocidos por todos los interesados del proyecto. Debería recompensarse sólo el comportamiento deseable. Por ejemplo, debería recompensarse o reconocerse la buena disposición para trabajar horas extra a fin de cumplir con un objetivo agresivo del cronograma, pero no debería recompensarse la necesidad de trabajar horas extra como consecuencia de una planificación deficiente. Las recompensas ganarperder (suma cero) que sólo una cantidad limitada de miembros del equipo del proyecto pueden lograr, tales como el miembro del equipo del mes, pueden perjudicar la cohesión del equipo. Recompensar el comportamiento ganar-ganar que todos pueden lograr, tales como presentar puntualmente los informes de progreso, tiende a aumentar el respaldo entre los miembros del equipo.

18

Valoración del Rendimiento del Equipo La valoración de rendimiento del equipo es realizada por Project Manager para evaluar e incrementar la efectividad del equipo de proyecto como un todo. Es necesario pensar la valoración de rendimiento del equipo como “efectividad del equipo”. Esto puede incluir una evaluación de la mejora de las habilidades para desarrollar las actividades del proyecto por parte de los miembros del equipo, como interactúan y resuelven conflictos, y tasas de productividad. Una novedosa y sofisticada forma de evaluación para completar las evaluaciones de desempeño es incluir los compañeros de trabajo y subordinados, como así también de los supervisores. Esto puede resultar en un panorama más claro utilizando los principios de retroalimentación de 360 grados. El término “360 grados” significa que la persona que está siendo evaluada recibe retroalimentación sobre su rendimiento desde muchas fuentes, incluidos los superiores, colegas y subordinados.

Gestionar el Equipo de Proyecto Gestionar el equipo de proyecto es completamente distinto a desarrollar el equipo de proyecto. Con el objetivo de gestionar el equipo de proyecto el Project Manager deberá:     

Observar Utilizar una agenda de temas Mantenerse en contacto Completar las evaluaciones de rendimiento del proyecto Involucrarse activamente en buscar y ayudar a resolver los conflictos que el equipo no pueda resolver por cuenta propia

La gestión del equipo se realiza durante el proceso de monitoreo y control del proyecto y fija su atención en la evaluación de desempeño del equipo de proyecto. Esto puede ser algo que no se haga habitualmente en la mayoría de los proyectos, ya que a nadie le gusta ser medido en su desempeño ni medir el desempeño de los demás, pero si no se realiza el proyecto sufrirá las consecuencias de las fallas de cualquier miembro del equipo. La buena gestión de proyectos precisa que el equipo de proyecto ayude en la creación del plan de gestión del proyecto. Como resultado de esto, es más aceptable que sean medidos por aquello que ayudaron a estimar o

19

definir como metas. Si se tienen dificultades para conseguir apoyo o cooperación, podría suceder porque existe falta de confianza, porque existe un sistema pobre de reconocimientos o recompensas o aún más grave, porque el equipo de proyectos y los interesados en el proyecto no fueron tenidos en cuenta en la creación del plan de gestión del proyecto. Otra razón para medir el rendimiento de los miembros del equipo es para el beneficio de cada uno de los miembros. Es necesario pensar en la disminución de la confianza y de la motivación del equipo, más la angustia y otros efectos que genera, que una persona no esté realizando lo que se espera, mientras los demás cumplen con lo acordado.

Observación y Conversación La observación y la conversación se usan para mantenerse en contacto con el trabajo y las actitudes de los miembros del equipo del proyecto. El Project Manager debe observar lo que pasa y mantener informado al resto del equipo de lo que pasa.

Evaluaciones del Rendimiento del Proyecto La evaluación de los rendimientos de los empleados para aquellos que los supervisan es común en la práctica de negocios del mundo entero. La necesidad de realizar evaluaciones formales o informales del rendimiento del proyecto depende de la duración del proyecto, de la complejidad del proyecto, de la política de la organización, de los requisitos de los contratos de trabajo, y de la cantidad y calidad de la comunicación regular. El Project Manager puede ajustar el proyecto para manejar los cambios de rendimiento basado en estas evaluaciones.

Agenda de Temas Es común que los Directores de Proyectos mantengan una agenda de temas a ser resueltos en el proyecto, siendo esta una herramienta para el manejo de las necesidades de los interesados (Stakeholders) y el equipo de proyecto. Esta agenda de temas les muestra a los interesados que sus necesidades son tenidas en cuenta, aun cuando el tiempo para cumplir con ellas pueda ser escaso.

20

Gestión de Conflictos Una gestión de conflictos exitosa tiene como resultado una mayor productividad y relaciones laborales positivas. Fuentes de conflicto incluyen recursos escasos, prioridades del cronograma y estilos de trabajo personales. Las reglas básicas del equipo, las normas de grupo y las prácticas de dirección de proyectos sólidas, como la planificación de la comunicación y la definición de roles, reducen la cantidad de conflictos. Si se manejan apropiadamente, las diferencias de opinión son saludables y pueden llevar a una mayor creatividad y a una mejor toma de decisiones. Cuando las diferencias se convierten en un factor negativo, los miembros del equipo del proyecto son inicialmente responsables de resolver sus propios conflictos. Si el conflicto se intensifica, el director del proyecto debería ayudar a facilitar una resolución satisfactoria. Los conflictos deberían tratarse en las fases tempranas y por lo general en privado, usando un enfoque directo y constructivo. Si continúan los conflictos negativos, será necesario recurrir a procedimientos cada vez más formales, incluida la posibilidad de adoptar acciones disciplinarias. (PMBoK, PMI). Las preguntas que suelen surgir son: ¿Es malo el conflicto? ¿Debería invertir tiempo en prevenir los conflictos? ¿Quién debe resolver el conflicto?

Aunque la mayoría de los conflictos pueden percibirse como malos, generalmente presentan una oportunidad de mejora ya que el proceso de resolución pone de manifiesto información oculta del equipo y del proyecto.

5.5 Caso para estudio Estudio de caso sobre delegación de autoridad, conflictos y Gerente de proyecto. (Adaptado de propuesta de Guido Clements) Codeword es una empresa de tamaño medio que diseña y fabrica sistemas electrónicos para aeronaves militares. Compite con otras empresas para obtener contratos para suministrar esos sistemas. Su principal clientes es el gobierno. Cuando Codeword recibe un contrato, crea un proyecto para terminar el trabajo. La mayor parte de los proyectos oscilan desde los 10 a los 50 millones de dólares en costo y de 1 a 3 años de duración. Codeword puede tener en cualquier momento de 6 a 12 proyectos en proceso, en diversas etapas de terminación.

21

Codeword tiene un pequeño grupo de gerentes de proyectos que depende del Gerente General; otras personas dependen de su gerente funcional. Por ejemplo, los Ing. Electrónicos dependen del Gerente de Ingeniería Electrónica, quien a su vez depende del Gerente General. El Gerente. Funcional asigna personas específicas para trabajar en diversos proyectos, algunos de tiempo completo en un proyecto, mientras que otros dividen los tiempos entre 2 o más proyectos. Jack ha estado en la compañía aproximadamente 8 años, desde que se graduó en la universidad en Ing. Electrónica. Ha ido ascendiendo hasta ser el principal Ing. Electrónico y depende del Gerente de Ing. Electrónica. Ha trabajado en muchos proyectos y es muy respetado en la empresa. Jack ha estado pidiendo la oportunidad de ser gerente de proyectos. Cuando se le otorgó a Codeword un contrato de 15 millones de dólares para diseñar y fabricar un sistema electrónico avanzado para una nueva aeronave, el Gerente ascendió a Jack a Jefe de Proyectos y le pidió dirigir este proyecto. Jack trabaja con los gerentes funcionales para lograr que se asigne al proyecto el mejor personal disponible. La mayoría de estas personas son amigos de Jack que han trabajado con él en proyecto anterior. Sin embargo, al estar vacante el puesto de Jack como principal Ing. Electrónico, el Gerente de Ingeniera Electrónica no tiene a nadie con el nivel de conocimientos apropiados para asignarlo al proyecto de Jack. Por lo tanto el Gerente contrata a una nueva persona, Alfreda. Atraída de un competidor, tiene un doctorado en Ing. Electrónica y 20 años de experiencia. Pudo obtener un sueldo más alto (más que el que Jack inclusive) y es asignada de tiempo completo al proyecto de Jack. Jack está muy interesado en el trabajo de Alfreda, y pide a diario reuniones con ella para discutir sus enfoques del diseño. Sin embargo la mayor parte de estas reuniones se convierten en monólogos de Jack sugiriendo como debe hacerse el diseño y prestando poca atención a lo que ella dice. Por último, Alfreda le pregunta a Jack por qué está dedicando más tiempo a revisar su trabajo que el de otros Ing. del Proyecto. Él le responde “No tengo que revisar el trabajo de ellos, ya sé cómo lo hacen. He trabajado con ellos en otros proyectos. Usted es nueva en el grupo y quiero estar seguro de que comprenda como hacemos que las cosas, quizás sea diferente a como lo hacía en su trabajo anterior.”

22

En otra ocasión, Alfreda le muestra a Jack lo que ella piensa que es su enfoque de diseño creativo que dará como resultado un sistema de costos más bajo. Jack le dice “Yo ni siquiera tengo un doctorado y puedo ver que eso no resultará. No sea tan esotérica y apéguese a la ingeniería clásica básica. Durante un viaje con Denis, otro ingeniero del proyecto, que ha conocido a Jack desde hace 6 años, Alfreda le dice que se siente frustrada por la forma en que Jack la trata. Ella le dice a Denis “Jack está actuando más como si él fuera el Jefe de Ing. Electrónica y no como el Gerente de Proyecto. Además yo he estudiado más sobre diseños electrónicos de lo que Jack nunca supo en su vida. El realmente no está actualizado en metodología de diseños electrónicos. También le dice a Denis que está pensando discutir este asunto con el Gerente de Ing. Electrónica y que nunca hubiera aceptado el trabajo en Codeword si hubiera sabido que iba a ser así.

Reflexione sobre el caso: ¿Piensas tú que Jack está listo para desempeñarse como Gerente de Proyectos? ¿Por qué si o Porque no? ¿Cómo pudo haberse preparado Jack para su nuevo papel? ¿Cuál es el principal problema de la forma en que Jack interactúa con Alfreda? ¿Porque piensas tú que Alfreda no ha tenido una discusión franca con Jack sobre la forma en la cual la trata? Si Alfreda aborda directamente a Jack ¿Cómo piensas que responderá Jack? ¿Cómo piensas tú que responderá a esta situación el Gerente de Ing. Electrónica? ¿Por qué debe hacerlo? ¿Qué puede hacer para poner un remedio a esta situación? ¿Qué se pudo haber hecho para evitar la situación?

23

6. Gestión de Las Comunicaciones Del Proyecto La mayoría de los estudios realizados destacan que las comunicaciones son el aspecto número uno que un Project Manager tiene que abordar en un proyecto. Es necesario entender la importancia de este tema, ya que entre el 75% y el 90% del tiempo de un Project Manager se invierte en comunicaciones. Un Project Manager principiante podría hacer podo en lo referente a las comunicaciones, remitiéndose solamente a emitir reporte de estado. Directores de Proyecto más experimentados o con más capacidad, dedicarán tiempo a crear un plan de comunicaciones y emitirán algo más que solo reportes de estado. Los grandes profesionales de la Gestión de Proyectos, además de las dos acciones previas definidas, le pedirán a los stakeholders que definan lo que ellos necesitan que les sea comunicado, identificarán que comunicaciones necesitan de los stakeholders, y periódicamente revisarán las comunicaciones con el equipo de trabajo. Cualquier persona implicada en el proyecto debe estar preparada para enviar y recibir comunicaciones en el lenguaje del proyecto y debe comprender que estas comunicaciones afectan al proyecto.

6.1 Planificación de las comunicaciones La planificación de las comunicaciones implica determinar las necesidades de información y comunicaciones de los stakeholders del proyecto. Esto incluye determinar lo que necesita ser comunicado, a quien, cuando, con que método y cuan frecuentemente. Se debe entender la importancia que tienen para esto las variables de entorno de la organización, tales como la cultura organizacional y los estándares de trabajo. Se deben entender también los procesos y procedimientos para conducir el trabajo y las comunicaciones, los registros históricos de procesos previos, como así también las lecciones aprendidas y cualquier otra información almacenada. En una etapa temprana del proceso de gestión de proyectos, todos los stakeholders deberán haber sido identificados así como también sus

24

requerimientos y expectativas. Los requerimientos no solo deberían relacionarse con lo que el producto del proyecto debe hacer, sino que también deberían incluir las necesidades y tipos de comunicación.

Con quien nos comunicamos Es importante tomar conciencia respecto de que la comunicación no solo unidireccional. Durante cada momento de la planificación del proyecto, el equipo de proyecto habrá tenido alguna oportunidad de interactuar con otros stakeholders. ¿Alguno de los stakeholders ha identificado algún grupo de riesgos potenciales para el proyecto? ¿Por qué entonces no reunirse con ellos en forma periódica, a través del proyecto, para ver si se han identificado nuevos riesgos? ¿Hay algún miembro del equipo inseguro de llegar a cumplir con las tareas que le fueron asignadas en tiempo y en forma? ¿Porque no establecer alguna forma de capacitación o determinar alguna lectura que pueda ayudar al miembro del equipo?

Figura 3.2: Objetivos de comunicación del proyecto

Modelo de comunicaciones Como sistema, la comunicación es divergente, teniendo la capacidad para expandirse centrífugamente, en función de la autonomía de sus elementos. El gestor de proyectos, a lo máximo que puede tratar de llegar, es a coordinar aquellas “informaciones” que, viniendo de cualquiera de los integrantes (elementos o subsistemas), sean relevantes para el proyecto y sea necesario poner en común, con el papel de tratar de regular todas aquellas emisiones que sea posible regular, así como el de transformarlas en “comunicación”, para obtener la máxima eficiencia de ellas.

25

Figura 3.3: Universo de la comunicación y la documentación (Fuente: Gestión Integrada de Proyectos, Marcos Serer Figueroa, 2001)

La complejidad que representa el que cada uno de los actores pueda actuar haciendo uso de su facultad de “informar” y no tanto de “comunicar”, así como la dificultad del gestor de proyectos de hacer posible el que todos los actores dispongan de la información precisa para hacer bien su trabajo, puede verse reflejada en la figura 3.3. Un modelo básico de comunicación, que aparece en la Figura 5.3, demuestra cómo se envían y reciben las ideas o la información entre dos partes, definidas como emisor y receptor. Los componentes clave del modelo incluyen:  Codificar. Traducir los pensamientos o las ideas a un lenguaje que otras personas puedan comprender.  Mensaje. La salida de la codificación.  Medio. El método usado para transmitir el mensaje.  Ruido. Todo lo que interfiere en la transmisión y comprensión del mensaje (por ejemplo, la distancia).  Decodificar. Traducir el mensaje nuevamente a pensamientos o ideas con sentido. Cada mensaje es codificado por el emisor y decodificado por el receptor. Esta decodificación por parte del receptor estará basada en la educación,

26

experiencia, lenguaje y cultura del mismo. El acuse de recibo significa que el receptor señala la recepción del mensaje, pero no necesariamente que esté de acuerdo con el mismo. Otra acción es la respuesta a un mensaje, lo que significa que el receptor decodifica, comprende y responde al mensaje (PMBoK, PMI, 3º Edición).

Figura 3.4: Comunicación – Modelo Básico (Fuente: PMBoK 3º Edición, PMI, 2004)

Independiente de las posibilidades múltiples de información abiertas, el gestor del proyecto debe proceder a establecer una serie de actividades que, en general, contemplen: Informes para el cliente o sponsor en los que:      

Explique la situación Prevenga de sucesos negativos cuando es necesario Haga análisis previsionales de los objetivos Deje constancia de hechos de interés Sugiera caminos a seguir El procedimiento de trabajo adoptado probablemente sugerirá la celebración de reuniones, de las cuales levantará acta que remitirá a cada uno de los asistentes. Si de ella derivara alguna información para otro actor que no hubiera asistido, preparará un informe, carta, etc. con la información, que hará llegar al interesado.  A partir de la información recibida de alguno de los actores, que sea útil para los otros, redactará un documento que distribuirá a quien corresponda. Y, fundamentalmente respecto al equipo de proyecto, se preocupará de que éste disponga de la información necesaria, que pueda provenir del resto de los stakeholders. Como el resto de elementos de un sistema, la comunicación depende mucho de la filosofía que debe imperar en el proyecto y de la estrategia establecida.

27

La estrategia, por ejemplo puede condicionar el tipo de comunicación que debe implementarse con los actores externos al proceso (administraciones públicas, prensa, etc.). En cualquier caso, la base de la comunicación siempre es la comunicación verbal, que permite mantener uno de los lineamientos genéricos de la Gestión de Proyectos como es el de la “motivación”. Pero, evidentemente la comunicación escrita es la que formaliza la gestión, dejando constancia de lo que conviene y sirviendo de recordatorio de las actuaciones comprometidas por cada uno de los actores. Se puede enfocar también la comunicación en función de la dirección que lleva. En ese sentido se puede hablar de comunicación “externa”, que va dirigida a los actores más externos al proceso e “interna”, dirigida a los stakeholders directamente involucrados en el proyecto. En todos los casos, el principio básico es el de la idea de la bidireccionalidad aludida anteriormente, que se refiere a la práctica que lleva a que cada vez que se informa se asegure que el interlocutor ha recibido la información y que es consciente de ello.

Figura 3.5: Tipos de comunicación (Fuente: Gestión Integrada de Proyectos, Marcos Serer Figueroa, 2001)

28

En cuanto a la comunicación entre los miembros del equipo, se hace fundamentalmente a través de reuniones de coordinación que suelen ser realizadas formalmente antes de las reuniones de seguimiento con el cliente y/o sponsor. Son reuniones en las que se intenta unificar criterios de actuación para con el resto de los interesados y revisar el estado de los objetivos, así como los medios que deberían utilizar el propio equipo o el resto de los stakeholders para corregir aquellos aspectos que deban ser corregidos. En todo caso las conclusiones de esas reuniones, así como las tareas a realizar deben estar reflejadas por escrito, a través de instrucciones y actas que puedan quedar registradas dentro del correo electrónico interno. La comunicación se realizará en muchas dimensiones tales como:    

Escrita u Oral Interna o Externa Formal o Informal Vertical u Horizontal

Comunicación efectiva Lograr una comunicación efectiva implica que el emisor debe codificar el mensaje cuidadosamente, determinar el método de comunicación a ser utilizado para enviar el mensaje y confirmar que el mensaje es entendido. Debe comprenderse claramente que el corazón de la comunicación no son las palabras sino la comprensión y que se trata de una acción multidireccional, no solo ser entendido, sino también entender. La mitad del trabajo de hacer que una comunicación sea efectiva es “escuchar”

Escucha efectiva El receptor debe decodificar el mensaje cuidadosamente y verificar que ha entendido el mensaje. Esto incluye observar al que habla, para descubrir gestos físicos y expresiones faciales, pensando en lo que se quiere decir antes de responder, ya sea para preguntar, pedir repetición o retroalimentación.

Barreras comunes para escuchar con efectividad Mucha parte de la verdadera y completa información que nos debiera interesar puede perderse por causa de algunas barreras creadas por nosotros mismos a la hora de escuchar:

29

    

Fingir escuchar Distracciones Prejuicio y mentalidad estrecha (escucha selectiva) Impaciencia Saltar a conclusiones prematuramente

Debemos prestar mucha atención a estas barreras, puesto los mensajes podrían llegarnos debilitados o distorsionados a causa de ellas. Plantearemos a continuación algunas sugerencias para mejorar las habilidades de escuchar:  Centrar la atención en la persona que habla  Participar en una escucha activa: El receptor confirma lo que ha entendido, acordando o pidiendo ampliación del tema.  Hacer preguntas  No interrumpir  Buscar Retroalimentación: Frases del tipo “No termino de entender, ¿podría aclararme lo que acaba de decir? Ayudan a reafirmar el entendimiento del mensaje. Finalmente, no debemos olvidar que: “El escuchar debe ser un proceso ACTIVO, que aumenta la comprensión y reduce el conflicto“

Canales de Comunicación Cada vez que se agrega una persona al equipo, las comunicaciones crecen exponencialmente. Los canales de comunicación en un equipo pueden calcularse con la siguiente formula: [N (N-1)] / 2 donde N es igual al número de personas. Si lo vemos en un ejemplo: si se tiene 4 personas en un equipo, ¿Cuántos canales de comunicación hay? Utilizando la fórmula se tendrá [4(4-1)]/2 = 6

Figura 3.6: Cantidad de canales de comunicación para un equipo de 4 personas

30

Tipos de comunicación La comunicación, en términos generales, se puede clasificar, desde el punto de vista de la forma: oral y escrita, y desde el punto de vista de los actores intervinientes: externa e interna.

Comunicación verbal Se lleva a cabo de manera formal en reuniones, que pueden ser de seguimiento o reuniones técnicas o en encuentros o contactos informales de diversa índole. A lo largo del ciclo del proyecto se producen innumerables reuniones de tipo informal, que actúan de preparación para las formales, de explicación de decisiones, y en general estos contactos son catalizadores – en algún caso – y provocadores en otros, de temas y situaciones que se inician o se definen. Uno de los problemas que tiene la comunicación verbal – sobre todo la informal – es el tiempo que consume y por ende la no disponibilidad del mismo para otros asuntos que deben resolverse. A pesar de ello, este tipo de comunicación consigue que se puedan sacar conclusiones y obtener datos que es muy difícil se consigan por la vía de la comunicación escrita. Un gestor de proyectos, puede, a través de una comunicación verbal estructurada llegar a saber realmente:  Las causas de los conflictos en los equipos  Los sentimientos de los miembros del proyecto, que en algún momento pueden atentar contra la integridad del equipo.  Las verdaderas causas de por qué un proveedor se está retrasando  El grado de conformidad de un cliente con la actuado en la gestión del proyecto  Qué objetivos (realmente) son los que interesan  Los motivos políticos de algunas decisiones  Otros La comunicación escrita es de suma importancia y por ello debe ser concienzudamente planificada, desarrollándose constantemente; todo esto sin dejar de ver que es fundamental poner especial énfasis en todo lo que significa el contacto personal del equipo de gestión y preferentemente del propio gestor con el resto de los interesados, fundamentalmente con el sponsor y el cliente si no fueran la misma persona. Recordemos, el contacto que genera esa “información biunívoca” sin duda va a ser la que

31

marcará las vías de entendimiento y confianza entre las partes. Posteriormente, serán los hechos los que darán crédito a todo lo hablado; pero una buena comunicación con entendimiento personal allana los problemas, replantea los errores y agranda los aciertos, dando a los resultados la justa premiación en función, también, de los esfuerzos realizados. Es evidente que en las relaciones humanas, la empatía fomenta el entendimiento, haciendo que las personas se comuniquen mejor, dejando de lado otras consideraciones más visibles: conocimientos, trabajo y racionalidad en general. Esta última consideración podría inhabilitar a algunos gestores de proyecto para que tengan una buena comunicación verbal con algunos de los interesados. En la elección de un buen director de Proyecto las habilidades de comunicación serán decisivas. En todo caso, siempre existe la posibilidad de encarar un aprendizaje para desarrollar la habilidad de “comunicar” y escuchar de manera efectiva. El “deseo” de estar motivado y de motivar es un valor importante, susceptible de generar confianza, y por ende un buen argumento para lograr una buena comunicación. Reuniones de seguimiento y coordinación: son las que se realizan a lo largo del ciclo de vida del proyecto de manera continuada y estructurada, realizando el seguimiento de los trabajos que se van desarrollando. Los temas que se suelen tratar son, entre otros, los siguientes:  Lectura y aprobación, si cabe, del acta de la reunión anterior. Lectura del orden del día y solicitud de tratamiento de otros puntos.  Comunicación del gestor o sponsor/cliente a todos los interesados involucrados directamente.  Puntos críticos a debatir.  Repaso del estado de las tareas que, de acuerdo con la planificación, se están desarrollando. Exposición de detalles, si cabe, por parte del especialista. Problemas que hayan surgido y que deban presentarse a la mesa para su conocimiento o resolución.  Estado de la planificación. Comentarios sobre medidas a adoptar en caso de desviaciones.  Estado del plan de costos. Comentarios sobre medidas a adoptar en caso de desviaciones.  Estado del cumplimiento de otros objetivos: diseño, calidad, riesgos, licencias, etc.  Listado de temas pendientes por resolver y plan de actuación con responsables para cada uno de los asuntos.

32

Uno de los objetivos de las reuniones de coordinación es el de servir de impulso a acciones que posteriormente, de manera formal o informal, se desarrollarán a lo largo del periodo que media hasta la próxima reunión. La cadencia de las reuniones depende del tipo de proyecto. Para proyectos de investigación pueden establecerse mensualmente o quizás más a menudo. Para proyectos de consultoría, depende también del tiempo total, pero pueden hacerse cada dos o tres semanas. Para proyectos de ingeniería, es normal que se realicen cada una o dos semanas. Las reuniones técnicas no suelen revestir la periodicidad tan inflexible como las de coordinación, sin embargo no por ello son menos importantes. De hecho, en muchos proyectos, son las que auténticamente resuelven los problemas, de modo que hay que fomentarlas. Tanto estas reuniones como las de coordinación es conveniente que acaben en un documento escrito que resuma el contenido de lo hablado. Las comunicaciones exclusivamente verbales pueden desarrollarse tanto a nivel interno (entre interesados próximos al proyecto), como a nivel externo, con otros que, aun que tengan singular importancia, no están directamente involucrados – con dedicación expresa – en el proyecto. El documento de cierre de la reunión, normalmente conocido como Minuta, deberá contener al menos: los participantes y los ausentes (puesto que si fueron convocados deben enterarse del resultado), los temas tratados, las resoluciones tomadas, las acciones a seguir y el responsable de llevarlas a cabo.

Comunicación escrita Es por naturaleza la más estructurada y clara pues en ella debe quedar reflejado todo el ciclo con sus pasos, propuestas y decisiones. Son el diario y el recordatorio para todos los actores y, por su propia condición, resultan insustituibles en el seguimiento técnico, económico o legal del proceso. La visión sistémica en la resolución de los problemas, y en general al afrontar un conflicto, también se lleva a cabo en el sistema de comunicación; es por ello que se utilizan diferentes vías que, de por sí, también reflejan distintos sistemas con sus reglas de actuación y formas concretas. Así es como aparecen los sistemas de informes, actas, cartas, faxes, correo electrónico, libros de órdenes, libros de incidencias y notas de órdenes en los momentos de la realización del proyecto. Como es lógico, no sólo el gestor del proyecto genera información escrita; también lo hacen el resto de interesados directos del proyecto.

33

Plan de Gestión de las Comunicaciones Las comunicaciones, al igual que otros aspectos importantes deben ser planificadas, el resultado palpable de ese proceso de planificación es el Plan de Gestión de las Comunicaciones, que es valioso y muy necesario, aun en los proyectos cortos. Este Plan documenta como se gestionarán y controlarán las comunicaciones, ya que generalmente la información a ser distribuida suele ser muy extensa. El plan de gestión de las comunicaciones proporciona:  Requisitos de comunicaciones de los interesados  Información que debe ser comunicada, incluidos formato, contenido y nivel de detalle  Persona responsable de comunicar la información  Persona o grupos que recibirán la información  Métodos o tecnologías usadas para transmitir la información, como memorandos, correo electrónico y / o comunicados de prensa  Frecuencia de la comunicación, por ejemplo, semanal  Proceso de escalamiento, identificando los plazos y la cadena de mando (nombres) para el escalamiento de polémicas que no puedan resolverse a un nivel inferior del personal  Método para actualizar y refinar el plan de gestión de las comunicaciones a medida que el proyecto avanza y se desarrolla  Glosario de terminología común. El plan de gestión de las comunicaciones también puede incluir pautas para reuniones sobre el estado del proyecto, reuniones del equipo del proyecto, reuniones electrónicas y correo electrónico. El plan de gestión de las comunicaciones puede ser formal o informal, muy detallado o ampliamente esbozado, dependiendo de las necesidades del proyecto. El plan de gestión de las comunicaciones está incluido en el plan de gestión del proyecto general, o es un plan subsidiario de éste. Entre los atributos de un plan de gestión de las comunicaciones se pueden incluir:  Elemento de comunicaciones. La información que será distribuida a los interesados.  Finalidad. Motivo de la distribución de dicha información.  Emisor.  Destinatario/s.  Frecuencia. Cada cuánto tiempo se distribuirá la información.  Fechas de inicio / finalización. Plazo para la distribución de la información.  Formato / medio. El diseño de la información y el método de transmisión.  Responsabilidad. El miembro del equipo encargado de la distribución de la información.

34

La Planificación de las Comunicaciones a menudo implica la creación de productos entregables adicionales que, a su vez, requieren tiempo y esfuerzo adicionales. Por consiguiente, la estructura de desglose del trabajo del proyecto, el cronograma del proyecto y el presupuesto del proyecto deberán actualizarse según corresponda.

6.2 Distribución de la información Ya sabemos que la comunicación es probablemente una de las actividades más importantes que debe llevar adelante el Director de proyecto, para ello será necesario distribuir información en sus diferentes formas:

Informes Son el instrumento más común y estandarizado del que se sirve un gestor de proyectos para mantener una comunicación escrita con todos los interesados y especialmente con el cliente, o sponsor. De hecho, los informes se suelen remitir exclusivamente al sponsor/cliente, pero según el escrito de que se trate y la filosofía definida al principio para la relación entre las partes, se editan copias para otros actores que interesa que conozcan el contenido. Las carátulas de los informes es conveniente que dispongan de una información mínima que permita una rápida identificación y su posterior archivo. Sobre los informes hechos por otros stakeholders, se propondrá la inclusión del mismo tipo de identificación para favorecer un archivo conjunto tanto por parte del cliente como por interés propio. Aunque para el archivo propio, y en cualquier caso, si no viene con la identificación prevista por imposibilidad de obligar a su cumplimiento (administraciones públicas por ejemplo) se deberá incluir a mano cuando llegue a disposición de la oficina de Gestión de Proyectos. Los tipos más interesantes para conocer son: Informes generales y periódicos de seguimiento del proyecto, que son informes que según el tipo de proyecto y su duración, tienen usualmente un carácter quincenal, mensual o bimensual. El informe suele apoyarse en documentación gráfica (diagramas, croquis, esquemas, etc.) que ayudan a una comprensión rápida de la situación. El receptor del informe suele ser el interlocutor ordinario por parte del cliente y los informes suelen ser más frecuentes durante la puesta en marcha del sistema, ya que en las fases de requerimientos, diseño, desarrollo y mientras se hace el proyecto, en la fase de implementación,

35

suele ser más frecuente informar y comunicar a través de las actas de reuniones o los informes específicos. Dos aspectos que convendrían resaltar de un informe periódico de seguimiento son los relativos a los puntos críticos que hay que acometer y que con frecuencia involucran al propio cliente; y otro asunto interesante es el apartado que intenta hacer una extrapolación de lo que ocurrirá de seguir la misma tendencia en el trabajo que se esté realizando hasta esa fecha. Como medida práctica, además se hace una extrapolación para todo el proyecto, se aconseja concretar lo que ocurrirá en los próximos 30 días (cuando no, menos) a la edición del informe. Otro tipo de informe son los informes ejecutivos, que conforman documentos de un número escaso de hojas, dirigidos a la presidencia o dirección general del cliente, o al sponsor, que pretende resumir en no demasiados párrafos y de forma bastante gráfica y sintética, el estado de la cuestión, abordando aspectos claves del proyecto. Lo ordinario es que los aspectos clave de este tipo de informes se refieran al presupuesto y al plazo, pero no están descartados otros objetivos que, en todo caso, se acuerdan con el cliente y más concretamente con el receptor final. Lo trascendente es, en definitiva, que el gestor del proyecto sepa qué tipo de informes resultan de utilidad, dejando aquellos aspectos que complican la lectura o no añaden nada efectivo al análisis para la toma decisiones o para el conocimiento de lo que existe. Estos informes se suelen hacer a lo largo de todo el ciclo de vida del proyecto. También a lo largo de todo el ciclo, se realizan informes específicos sobre temas diversos que corresponden a diferentes aspectos del proyecto que interesa que conozca el cliente, o algún otro de los interesados. Así por ejemplo se suelen hacer informes sobre la marcha concreta de la construcción de algún elemento específico durante el desarrollo, sobre la evolución del costo de una parte significativa del proyecto, sobre la revisión de las hipótesis de diseño de algún elemento, etc. Se hacen informes que hablan del costo, de la seguridad, de la calidad, del alcance, del plazo, etc. Entre ellos, unos que revisten singular importancia son los que definen bases de inicio o hipótesis de partida del trabajo de cada miembro del equipo de proyecto que responden a deseos expresos del sponsor/cliente o a objetivos a cumplir. Estos informes se llevan por el gestor a las reuniones de inicio y se solicita oficialmente al cliente la validación y al interesado que sea, su aceptación expresa. En esa reunión se levanta el acta correspondiente para que se formalice la situación.

36

Actas de reunión Se pueden considerar como un tipo de informe más, lo que facilita un archivo conjunto de los documentos. La preparación de la reunión se hace a través del orden el día que el gestor debe emitir unos días antes del previsto para la reunión, y enviarlo a todos los interesados. Este documento preparatorio incluirá el día, la hora de inicio, los asuntos a tratar con el tiempo asignado para cada uno de ellos, así como los asistentes previstos. Las actas las redacta el gestor y deben reflejar un resumen de lo hablado con indicación de:  Aprobación de la lectura del acta de la reunión anterior, o en su caso la introducción de las modificaciones a que hubiera lugar. De su lectura pueden inducirse reflexiones que, o bien se resuelven porque pertenecen a lo tratado el día anterior o bien se dejan para ser tratados según el orden del día previsto para ese momento.  Si hay temas urgentes, lo lógico es que sean los primeros en ser tratados.  Si hay un asunto específicamente mencionado por uno de los actores, se indicará cuál es la fuente.  Para cada asunto es recomendable, indicar el objeto de su tratamiento: para información o para que algún otro actor acometa alguna acción (en ese caso, se citará al actor).  Se suele dejar constancia de los asuntos pendientes, si los hay, así como la fecha de su posible tratamiento si es posible. De las actas, una vez escritas, se ha de enviar una copia a cada uno de los integrantes de la reunión autorizados para ello y al cliente en cualquier situación.

Cartas, faxes y correo electrónico Muchas de las comunicaciones que hasta hace pocos años eran verbales, han pasado, en los últimos tiempos, a ser escritas a la luz de la facilidad que los medios han provocado para que así sea. Las ventajas que lo anterior comporta son dos: por un lado, son mucho más explícitas y tratan el tema que sea sin ambivalencias y, por otro, dejan constancia de los asuntos. De esas ventajas se liberan otras como son la economía de los medios y recursos, y el aprovechamiento de los mismos en otros temas. Cuando se quiere sumar rapidez a formalidad y precisión, se suele enviar un fax y a continuación se envía la misma documentación por carta. La

37

carta, en todo caso, sigue siendo el documento formal que se utiliza cuando se quiere distinguir el contenido de forma especial respecto a cómo se podría suponer en otros tipos de comunicación. De hecho lo que termina de conferirle un grado de seriedad y validez, jurídicamente hablando, es el poder ser enviada bajo el soporte de un escribano público. Aunque ya se puede entender que no es una vía demasiado amistosa de comunicarse, pero hay ocasiones en que no existe mejor procedimiento. El correo electrónico sigue teniendo un auge extraordinario y se le augura un crecimiento mucho mayor, ya que permite un archivo y redistribución mucho más rápido y accesible que las cartas y faxes. En todos los casos, en el envío de estos tipos de documentos siempre se habría de indicar:  Una referencia del asunto tratado: nº de proyecto, clasificación según la WBS (EDT) o clasificación por centro de costos y el asunto en cuestión.  Las copias que de él se hacen y a quién se remiten.  Persona/s que editan el documento. Y retomamos en este punto el significado del término de gestión de la “comunicación”, para hacer énfasis en lo que mencionamos al comenzar este apartado en el sentido de que, cuando se utilizan esta vías para generar la información precisa, el sistema aún está incompleto, quedando pendiente la bidireccionalidad del intercambio. Esto es, asegurarse que el receptor de la información la ha recibido, y que se está consiguiendo el efecto esperado y no otro. A este respecto conviene matizar que no siempre el escrito llega a ser lo suficientemente afortunado en su redacción como para acertar en lo que se quiere transmitir y con el tono requerido; por eso es conveniente apoyarlos siempre con una comunicación verbal, o una confirmación, también por escrito, de que se ha recibido, para testar si se está de acuerdo o no con lo redactado; para en definitiva, estar seguro de que se entiende lo que el redactor quiere que se entienda. Estos aspectos, un gestor debe cuidarlos mucho, dada su condición de “coordinador” de voluntades y esfuerzos, en pro de unos objetivos que tienen que ser comunes para todos. Una deficiente interpretación de algún escrito puede generar suspicacias que sin duda no ayudarán lo más mínimo a generar la confianza necesaria en la Gestión del Proyecto que permita hacer esa labor de “convergencia” de todos los stakeholders.

38

Libros de órdenes e incidencias Son instrumentos utilizados en los proyectos de edificación, tanto en el área industrial como arquitectónica, como así también en los proyectos de desarrollo de sistemas. El libro de órdenes, como su nombre indica, recoge los mandatos de la dirección facultativa que son de obligado cumplimiento para el proveedor. Este instrumento resulta extremadamente útil cuando se presentan situaciones de conflictividad de cara a posibles repercusiones jurídicas, o simplemente para dar más fuerza a las peticiones o indicaciones de la dirección facultativa. El gestor del proyecto debe recomendar la utilización de este instrumento desde el primer momento.

Figura 3.7: La comunicación escrita y su frontera con la verdad (Fuente: Gestión Integrada de Proyectos, Marcos Serer Figueroa, 2001)

39

Notas o instrucciones técnicas de construcción Durante la construcción del producto objeto del proyecto, corresponde al director facultativo la emisión de las órdenes a los diferentes proveedores, que supongan actuaciones sobre el desarrollo del producto final, ya que es una responsabilidad no transferible. Pero sus órdenes deben ser aprobadas por el gestor del proyecto, (asumiendo la estructura de organización de proyectos más usual que es la matricial, pudiendo ser función exclusiva del gestor del proyecto el manejo de proveedores en una organización proyectizada), aun cuando modifiquen los objetivos inicialmente aprobados y que han servido de base para la misión del director facultativo. Así por ejemplo no puede dar órdenes sin aprobar que modifiquen el alcance, el precio, la calidad, la seguridad, etc. En esas y otros ocasiones el gestor del proyecto debe autorizar, como representante de la propiedad, cualquier modificación. La oficina de gestión del proyecto también emite instrucciones técnicas de construcción que afectan fundamentalmente a órdenes de secuencias de construcción que afectan al plazo, así como otras que repercuten en el costo, así como las relativas a cualquier objetivo cuyo control esté reservado al gestor o compartido con él. En todos esos aspectos, suele ser normal que muchas órdenes del ingeniero en jefe se emitan por escrito con “notas internas” que están incluidas dentro de un procedimiento general de actuación. Pues bien, de acuerdo con ese mismo procedimiento, que puede estar incluido dentro del manual de procedimientos, los desarrolladores internos o externos, tienen que comunicar alguna anomalía si consideran que ellas pueden dar lugar a una reclamación económica por su parte, a un aumento de plazo, etc. En todos estos casos se debe solicitar el consentimiento de la oficina de proyectos. En todo caso, la proximidad a los hechos por parte del gestor del proyecto y su equipo, hace fácil la situación y hace, también poco viable que, en un ambiente de relación razonable, se produzcan disfunciones en las actuaciones o problemas de competencia. Sólo cuando no se han sabido plantear desde un principio los diferentes roles de forma coherente – y también contractualmente – o cuando el gestor no ha llegado a ganarse la confianza de los diferentes involucrados, es cuando aparecen los problemas de competencias y se genera el caldo de cultivo propio de un final no deseado y en contra, al menos, de los intereses del cliente.

40

Los documentos de proyecto Nos referimos aquí a los documentos generados por los diferentes involucrados en el proyecto que, de forma escrita y gráfica, representan las formas y contenidos que se deben transformar en algo material. Todos ellos deben ser controlados y gestionados por la oficina de gestión del proyecto, que, sin pretender asumir o soslayar la responsabilidad que tienen sus autores, ha de tratar de asegurarse, en el mayor nivel de confianza posible, que:  Son suficientes  Son correctos, técnicamente hablando  Responden a los intereses del cliente  Respetan los condicionantes insoslayables (medio ambiente, seguridad, urbanismo, aspectos éticos de la gestión de proyectos)  Cada involucrado conoce aquellos documentos que, generados por otros, él necesita para el desarrollo de sus propias funciones, y además en su última versión.

Registro de la documentación Para el archivo de documentación, proponemos establecer el sistema utilizado como modelo dentro de los programas que aseguran la calidad tipo ISO o similar. Uno de los sistemas que ahora recomendamos es el que confiere al director del encargo – el gestor – la responsabilidad del archivo del proyecto en cuestión y por lo tanto de su ordenación y de la normativa a aplicar en función de la misión del proyecto (léase formas de actuar). Normativa que, como es lógico, debe seguir también las directrices del propio plan de calidad específico del trabajo. El procedimiento que se podría establecer en líneas generales sería el siguiente: Documentación sobre lecciones aprendidas. La documentación incluye las causas de las polémicas, el razonamiento subyacente a la acción correctiva elegida y otros tipos de lecciones aprendidas sobre Distribución de la Información. Las lecciones aprendidas se documentan a fin de que pasen a formar parte de la base de datos histórica tanto de este proyecto como de la organización ejecutante.

6.3 Reporte de desempeño / rendimiento Los informes de rendimiento o Reportes de desempeño son realmente un proceso de comunicación, ya que reúne datos e información de rendimiento enviándolos a los interesados. Es necesario que dicho reportes de rendimiento cumplan con los requerimientos establecidos en el proceso

41

de definición del proyecto en lo referente al contenido, nivel de detalle y forma. Los reportes de rendimiento pueden incluir:  Reportes de Estado: Descripción del estado actual del proyecto en función a lo estimado en las líneas base de Alance, Tiempo, Costo y Calidad.  Reportes de Progreso: Descripción de lo logrado hasta el momento.  Reportes de Tendencias: Análisis del rendimiento del proyecto con el paso del tiempo para determinar si dicho rendimiento está decayendo o mejorando.  Reportes de Pronóstico: Reporte de predicción del estado y rendimiento del proyecto en el futuro.  Reportes de Variación: Comparación del estado actual con las líneas base.  Valor Ganado: Integración del alcance, tiempo y costo para evaluar el rendimiento del proyecto.  Lecciones Aprendidas: Conclusiones finales sobre situaciones del proyecto que han permitido el aprendizaje que servirá de base para futuros proyectos.

6.4 Cierre administrativo Un trabajo adicional relacionado con los informes y las comunicaciones del proyecto implica verificar y documentar los resultados del proyecto para formalizar la aceptación del producto del proyecto por el sponsor. Se busca:  Reunir todos los registros del proyecto y crear un reflejo de especificaciones finales con los indicadores de éxito y eficiencia del proyecto.  Cerrar fase por fase, sin demorar hasta la finalización del proyecto.  Llevar los archivos del proyecto creando al menos un juego completo de registros del proyecto ordenado.  Reunir los contratos importantes y los registros contables  Documentar apropiadamente la aceptación formal  Reflexionar y documentar las lecciones aprendidas

6.5 Caso para estudio Sobre el caso planteado en el punto 5.5 sobre Codeword identifique cuantos canales de comunicación intervienen y reflexione sobre cuáles son los principales problemas de comunicación.

42

Módulo 4 Aspectos Complementarios de la Gestion de Proyectos

7. Gestion de riesgos del proyecto En todo proyecto hay incertidumbre, por ende, todo proyecto implica riesgos. La experiencia muestra una pobre performance en lograr cumplir los objetivos de alcance, calidad, tiempo y costos previstos en los Proyectos. Algunas de las causas de ello pueden ser: • Eventos no previstos • Falta de anticipación • Eventos previstos con consecuencias no medidas con anticipación En cualquiera de los casos estamos hablando de Riesgos. Un Riego es un evento discreto que tiene posibilidad (no certeza) de ocurrir y tiene algún impacto sobre algún objetivo del proyecto. Si bien estamos acostumbrados a dar a los riesgos una connotación negativa, es importante saber que los riesgos pueden tener también impactos positivos (estos casos son percibidos como oportunidad). Otro aspecto importante a resaltar es la diferencia entre Riesgo y Contingencia. • El riesgo es un problema potencial (no ha ocurrido aún), • La contingencia es un problema real (ya ha ocurrido). El Gerenciamiento de Riesgos es el arte y ciencia de identificar, evaluar, y responder a los riesgos de un proyecto a lo largo de la vida de mismo. Comprender que deberemos gestionar en un ambiente de riesgo es esencial para el progreso del proyecto y, a menudo los fracasos son una parte fundamental del aprendizaje. Aunque algunos riesgos no se puedan evitar, reconocerlos y controlarlos debe ser una actitud permanente que desafía nuestra creatividad.

1

7.1 Planificación de la gestión de riesgos. En muchas ocasiones la gestión de riesgos es percibida como una tarea burocrática que se hace al inicio del proyecto para generar un documento que conforme a algunos intereses. Poder enfrentar y administrar los riesgos requiere que su administración sea considerada como parte de un proceso dinámico y competitivo, en lugar de sólo una actividad adicional y estática de la administración de un proyecto. Es normal que los riesgos sean conocidos por los miembros del equipo del proyecto, pero la mayor parte de los problemas comienzan porque no son comunicados apropiadamente y en el momento oportuno. En muchas ocasiones nos cuesta comunicar los riesgos a los niveles pertinentes de la organización o a los clientes; en definitiva a los stakeholder clave que deban interesarse. Una buena Gestión de riesgos solo podrá realizarse si se cuenta con un ambiente en el que las personas sientan la libertad de expresar sus puntos de vista aún cuando estos difieran de los de sus superiores. Los riesgos son inherentes al proyecto, por ende inevitables. Debemos aprender a convivir con ellos si queremos gestionarlos. Cuando los riesgos se perciben como algo negativo, los integrantes de un equipo se muestran esquivos a informar sobre ellos. Esto es así al punto que, en algunas organizaciones mencionar los riesgos nuevos se toma como una queja. Una cultura como esta puede hacer que los integrantes del proyecto tiendan a suavizar la realidad para evitar malos momentos, todo lo cual redundará en una identificación tardía del riesgo. Aún cuando los riesgos nos preocupan, es importante que el proyecto no sea juzgado solo por la cantidad y naturaleza de sus riesgos. Toda esta actividad deberá ser cuidadosamente planificada para poder encararla con seriedad y compromiso, para ello es que se deberá, como primer medida, crear un “Plan de Gestión de Riesgos”.

2

Plan de gestión de riesgos: Un Plan de Gestión de Riesgos describe como se llevará adelante todos los procesos vinculados al gerenciamiento de los riesgos desde la identificación hasta la confección del Plan de Respuesta y el monitoreo y control de los riesgos. Es importante resaltar que hay una diferencia entre este plan y el Plan de Respuesta a Riesgos ya que este último se crea una vez identificados y analizados los riesgos para describir las acciones de mitigación y contingencia que se implementarán. Algunos aspectos a definir en un plan de gestión de riesgos:  Métodos y técnicas que se usarán para identificar, analizar, responder y controlar los riesgos  Roles y responsabilidades para cada una de esas actividades  Presupuestos y tiempos que se van a invertir en estos procesos  Categorías y escalas para la descripción y análisis de los riesgos ( para clasificar y para medir los riesgos)  Umbrales de tolerancia de los stakeholder. Estos umbrales indican cuales son las medidas de riesgos que requieren tratamiento proactivo  Informes requeridos para comunicar y gestionar los riesgos  Procesos de seguimiento que describan como se hará el monitoreo y auditorías de riesgos.

7.2 Identificación del riesgo La identificación de riesgos es el proceso sistemático de descubrir anticipadamente las amenazas sobre los objetivos del proyecto. Se trata de identificar qué riesgos probablemente afectarán al proyecto y documentar sus características. Este es un proceso iterativo que se lleva a cabo fundamentalmente en la planificación del proyecto pero que debe repetirse sistemáticamente a lo largo del mismo a efectos de descubrir nuevas amenazas. El objetivo final es lograr una lista de riesgos del proyecto, para ello será necesario implementar un conjunto de herramientas y técnicas entre las cuales podemos mencionar: Tormenta de ideas: el equipo del proyecto y otros stakeholder pueden reunirse con la coordinación apropiada para generar una lista inicial de riesgos posibles.

3

Entrevistas: entrevistar a personas con experiencia en el tipo de proyecto que se encara o conocimiento sobre la tecnología que se está por emplear puede ser una excelente fuente de información para descubrir riesgos. Revisión de documentación: La documentación del proyecto, del contrato, los documentos de referencia son fuentes de información para el descubrimiento de riesgos Listas de comprobación: Una organización que ejecuta proyectos con frecuencia puede sistematizar una lista de los riesgos más comunes en sus proyectos, clasificarla por tipos de proyectos y contar así con un check list que permita verificar que no estamos olvidando pensar en algún riesgo común. Finalmente terminaremos generando un Registro de Riesgos, que consiste en una lista pormenorizada de los riesgos del proyecto que, preferentemente debiera incluir sus causas.

7.3 Análisis cualitativo del riesgo El análisis cualitativo de los riesgos prepara las condiciones para que los próximos procesos puedan ejecutarse, ocupándose de caracterizar los riesgos y describir todos sus atributos. En este punto es importante tomar en cuenta que las dos principales dimensiones que definen un riesgo son: • Impacto • Probabilidad Cualquier análisis posterior sobre la peligrosidad de un riesgo debiera hacerse sobre la base de estas dimensiones por lo cual los dos principales atributos a definir en este proceso son estos. Impacto: Puede medirse de diferentes modos: en función del tiempo que se perderá/ ganará por su efecto; en función del costo, en una escala cualitativa del tipo: alto, medio, bajo, entre otras posibilidades. Probabilidad: Puede medirse la probabilidad en una escala numérica de porcentaje o bien en una escala cualitativa del tipo: alta, media, baja, entre otras posibilidades. En ocasiones pueden usarse matrices de probabilidad/Impacto como la que se presenta a continuación para definir estos ítems y a la vez conocer la severidad de cada riesgo:

4

Impacto

0,05

0,10

0,20

0,40

0,80

0,9

0,045

0,09

0,18

0,36

0,72

0,7

0,035

0,07

0,14

0,28

0,56

0,5

0,025

0,05

0,10

0,20

0,40

0,3

0,015

0,03

0,06

0,12

0,24

0,1

0,005

0,01

0,02

0,04

0,08

Probabilidad Probabilid ad

Figura 4.1 - Matriz de probabilidad/impacto

Es importante que la definición de las escalas en que los riesgos serán cualificados haya sido previamente consensuada y documentada en el Plan de Gerenciamiento de Riesgos. Como resultado de este proceso podremos obtener para cada riesgo: • Categoría • Impacto • Probabilidad de ocurrencia • Otra información necesaria para su evaluación

7.4 Análisis cuantitativo del riesgo El análisis cuantitativo de riesgos se concentra en determinar cuáles son los riesgos que generan mayor peligrosidad para el proyecto. Una de las técnicas más usadas para el análisis cuantitativo de riesgos es el análisis de Valor Monetario Esperado (EMV por sus siglas en inglés). Con los riesgos se construye una lista indicando los valores de probabilidad y de impacto. Ambos valores deben ser relacionados para poder tomar decisiones sobre los riesgos.

5

La relación natural entre ambos será el producto, por lo que el producto de probabilidad por impacto de cada riesgo nos dará como resultado lo que conocemos como exposición al riesgo. Cuando esta exposición está medida en unidad monetaria se llama EMV. Ejemplo: Riesgos

Impacto

Probabilidad de ocurrencia

Grado de exposición al riesgo

A

$ 100

30%

30

B

$ 30

50%

15

C

$ 20

80%

16

D

$ 50

20%

10

E

$ 70

50%

35

Con este último valor se podrá hacer la selección de los riesgos a tratar eligiendo siempre los de mayor exposición o EMV que son los que, en definitiva, presentan mayor peligrosidad para el proyecto. Seguramente a esta altura nos damos cuenta que actuar de manera proactiva generando planes de respuesta para todos los riesgos identificados y analizados podría ser demasiado costoso e improductivo. Un gestor maduro sabrá que algunos riesgos deberá tomar y otros deberá mantenerlos controlados. El grado de exposición al riesgo será el factor determinante para decidir cuáles serán los riesgos que necesitan mayor control. Para ello se realiza la priorización de riesgo, para lo cual el primer paso será ordenar la lista en función de la columna de exposición. En el ejemplo: Riesgos

E A C B D

Impacto

$ 70 $ 100 $ 20 $ 30 $ 50

Probabilidad de ocurrencia

Grado de exposición al riesgo

50 % 30 % 80 % 50 % 20 %

35 30 16 15 10

Figura 4 -Priorización de riesgos

6

Así tendremos los riesgos ordenados del de mayor severidad al de menor severidad. Luego, para tomar la decisión podemos aplicar la ley de Pareto cuya aplicación a este caso nos permitiría deducir que con el 20 % de los riesgos podemos tener el 80% del peligro controlado. Por lo tanto se aconseja hacer una línea de corte en aproximadamente el 20 % de los riesgos de mayor severidad y con ellos pasar al próximo paso que será generar los correspondientes planes de respuesta a los riesgos.

7.5 Planificación de la respuesta a los riesgos La planificación de la Respuesta a riesgos es el proceso de generar opciones y genera acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del Proyecto. Todas estas acciones deberán presentarse en un plan que indique mucho más que el enunciado de la acción. Algunos de los aspectos que debiera incluir un buen plan de respuesta a los riesgos se detallan a continuación: • • • • • • • • •

Riesgo Datos cuali - cuantitativos del riesgo Actividad/es a realizar para minimizar o evitar el riesgo Responsable Tiempos Recursos Indicadores de monitoreo Frecuencia de monitoreo Medidas de contingencia

Interesa destacar en este punto la diferencia entre una medida de mitigación y una de contingencia: mientras la primera indica que se hará para que el riesgo tenga menos posibilidad de ocurrir o menor impacto, la segunda describe lo que se hará en caso que ocurra.

7.6 Monitoreo y control de los riesgo El monitoreo y control de los riesgos es el proceso de identificar, analizar y planificar nuevos riesgos a la vez que se revisa periódicamente las probabilidades e impactos esperados de los riesgos ya identificados para

7

alertar posibles activaciones (riesgos que se convierten en problemas reales) y estudiar nuevas fuentes de riesgos y causas. Algunas acciones a llevar a cabo en este proceso serán: • Reevaluación de los riesgos: Es importante que los procesos definidos para el proyecto involucren necesariamente una revisión periódica del estado de los riesgos identificados y el alerta de aquellos que se vuelven más inminentes por las condiciones actuales del proyecto. • Auditoría de los riesgos: La auditoría inspecciona y documenta la efectividad de los planes de respuesta y su implementación. • Análisis de variaciones y Tendencias: deben revisarse las variaciones de los indicadores del proyecto para poder establecer tendencias, para ello es posible valerse de la técnica del valor ganado como medio de análisis. • Reuniones de Revisión de Estado de Situación: Realizar reuniones periódicas para tratamiento de estos temas, o bien incluir en las reuniones de avance del proyecto el tratamiento de los riesgos facilitará el seguimiento y la internalización de los riesgos en el equipo de proyecto.

8

8. Gestión de abastecimiento del proyecto. La Gestión del abastecimiento o adquisiciones del proyecto se refiere a los procesos necesarios para lograr abastecer al proyecto de todos los productos, servicios o resultados necesarios para llevar adelante el proyecto. Esto se logra: • Determinando qué, cómo y cuándo comprar o adquirir. • Documentando los requerimientos del producto o servicio e identificando los proveedores potenciales. • Obteniendo cotizaciones, ofertas y/o propuestas adecuadas. • Revisando ofertas y seleccionando los proveedores escogidos. • Manejando el contrato y las relaciones entre los vendedores y los compradores. • Completando y cerrando los contratos aplicables al proyecto.

Figura 4.2 - Procesos de la Gestión de Adquisiciones

Los proyectos requieren generalmente la implementación de numerosas contrataciones de diversa índole. El instrumento esencial en estos procesos es el CONTRATO

9

Un contrato es un acuerdo vinculante para las partes en virtud del cual una de ellas se compromete a proveer productos, servicios o resultados especificados, mientras la otra parte asume el compromiso de retribuir con dinero u otra contraprestación válida y acordada. Un contrato: • Obliga legalmente a las partes. • Describe derechos y obligaciones • Documenta un acuerdo Un contrato se compondrá de un conjunto de Términos y Condiciones. Los términos forman parte integral e inseparable del acuerdo, en tanto que las condiciones fijan reglas que dependen de la ocurrencia de algún determinado evento o circunstancia para entrar en vigor. Las condiciones pueden ser precedentes o subsecuentes: • Precedente (si evento entonces obligación) • Subsecuente (obligación a menos que ocurra evento) Los contratos pueden ser de diferentes tipos, dependiendo de las necesidades e intereses de las partes, del tipo de bien o servicio a contratar y fundamentalmente de los riesgos que la contratación involucre.

TIPOS DE CONTRATOS: Contrato de precio fijo: Un contrato de precio fijo implica un precio único, total y fijo por la entrega de la totalidad de lo comprometido: Este tipo de contratos puede usarse cuando la contraprestación está claramente definida. Supone mucho riesgo en los casos de productos o servicios con especificaciones poco claras o incompletas y en aquellos productos con alto grado de intangibilidad como el software por ejemplo.

Importante: El producto, bien o servicio debe estar bien definido Riesgo:  Bajo para el proyecto  Alto para el proveedor

10

Contrato de costos reembolsables: Este tipo de contrato implica el pago al proveedor de los costos incurridos más un monto que representa la ganancia para el vendedor. Este tipo de contratos se utiliza cuando la incertidumbre en cuanto a la cantidad de insumos o recursos a invertir es alta. El cliente acepta pagar al contratista todos los costos reales (Mano de Obra, Materiales, etc.) con independencia de la cantidad, más alguna utilidad acordada. Este tipo de contrato tiene un alto riesgo para el equipo de proyecto, ya que los costos del contratista pueden exceder los costos estimados para el proyecto. Requiere un mayor control, y periódicas estimaciones de cuánto será el costo total que va a incurrir el proveedor. Tiene poco riesgo para el proveedor, aunque a la larga si el costo se excede generará mala reputación para el proveedor. Importante: - Auditorias de Costo y periódicas estimaciones - Requiere mayor control Riesgo:  Alto para el proyecto  Bajo para el proveedor

Contrato con incentivos: Los contratos con incentivos premian la consecución o superación de ciertos objetivos, (de alcance, plazos, costos). Generalmente son una combinación de Precio Fijo y Costos reembolsables a los que se le agrega un incentivo en función de indicadores de performance preestablecidos. Importante: - Definir claramente las condiciones y cálculo del incentivo Riesgo:  Medio para el proyecto  Bajo para el proveedor Tiempo y materiales: Los contratos de tiempo y materiales son un tipo híbrido de acuerdo contractual en el que se fija valor unitario por las horas de trabajo y por los materiales a consumir. En la tasa horaria se incluye costo directo, indirecto y ganancia y luego se factura por cantidad de horas invertidas.

11

Este tipo de contratos en general no promueve la eficiencia puesto que el proveedor tiene ventaja en la medida que más tiempo transcurre y por ende requieren mucha auditoría por parte del comprador. Aún así son muy usados en los casos en que es dificultoso estimar con certeza el esfuerzo que se requerirá para completar el trabajo. Al proveedor se le paga por una cantidad prefijada por unidad de servicio. (Ej. $25 por hora por 7000 Horas de trabajo). El valor total será en función de las cantidades necesarias para completar el trabajo. • El costo incluye el costo directo e indirecto más la ganancia. • Se pagan horas reales a la tasa horaria más el costo de los materiales. • La ganancia del proveedor aumenta cuando el esfuerzo es mayor que el estimado. Importante: El acuerdo no promueve la eficiencia. Riesgo:  Alto para el proyecto  Bajo para el proveedor Son muchas las razones para subcontratar, entre ellas podemos mencionar las que se detallan a continuación: • • • • • • •

Reducir y controlar los costos operativos Liberar recursos internos para otros propósitos Obtener recursos con conocimientos no disponibles internamente. Compartir riesgos Menor necesidad de inversión de capital Calidad Mejorada Acceso a experiencia especifica

Una contratación depende de muchos factores, algunos de ellos promueven una contratación exitosa mientras otros son fuente de problemas y conflictos. Factores para una contratación exitosa • • • • • • •

Comprender las metas y objetivos de la empresa contratante Seleccionar al proveedor adecuado Un desarrollo progresivo de las relaciones Un contrato debidamente estructurado Una comunicación abierta con los individuos / grupos afectados Una atención especial a los problemas personales Respaldo y compromiso de los niveles superiores de la organización

12

Factores que llevan al fracaso en la contratación: • • • • •

Resistencia de los miembros del equipo de proyecto. Pérdida de control. Percepción del objetivo o bien subcontratado. Proveedores con preasignación. Grado del plan no acorde con la importancia o complejidad del bien o servicio subcontratado.

Muchos son los elementos de un contrato. A continuación se detalla a modo de ejemplo, algunas de las cláusulas principales a tomar en cuenta en la confección de un contrato:  Producto o servicio a contratar: Una clara descripción del bien o servicio a contratar.  Exposición falsa de costos: Afirma que es ilegal que el contratista exagere las horas o costos gastados en el proyecto.  Aviso de exceso en los costos o demoras en el programa: Indica cómo serán las notificaciones ante estas circunstancias.  Aprobación de los subcontratistas: Indicaciones al contratista sobre que deberá tener aprobación antes de subcontratar a una persona o bien para una tarea del proyecto.  El equipo o la información a proporcionar por el contratista: Incluye las fechas de entrega y que partidas (pieza de prueba por Ej.). Esto nos protege ante demoras por parte del cliente en proporcionar información, piezas o partidas.  Patentes: La propiedad de patentes que puedan hacer de realizar el proyecto.  Cancelación: Presenta condiciones para dar por finalizado el contrato.  Divulgación de información confidencial: Prohíbe a una de las partes a revelar a un tercero o usar con un propósito distinto al trabajo del proyecto a información confidencial, tecnologías, o procesos utilizados durante el proyecto.  Consideraciones internacionales: Especifica los ajustes a realizar cuando el proyecto y el contratista son de diferentes países.  Condiciones de pago: Se refiere a la base sobre la cual se realizarán los pagos. (Pagos mensuales, % del contrato, un solo pago al final del contrato, etc.)  Pagos de primas – penalidades: Cláusulas de premio por terminación a tiempo o antes de lo que indique el programa, o si se exceden los requisitos del producto o servicio. Cláusulas de penalidades mediante la cual el cliente puede reducir el pago final si el proyecto no se termina de acuerdo con el programa o si no se cumplen los requisitos de desempeño. Debe permitir manejar el rendimiento deficiente.  Cambios: EL procedimiento para proponer, aprobar y poner en práctica los cambios al alcance o al programa del proyecto. También

13

se deberá indicar si existieran cambios de precios, cómo se implementarán y cómo se pagarán.  Evaluaciones: frecuencia, intensidad, carácter de los resultados, etc.  Interlocutores válidos: personas habilitadas para realizar recepción, aprobación, etc.

8.1 Planificación del abastecimiento El proceso de planificación del abastecimiento del proyecto consistirá en definir: • Que se compra y que se hace en el proyecto • Que tipos de contratos se usarán para cada adquisición • Las responsabilidades de cada participante de la organización en el proceso de contratación • Documentos a utilizar • Plazos • Informes a proveer • Restricciones que afectarán las decisiones de compra y contratación • Periodos de adelanto para las solicitudes • Tipos de garantías a requerir • Instrucciones para los proveedores • Identificación de proveedores precalificados • Definición de métricas para los procesos involucrados

8.2 Planificación del requerimiento Para cada contratación se deberá llevar adelante una requisición o solicitud a proveedores. Esta actividad debe ser planificada para respaldar el proceso de solicitar al proveedor sus propuestas y luego efectuar la selección. Se deberán organizar los documentos que se utilizarán y se establecen los criterios para la admisión y selección de proveedores y propuestas. La complejidad y detalle de esta documentación deberá ser coherente con el valor del bien a adquirir y los riesgos involucrados. Entre los criterios de evaluación se puede mencionar:    

Comprensión de la necesidad Costo total del ciclo de vida Capacidad técnica Enfoque de gestión

14

    

Enfoque técnico Capacidad Financiera Tamaño y tipo de negocio Referencias Derechos de propiedad

8.3 Requisición Con el proceso de Requisición se solicita y se obtiene la respuesta de los proveedores. Podemos distinguir al menos entre dos tipos de solicitudes a proveedores: • RFP (Request For Proposal): El requerimiento para propuesta consiste en solicitar al proveedor el bien o servicio especificando la necesidad a satisfacer y dejando al proveedor la posibilidad de hacer su oferta libremente. La evaluación se hará en este caso por calidad de la oferta y por precio. • RFQ (Request For Quotation): El Requerimiento para Cotización implica una especificación sumamente detallada por parte del comprador del producto o servicio a contratar y solicita simplemente el precio de venta al proveedor. En este caso la selección debe hacerse solo por precio y no se aceptan cambios ni mejoras a las calidades solicitadas. Los resultados finales de este proceso serán: • Lista de proveedores calificados • Documentos de la Adquisición • Propuestas y Cotizaciones

8.4 Selección de la fuente La selección de la fuente es el proceso por el cual se analizan las propuestas y las cotizaciones recibidas, se aplican los criterios de evaluación que previamente se definieron, acordaron y comunicaron y finalmente se decide el proveedor y propuesta a contratar. Durante este proceso se usarán diferentes sistemas de ponderación, negociación, sistemas de selección y ponderación y estimaciones

15

independientes para asegurar que las propuestas están dentro de los límites aceptables. Como resultado de este proceso se obtendrá:  Proveedores seleccionados: Se finaliza el proceso con la definición y comunicación de los proveedores elegidos en función de los criterios y negociación final.  Contratos: Los contratos son adjudicados, confeccionados y formados. Se someten a revisión y aprobación final.  Disponibilidad de recursos: Como resultado de este proceso se conoce además los recursos de que se dispondrá y los momentos acordados para su asignación y plazos.

8.5 Administración del contrato La administración de Contratos incluye todos los trabajos necesarios para asegurar que se cumplen los requisitos contractuales pautados, que las entregas se reciben en tiempo y con las calidades exigidas. En definitiva se asegura que los términos del contrato se cumplen y las condiciones se controlan para su aplicación. Debe tomarse en cuenta que ambas partes, solicitante y proveedor deben hacer administración del contrato a efectos de cuidar los intereses. Se deberá aplicar: • Sistema de control de cambios del contrato • Revisiones de rendimiento y entregas • Inspecciones y auditorías • Sistemas de pago • Administración de reclamos • Gestión de registros

8.6 Cierre de contrato El cierre del contrato debe aplicarse a cada una de las contrataciones pautadas para el proyecto. Consistirá en: • Verificar que todos los trabajos y productos han sido aceptados. • Asegurar que se tiene todos los registros de las gestiones del contrato • Generar el correcto archivo de registros y documentos para reclamos futuros.

16