_________________________________________________________________________________ CAPTULO CUATRO

Administracin del diseo

Figura 4. 1 Diagrama de Gantt para la administracin de tareas en un proyecto

Captulo 4

Un proyecto es un ensamblaje de personas y equipos, y son normalmente manejados por un gerente del proyecto; el gerente del proyecto no tiene que tener solamente considerables habilidades tcnicas, sino tambin un profundo entendimiento del fino arte del manejo (administracin). La administracin es una disciplina que organiza los recursos de una institucin y que se aplica en un sin nmero de reas; el proceso de diseo es una actividad que puede consumir cantidades de tiempo y recursos significativos, por lo que es importante e imperativo poder administrar el tiempo y los recursos de los que dispone el equipo de diseo y la compaa para la solucin del problema en cuestin. En este captulo se presentan algunas tcnicas que pueden ser tiles para administrar estos recursos. El equipo del proyecto, liderado por el gerente (manager, lder, director, jefe) del proyecto, est en bsqueda de una solucin, efectiva en relacin con su costo, para el cliente; en este sentido se debe estar en posicin al final, de cuantificar tanto el costo del producto como su efectividad. El enfoque que se presenta en este captulo, se centra en la descripcin de herramientas que se pueden utilizar para aprovechar y organizar de manera adecuada los recursos disponibles (personas, tiempo, dinero, etc.) para ejecutar el diseo. Hay que subrayar que por lo general todos los proyectos de diseo tienen limitaciones de recursos, siendo los recursos ms crticos el tiempo y el presupuesto; se justifica entonces establecer formas adecuadas de planificar, organizar, dirigir y controlar estos proyectos.

4.1. Administrar Podran discutirse muchas definiciones de administracin, sin embargo una definicin generalizada y suficiente es: Administracin es el proceso mediante el cual se orienta el aprovechamiento de los recursos materiales, humanos, financieros y tcnicos de una organizacin hacia el cumplimiento de los objetivos institucionales. La administracin, sea cual sea el mbito en el cual se aplica, involucra cuatro funciones principales: Planeacin, organizacin, direccin y control. Como planeacin se entiende el proceso de fijar metas y decidir la mejor manera de alcanzarlas. En un proyecto de diseo esto implica considerar el objetivo general del proyecto y traducirlo en metas y objetivos estratgicos y tcticos apropiados. La organizacin es el proceso de asignar y disponer recursos humanos y no humanos para desarrollar el proyecto con xito. En otras palabras se debe crear un sistema para desarrollar y asignar tareas, obtener y asignar recursos, y tambin coordinar las tareas para alcanzar los objetivos. La planeacin y la organizacin no tienen su efecto deseado si no existe la adecuada direccin. La direccin principalmente se debe enfocar en influir en los miembros de la organizacin (equipo) para que estos participen en las tareas de la mejor manera y se puedan obtener as los objetivos planeados. El administrador debe tener la capacidad de determinar y aplicar las acciones de poder y motivacin para que todo el equipo trabaje hacia el logro de las metas. Lo que no se mide no se controla, y lo que no se controla puede conducir a cualquier cosa. El control visto de manera ampliada, es el proceso de monitorear y regular el proceso de la organizacin (equipo) hacia el logro de objetivos. Debe mencionarse que existe una diferencia entre dirigir y controlar; el control aqu estar asociado a asegurar que la evolucin y el desempeo real del proyecto se ajuste a las restricciones y objetivos establecidos.

4.2. Porque administrar las actividades de diseo? El proceso de diseo es como un campo abierto a travs del cual se pueden tomar mltiples y diferentes rutas para ir desde las necesidades de los clientes hasta, tambin, diferentes soluciones

Administracin del diseo 3

a estas necesidades; en este sentido, una gran parte del entorno en el que ocurre el diseo es creado por el diseador, es responsabilidad de este decidir, entre otras cosas, qu actividades deben ser realizadas, quin va a realizarlas, y el orden en que deben ser ejecutadas; son estas particularidades las que definen las rutas y las diferencias en los resultados obtenidos. La creacin y el control del ambiente de diseo es parte de un proceso que se conoce como administracin de diseo; existen varias herramientas disponibles y que el equipo de diseo puede usar para planificar, organizar, dirigir y controlar proyectos de diseo, aqu se presentarn algunas de ellas. Un proyecto puede ser caracterizado como una actividad con una serie bien definida de objetivos deseados. La administracin exitosa de un proyecto en general se establece en funcin de propsito, presupuesto y programacin; es decir, el proyecto debe alcanzar las metas (diseo exitoso), ser completado dentro de los lmites de recursos disponibles, y realizado dentro del tiempo estimado. Un trabajo de diseo exitoso equilibrar tres clases de intereses: la meta del cliente de introducir un producto nuevo, las restricciones presupuestarias de la compaa de diseo y el tiempo establecido en plan de comercializacin del cliente. Si el equipo de diseo llegase a fallar en cualquiera de estos objetivos la compaa podra perder su ventaja competitiva, especficamente si no se puede cumplir con el presupuesto es posible que la compaa no sea capaz de permanecer en el negocio por mucho tiempo. La trada de propsito, gasto y programacin, es la que forma la base de las herramientas que se utilizan para administrar proyectos. Los proyectos de diseo son en general difciles de administrar, principalmente porque estos son particulares, es decir que son diferentes a otros tipos de proyectos. En un proyecto de diseo, el diseador con frecuencia no puede saber que constituir un xito hasta que el proyecto est en proceso; esto solo se alcanza a lograr cuando se pueden aclarar todos los objetivos del proyecto y terciar todas las opiniones de los participantes, generalmente despus de bastantes intercambios de ideas con los clientes. Asimismo, si bien en general en otros tipos de proyectos slo se espera un resultado, en uno de diseo se podran producir muchos considerados como aceptables. En la programacin tambin existen diferencias entre los proyectos de diseo y los proyectos de otro tipo. En la mayora de los proyectos se puede planificar la realizacin de ciertas actividades, sabiendo cunto tiempo se llevar cada una y se puede determinar un orden lgico para ellas; al reunir y organizar los datos de planeacin y programacin se puede determinar cunto tiempo se llevar el proyecto. Sin embargo, en un proyecto de diseo es normal que muchas veces el manager, en lugar de sumar el tiempo que se llevarn las tareas, pregunte: de cunto tiempo disponemos? La programacin es el intento del equipo de diseo por utilizar todo el tiempo disponible para generar y considerar mltiples alternativas viables de diseo, al mismo tiempo que trata de satisfacer la restriccin de terminar el proyecto en una fecha especificada y acordada. Son estas diferencias, esta ambigedad en propsito y la dependencia del tiempo del cliente, las que refuerzan la necesidad de establecer e implementar algunas herramientas de administracin. De hecho, las incertidumbres y los impactos externos asociados con proyectos de diseo tienden a hacer que algunas herramientas de administracin sean incluso ms tiles y necesarias que lo que son en proyectos bien entendidos. Los proyectos de diseo como ya se mencion son desarrollados por equipos; una de las caractersticas que hay que desarrollar al interior de todo equipo y con mayor nfasis en los de diseo es la capacidad de comunicar con eficacia las actividades, la programacin y los avances del equipo a todos sus miembros y a otros participantes. Por otro lado, el lder o jefe del equipo tiene que asignar el trabajo de manera equitativa y apropiada, se requiere tambin tener la seguridad de que el trabajo se ha realizado adecuadamente y en una secuencia que posibilite que otros integrantes del equipo que dependen de un trabajo previo planifiquen sus acciones. Todas estas caractersticas operativas y la naturaleza particular de los equipos refuerzan la necesidad del uso de herramientas de administracin.
Giovanni Torres Charry. IM, MSc. 2011

Captulo 4

4.3. Problemas al manejar un proyecto de Ingeniera En trminos generales, los problemas que pueden verse en un proyecto tpico, generalmente se descubren ellos mismos en trminos de tres atributos principales: 1. Plan (tiempo) 2. Costo (comparado con el costo estimado inicial) 3. Desempeo Los proyectos son planeados originalmente para cumplir con los requerimientos de diseo dentro de un tiempo prescrito y bajo unas restricciones de dinero. Aunque hay numerosas razones por las que un proyecto no satisface estos tres aspectos claves; algunas de las razones ms comunes son: 1. Inadecuada articulacin de los requerimientos. 2. Pobre planeacin 3. Inadecuadas habilidades tcnicas y perseverancia 4. Deficiencia en el trabajo en equipo 5. Pobre coordinacin y comunicacin 6. Insuficiente monitoreo del progreso 7. Bajo soporte de la empresa 1. Inadecuada articulacin de los requerimientos Los requerimientos para un proyecto son normalmente definidos por los clientes y son a veces referidos como requerimientos del usuario. Los productos pueden ser completamente nuevos o pueden representar actualizaciones (mejoras) a productos actuales. Especialmente si son nuevos, los clientes generalmente tienen dificultades para expresar estos requerimientos de una forma consistente y completa y en trminos que puedan ser utilizados por los diseadores. Tambin puede darse el caso en que sea muy simple entender desde el inicio todos los requerimientos. Pobres requerimientos llevan a pobres diseos. 2. Pobre planeacin Los proyectos normalmente siguen un plan del proyecto escrito al inicio. Tales planes frecuentemente estn amarrados como parte de una propuesta y no pueden ser fcilmente modificados en lo que concierne a compromisos con los clientes. Debido a que el desarrollo de los proyectos es algo particularmente dinmico, la mayora de los planes de los proyectos estn obsoletos de 2 a 6 meses despus de que han sido escritos. Por lo que necesitan ser continuamente actualizados para reflejar el entendimiento del actual estado del proyecto. 3. Inadecuadas habilidades tcnicas y perseverancia Muchos jefes de proyectos se quejan de que no han podido contar con los recursos de personal necesarios para ejecutar sus proyectos. En muchas ocasiones se debe seleccionar a las personas para el proyecto dentro de la compaa, y puede suceder que no se pueda contar con los mejores individuos. Cuando es posible contratar fuera de la compaa, aun si el nuevo personal es competente tcnicamente, toma tiempo para ellos ascender en la curva de aprendizaje, en trminos del proyecto mismo como de la cultura de la compaa. Tambin puede tenerse prdida de capacidades tcnicas claves porque las personas son utilizadas en otros proyectos en la compaa o porque estos tcnicos se van a otra compaa. Es crtico para el lder del proyecto mantener un excelente staff tcnico o en su defecto hacer frente a la fuerte posibilidad de un desempeo tcnico inadecuado, que mostrara tambin problemas en el cronograma y costos.

Administracin del diseo 5

4. Deficiencias en trabajo en equipo Los proyectos de diseo de hoy en da son muy complejos y requieren que los miembros del equipo interacten da a da. Si estas interacciones no ocurren, o son negativas, el proyecto sufre y se puede venir a pique. An con pequeos grupos de personas fuertes tcnicamente, si ellos no operan como un equipo, el proyecto puede presentar riesgo de fallar. Las habilidades del gerente del proyecto son aqu ms importantes que cualquier otra cosa; l o ella deben ser capaces de forjar un espritu de cooperacin y trabajo en equipo. 5. Pobre comunicacin y coordinacin Una de las habilidades claves de un gerente de proyectos, es la comunicacin. La comunicacin efectiva es crtica tanto dentro del proyecto mismo como fuera del proyecto; para interactuar con elementos de la compaa (gerencia, contabilidad, financiera, etc.), como con los clientes. Se requieren esfuerzos especiales para mantener a las personas continuamente informadas sobre qu est pasando y el porqu. Un gerente de proyecto responsable debe siempre tener la percepcin de la necesidad de comunicar y estar preparado para invertir el tiempo necesario para comunicar y coordinar. 6. Insuficiente monitoreo del progreso Por razones que no son del todo claras, muchos gerentes de proyectos inician sus proyectos y los dejan para que se desarrollen libremente hasta que se ejecuta una revisin crtica planteada en el proyecto. Un buen gerente de proyecto se mantiene en contacto con la gente y con el progreso da a da, la mayora de las veces pasendose alrededor, e informalmente explorando los tpicos importantes, los problemas y las necesidades. An el personal altamente competente requiere de monitoreo, siempre y cuando ste sea hecho de una manera que no obstruya y que sea amigable. Siendo cuidadoso y monitoreando de manera sensitiva el progreso entre eventos claves, uno es capaz de mantener el proyecto en su rumbo y evitar desastres durante las revisiones formales del proyecto cuando ambos, el cliente y el gerente estn presentes. Esto es especialmente cierto durante los primeros das de un proyecto porque uno nunca tiene un segundo chance para dar una primera buena impresin. Un monitoreo consistente y constructivo desde el inicio establece el paso para el xito del proyecto. 7. Bajo soporte de la compaa Se espera que todas las organizaciones provean asistencia y soporte a los proyectos que son a menudo indispensables para estas organizaciones. El soporte debe estar disponible no slo del jefe del gerente del proyecto sino tambin de los diferentes grupos de soporte designados tales como contabilidad, financiera, produccin, manufactura y una coleccin de estructura organizacionales. Por ejemplo, el rea de contabilidad/financiera pueden ser requeridas para suministrar peridicamente reportes (mensualmente) de costos del proyecto al gerente del proyecto y al equipo del proyecto; si estos reportes estn tarde o no son correctos la mayora de las veces, el gerente del proyecto estar operando con una desventaja reconocida, el gerente no debe permitir que esta situacin contine.

Las acciones anteriores presentan slo siete maneras en las que un proyecto puede salirse del rumbo; claramente existen muchas otras. Si usted es un gerente de proyecto, tiene sentido entender estas y otras reas problema de tal manera que pueda encontrar soluciones antes que ellas conduzcan a excesos en costos y tiempo y un desempeo inadecuado. Estos problemas claves pueden ser re-establecidos en trminos de una gua especfica para el gerente de proyecto, como se describe: Formas seleccionadas para que el gerente del proyecto que evite problemas 1. Revise y analice continuamente y en detalle los requerimientos; agrupe los problemas y los requerimientos con su manejo, y cuando sea necesario revselos con el cliente.
Giovanni Torres Charry. IM, MSc. 2011

Captulo 4

2. Prepare el mejor plan que se pueda para el proyecto y actualcelo al menos cada cuatro meses, asegrese que su plan es conciso y legible (entendible) por el personal del proyecto. 3. No acepte pobres desempeos tcnicos en su proyecto; insista en el mejor talento tcnico, aquellos quienes cumplan con los ms altos estndares de desempeo y creatividad. 4. Construya un equipo responsable, que sea capaz de comunicarse libremente y resolver problemas del proyecto; descarte aquellas personas que muestren que no pueden trabajar en equipo. 5. Mantenga altos estndares de coordinacin y comunicacin abierta y honesta con sus jefes, personas de otras compaas, el staff del equipo, y los clientes. 6. Monitoree el estado y el progreso del proyecto a travs de caminatas informales, siendo sensible a los hbitos de trabajo y necesidades de su gente; establezca revisiones peridicas ms formales sobre el estado. 7. Establezca mecanismos de soporte eficientes y productivos dentro de la compaa, de tal manera que se maximice la efectividad de estas interacciones.

4.4. La direccin del equipo La organizacin y tamao del equipo o equipos de diseo estarn influenciados por la compaa en la que est inmerso, sin embargo digamos que independientemente de estos aspectos existe una persona que dirige, gestiona y administra al equipo o equipos del proyecto, el gerente del proyecto. El gerente del proyecto tiene la responsabilidad de todo el proyecto, en todas sus dimensiones. En el nivel ms alto, este se enfoca en el plan, el costo y el desempeo tcnico del proyecto. Un estimado del tiempo que un gerente de proyecto puede invertir en cada una de estos aspectos pueden ser de 20 % para el plan, 30 % para el costo, y 50 % para el desempeo, asumiendo que todas las actividades relacionadas al trabajo del proyecto se pueden dividir en estas tres categoras. Si se incluye actividades puramente administrativas como una cuarta categora, los porcentajes pueden ser de 15 % para el plan, 25% para el costo, 35% para el desempeo y 25% para la administracin. El ltimo tem debera incluir cosas como las entrevistas al personal, la preparacin de sus evaluaciones y responsabilidades similares. Las responsabilidades clsicas de un gerente de proyecto son usualmente descritas en trminos de cuatro actividades: 1) planeacin, 2) organizacin, 3) direccin y 4) monitoreo. La actividad de planeacin es dominante en los primeros estados de un proyecto, especialmente en lo que tiene que ver con la preparacin coherente de un plan para el proyecto. En el estado estable del proyecto, la planeacin involucra actualizar el plan, repensarlo y planear cmo manejar problemas y contingencias especiales. La organizacin involucra decidir cmo organizar el proyecto mismo y reorganizarlo cuando y donde sea necesario. Esto tambin involucra la asignacin de recursos a las variadas y diferentes tareas del proyecto; esto se refleja en la preparacin inicial de listas de tareas, estructuras de divisin de trabajo, matrices de responsabilidad para el proyecto, y as por el estilo. La actividad de direccin es la ejecucin diaria, formal e informal, del proyecto y sus varias revisiones, as como tambin la delimitacin de las asignaciones cuando se requieren cambios o ajustes finos para resolver problemas. El monitoreo involucra la lectura continua del estado de todos los aspectos del proyecto en rel acin con los requerimientos y el plan del proyecto. Si el monitoreo resulta en el descubrimiento de problemas, deben tomarse acciones remediales bajo la actividad de direccin. Un factor a menudo frustrante aparece cuando las responsabilidades del gerente del proyecto y la autoridad no son congruentes. El gerente del proyecto usualmente tiene toda la responsabilidad para el xito o falla del proyecto esto puede ser extremadamente difcil si esta persona no puede, por ejemplo,

Administracin del diseo 7

contratar o despedir personal, negociar con vendedores externos y proveedores externos, y hacer arreglos finales con los clientes. La limitada autoridad es una de las "banderas rojas" de la mayora de los gerentes de proyectos. Un resumen de las diferentes responsabilidades y deberes de un jefe de proyecto es: Costo/presupuesto Confirmar que el proyecto puede ser completado dentro del presupuesto estimado. Revisar peridicamente (p.e. mensualmente) los reportes de costos Estimar y mitigar los riesgos en los costos del proyecto. Asegurar la validez de los costos del ciclo de vida del producto. Plan

Establecer y actualizar el plan maestro Asegurar que todos los eventos claves al interior del proyecto sean cumplidos Determinar maneras de acomodar el tiempo cuando ocurren desfases. Obtener estimativos vlidos de tiempo para completar el proyecto. Planear revisiones del estado del proyecto, internas y con el cliente.

Desempeo tcnico Confirmar la validez de la propuesta tcnica Realizar seguimiento continuo del estado del desempeo tcnico. Asegurar que el producto satisface todos los requerimientos tcnicos. Administrativo Entrevistar al personal, contratar y efectuar la evaluacin. Comunicarse e interactuar con las gerencias Comunicarse e interactuar con los grupos internos de soporte. Construccin y direccin de los equipos de diseo Asegurar la disponibilidad de las instalaciones necesarias.

4.5. Algunas herramientas para la administrar proyectos de diseo En el desarrollo de un proyecto de diseo, sea cual sea el modelo que se utilice para trasladar las necesidades de los clientes en una solucin, se requieren utilizar varios procedimientos y medios para reunir, organizar y manejar la informacin requerida para generar las alternativas y evaluar su eficiencia. En lo que sigue se van a presentar y describir brevemente las herramientas que pueden utilizarse para planificar un proyecto de diseo, organizar las actividades, acordar las responsabilidades para el proyecto y hacer seguimiento del progreso. No obstante los mtodos y medios que se van a presentar pueden ser asignados a los pasos en el proceso de diseo, la administracin del proceso de diseo requiere ms que la aplicacin mecnica de herramientas de administracin de proyectos. La administracin en general, consta de cuatro funciones que son: La planeacin. La planeacin est relacionada directamente con los requerimientos del proyecto; para poder planificar un proyecto es necesario: Definir el propsito del proyecto, establecer el tiempo disponible y estimar la cantidad de recursos que pueden ser utilizados. La organizacin. Organizar, en un proyecto consiste esencialmente en determinar quin es el responsable de cada rea, de las tareas o actividades del proyecto, y qu otros recursos humanos y tcnicos pueden ser asignados para realizar las tareas.

Giovanni Torres Charry. IM, MSc. 2011

Captulo 4

La direccin. Puede ser una de las funciones ms complicadas de ejecutar en un proyecto, porque la direccin va mas all de la aplicacin de herramientas, est mucho ms asociada al liderazgo; en este sentido, dirigir un proyecto significa utilizar las herramientas y el carisma del lder para motivar a un equipo, mostrar que las tareas pueden ser entendidas, que la divisin del trabajo es justa, y que el nivel de trabajo produce avances satisfactorios hacia las metas del equipo. El monitoreo/control. Para que exista el control efectivo deben existir metas medibles a las cuales se les pueda hacer seguimiento de los avances en el tiempo; los resultados de estas valoraciones indicarn si las cosas marchan bien o que deberan tomarse algunas medidas, en este caso los resultados pueden sustentar el cambio de los planes o la toma de acciones correctivas.

En las secciones siguientes se presentan, se analizan y proporcionan ejemplos de las herramientas que podran utilizarse en la administracin de un proyecto de diseo. No es necesario que los equipos utilicen cada una de estas herramientas en todos los proyectos, es potestad del lder del equipo establecer de forma autnoma o en conjunto con el equipo que herramientas utilizar.

4.5.1. Estructuras de divisin del trabajo (EDT) Una de las herramientas utilizadas para la organizacin del proyecto son las estructuras de divisin del trabajo (EDT); con esta herramienta bsicamente lo que se desea saber es lo que se tiene que hacer para terminar el proyecto. La EDT en un proyecto de diseo es una representacin jerrquica de todas las tareas requeridas para completarlo. La filosofa que sustenta la divisin del trabajo, es que la mejor manera de enfrentarse a una labor muy grande o complicada es dividirla en labores ms pequeas y manejables. La EDT representa la divisin de los proyectos, en partes lo suficientemente pequeas, que hacen los directores; esta divisin permite estimar con confianza los recursos y el tiempo necesarios para cada tarea. En un proyecto, el lder del equipo de diseo deber asegurarse que los expertos realicen las tareas que van de acuerdo con sus conocimientos; para hacer esto de una manera adecuada, el lder del equipo tiene que primero determinar cules son las tareas y as poder asignarlas a los expertos del equipo en cada una de las reas a las que corresponda; un proyecto generalmente involucra la intervencin de profesionales o personas con conocimientos en varias especialidades. La EDT es una lista de todas las tareas necesarias para completar el proyecto, su organizacin es tal que permite al lder del proyecto y al equipo de diseo entender cmo encajan todas las tareas en el proyecto de diseo; esto ayuda al equipo a acabar de entender la magnitud del proyecto y tambin podra ayudar a determinar requerimientos de personal no identificados al inicio. No existe una nica manera de hacer la divisin del trabajo, en la figura 4.2 se muestra una estructura de divisin del trabajo establecida para el diseo de la mquina de pruebas mecnicas para la hoja de Aloe Vera (AMTM 100); como se puede ver en esta divisin, en el nivel ms alto se tienen siete tareas bsicas: Entender los requerimientos del cliente Analizar los requerimientos funcionales Generar y evaluar alternativas Seleccionar entre las alternativas Diseo de detalle Documentar el proceso de diseo Administracin del proyecto

Como se mencion previamente, la idea de la EDT es dividir el proyecto en subtareas lo ms pequeas posibles, que sean manejables; en este ejemplo se observa cmo cada una de las tareas de alto nivel se han dividido, y estas a su vez tambin se han dividido para mayor detalle; sin embargo en esta figura solo se

Administracin del diseo 9

muestran con detalle algunas tareas, por las limitaciones que impone el tamao de la pgina. Si fuera necesario hacerlo, el equipo encargado de este proyecto, probablemente ahondara ms en todas las reas. Este mtodo de organizar el trabajo no es la nica manera de conformar la estructura de divisin del trabajo, por lo que el equipo de diseo podra presentar esta estructura utilizando otra forma.

Figura 4.2 Estructura de divisin del trabajo para el diseo de la mquina AMTM 100
Claves para el desarrollo de la estructura de divisin del trabajo 1. Una estructura de divisin del trabajo debe estar completa. Para que sea completamente til, la EDT debe incluir explcitamente cualquier tarea o actividad que consuma recursos o tiempo, bien sea como una tarea principal o como un componente conocido de otra tarea; sta es la razn por la que las tareas de documentacin y administracin se presentan en la figura 4.2. Las actividades como la redaccin de informes, asistencia a juntas y presentacin de resultados son necesarias para la consumacin del proyecto, y si no se planifican, con toda certeza producirn un mal resultado ms adelante. 2. El principio bsico de una estructura de divisin del trabajo es que cada tarea que se lleva a un nivel ms bajo siempre se divide en dos o ms subtareas en dicho nivel; si la tarea no se divide, entonces el nivel ms bajo est incompleto o simplemente es un sinnimo del nivel ms alto. 3. Una regla fundamental para desarrollar una estructura de divisin del trabajo es que si no se puede determinar cunto tiempo se llevar una actividad o quin la realizar, entonces probablemente se deber dividir an ms. Es normal encontrar que los directores de proyecto experimentados desarrollan estructuras de divisin del trabajo ms cortas y menos detalladas que los directores relativamente inexpertos, debido a su mayor experiencia es probable que puedan incluir subtareas dentro de tareas identificables y medibles y que por lo tanto no requieran desagregacin.
Giovanni Torres Charry. IM, MSc. 2011

Captulo 4

4. Cualquier parte de su jerarqua de tareas en una EDT deber sumarse, es decir, el tiempo requerido para completar una actividad en un nivel superior (por ejemplo, Generar alternativas) debe ser la suma de las tareas que se enumeran en el nivel que sigue hacia abajo (lluvia de ideas, desarrollar tabla morfolgica, desarrollar conceptos globales). Esto sugiere que la divisin del trabajo hasta el siguiente nivel de abajo debe ser realizada en forma suficiente e ntegra. Dos criterios para evaluar la utilidad de una EDT son: Integridad, en este caso se refiere a la idea de que la estructura de divisin del trabajo deber englobar todas las actividades que consumen recursos o tiempo. Suficiencia, se refiere a la idea de que las tareas se dividan con calidad, es decir, hasta un nivel de detalle adecuado, de modo que el equipo de diseo pueda determinar cunto tiempo se requerir para realizarlas. La estimacin de quin y qu se requiere y por cunto tiempo, es una disciplina valiosa para cualquier proyecto, ya sea en un curso de diseo o en el "mundo real", tanto para desarrollar el diseo como para asegurarse de que hay tiempo suficiente para documentar y presentar los resultados. En muchas ocasiones se tiende a confundir lo que es la estructura de divisin del trabajo. Qu no es una EDT: Muchos directores de proyecto inexpertos, confunde la EDT con el organigrama para completar un proyecto; esta confusin se debe a veces a que la experiencia previa del director con grficas visualmente similares, es a menudo con "organigramas". Para aclarar la diferencia, recuerde que la estructura de divisin del trabajo es una divisin de tareas, no de funciones o personas en una organizacin. La EDT trabajo no es un diagrama de flujo. En muchos casos la lista de tareas se organiza de modo que una tarea (por ejemplo, la redaccin del informe final) se muestre en una parte de la jerarqua diferente de la que ocupan las otras tareas que deben precederla (por ejemplo, todo el diseo, la construccin y las pruebas que se estn reportando); un diagrama de flujo, por otro lado, muestra las relaciones temporales y lgicas entre las tareas. Una estructura de divisin del trabajo no es una lista de todas las disciplinas o habilidades que se requieren para completar las tareas. En muchos casos las tareas por completar requieren varias habilidades diferentes (por ejemplo, ingeniera elctrica e ingeniera en sistemas de propulsin). Las tareas realizadas por profesionales con estas habilidades se pueden combinar en la misma parte de la jerarqua si la lista de tareas satisface los criterios anteriores de integridad y suficiencia.

La figura 4.3 es otro ejemplo de una estructura de divisin del trabajo, este ejemplo es para la construccin, ensamble y pruebas de la mquina AMTM100. Esta estructura de divisin del trabajo aunque sigue siendo jerrquica, no est presentada en forma grfica, algunos equipos prefieren utilizar la forma grfica por ser ms clara, sin embargo es perfectamente permisible utilizar una forma tabular como la de la figura 4.3, siempre y cuando cumpla con los criterios de integridad y suficiencia y adems que el equipo la entienda adecuadamente. Es bueno recordar que la estructura de divisin del trabajo es una herramienta que un equipo utiliza para asegurarse que entiende todas las tareas necesarias para completar su proyecto. Por esta razn es tan valiosa para determinar las metas del proyecto; en este sentido el nivel de detalle presentado en la figura 4.3 podra requerir la elaboracin de estructuras de divisin del trabajo de apoyo para algunas de las actividades.

Administracin del diseo 11

PROYECTO AMTM100 Fase de construccin, ensamble y pruebas Fecha: 05/01/2011 Estructura de divisin del trabajo Cdigo GTC.101 GTC.101.1 GTC.101.1.1 GTC.101.1.2 GTC.1001.2 GTC.1001.3 GTC.1001.4 GTC.1001.5 GTC.1001.6 GTC.1001.7 GTC.1001.8 GTC.1002 GTC.1002.1 GTC.1002.2 GTC.1002.3 GTC.1002.3.1 GTC.1002.3.2 GTC.1002.4 GTC.1003 GTC.1003.1 GTC.1003.2 GTC.1003.3 GTC.1003.4 GTC.1004 GTC.1004.1 GTC.1004.1.1 GTC.1004.1.2 GTC.1004.1.3 GTC.1004.2 Ttulo Planeacin de la construccin, ensamble y pruebas Revisin de planos y listado de partes Revisin de planos y listado de partes por mdulo Concepto de aceptacin o ajustes Seleccin de proveedores posibles de mecanizado por mdulo Seleccin de posibles proveedores sistema elctrico Seleccin de posibles proveedores sistema control Solicitud y evaluacin de cotizaciones Elaboracin de contratos Elaborar cronograma para la construccin ensamble y pruebas Revisin interna Construccin Envo de planos y especificaciones tcnicas a cada proveedor Revisin de avances Recepcin y aceptacin de mdulos Revisin de especificaciones y control de calidad Concepto de aceptacin o solicitud de ajustes Compra de partes comerciales para el ensamble Ensamble de la mquina Alistamiento de los mdulos y elementos comerciales Alistamiento de las herramientas y materiales Ensamblaje de la mquina Aplicacin de ajustes Realizacin de pruebas Chequeo general de la mquina - apariencia Prueba en vaco Prueba con material Concepto de aceptacin o realizacin de ajustes Realizacin de informe de construccin

Figura 4.3 Estructura de divisin del trabajo para la construccin, ensamble y pruebas de la AMTM100
4.5.2. Tablas de responsabilidad lineal Generalmente, una vez se ha desarrollado una EDT para el proyecto, se utiliza la tabla de responsabilidad lineal para determinar qu miembro del equipo tiene la responsabilidad principal para la terminacin exitosa de cada tarea, as como para identificar a otras personas que deben participar para terminar la tarea. La tabla de responsabilidad lineal se configura como una matriz que relaciona cada una de las tareas que requieren responsabilidad administrativa con los miembros del equipo, el cliente, los usuarios y otros participantes. Los proyectos de diseo son desarrollados por equipos, por lo que el uso de tablas de responsabilidad son tiles, tanto para identificar con claridad quin es responsable de cada tarea, como para indicar cualquiera de los individuos adicionales (compaeros de equipo, el cliente, un experto externo, etc.) que debern intervenir. Despus de que se identifican las tareas por realizar mediante la estructura de divisin del trabajo, un equipo de diseo tiene que determinar si cuenta o no con los recursos humanos, las personas, para realizar las tareas. El equipo tambin tiene que decidir quin ser el responsable de cada tarea. Esto se puede hacer elaborando una tabla de responsabilidad lineal. En la tabla de responsabilidad lineal se enumeran todas las tareas a considerar y administrar y se asignan a uno o a todos los participantes del proyecto.
Giovanni Torres Charry. IM, MSc. 2011

Captulo 4

La figura 4.4 muestra una tabla de responsabilidad lineal simplificada correspondiente a muchas de las tareas en el proyecto AMTM100 de la figura 4.2; adems de todas las tareas de alto nivel, en esta tabla tambin se presentan las subtareas asociadas con varios de los niveles bajos. En la prctica, conviene sealar todas las tareas de alto nivel y las subtareas que requieren atencin por parte de la gerencia; se sugiere que un director con poca experiencia proporcione mas detalles de los que requerira un director experimentado, de esta manera se asegura que no ha olvidado ninguna actividad y que se ha asignado efectivamente a las personas apropiadas. Como se puede ver en la figura 4.4, hay una fila para cada tarea, en donde se seala la funcin, si la hay, de cada participante en el proyecto. Estas funciones no necesariamente incluyen la atribucin de la responsabilidad principal. De hecho, la mayora de los participantes desempean una cierta funcin de apoyo para muchas de las tareas, por ejemplo revisar, consultar o trabajar en la direccin de quien sea responsable. Se asigna una columna a cada uno de los participantes; esto les permite recorrer la columna hacia abajo para determinar sus responsabilidades en el proyecto. Por ejemplo, obsrvese que el cliente (o el representante designado por el cliente) tiene la facultad de dar su aprobacin final en las reuniones de revisin que se hagan. Existen dos consultores externos que pueden ser consultados; concretamente el consultor uno, que seguramente est relacionado con la mercadotecnia, es consultado durante la aplicacin de la tcnica del QFD, especficamente durante el establecimiento de las especificaciones objetivo. El jefe del equipo, el director del diseo, ha hecho valer su derecho a ser informado en varios puntos del proyecto, sobre todo en funcin de las revisiones internas de diseo. En la tabla de responsabilidad de la figura 4.4, tambin se observa que el lder del proyecto no siempre tiene la responsabilidad principal en cada tarea del proyecto. A menudo sucede que en proyectos realizados en equipo el lder no es responsable de las tareas ajenas a su rea tcnica de conocimientos, aunque es posible que desee especificar una funcin de revisin o apoyo para permanecer informado. Compartir la responsabilidad de esta manera en ocasiones es bastante difcil para los equipos y los lderes de stos. Compartir la responsabilidad, lo cual est fuertemente ligado con la fase de tormenta de la formacin del equipo de diseo, requiere prctica. Por consiguiente, la tabla de responsabilidad lineal se puede utilizar para hacer ms explcita para el equipo esta fase de la formacin de este y para facilitarle llegar a un consenso sobre quin har qu en el proyecto. Tambin se puede utilizar para que los participantes externos en un proyecto entiendan lo que se espera de ellos. Asimismo, es posible que los expertos externos tengan que organizar su tiempo para asegurar su disponibilidad, y el director de diseo quiz necesite disponer de los recursos necesarios para pagar el tiempo de los expertos. Est claro que la tabla de responsabilidad lineal puede ser un documento muy importante para traducir el "qu" de la estructura de divisin del trabajo en "quin" es el responsable. Al mismo tiempo, podramos caer en la tentacin de incluir ms en la tabla de responsabilidad lineal como sustituto de admitir que nosotros o nuestro equipo no sabe algo. Por ejemplo, si en cada tarea se les asigna una funcin de apoyo o trabajo a todos los participantes del equipo, surgirn dudas sobre si realmente entendieron dichas funciones. Asimismo, si un lder de equipo asume la responsabilidad principal de todas las tareas, el equipo con toda certeza se ver inducido a considerar la tabla de responsabilidad lineal como un poco ms que un arrebato del poder o como un espejo de las inseguridades del lder. As pues, es mejor considerar una tarea abierta y dejar su fila en blanco en lugar de llenarla a ciegas por el afn de llegar a una conclusin falsa. Tambin es importante que un equipo entienda que puede ser necesario reexaminar las funciones de cada participante conforme se desarrolla el proyecto, sobre todo si el equipo es relativamente inexperto o el proyecto inicial es ambiguo.

Administracin del diseo 13

Tabla de responsabilidad lineal 1.0 Entender los requerimientos del cliente 1.1 Aclarar el planteamiento del problema 1.2 Establecer las necesidades de los clientes 1.2.1 Realizar vigilancia tecnolgica 1.2.2 Realizar anlisis grupal 1.3 Establecer especificaciones objetivo 1.3.1 Establecer medidas de ingeniera 1.3.2 Aplicar tcnica de QFD 1.3.2.1 Realizar vigilancia tecnolgica 1.3.2.2 Realizar encuestas a los clientes 1.3.2.3 Realizar benchamarking a mquinas para p. de dureza 1.3.2.4 Establecer especificaciones objetivo 1.4 Revisar con el cliente 2.0 Analizar requisitos funcionales 2.1 Modelo de Caja negra - caja de cristal 2.1.1 Desarrollar modelo de Caja negra 2.1.2 Desarrollar arbol funcional 2.1.1 Desarrollar modelo de Caja de cristal 2.2 Revisar internamente 3.0 Generar y evaluar alternativas 3.1 Generar alternativas 3.1.1 Realizar vigilancia tecnolgica 3.1.2 Consultar expertos 3.1.2 Desarollar conceptos de solucin para cada funcin 3.1.3 Desarrollar tabla morfolgica 3.1.4 Desarollar conceptos de solucin globales 3.2 Evaluar alternativas 3.2.1 Ponderar objetivos 3.2.2 Comparacin por pares 3.2.2 Revisin interna 3.3 Revisar con el cliente 4.0 Diseo de detalle 4.1 Dimensionar y calcular estructura 4.2 Dimensionar accionamientos 4.3 Disear esquemas de control 4.3 Disear esquemas adquisicin de datos 4.4 Integracin de sistemas 4.5 Revisin interna 4.6 Revisar con el cliente 4.0 Documentar el proyecto 4.1 Generar informes internos y externos 4.1 Registros de diseo, manuales, especificaciones 5.0 Administracin del proyecto
Cdigo: 1 = Responsable 2 = Apoyo /trabajo 3 = Revisin

Miembro No1 Miembro No2 Miembro No3 Miembro No4 Director del del equipo del equipo del equipo del equipo diseo 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 2 2 2 6 2 2 2 1 1 1 2 2 4 4 1
4 = Aprobacin 5 = Debe ser consultado 6 = Puede ser consultado

Director de manufactura

Representante del cliente 5 6

Consultor externo 1

Consultor externo 2

2 2 2 2 2 2 2 2 2

2 2 2 2 2 2 2 2 2 2

2 2 2 2 2 2 2 2 2 3 3 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 1 2 4 3 3 3 3 3 6 2 4 4 3 3 3 6 6 4 2 2 2 2 3 2 2 2

6 6

6 4

5 6

1 1 1 1 1 1

5 5

Figura 4.4 Tabla de responsabilidad lineal para el proyecto de diseo AMTM100

Giovanni Torres Charry. IM, MSc. 2011

Captulo 4

4.6. Programas y otras herramientas de administracin del tiempo Se pueden programar las actividades de varias maneras, por ejemplo mediante calendarios de equipo, grficas de Gantt o redes de actividades. Como su nombre lo indica, un calendario de equipo muestra de cunto tiempo dispone el equipo de diseo, e incluye sealamientos que indican lmites de tiempo y periodos dentro de los cuales se debe completar el trabajo. Una grfica de Gantt es una representacin de barras horizontales que describe el curso de las diversas actividades de diseo contra una lnea de tiempo. Una red de actividades es una grfica de las actividades y los eventos del proyecto, y muestra el orden lgico en el que se deben realizar. Es importante saber que si bien un programa ayuda a planificar y controlar el trabajo de un equipo de diseo, fcilmente puede ser slo una simple imagen llamativa o grfica de mercadeo (existe software que ayuda a desarrollare este tipo de grficos).

Se utilizan herramientas de programacin y otras similares que sirven para identificar con anticipacin las cosas que realmente complicaran el proyecto si no se realizan a tiempo. Existen tres herramientas de programacin primordiales de uso frecuente en la administracin de un proyecto: el calendario, la red de actividades y los diagramas de Gantt. Un calendario de equipo es probablemente la herramienta ms conocida, ya que cumple muchas de las funciones de las agendas o diarios personales. Simplemente es una proyeccin de los lmites de tiempo o fechas de vencimiento de un proyecto en un calendario convencional. Las otras dos herramientas, la red de actividades y la grfica de Gantt, son poderosas y, por consiguiente, potencialmente ms tiles. Las dos son representaciones grficas de las relaciones lgicas entre las tareas y los periodos dentro de los cuales sern realizadas. De hecho, la mayora de los programas de computadora de administracin de proyectos utilizan la misma informacin para generar tanto redes de actividades como diagramas de Gantt. Existen, sin embargo, diferencias importantes en la prctica que vale la pena describir para que el equipo de diseo pueda decidir qu herramienta es ms apropiada para su proyecto.

4.6.1. Calendarios de equipo Como ya se dijo, un calendario de equipo es simplemente una proyeccin de los lmites de tiempo en un calendario convencional como el que se podra encontrar en una pared o un escritorio. Estos lmites de tiempo ciertamente incluyen los impuestos desde afuera, tal como compromisos con clientes (o con profesores en el caso de proyectos acadmicos), pero tambin deben incluir fechas de vencimiento generadas por el equipo para las tareas planteadas en la estructura de divisin del trabajo. En este sentido, el calendario de equipo realmente es un acuerdo por parte del equipo para asignar los recursos y el tiempo necesarios para cumplir las fechas de vencimiento que aparecen en el calendario. La figura 4.5 muestra el calendario de trabajo establecido para el mes de febrero para el equipo de diseo del proyecto AMTM100, en este caso no hay imposiciones de tiempo puestas desde afuera del equipo; sin embargo en algunos proyectos podra suceder que el calendario debiera ajustarse a tiempos y fechas establecidas por el cliente externo, el departamento de mercadeo, produccin u otro ente relacionado con el proyecto; en estos casos el equipo no tiene control sobre dichas fechas y debe ajustar sus recursos y actividades para cumplirlas. En la elaboracin de un calendario de equipo hay que tener en cuenta varios puntos. Primero, la nocin de calendario de equipo presupone que todas las fechas de vencimiento de plazos quedaron entendidas y fueron acordadas por todos los integrantes del equipo. Como tal, el calendario llega a ser un documento que puede -y debera- ser revisado en cada junta del equipo. Segundo, el calendario de equipo debe permitir tiempos que por lo menos sean compatibles con las estimaciones de tiempos generadas en la estructura de divisin del trabajo. Si se concluye que una tarea requiere dos semanas, no hay por qu asignarle slo una semana en el calendario de equipo.

Administracin del diseo 15

Cabe sealar un ltimo punto: el calendario de equipo, aunque es fcilmente entendido por los miembros del mismo, no puede por s mismo capturar las relaciones entre las actividades. Los calendarios de equipo en realidad son tiles slo para proyectos simples o en casos en los que son complementados con otras herramientas de administracin de proyectos (como las que se estudian en la siguiente seccin).

Sunday

Monday

Tuesday

FEBRUARY 2011
Wednesday

Thursday

Friday

Saturday

3
Mquina ensamblada (elementos mecnicos)

8
Mquina energizada

9
08:00 - 10:00 a.m. Reunin revisin interna

10
Inicio pruebas

11

12

13

14

15

16
Finaliza pruebas

17
Inicio ajustes

18

19

20

21

22
Finaliza ajustes

23
Pruebas finales

24

25
Finaliza Planos, manuales Informe final

26

27

28
8:00 - 10:00 a.m Reunin interna

Sa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Ja nua ry 2011 M T W Th F

Ma rc h 2011 T W Th F 1 2 3 4 6 7 8 9 10 11 13 14 15 16 17 18 20 21 22 23 24 25 27 28 29 30 31 S M

Sa 5 12 19 26

Notes:

www.vertex42.com

2009 Vertex42 LLC

Figura 4.5 Calendario de trabajo para el proyecto de diseo AMTM100

4.6.2. Redes de actividades La red de actividades se basa en la nocin de que cada tarea y su resultado pueden ser tratados como una actividad o un evento aparte. Por ejemplo, en un proyecto de construccin, se podra considerar la accin de "excavar una zanja para los cimientos" como una actividad, y la "existencia de la zanja para los cimientos" como un evento. Se podra considerar entonces la tarea "construir cimbras" como una actividad, y "cimbras construidas" como un evento. Por ltimo, se podra considerar la tarea "vaciar el concreto en las cimbras" como otra actividad, y "cimientos terminados" como otro evento. Ahora bien, existen por lo menos dos maneras de representar esta serie de actividades y eventos grficamente. Por ejemplo, se podra construir una red de nodos y arcos de conexin, y luego identificar cada nodo con un evento y cada arco como la actividad que hace que suceda el evento. Por otra parte, se podra representar cada actividad con un nodo, e identificar los eventos simplemente como los arcos que parten de los nodos. Obviamente es indistinto qu esquema se elija, mientras seamos consistentes. Se utilizar la forma de red de actividades llamada red de actividades en nodo, la cual se adhiere a la regla convencional de colocar actividades en o sobre nodos. Esta forma de red de actividades es la que ms se utiliza actualmente en los programas de computadora de administracin de proyectos.
Giovanni Torres Charry. IM, MSc. 2011

Captulo 4

Si se tuviera que utilizar una lista de todas las tareas, como la generada por una estructura de divisin del trabajo muy completa, se creara una lista o serie de nodos, uno por cada actividad. Sin embargo, puesto que se pretende programar las actividades, es absolutamente esencial que se determine apropiadamente el orden lgico, o las relaciones de precedencia entre ellas. En el sencillo ejemplo de construccin antes mencionado, slo un jefe de obras insensato (o temerario) pretendera vaciar el concreto antes de que las cimbras estuvieran construidas y en su lugar. A menudo existen relaciones similares en proyectos de diseo. No se intentara, por ejemplo, determinar cules de los objetivos del usuario son ms importantes hasta estar seguros de que ya se enumeraron ntegramente todos. De manera similar, un lder de equipo alentara al equipo de diseo para que pospusiera las alternativas de evaluacin hasta despus de generar todas la alternativas. En estos casos se ve que el orden lgico de las actividades del proyecto evitar que se realice una actividad hasta que se complete la anterior. Este tipo de relacin lgica se llama precedencia de terminacin para inicio. Es decir, se debe terminar una actividad antes de iniciar la siguiente. En ocasiones, las relaciones lgicas son ms sutiles. Por ejemplo, se podra obtener una idea de diseo potencialmente til mientras an se estn estudiando las necesidades del cliente. En este caso, la relacin es tal que se puede comenzar la tarea de generar ideas antes de completar la de entender las necesidades, pero no se puede considerar completa la tarea de generacin de ideas hasta estar seguros de que se complet la tarea de entender las necesidades. Esto se llama precedencia de terminacin para terminacin, y significa que no se puede terminar la tarea sucesora hasta estar seguros de que se termin la actividad anterior. Un ejemplo comn de precedencia de terminacin para terminacin ocurre durante la redaccin de un informe final. A los equipos en ocasiones se les pide que comiencen a escribir dicho informe sobre un proyecto con mucha anticipacin, porque eso les permite escribir notas sobre la investigacin bibliogrfica realizada mientras los datos an estn frescos en sus mentes. Sin embargo, sera muy desconcertante saber que un equipo termin el informe final antes de completar los aspectos de diseo de su proyecto! Un tercer tipo de relacin es la precedencia de inicio para inicio, en la que no se puede iniciar una actividad hasta comenzar tambin otra, aunque ninguna necesita estar terminada antes que la otra. Un ejemplo de este tipo de relacin podra ser la edicin de secciones del informe final de un proyecto. Para hacer que un miembro del equipo revise la gramtica y el estilo, una parte del informe debe haber sido escrita ya, pero no tiene que estar terminada para iniciar la revisin. (Evidentemente, en estos casos y en otros similares se debe actuar con juicio). Es posible que se tengan que volver a hacer las revisiones realizadas antes de que las secciones del informe estn casi terminadas, porque estas secciones incompletas posteriormente se documentan ms. Es importante entender los diferentes tipos de relaciones entre las tareas, porque si se asume que todas las actividades son totalmente independientes u obedecen precedencias de terminacin para inicio, se estarn desperdiciando oportunidades de realizar el trabajo con anticipacin cuando los recursos quiz estn ms disponibles o incluso ociosos. Una vez que se entienden las relaciones lgicas, se puede elaborar una red de actividades para el proyecto. Bsicamente, esta red se compone de un nodo por cada actividad y una flecha que sale de cada actividad hacia sus sucesoras lgicas. En general existen varias actividades que no tienen predecesoras o sucesoras lgicas. Al inicio de un proyecto, las actividades como la investigacin bsica o las juntas iniciales con el cliente tal vez no dependan de algo antes que ellas; para tratar con esto, hay una regla convencional que requiere iniciar una red de actividades con el nodo de "inicio del proyecto". En algunos casos, de hecho puede haber un inicio formal, como una junta de iniciacin del proyecto, pero en otros esto es lo que se conoce como actividad ficticia. Asimismo, para asegurarse de que cada nodo tiene un lugar para conectar su flecha dirigida hacia afuera, hay un nodo convencional de "fin del proyecto". Una vez ms, puede haber una terminacin formal del proyecto, como la entrega del informe final o una junta con el cliente por ltima vez, pero si no, la red deber tener un nodo ficticio para finalizarlo. Una consecuencia de la regla convencional de "inicio del proyecto" y "fin del proyecto" es que cada nodo en la red, excepto estos dos, tendrn por lo menos una flecha que entra en l y por lo menos una que sale de l. Si la actividad tiene

Administracin del diseo 17

precedentes lgicos, entonces la flecha de entrada vendr de stos. Si la actividad tiene sucesores lgicos, entonces la flecha o flechas que salen de la actividad debern apuntar hacia la sucesora. Existen algunas actividades cuyo tiempo de inicio se puede ajustar sin afectar el tiempo total requerido para completar el proyecto, mientras que puede haber otras actividades que deban iniciar tan pronto como sea lgicamente posible. Una actividad para la que se puede ajustar el tiempo de inicio se dice que tiene una holgura, que es la diferencia de tiempo entre la fecha ms temprana en la que se puede iniciar esa actividad y la fecha ms retardada en la que puede dar inicio sin afectar el tiempo total del proyecto. Las actividades que no tienen holgura se dice que estn en la ruta crtica. El inicio y la terminacin a tiempo de las actividades que estn en la ruta crtica son de primordial importancia para la terminacin oportuna de un proyecto. Por eso los directores de proyecto exitosos prestan mucha atencin a las actividades que estn en la ruta crtica, mientras que permanecen "slo" atentos a las otras. Evidentemente no se pretende explicar por completo las sutilezas de este tipo de programacin, pero s vale la pena que un equipo de diseo determine qu actividades deben apegarse meticulosamente al programa, y cules estn fuera de la ruta crtica. El ajuste de las actividades que no estn en la ruta crtica tambin es importante para balancear la carga de trabajo del equipo. De hecho, en general es mejor planificar el trabajo de un equipo, de modo que pueda realizar cosas a un paso fijo o relativamente constante, puesto que las ocurrencias normales de la Ley de Murphy siempre crean oportunidades para que las tareas se acumulen cerca del final. Por consiguiente, conviene planificar el trabajo y colocar las actividades que tienen cierta holgura al principio del proyecto. En ocasiones se dice que en proyectos de diseo es mejor organizar el trabajo de modo que podamos vernos presos del pnico al principio. (La experiencia sugiere que si usted se ve preso del pnico pronto, an cabe la posibilidad de que experimente pnico ms tarde, aunque muy probablemente ser por problemas ms interesantes y tiles.)

4.6.3. Grficas de Gantt La misma informacin que se incorpora a una red de actividades tambin puede ser representada como una grfica de barras, o grfica de Gantt. La figura 4.6 muestra un diagrama de Gantt que podra estar asociada a una red de actividades si se hubiera generado esta, para este se utiliz el software libre OpenProj. Se alcanza a observar que cada actividad tiene una fecha de inicio y una de terminacin que se leen a partir del eje de tiempo en la parte superior de la grfica. Muchos gerentes consideran que la grfica de Gantt es ms fcil de leer que una red de actividades, puesto que permite relacionar el tiempo de una manera ms que evidente. Adems, se puede desarrollar o bosquejar una grfica de Gantt sin herramientas basadas en la computadora, utilizando solamente papel cuadriculado, aunque tambin puede ser elaborada con programas de hoja de clculo estndar. Sin embargo, esta simplicidad puede tener un precio. Un equipo de proyecto puede construir una grfica de Gantt sin poner cuidado en las relaciones lgicas antes mencionadas. Si esto sucede, seguramente se presentarn varios problemas durante el desarrollo del proyecto. En primer lugar, se vuelve ms difcil para el equipo establecer prioridades si las relaciones lgicas entre las tareas no estn claras. El equipo, por ejemplo, puede realizar la tarea ms interesante o ms difcil, aun cuando otras estn en la ruta crtica. Adems, sin informacin precisa con respecto al orden lgico de los eventos, es posible que el equipo encuentre que una tarea aparentemente sin importancia tiene sucesoras ms importantes que no pueden ser iniciadas. Por ltimo, si la separacin es inevitable en algunas tareas, todo el periodo de holgura en una actividad puede consumirse, y esto hace que dicha actividad y sus sucesoras se vuelvan crticas. Esta clase de problemas se puede evitar si se supone que la red de actividades est relacionada con una grfica de Gantt con precedencia de terminacin para inicio. De este modo, los equipos deben trabajar como un grupo para construir primero la red de actividades. Entonces, algunos o todos los miembros del equipo pueden asentar sus resultados en una grfica de Gantt o en otro formato grfico similar. Esto contribuye a garantizar que el equipo ha considerado todas las tareas y las relaciones entre ellas, y eso refuerza la planeacin emprendida al elaborar la tabla de responsabilidad lineal.
Giovanni Torres Charry. IM, MSc. 2011

Captulo 4

Figura 4.6 Diagrama de Gantt para el proyecto AMTM 100

Administracin del diseo 19

Septiembre

Septiembre

Proyecto de investigacin: Caracterizacin mecnica de la hoja de aloe y diseo de mquinas para la extraccin y transformacin de gel de aloe vera Cronograma de actividades - Fase I Meses

Noviembre

Noviembre

Diciembre

Febrero

Febrero

Agosto

Agosto

propiedades fsicas y mecnicas

Diseo de mquinas y

dispositivos

Identificacin de las caractersticas fsicas y mecnicas de la hoja de aloe vera relevantes en la extraccin del gel. Desarrollo de experimentos y protocolos para la caracterizacin fsica y mecnica de la hoja de aloe vera. Diseo y construccin de equipos para las pruebas de caracterizacin de la hoja de aloe vera. Realizacin de pruebas de caracterizacin dela penca de sbila Anlisis y consolidacin de resultados de pruebas de caracterizacin dela penca de sbila Identificacin de las necesidades especficas del proceso de extraccin de gel. Desarrollo de experimentos y protocolos para la caracterizacin de los diferentes mecanismos de extraccin Diseo y construccin de equipos para las pruebas de caracterizacin de los mecanismos de extraccin de gel. Realizacin de pruebas de caracterizacin de los mecanismos de extraccin de gel. Anlisis, consolidacin de resultados y establecimiento del esquema de extraccin mas apropiado. Diseo de prototipos virtuales de mquinas para el esquema de extraccin seleccionado. Construccin de prototipo de mquina de extraccin Verificacin y validacin del prototipo de la mquina de extraccin de gel Elaboracin de planos, manuales de procesos y manuales de operacin y mantenimiento de la mquina de extraccin de Elaboracin de la solicitud de patente mquina de extraccin de gel Socializacin de los resultados a la comunidad productora de aloe vera. Meses Coordinador del proyecto Coinvestigador Estudiante de maestra fase experimental Estudiante de maestra fase diseo de equipos Estudiante de pregrado fase experimental Estudiante de pregrado fase diseo de equipos Estudiante de pregrado fase diseo de equipos

Caracterizacin de las

Seleccin del esquema de

extraccin

de la penca de sbila

1 50 30 50 0 50 0 0

2 50 30 50 0 50 0 0

3 50 30 50 0 50 0 0

4 50 30 50 0 50 0 0

5 37 30 50 0 0 0 0

6 40 20 50 0 50 50 0

7 50 10 50 0 50 50 0

8 50 10 50 50 50 50 0

9 50 20 50 50 50 50 0

10 50 20 50 50 0 0 0

11 50 20 50 50 0 0 0

12 50 40 50 50 50 0 0

13 50 20 50 0 50 0 0

14 50 30 50 0 50 0 0

15 50 32 50 0 50 0 0

16 50 40 50 50 0 0 0

17 50 40 50 50 0 0 0

18 50 0 50 50 0 50 50

19 50 0 0 50 0 50 50

20 50 0 0 50 0 50 50

21 50 0 0 50 0 50 50

22 50 0 0 50 0 0 0

23 50 0 0 50 0 0 0

24 50 0 0 50 0 50 50

25 50 0 0 50 0 50 50

26 50 0 0 50 0 50 50

27 50 0 0 50 0 50 50

28 50 0 0 50 0 0 0

29 50 25 0 50 0 0 0

30 Meq 50 30 0 50 0 0 0 14,8 5,1 9,0 10,0 6,0 6,0 4,0

Figura 4.7 Diagrama de Gantt adaptado en hoja de clculo para manejo actividades de recursos humanos en proyecto de investigacin

Giovanni Torres Charry. IM, MSc. 2011

Agosto

Marzo

Marzo

Marzo

Mayo

Enero

Mayo

Enero

Mayo

Fase/Actividad

Diciembre

Octubre

Octubre

Junio

Junio

Junio

Abril

Abril

Abril

Julio

Julio

Julio

En la figura 4.7 se muestra otro tipo de herramienta de control que se asemeja a un diagrama de Gantt, en este caso fue realizada en Excel y personalizada para que adems de visualizar en el tiempo la planeacin en la ejecucin de las actividades tambin se muestren los requerimientos de recurso humano.

4.7. Presupuestos La herramienta principal utilizada para administrar actividades que implican gastos en un proyecto es el presupuesto. En esencia, un presupuesto es una lista de todas las partidas que incurren en un costo econmico, organizada en una serie de categoras lgicamente relacionadas (por ejemplo, mano de obra, materiales, etc.). Obsrvese que hay una importante diferencia entre el presupuesto para realizar el diseo, o las actividades del mismo, y el presupuesto necesario para realizar o construir el artefacto en proceso de diseo. Nuestro inters se centra principalmente en el presupuesto para realizar el diseo. Los presupuestos son herramientas esenciales aunque difciles para los directores de proyecto. Permiten a los equipos determinar qu recursos financieros y de otro tipo se requieren, y adaptar estos requerimientos a los recursos disponibles. Los presupuestos tambin requieren que los equipos expliquen cmo estn gastando el dinero del proyecto. Y por ltimo, los presupuestos sirven para formalizar el apoyo de la organizacin ms grande de la cual se obtuvo el equipo. El manejo de un proyecto de gran envergadura podra requerir muchos de los conceptos de ingeniera econmica que pueden ser vistos en un pregrado de ingeniera, por otro lado, en general no se requieren presupuestos grandes y complejos para realizar los proyectos de diseo que normalmente se llevan a cabo en entornos acadmicos y similares. (Recurdese, como ya se dijo con anterioridad, que interesa el presupuesto para realizar los diseos, no el presupuesto para fabricar los objetos diseados.) De este modo, los presupuestos para proyectos de diseo normalmente incluyen gastos de investigacin, materiales para prototipos y gastos de apoyo relacionados con el proyecto. El anlisis del presupuesto se limitar a las categoras anteriores de costos, es decir, materiales, viajes y gastos imprevistos. Esto significa que al intentar un presupuesto para un proyecto de diseo, al principio es necesario tratar de determinar qu clases de soluciones son posibles. Esto no quiere decir que se tenga que obtener la solucin, sino que se debern considerar las necesidades de recursos ms pronto de lo que realmente pudiera ser deseable. Un efecto de esto es que en los proyectos de diseo con frecuencia se trata de establecer presupuestos no excesivos que fijan lmites en lo que se puede gastar especificando el costo ms alto en el que se puede incurrir. El peligro en este procedimiento es que si se realiza de esta manera por rutina, para todos los proyectos en una organizacin, los recursos se reservarn para todos los proyectos de diseo y otros proyectos que nunca sern utilizados. Como una nota final, es importante valorar apropiadamente el tiempo invertido en un proyecto de diseo por todos y cada uno de los integrantes del equipo. Una forma de valorar el tiempo de un miembro del equipo es adoptar el "algoritmo" que los patrones utilizan para "facturar" el tiempo de un ingeniero que trabaja en un proyecto. La mayora de las compaas cobran entre dos y cuatro veces la compensacin directa de un empleado cuando le cobran a un cliente por el tiempo de dicho empleado. Ese multiplicador cubre las prestaciones adicionales, los costos de supervisin, los gastos generales y la utilidad. Si se tuviera que facturar el tiempo de un ingeniero con un salario equivalente a $8000 la hora, este trabajando 20 horas por semana en el proyecto durante 16 semanas, el costo cobrado por una compaa de diseo estara entre $5120.000 y $10240.000. En otras palabras, el tiempo es un recurso valioso, escaso e insustituible. ! Utilcelo bien no lo despilfarre!

4.8. Herramientas de monitoreo y control Hasta ahora presumiblemente se ha desarrollado un plan, un programa y un presupuesto. Cmo se puede dar seguimiento a la forma en que el equipo funciona con respecto al plan? sta es una pregunta importante, aunque puede ser muy difcil de responder. De nuevo, en el manejo de un proyecto de diseo,

Administracin del diseo 21

el monitoreo y el control son ms sutiles, y en cierto modo ms difciles que en otro tipo de proyectos en los cuales las actividades o tareas son muy claras y delimitadas. Existen varias tcnicas y herramientas disponibles para monitorear proyectos, una de ellas es la llamada matriz de porcentajes completa que se utiliza mucho en la industria de la construccin como un medio para relacionar la extensin del trabajo realizado en las partes de un proyecto con el estado del proyecto en su totalidad. El objetivo de la matriz de porcentajes completa es determinar el estado general del proyecto. Una matriz de este tipo utiliza la informacin de la estructura de divisin del trabajo y el presupuesto. La construccin de esta matriz slo requiere que se conozca el costo de cada partida o rea de inters, y el porcentaje del costo total correspondiente a dicha partida. De este modo, la matriz de porcentajes completa permite asentar el porcentaje del trabajo realizado en la tarea o partida de trabajo, y sumando todas las partidas en el proyecto, se puede calcular el porcentaje total del proyecto que se ha terminado. En general, el mtodo es muy adecuado para casos en los que se dispone de un mtodo claro para calcular avances. Si, por ejemplo, el trabajo de cimentacin de un proyecto de construccin constituye el 25% de los costos totales esperados de un proyecto, entonces se ha completado por lo menos el 12.5% del proyecto cuando se ha terminado la mitad del trabajo de cimentacin. Un jefe de obras puede actualizar peridicamente los avances en cada una de las reas generales de la estructura de divisin del trabajo para determinar el avance de todo el proyecto. En algunos casos una medida fsica puede servir para representar avances, por ejemplo metros de concreto colados en comparacin con el volumen total requerido en el plan, o toneladas de acero erigido en comparacin con las toneladas totales presupuestadas. Si bien este procedimiento es atractivo en proyectos estndar, en proyectos de diseo, por regla general, preocupa ms el avance con respecto al tiempo permitido que con respecto al presupuesto disponible, y es probable que no se disponga de medidas fsicas. Una alternativa es utilizar la duracin estimada de las actividades del equipo en lugar de presupuestos en dinero, junto con una regla simple para hacer el seguimiento de los avances. Una regla simple es que si se comienza a trabajar en una actividad, entonces el equipo de inmediato puede reclamar el 33% (o el 50%) de avance en dicha actividad. Sin embargo, el equipo no obtiene un progreso adicional hasta que se completa la actividad. Cuando se completa, el equipo recibe el 67% restante (o el 50%) de crdito por la tarea. En ningn caso se le otorga al equipo ms de 100% de crdito por una tarea, sin importar cunto tiempo se lleve en realidad una tarea, y el equipo obtiene el crdito completo cuando el trabajo est hecho, sin importar cunto tiempo se haya llevado en realidad. (Este mtodo claramente da mayor importancia a la divisin cuidadosa y precisa del trabajo en la estructura de divisin del trabajo.)

Giovanni Torres Charry. IM, MSc. 2010

Captulo 4

Matriz de porcentajes completa ACTIVIDAD Iniciar el Proyecto Aclarar el planteamiento del problema Establecer las necesidades de los clientes Establecer especificaciones objetivo Modelo de Caja negra - caja de cristal Generar alternativas Evaluar alternativas Dimensionar y calcular estructura Dimensionar accionamientos Disear esquemas de control Disear esquemas adquisicin de datos Integracin de sistemas Registros de diseo, manuales, especificaciones Finalizar el proyecto Total de das presupuestado
Cdigo: 0 = No inici, nada de crdito 1 = Inici proceso, 1/3 crdito

Duracin planificada (das) 0 3 10 8 5 20 15 20 15 10 5 5 15 0 131

Porcentaje total 0% 2% 8% 6% 4% 15% 11% 15% 11% 8% 4% 4% 11% 0% 100%

Estado (ver cdigo) 2 2 2 2 2 2 2 2 1 1 1 0 0 0

Crdito (das) 0,0 3,0 10,0 8,0 5,0 20,0 15,0 20,0 5,0 3,3 1,7 0,0 0,0 0,0 69,5%

2 = Term inado, crdito com pleto

Figura 4.8 Matriz de porcentajes completa para el proyecto de diseo AMTM100

Considrese la figura 4.8, en la que se muestra una matriz de porcentajes completa modificada para el proyecto de diseo AMTM100. La matriz de porcentajes completa muestra la duracin planificada o presupuestada para cada tarea, el porcentaje del proyecto total que la tarea representa, y su estado. En los casos en que una tarea ha sido iniciada o terminada, el crdito se otorga al proyecto total. En casos en los que no hay avances, no se otorga ningn crdito. Se imponen tres observaciones. En primer lugar, el director del proyecto o el lder del equipo podra otorgar un porcentaje ms exacto de terminacin que el 0, 33 y 100% utilizados en este ejemplo (y siguiendo una regla simple), y podra hacerlo as para tareas seleccionadas. Recurdese que el equipo es el que elige los valores en la regla simple y estndar. En segundo lugar, el equipo puede comparar el avance alcanzado hasta este momento con el tiempo total asignado al proyecto. Si, por ejemplo, el proyecto de diseo fuera en la octava semana de un total de doce, la matriz de porcentajes completa parecera indicar que el proyecto est ms o menos dentro de lo planeado. Si el equipo estuviera en la dcima semana, esta matriz provocara alarma. En tercer lugar, se observa que si el equipo ha realizado un buen trabajo para determinar la naturaleza y duracin de las tareas requeridas para completar el proyecto, esta matriz y este mtodo le permitirn monitorear su trabajo. Si no lo ha hecho, este mtodo es simplemente una ilusin. En la figura 4.8 Se presenta cada actividad y su proporcin del proyecto total; al equipo se le otorga un 33% de crdito cuando se inicia una actividad y el resto al completarla. A menos que las tareas hayan sido divididas suficientemente, este mtodo puede conducir a errores, aunque en el caso de proyectos pequeos proporciona una aproximacin razonable del avance del proyecto.