evaluador gestión de proyectos

8/10/2019 Evaluador Gestin de Proyectos

1/173

Gestin de Proyectos Segn Metodologa Lean.

Simulador Conductual SimuLean.

Estudiante: Jose Antonio Rubio TorDirector: Jaume Mussons Sells


2/173

2


3/173

3

1.- INTRODUCCIN 5

2.- METODOLOGA LEAN APLICADA A LA GESTIN DE PROYECTOS 9

2.1-ANTECEDENTES ............................................................................................................... 92.1.1-ORIGENDELEAN ............................................................................................................ 92.1.2-PRINCIPIOSBSICOSLEAN ....................................................................................... 112.1.2.1- Valor .............................................................................................................................. 122.1.2.2- Flujo de valor ................................................................................................................. 122.1.2.3- Flujo ............................................................................................................................... 122.1.2.4- Pull ................................................................................................................................. 132.1.2.5- Perfeccin ...................................................................................................................... 142.1.3-ORIGENYPRINCIPIOSBSICOSDECCPM .............................................................. 152.1.3.1- Planificacin .................................................................................................................. 15

2.1.3.2- Ejecucin ....................................................................................................................... 16

2.1.3.3- Monitorizacin ............................................................................................................... 162.2-LEANAPLICADOALAGESTINDEPROYECTOS ............................................... 172.2.1-PROJECT SYSTEM............................................................................................................... 172.2.2-LIDERAZGO DE PERSONAS................................................................................................. 212.2.3-CARTA DEL PROYECTO. ..................................................................................................... 272.2.4-SOLUCIN CORRECTA........................................................................................................ 312.2.5-GESTIN DE LA VARIACIN............................................................................................... 412.2.6-GESTIN DE RIESGOS DEL PROYECTO................................................................................ 452.2.7-PLAN DE PROYECTO........................................................................................................... 492.2.8-EJECUCIN DEL PROYECTO............................................................................................... 59

3.- DESARROLLO DEL SIMULADOR 63

3.1-DISEODELASPREGUNTAS ...................................................................................... 633.1.1-METODOLOGA APLICADA................................................................................................ 633.1.2-FASES DEL INBOX.............................................................................................................. 643.1.3-PLANTEAMIENTO DE LAS SITUACIONES............................................................................ 643.1.4-PLANTEAMIENTO DE LAS RESPUESTAS............................................................................. 643.2ELECCINDELLENGUAJEDEPROGRAMACIN .............................................. 673.2.1-ENTORNO DE PROGRAMACIN VISUAL BASIC 6.0 ............................................................. 673.2.2-BASES DE DATOS SQL........................................................................................................ 693.2.3-ENTORNO DE DISEO MACROMEDIA FLASH MX................................................................ 713.3DESARROLLODELSIMULADOR .............................................................................. 73

3.3.1-ENTORNO USUARIO........................................................................................................... 733.3.2-ENTORNO ADMINISTRADOR.............................................................................................. 753.3.3-ESTRUCTURA DE LA BASE DE DATOS................................................................................ 773.3.4-FUNCIONES SIMULEAN...................................................................................................... 81

4.- CONCLUSIONES 91

5.- LINEAS FUTURAS 93

6.- BIBLIOGRAFA Y REFERENCIAS. 95


4/173

4

ANEXO I - TRIZ (FUENTE WWW.TRIZ40.COM) 97

ANEXO II MANUAL DE USUARIO - SIMULEAN 117

1.1MANUALDEUSUARIO ............................................................................................... 1191.1.1-REQUISITOS MNIMOS DE INSTALACIN.......................................................................... 119

1.1.2MANUAL EXPLICATIVO.................................................................................................. 120

ANEXO III MANUAL DE USUARIO CC-PULSE 123

1.1-FUNCIONALIDADS CC-PULSETM:ACCESO Y DESCRIPCIN.................................................. 1251.2-VISTAS,FILTROS E INFORMES. ........................................................................................... 1491.3-FUNCIONALIDADES AVANZADAS Y TEMAS DE INTERS.................................................... 1591.4-INSTALACIN,REGISTRO Y OTRAS FUNCIONALIDADES RELACIONADAS. .......................... 163


5/173

5

1.- INTRODUCCIN

El objetivo de este Proyecto Final de Carrera es el desarrollo de un software de simulacinconductual, para la evaluacin del nivel de conocimientos de los usuarios sobre la gestin de

proyectos segn la metodologa Lean. Esta clase de simuladores, frecuentemente utilizados pornumerosas entidades educativas, as como por empresas para la formacin de alumnos oempleados, pertenecen a las herramientas de formacin basadas en el uso de ordenadores(Computer-Based Training) y son empleados en metodologas de enseanza Blended Learning(b-learning). Las metodologas de enseanza B-learning se caracterizan por la combinacin declases presenciales con el uso de materiales tecnolgicos para completar la formacin mediantesesiones no presenciales (e-learning).

El propsito de este proyecto ha sido crear un simulador de propsito formativo, llamadoSimuLean, que requerir de la presencia de un administrador, habitualmente el profesor de lamateria, para la evaluacin de los resultados de los usuarios y para la resolucin de las dudasque puedan surgir a los usuarios durante la resolucin de las cuestiones planteadas por el

simulador.A continuacin se enumeran las propiedades del software SimuLean:

Software diseado para que los usuarios puedan aplicar los conocimientos adquiridossobre la gestin de proyectos segn metodologa Lean en la resolucin de imprevistosde diferentes tipologas (tiempo, recursos, economa, diseo, etc.) que pueden ocurrirdurante la ejecucin de un proyecto.

El simulador plantea a los usuarios diferentes situaciones e imprevistos, habituales en eltranscurso de proyectos reales, en las cuales debern elegir la solucin ms adecuadaentre las cuatro propuestas, con el fin de gestionar correctamente dichos proyectos.

SimuLean evala a los usuarios desde diferentes perspectivas puesto que la respuestadada a cada situacin se analiza desde 4 puntos de vista diferentes:

Satisfaccin Personal.

Satisfaccin Cliente.

Calidad.

Rentabilidad.

Los usuarios pueden consultar en todo momento la evaluacin de las decisiones que han

tomado ante las situaciones planteadas en la gestin de los proyectos. A tal efecto, sehan dispuesto unos grficos que muestran las puntuaciones obtenidas segn cada uno delos puntos de vista enumerados anteriormente. Adicionalmente, se ha creado unhistrico que muestra las situaciones planteadas y las decisiones tomadas por losusuarios.

Los usuarios recibirn un comentario de la junta directiva despus de cada decisinadoptada, lo que les permitir conocer el grado de idoneidad de la solucin adoptada.

Los usuarios pueden ejecutar el programa desde cualquier PC que lo tenga instalado sinnecesidad de estar en un aula con el profesor, esto posibilita un alto grado deflexibilidad e independencia.


6/173

6

Adems de tomar decisiones ante situaciones surgidas en la gestin de proyectos, losusuarios de la aplicacin debern poner en prctica sus conocimientos tericos, sobre lagestin de proyectos segn metodologa Lean, para la resolucin de unos ejercicios, decarcter eminentemente terico, que se propondrn a lo largo de la simulacin.

Se ha implementado una funcin de importacin de los datos de los diferentes usuariospara facilitar la evaluacin, por parte del profesor, de las decisiones adoptadas por

dichos usuarios. Esta funcin facilita al profesor las respuestas proporcionadas as comola puntuacin obtenida por cada uno de los usuarios en cada uno de los cuatro aspectosevaluados.

Se ha dotado a la aplicacin SimuLean de medidas de seguridad elementales. As, todoslos archivos se han codificado de forma que los usuarios slo podrn visualizarlosdurante la simulacin. Tambin se han cifrado los ficheros que se envan al profesor

para la evaluacin de los usuarios con el fin de que estos no puedan ser manipulados.Finalmente, la base de datos con las situaciones planteadas, las posibles respuestas, las

puntuaciones y los comentarios se ha protegido mediante contrasea de forma que slo

el profesor pueda acceder a los datos que se almacenan en ella.

Los simuladores educativos son una importante herramienta pedaggica que permiten acelerar eincrementar la calidad del procesos de aprendizaje de los alumnos a travs de la puesta en

prctica de los conocimientos tericos adquiridos en clase mediante el planteamiento desituaciones reales frente a las que adoptar soluciones.

En los simuladores educativos se pone a los alumnos en la necesidad de opinar, de implicarse,de tomar sus propias decisiones, situndolos en un contexto que imita algn aspecto de larealidad, y estableciendo en ese mbito situaciones similares a las que se debern enfrentar en suvida profesional, de forma que puedan experimentar sin riesgo y obtener conclusiones. Para

ello, se les proporciona detalles de la situacin y se les propone alternativas de actuacin,proporcionndoles, a continuacin, un feedback sobre los resultados de las acciones adoptadas.

El uso de simuladores informticos en la formacin en direccin de proyectos no tiene comoobjetivo que los participantes identifiquen las reglas implementadas en el simulador, sino que loque se busca es que stos construyan su propio modelo mental para entender la lgica de los

proyectos.

El empleo de simuladores en la enseanza presenta las siguientes ventajas y limitaciones:

Permiten a los asistentes:

Aprender y demostrar lo aprendido.

Afrontar un proceso de toma de decisiones similar al que debern enfrentarsedurante su ejercicio profesional.

Autoevaluarse.

Acortar los periodos necesarios para el aprendizaje.

Permiten al profesorado:

Que los asistentes apliquen criterios normalizados.

Idear ejercicios didcticos y de evaluacin estrechamente ligados a lassituaciones a las que los profesionales se enfrentan en la realidad.


7/173

7

Determinar con exactitud las tareas concretas que los asistentes deben demostrarque saben realizar y establecer los criterios evaluativos.

Concentrar el inters en los puntos claves para el xito profesional en la materiatratada.

Limitaciones:

La simulacin imita, pero no reproduce exactamente la realidad. Hay aspectosde la realidad, principalmente los relativos a las relaciones humanas, que no

pueden ser simulados y, esto se debe tener presente siempre que se empleecualquier tipo de simulacin.

Se debe ser muy cauto a la hora de predecir cul ser el comportamiento de unapersona ante una situacin real, basndose en las respuestas proporcionadasante una situacin simulada.

No se debe restringir el desarrollo de las habilidades ni la evaluacin del

rendimiento de los alumnos nicamente al empleo de simuladores. Se debe, portanto, combinar el empleo de diferentes mtodos y recursos.


8/173

8


9/173


10/173

10

Transporte, Esperas, Inventarios, Movimiento, Procesos innecesarios. El sistema TPS esun claro ejemplo de proceso de mejora continua (Kaizen).

Just In Time. Sistema de produccin bajo demanda que reduce considerablemente loscostes de gestin, sobreproduccin y de stocks inmovilizados. Tambin se caracteriza

por implantar el TPM (Total Productive Maintenance), que consiste en mantener todas

las instalaciones en perfecto estado, de forma que no se penalice la produccin. Lagestin de stocks se realiza mediante tarjetas Kanban, que permiten controlar el flujo detrabajo de una fbrica actuando slo cuando el cliente lo demanda (sistema pull). Losobjetivos principales del JiT son los siguientes:

Minimizar tiempos de entrega.

Minimizar el stock.

Tolerancia cero a errores.

Reduccin al mximo de las paradas tcnicas.

6-SIGMA. Metodologa de gestin de la calidad, basada en el control de procesos, cuyoobjetivo es lograr disminuir el nmero de defectos en la entrega de un producto oservicio al cliente. La aplicacin de una metodologa Six Sigma lleva asociado unnotable incremento de la rentabilidad y la productividad.

Poka-Yoke. Se denomina Poka-Yoke a cualquier dispositivo orientado a evitar loserrores de las personas que los manipulan. Estos dispositivos fueron introducidos enToyota en la dcada de los 60. Los objetivos del Poka-Yoke son los siguientes:

Imposibilitar el error humano (sistema de deteccin).

Resaltar el error cometido de tal manera que sea obvio para el que lo ha cometido

(sistema de alarma) TOC (Theory of Constraints). La teora de las limitaciones fue creada por Eliyahu M.

Goldratt. Esta teora establece que todo sistema de produccin puede presentar dos tiposde limitaciones:

Limitaciones fsicas. Son equipos o instalaciones, recursos humanos, etc., queimpiden que el sistema cumpla con su meta de negocio. Se pueden explotarmediante el aumento de la capacidad del recurso o aprovechando al mximo dichacapacidad.

Limitaciones polticas. Son aquellas relativas a las normas que evitan que laempresa alcance su meta. La nica forma de explotarlas es cambiando las normas.

Kaizen (mejora continua). Es un sistema enfocado a la mejora continua, de maneraproactiva, de toda la empresa. Es un sistema que permite vislumbrar resultados en uncorto perodo de tiempo si se establece una buena estrategia y plan de implementacin,y se forma adecuadamente al personal.

Naturalmente el concepto de Kaizen nos lleva al sistema de produccin Toyota yconsecuentemente a Lean.


11/173

11

2.1.2 - PRINCIPIOS BSICOS LEAN

La metodologa Lean centra sus esfuerzos en dos elementos clave:

Eliminar los despilfarros Maximizar la flexibilidad

Se define Despilfarro (muda) como toda actividad o consumo de recursos que no aada valor alproducto. Por ello la gestin Lean trata de llevar a cabo cualquier proceso empleandonicamente los recursos imprescindibles. Se han establecido 7 tipos de despilfarros y son lossiguientes:

Defectos en los productos, referidos a los fallos de calidad que trascienden del puestodonde se han producido.

Sobreproduccin. Un claro ejemplo sera el mtodo de produccin basado eneconomas de coste sin tener en cuenta la demanda.

Existencias. Acumulacin de material que no est siendo objeto de ninguna actividad,esto es, cualquier tipo de stock.

Sobreprocesamiento o procesamiento innecesario. Consiste en el empleo deprocedimientos inadecuados para la elaboracin de los productos.

Movimientos de personal no necesarios. Por ejemplo, debidos a una mala asignacin detareas.

Transporte de producto innecesario. Por ejemplo, por una distribucin inadecuada de laplanta.

Esperas de materiales o puestos de trabajo por cualquier motivo. Incluyendo porsupuesto las de los empleados debidas a que el equipo de procesamiento ha de terminarsu tarea o a que se debe finalizar una actividad precedente.

El otro gran elemento clave del planteamiento propuesto para alcanzar un nivel muy elevado decompetitividad es la flexibilidad. Dado que la metodologa Lean se basa en el principio de quela oferta se debe ajustar a la demanda es necesario que todos los elementos que integran elsistema estn dotados de una gran flexibilidad que les permita cambiar rpidamente de tarea sinincurrir en perdidas innecesarias de tiempo (despilfarros). As pues, frente a metodologastradicionales de economas de escala que apuestan por la especializacin con el objetivo deobtener la mayor produccin posible, en la metodologa Lean es necesaria la versatilidad, puesto

que es el mercado el que tira (pull) de la produccin, esto es, la produccin se debe ajustarsiempre a lo que solicita el mercado.

Segn estableci Womack hay 5 aspectos claves en la metodologa Lean:

Especificar con precisin el concepto de valor.

Identificar el flujo de valor para cada producto.

Hacer que el valor fluya sin interrupciones, siempre que alguien lo solicite.

Dejar que el consumidor atraiga hacia s (pull) el valor precedente del fabricante.

Perseguir la perfeccin.


12/173

12

2.1.2.1- Valor

Hay que definir el valor desde la perspectiva del cliente. Una tarea crtica de cualquier actividadconsiste en ponerse del lado del cliente para evaluar si una actividad crea valor. El cliente estardispuesto a pagar nicamente por las cosas que cree que tienen valor. Se considera pues Valor

cualquier cosa por la que un cliente estar dispuesto a pagar. Por lo tanto, cualquier actividadque no incremente el precio que pagara el cliente slo agrega costes al proyecto.

El valor slo es significativo cuando se expresa en trminos de un producto o servicioespecfico que satisface las necesidades del consumidor, a un precio concreto, en un momentodeterminado. Para conseguir esto, es imprescindible replantear el concepto de valor en lasempresas, pues a menudo ocurre que las necesidades inmediatas de los accionistas de unaempresa y la mentalidad econmico-financiera de los directivos se ponen por encima de lasrealidades cotidianas consistentes en especificar y crear valor para el consumidor o cliente.

Una vez definido el producto, hay que determinar un coste objetivo, basado en la cantidad derecursos y esfuerzos necesarios para fabricar un producto con ms capacidades yespecificaciones determinadas si todos los despilfarros visibles se eliminaran del proceso.

2.1.2.2- Flujo de valor

El flujo de valor se compone de todas las tareas necesarias que deben ser completadas paraentregar el producto o servicio final al cliente. Muchas de las tareas que emprendemos noagregan ningn valor adicional por el que el cliente estara dispuesto a pagar. Creando unmapa de la corriente de valor, podemos separar fcilmente las tareas que agregan valor deaquellas que no agregan valor. Hay 3 corrientes clsicas del valor:

Del concepto del diseo a la produccin.

De la iniciacin a la realizacin de una orden.

Del envo al pago de la factura.

Las tareas que no agregan valor al cliente se consideran despilfarros (despilfarros tipo 2 oMuda) y podran eliminarse de la corriente del valor. Por su parte, algunas tareas sondespilfarros pero necesarias para poder completar el proyecto en tiempo y forma (despilfarrostipo 1). El objetivo ltimo del pensamiento Lean ser quitar tanto despilfarro (muda) del flujo devalor como sea posible. Tenemos pues dos tipos de despilfarro:

Despilfarro tipo 1. Actividad parcialmente sin valor aadido, pero necesaria paracompletar las tareas. Slo agrega coste al proyecto.

Despilfarro tipo 2. Actividad que carece de valor aadido. Muda a eliminar.

2.1.2.3- Flujo

El proceso tradicional en la fabricacin de bienes se ha constituido en un entorno con colas yesperas. Dentro de un ambiente Lean debemos tomar un camino diferente. Hay que enfocarseen el cliente y crear una corriente de valor, diseada especficamente para satisfacer susnecesidades. Se debe eliminar muda del flujo de valor y reducir el plazo de espera para laentrega del producto o servicio. Esto significa que debemos reducir los tiempos de demora en elflujo de valor al quitar obstculos innecesarios en el proceso. Debemos reparar el flujo original

y lograr un movimiento continuo del producto a travs de la corriente de valor. Al realizar estoal inicio del proyecto, nos permitir:


13/173

13

Liberar espacios.

Descubrir que tenemos demasiado stock en el proceso industrial.

Cambiar un proceso ineficiente.

Entender que los empleados pueden no ser multifuncionales.

Algunos del los obstculos tpicos a remover del flujo de valor son:

Rigidez de los departamentos funcionales.

Ciclos de aprobacin recurrentes.

Cambios constantes en los requerimientos del proyecto.

Interferencia innecesaria de la gerencia general.

La clave es concentrarse en el producto y sus necesidades, y no en la organizacin o la

maquinaria, para que todas las actividades que aportan valor sigan un flujo continuo. Pero,cmo conseguir que el valor fluya? Para conseguirlo, inicialmente hay que concentrarse en elproducto real para, posteriormente, concentrarse en los lmites y fronteras tradicionales paraimplantar una metodologa Lean, que elimine los impedimentos a dicho flujo. Finalmente, habrque implantar las prcticas y herramientas especficas, que eliminan flujos hacia atrs,despilfarros e interrupciones de todo tipo. Estos tres puntos pueden llevarse a la prcticasimultneamente.

Uno de los aspectos fundamentales para alcanzar un flujo continuo de valor consiste en que todoel mundo debe poder observar todas las actividades que suceden a lo largo de un flujo de valor(que habitualmente fluye a travs de muchos departamentos, funciones y empresas). Paraconseguir este propsito son muy tiles las herramientas de control visual, de tipo Andon. De

este modo, resulta ms adecuado el uso de mquinas ms sencillas, menos automatizadas y mslentas, aunque ms precisas y, por tanto, menos costosas.

Otro aspecto fundamental ser el mantenimiento ordenado de los lugares de trabajo tal y comoestablece TPM.

2.1.2.4- Pull

Aplicar el sistemaPullen una empresa consiste en adquirir la capacidad de disear, programar yhacer exactamente lo que el consumidor desea precisamente, y en el momento que lo desea, a uncoste razonable. De esta manera slo se fabrica lo que el cliente dice que necesita en cadamomento. Este sistema es totalmente antagnico a otros que pretenden aumentar el nivel deventas de un producto especfico en un momento determinado, como son las promocionesespeciales.

Los equipos de proyectos deberan permitir a sus clientes que se involucren en el proceso delproyecto con el fin de poder extraer valor de ellos.

Por ejemplo, entregar tecnologa por s misma no agrega valor al Cliente. Slo cuando losnuevos mtodos o ideas resuelven un problema bien definido por el cliente es cuando tienenvalor. Al trabajar en el flujo de valor, nos enfocamos en eliminar muda. De forma similar, slodebemos construir lo que nuestro cliente necesita, cuando nuestro cliente lo necesita. De esta

manera debemos permitir que nuestro cliente sea nuestro regulador de agendas y el que nos digalo que debemos estar haciendo da a da.


14/173

14

2.1.2.5- Perfeccin

Un proyecto lean requiere vigilancia constante para mantener y mejorar su desempeo. Exige

disciplina de equipo y una intolerancia total hacia el desperdicio de recursos. Es necesaria labsqueda permanente de la perfeccin con el fin de evitar la Ley de la entropa segn la cuallas cosas de nuestro mundo siempre tienden a ser cada vez ms aleatorias y caticas a lo largodel tiempo.

Hay muchos obstculos a vencer para lograr un ambiente lean. Ms de una vez se han creadomquinas que pueden hacer un producto eficiente a velocidades increbles. Sin embargo, tarde otemprano el producto se asienta en una lnea hasta la prxima etapa de Procesado, y el proyectovuelve al ambiente de parar-iniciar-parar-iniciar. Necesitamos vencer este y muchos otrosobstculos para eliminar permanentemente todo el despilfarro de la corriente de valor.

Esto ser imposible de conseguirlo con un slo proyecto ya que el ciclo continua y con nuestro

esquema lean cada vez podemos ser ms eficientes.


15/173

15

2.1.3- ORIGEN Y PRINCIPIOS BSICOS DE CCPM

Desarrollada por Eliyahu M. Goldratt, la gestin de proyectos segn la cadena crtica (CCPM)est basada en mtodos y algoritmos derivados de la Teora de las Limitaciones (TOC). La idea

original de CCPM fue inicialmente publicada en 1997 en el libro Critical Chain.

La gestin de proyectos segn la cadena crtica es un mtodo de gestin y planificacin deproyectos elaborado por Eliyahu M. Goldratt que pone especial nfasis en los recursosnecesarios para realizar las tareas. Esta teora contraviene mtodos ms tradicionales comoPERT y el mtodo del camino crtico que enfatizan el orden de las tareas y una planificacinrgida. Un proyecto gestionado segn CCPM tender a mantener una asignacin nivelada de losrecursos pero precisar de gran flexibilidad por parte de stos a la hora de comenzar las tareas ya la hora de cambiar entre tareas con el fin de mantener el proyecto completo dentro delcalendario previsto. Los principales elementos diferenciadores de la cadena crtica respecto delcamino crtico son los siguientes:

El uso de dependencias de recursos generalmente implcitas. Implcitas se refierea que no estn incluidas en la red del proyecto pero tienen que ser identificadasmediante la bsqueda de los recursos requeridos.

La falta de bsqueda de la solucin ptima. Esto significa que una solucin"suficientemente buena" es suficiente porque:

Hasta donde se sabe, no existe mtodo analtico alguno que permitahallar un ptimo absoluto.

La incertidumbre inherente a los estimados es mucho ms grande que ladiferencia entre una solucin ptima y una suficientemente buena.

La identificacin e insercin de buffers de tiempo: Buffer de proyecto.

Buffers de alimentacin.

Buffers de recursos.

Monitorizacin del estado del proyecto mediante el anlisis del ratio deutilizacin de los buffers, en lugar de a travs de la revisin del estado de lasdiferentes tareas.

La metodologa CCPM distingue 3 fases claramente diferenciadas: planificacin, ejecucin ymonitorizacin

2.1.3.1- Planificacin

Se crea la planificacin del proyecto de manera similar a como se hara segn la metodologadel camino crtico. Se determinan dos duraciones para cada tarea: una estimacin optimista deduracin, es decir, aquella que se puede conseguir con un 50% de probabilidad, y otraestimacin ms realista, llamada de seguridad, de duracin que se puede conseguir con un 90%o 95% de probabilidad.

A continuacin se asignan los recursos a las tareas utilizando la estimacin optimista. La

secuencia ms larga de tareas desde el principio del proyecto hasta el final del mismo seidentifica como la cadena crtica.


16/173

16

Asumiendo que las tareas tienden a alargarse debido a la ley de Parkinson o al Sndrome delestudiante, se disean buffers que fijan fechas para la liberacin de entregables y que posibilitanun seguimiento de la planificacin en tiempo y coste del proyecto. La diferencia de tiempo entrela estimacin realista y la optimista, formar el conocido como buffer de proyecto y estar

situado al final de la cadena crtica. Adems, se implementarn buffers al final de todos losprocesos que alimentan a la cadena crtica.

2.1.3.2- Ejecucin

Cuando la planificacin del proyecto est completada y el proyecto est listo para comenzar, lostamaos de los buffers quedan bloqueados y no podrn ser modificados durante el proyecto entanto que sern utilizados para el seguimiento de la planificacin.

Sin mrgenes en la duracin de las tareas individuales, los recursos en la cadena crtica son

empleados asegurndose que trabajan en la tarea asignada de la cadena crtica y slo en ella. Seelimina la multitarea. Debido a que el tiempo asignado es la duracin optimista, existe unacierta presin sobre los recursos para completar sus tareas tan pronto como sea posible, evitandode este modo la aparicin del sndrome del estudiante y la ley de Parkinson.

2.1.3.3- Monitorizacin

La monitorizacin es, en cierto modo, la principal ventaja de CCPM. Dado que las tareas se hanasignado segn la estimacin de duracin optimista, no se puede forzar a que todas las tareas secompleten a tiempo. En lugar de ello se monitorizan los buffers mediante el empleo de Fever

Charts (Grficos de Fiebre) que permiten ver rpidamente el nivel de consumo de tiempo de losbuffers. Si el nivel de consumo del buffer es bajo, el proyecto est cumpliendo los plazos. Si elconsumo de tiempo es tal que puede ser que al final del proyecto no va a sobrar buffer o va asobrar muy poco, se debern desarrollar planes o acciones correctivas que permitan recuperar

parte del tiempo perdido. Cuando el consumo de buffer alcanza un valor crtico es el momentode implementar los planes alternativos que se desarrollaron cuando no se haba alcanzado anese nivel de criticidad.


17/173

17

2.2- LEAN APLICADO A LA GESTIN DE PROYECTOS

La metodologa Lean aplicada a la gestin de proyectos, en adelante LPM, es postulada porLawrence P. Leach en su libro Lean Project Management: Eight Principles for Success

publicado en 2005. En esta publicacin, Leach combina elementos de la gestin de proyectossegn la cadena crtica con elementos propios de Lean para acelerar el conjunto de proyectocentrando los esfuerzos en la eliminacin de los despilfarros (muda). Todo ello lo hace dandolas claves para la gestin y desarrollo de los siguientes puntos:

Project System.

Liderazgo de personas.

Carta del proyecto.

Solucin correcta.

Gestin de desviaciones.

Gestin de riesgos del proyecto. Plan del proyecto.

Ejecucin.

2.2.1- PROJECT SYSTEM

LPM surge para explotar el conocimiento de la totalidad del sistema de ejecucin de proyectos,no centrndose exclusivamente en la planificacin como hace CCPM. As, en lo que a laorganizacin empresarial se refiere, se recomienda que la presencia de una oficina de gestin de

proyectos (PMO) llegue mucho ms all y que la organizacin entera asuma la metodologa degestin de proyectos y la aplique en el da a da.

La metodologa PMBOK afirma: El equipo de gestin es responsable de determinar que esadecuado para cada proyecto, porque cada proyecto es nico por definicin: Un proyecto esun esfuerzo temporal para crear un nico resultado, producto o servicio. Sin embargo, segn lametodologa Lean, Un proyecto es un elemento con propsitos de negocio, con un clientedetrs de las personas que efectan el trabajo, que normalmente involucra a un equipo de

personas y que se prolonga en el tiempo ms all de una semana. En definitiva, Un proyectoes algo que requiere de cierto grado de planificacin para poder realizarse con xito.

Para realizar satisfactoriamente los proyectos, el Instituto de Gestin de Proyectos (PMI)

establece procesos y reas de conocimiento. Los procesos son agrupados de acuerdo con el flujogeneral de un proyecto (Inicio, planificacin, ejecucin, cierre y control y monitorizacin),quedando cada grupo definido en trminos de inputs y outputs. Cada proceso tiene proveedoresde inputs y genera outputs que van hacia los clientes (SIPOC). Las reas de conocimientodefinidas por PMI son integracin, alcance, tiempo, coste, calidad, recursos humanos,comunicaciones, riesgo y adquisiciones.

La metodologa LPM aboga por simplificar el liderazgo del proyecto para satisfacer a las partesinteresadas en el menor tiempo posible, mientras se minimizan los desperdicios y el nivel destress en los participantes en el proyecto.

La teora de las limitaciones (TOC) afirma que cualquier restriccin limita el output de unsistema. Los principios TOC proponen centrarse en la meta, trabajando para maximizar elrendimiento en los sistemas de negocio. Desplegando para ello 5 pasos el rimero de los cuales


18/173

18

es identificar la restriccin. Siguiendo estos principios, y asumiendo que los proyectos secomponen de tareas independientes con tiempos de duracin independientes, LPM postula tresafirmaciones sobre la gestin de proyectos:

No hay que finalizar cada tarea a tiempo para que el proyecto finalice a tiempo.

Empezar un proyecto antes no significa que vaya a finalizar antes. Aadir buffers reduce la duracin del proyecto y los costes.

Un principio que subyace LPM es cualquier proyecto que merece la pena hacerlo, merece lapena hacerlo rpido; esto es debido a que la mayora de los proyectos no comienzan el retornode la inversin (ROI) hasta que se han finalizado por completo.

Los principios de produccin lean son 5: Valor, flujo de valor, flujo de actividades, pull a lasactividades y perfeccin. A continuacin trataremos de asociar estos 5 principios a la gestin de

proyectos:

El valor coincidir con el foque TOC en la meta y con el enfoque six sigma en el

cliente. Identificar el flujo de valor en los proyectos coincide con el sistema de ejecucin de

proyectos.

Centrarse en el flujo sintoniza con la aproximacin de mltiples proyectos deTOC/CCPM que busca maximizar el flujo de proyectos a travs de la restriccin.

Para proyectos individuales la cadena crtica y la administracin de buffersimplementan PULL. Mientras que para sistemas con mltiples proyectos son la

planificacin del recurso tambor y el buffer de limitacin de capacidad los que loimplementan.

La metodologa LPM desarrolla una cadena crtica como objetivo principal del proyecto ytrabaja para eliminar los desperdicios de tipo sobreproduccin (elementos que no aportan valoral cliente), inventarios en espera de ser procesados y recursos humanos esperando tareas en lasque trabajar. La cadena crtica incluye la dependencia lgica (secuencia de tareas tcnicas) y ladependencia de recursos (quien va a realizar el trabajo). LPM establece la cadena crticadespus de quitar las contenciones de recursos (resource contentions) en lugar de antes de laconsideracin de dichas limitaciones. La cadena crtica debe permanecer invariable durante latotalidad del tiempo que dure el proyecto y este debe ser el objetivo principal del Director delProyecto.

La cadena crtica se identifica como el camino ms largo a travs de la red del proyecto despusdel nivelado de recursos. La cadena crtica no tiene falta de actividad una vez identificada y

suele ser diferente del camino crtico.

A la hora de planificar las tareas, y en tanto que la duracin de las mismas es variable de unproyecto a otro, es mejor estimarlas en su tiempo promedio que en su mximo tiempo. Eltiempo restante se puede colocar en un buffer al final de la cadena de de tareas. Requiere menostiempo colocar el tiempo en un buffer al final del proceso que proteger cada tarea porqueexcesos de tiempo en algunas tareas se compensarn con otras acabadas antes de plazo.

Hay situaciones en las que una tarea requiere de la finalizacin de varias predecesoras parapoder comenzar, es lo que se conoce como fusin o Merging. Los problemas en lasincronizacin de esta fusin son habituales y suelen provocar retrasos. LPM soluciona estos

problemas mediante el uso de buffers de alimentacin (Feeding Buffers). Estos buffers seintroducirn en aquellos puntos donde alguna cadena de actividades alimenta la cadena crtica,


19/173

19

ayudando de este modo a inmunizar la cadena crtica frente al retraso en los caminos dealimentacin de este proceso.

La planificacin de proyectos requiere determinar el momento en que han de comenzar lascadenas no crticas de tareas. Pueden empezar tan pronto como sea posible (early start) que es

lo habitual, o tan tarde como sea posible (late start) sin retrasar la cadena crtica. La ventajade early start es que ayuda a evitar problemas de sincronizacin, pero su desventaja es querequiere mltiples caminos a comenzar al principio del proyecto, cuando el equipo est todavaformndose, ocasionando a la vez que el flujo de caja del proyecto sea mayor del necesario alcomienzo del proyecto. El empleo de buffers de alimentacin permite comenzar las actividadestan tarde como sea posible a la vez que se protege el proyecto en su totalidad porque dichos

buffers aaden suficiente tiempo para asegurar que las cadenas que alimentan estarncompletadas cuando sea necesario, con una alta probabilidad. El inicio planificado de lascadenas de alimentacin ser posterior que el determinado segn early-start lo que dota al

proyecto de las ventajas de empezar ms tarde, entre ellas, un mejor flujo de caja (cash flow).

El uso de la administracin de los buffers durante la ejecucin del proyecto sirve para resolver

dos cuestiones de capital importancia: Qu tarea es la prxima que se debe trabajar?

Cundo tengo que tomar medidas para acelerar el proyecto?

Realizar el seguimiento de proyectos LPM conlleva identificar cuando las tareas comienzan ycuando finalizan; as como la obtencin de estimaciones de la duracin restante de las tareas en

proceso. Es mejor utilizar una estimacin del tiempo restante que una estimacin del grado deavance porque la gente tiende a sobreestimar el grado de avance actual del proceso. Adems, eltiempo restante es precisamente el nmero necesario para estimar el tiempo de finalizacin del

proyecto. El seguimiento de proyectos en LPM usa la estimacin de tiempo restante de tareas

incompletas para calcular el impacto del estado de la tarea, incluyendo la absorcin de ladesviacin por los buffers de alimentacin, para determinar el nivel de buffer consumido. Losgestores de las tareas debern priorizar aquellas tareas que realizan un mayor uso de los buffersasignando los recursos necesarios que permitan que se complete en el menor tiempo posible.

En la metodologa LPM no existen Due Dates intermedias. Esto ayuda a prevenir la ley deParkinson, segn la cual todas las tareas tienden a extenderse durante todo el tiempo que se lesha asignado, y el sndrome del estudiante, segn el cual las tareas no se empiezan hasta que ladue date est prxima.

En cuanto a la priorizacin de tareas, la prioridad de una tarea no tiene porque coincidirnecesariamente con la prioridad del proyecto, puesto que puede suceder que la prioridad de una

cadena no crtica sea mayor que la de la cadena crtica debido a que alguna tarea predecesora seha retrasado amenazando el buffer del proyecto no crtico.

Durante la ejecucin del proyecto se debe realizar un seguimiento continuo del nivel de cargadel buffer del proyecto. Si el nivel de carga del buffer est en su zona media se debendesarrollar planes para recuperar buffer. Si el nivel de carga llega a la zona alta se debenimplantar las medidas desarrolladas cuando estaba en zona media. Es lo que se conoce comoFever Chart.

La gestin LPM aplicada a mltiples proyectos identifica la restriccin como el recurso msusado entre todos los proyectos. El entramado ajusta el inicio de los diferentes proyectos deforma que los recursos se van asignando a las diferentes tareas entre todos los proyectos, a

medida que se van necesitando, para que el sistema completo de proyectos fluya segn el ritmode la capacidad del recurso restriccin, tambin denominado recurso tambor en tanto que es el


20/173

20

que marca el ritmo. El sistema de proyectos implementa de este modo una tcnica PULL debidoa que el recurso tambor es el que determina el secuenciado de las peticiones. Los retrasos eneste recurso pueden afectar a la totalidad del proyecto, por lo que se hace necesario el uso de

buffers para protegerlo. El recurso tambor es el recurso ms cargado de entre todos losproyectos, esto asegura que el nivelado de proyectos a partir del recurso ms cargado,

garantizar suficiente tiempo para el resto de recursos.El objetivo de LPM no es programar todos los recursos a lo largo de todos los proyectos porqueel calendario cambia cada da conforme cambian las tareas del proyecto. Es pues esencialdeterminar la tarea correcta en la que trabajar basndose en los resultados obtenidos hasta elmomento.

La metodologa LPM requiere que la direccin determine como entramar los proyectos en elProject Delivery System. Se deben organizar los proyectos de forma que se mantenga laduracin individual de los proyectos tan corta como sea posible. Todos los proyectos no son dela misma naturaleza, normalmente los proyectos realizados para clientes son ms importantesque los proyectos realizados internamente, y a veces requieren de los mismos recursos, lo cual

puede provocar conflictos. Una buena manera de solucionarlos es mediante el uso de una matrizde conflictos en la que los proyectos realizados para clientes tendrn prioridad sobre losefectuados internamente.

El objetivo de la gestin de mltiples proyectos simultneos es completar lo ms rpido posiblelos proyectos y resolver las preguntas Cundo va a estar acabado? y Cunto va a costar?Una buena forma de responder a la primera pregunta es mediante el empleo de Fever-chartssimilares a las utilizadas para conocer el estado de los buffers. Para resolver la segunda preguntase recomienda implementar un buffer de coste que permita realizar el seguimiento de costes. Elcoste total estimado ser la sume de los costes de las tareas individuales ms el buffer. El bufferde coste se debe calcular considerando la variacin de cada uno de los elementos de coste de los

proyectos. Una vez ms, una forma de controlar estos buffers es mediante el empleo de fever-

charts. Una herramienta de gestin de proyectos denominada earned value cost variancemuestra la cantidad de buffer de coste consumido. Usar este tipo de buffers es un claro ejemplode combinar mtodos tradicionales de gestin de proyectos con LPM.

Todo sistema de ejecucin de proyectos (PDS) debe contener al menos:

Carta del Proyecto (Project Charter), definiendo la visin y el propsito del proyecto,y dotando de autoridad al director del proyecto para planificarlo.

Plan del Proyecto, exponiendo la totalidad de entregables (empezando con un WorkBreakdown Structure), la asignacin de roles y responsabilidades, y los procedimientos

para completar el alcance del proyecto.

Procedimientos para introducir cambios en el proyecto. Seguimiento y Control.


21/173

21

2.2.2- LIDERAZGO DE PERSONAS

La gestin de proyectos se centra eminentemente en la gestin de personas. Es por ello que lafase de refrendo de las partes interesadas se debe afrontar al principio del proyecto para

comenzarlo en una buena direccin. El objetivo de esta fase es lograr que todos las partesinvolucradas (stakeholders) del proyecto trabajen juntos para conseguir el xito del mismo.

Una de las claves para satisfacer las necesidades del cliente es empezar satisfaciendo al equipoimplicado en el proyecto, incluyendo a todos los participantes y proveedores. Una buena idea

para conseguir un buen punto de partida es que todos los participantes firmen la carta delproyecto (Project Charter) y el plan del proyecto. Siempre se debe incluir entre losparticipantes del proyecto, entre otros, al cliente, al equipo de trabajo y al usuario final delresultado del proyecto.

Se debe analizar el grado de compromiso y de influencia de cada uno de los participantes con elfin de determinar la posicin que deben ocupar. Una buena forma es completar una matriz de

influencia con la posicin en la que estn los diferentes participantes y dibujar una flechasealando el punto donde necesitaras que estuviesen. Se deben focalizar los esfuerzos endesplazar aquellos que presentan flechas ms largas.

La asignacin de las tareas es un proceso continuo a lo largo de todo el proyecto. Para ello sedebe definir un buen procedimiento de comunicacin para identificar quin tiene que serinformado de qu cosas durante el proyecto.

Una reunin formal de refrendo debe abarcar las siguientes tareas:

Definir el objetivo del proyecto y el propsito de la reunin.

Afirmar la visin del proyecto.

Clarificar los beneficios del proyecto e identificar los responsables para asegurar elxito.

Revisar el plan del proyecto.

Concluir la reunin con un compromiso verbal de los participantes de que apoyan elproyecto.

Realizar un acta de la reunin indicando asistentes y afirmando su compromiso con elproyecto.

Entre las tareas asociadas al liderazgo de proyectos se pueden destacar las siguientes:

Identificar los participantes en el proyecto.

Entender las necesidades de todas las partes implicadas en trminos de resultado delproyecto (producto) y procedimientos del proyecto (por ejemplo comunicacin).

Crear un plan de proyecto que satisfaga las necesidades de todos los participantes delmismo y que incluya metas, objetivos y asignaciones de responsabilidad.

Ejecutar el proceso para alcanzar las metas y objetivos.

Cerrar el proyecto una vez completado.

Un elemento clave en el liderazgo es la gestin de equipos. Todos los equipos pasan por las

fases de formacin, agitacin, normalizacin y realizacin. Lograr que un equipo supere la fasede agitacin, durante la que aparecen fricciones y maniobras para situar la posicin que cadauno tendr en el equipo y que suele provocar respuestas emocionales, requiere trabajar


22/173

22

individualmente con cada uno de los miembros del equipo. Una buena forma de hacerlo esmediante el modelo de liderazgo de Hersey, Blanchard y Jhonson que incluye los estilos deliderazgo siguientes:

S1 - Informante/Director: alto enfoque en la tarea y bajo enfoque en la relacin.

S2 - Entrenador/Vendedor: alto en foque en la tarea y alto enfoque en la relacin. S3 - Soportativo/Participativo: bajo enfoque en la tarea y alto enfoque en la relacin.

S4 - Delegativo: bajo enfoque en la tarea y bajo enfoque en la relacin.

Tambin establece los siguientes estilos de seguimiento:

R1 - Principiante entusiasmado: baja capacidad y alto grado de compromiso.

R2 - Aprendiz desilusionado: cierta capacidad y bajo grado de compromiso.

R3 - Capaz pero cauto: alta capacidad y grado de compromiso variable.

R4 - Conseguidor de metas independiente: alta capacidad y alto grado de compromiso.

Se puede apreciar grficamente en la siguiente ilustracin:

Cabe mencionar que las posiciones de las personas en la matriz pueden cambiar de un proyectoa otro.

Los equipos de trabajo son nicos, suelen ser un grupo de personas reunidas para trabajar en unproyecto durante un tiempo acotado. Por eso, inicialmente dispones de un determinado nmerode personas que no se conocen, no confan unos en otros y que disponen de una serie dehabilidades relacionadas con las tareas a realizar durante el proyecto. Lo primero que se debeconseguir en esta fase de formacin es que todos tengan muy claro cul es la meta, de formaque todos avancen, ms o menos, en la misma direccin. Una buena forma de conseguir estos esinvolucrndolos en la definicin del proyecto y en el desarrollo de la visin del proyecto, lo que

proporcionar una meta comn para todos ellos. Se habrn dado los pasos necesarios para laentrar en la fase de agitacin. A continuacin es necesario dotar de confianza al grupo, de forma

que se alcance la fase de normalizacin, donde los miembros del equipo comienzan a conocercmo trabajar entre ellos para conseguir el objetivo comn. Conforme el equipo comienza a

Delegativo

Participativo Entrenador

Director

R1R3 R2R4


23/173

23

funcionar y a avanzar hacia la meta habr obstculos que requerirn pequeos cambios dedireccin o, en algunos casos, cambios drsticos (cambios de alcance). El director del proyectodebe proporcionar, no slo la direccin correcta hacia la meta, sino los recursos necesarios paraalcanzarla.

A continuacin se describen los principales roles dentro de un proyecto: Director del Proyecto: es el principal responsable de que el proyecto sea un xito. El

director controla el flujo de valor del proyecto. Es el encargado de esbozar y aprobar eldiseo del proyecto as como de la elaboracin del plan del mismo. Adems, es la

persona encargada de crear y mantener las asignaciones del proyecto. Por otra parte, eldirector es el encargado de responder a la pregunta principal para el control del

proyecto: Cundo debo actuar para recuperar buffer? Otras tareas propias de este cargoson las de mantener el flujo de trabajo, controlar los cambios que se produzcan en el

proyecto y ayudar al equipo en la comunicacin y resolucin de problemas. Adems,debe de tomar decisiones operacionales como:

Disposicin de materiales no incluidos en las especificaciones.

Aprobar o rechazar solicitudes de tiempo o dinero para completar actividades.

Solventar peticiones de cambios de alcance.

Resolver conflictos con los recursos.

Acelerar actividades que puedan amenazar la fecha de entrega.

Responder frente a influencias externas no previstas.

Solucionar errores.

El director del proyecto se debe encargar de la monitorizacin del Project Buffer y detodos los buffers de alimentacin segn la periodicidad preestablecida. En el caso deque alguno de los buffers se encuentre en la zona intermedia de la fever chart, seencargar de planear medidas para la liberacin de buffer. En caso de que alguno de los

buffers se encuentre en zona roja, se encargar de dar la orden de ejecutar las medidasprevistas para la liberacin de buffer.Algunas organizaciones designan un lder del proyecto y un director de proyecto. Enestos casos el lder es la cabeza tcnica del proceso y el director se encarga de la

planificacin y el control del proyecto.

Gestor de Tareas: se encarga de que se mantenga el flujo del proyecto. Su misin esdeterminar cul es la siguiente tarea que debe realizar. Una buena aproximacinconsiste en trabajar en aquellas tareas que facilitarn que el proyecto finalice lo antes

posible. LPM no utiliza fechas de Inicio sino que utiliza administracin de buffers paraasignar las tareas dinmicamente. Toda tarea empezar cuando la tarea predecesora

haya finalizado y el recurso est disponible, y se finalizar tan pronto como sea posible.Cuando un recurso finaliza una tarea, el gestor de tareas debe asignarle la tarea que

pueda comenzar y que est causando un mayor uso de buffer. Esto aplica tanto a lagestin de proyectos individuales como a la gestin de mltiples proyectos. En el casode mltiples proyectos los recursos disponibles se asignarn a las tareas con mayor usode buffer sin tener en cuenta la prioridad del proyecto que contiene esa tarea.

Durante la ejecucin de los proyectos, el gestor de tareas tiene un puesto clave para lacorrecta implementacin del LPM puesto que es el encargado de reportar el estado delas tareas y estimar el tiempo restante de las que estn procesndose. Este ltimo

parmetro determina el nivel de uso de buffer y por tanto afecta a la prioridad de lastareas de todas las personas implicadas en el proyecto. Por todo ello debe ser

responsable a la hora de hacer estimaciones.


24/173

24

El gestor de tareas es responsable de liberar la tarea en el menor tiempo posible. Si enun momento determinado, el gestor de tareas no sabe cmo resolver un problema que

permita la finalizacin de una tarea, ste deber inmediatamente solicitar ayuda aldirector del proyecto

Recursos: son las personas encargadas de la realizacin de las tareas y de la elaboracin

de los entregables. Son los responsables de obtener unos resultados de calidad en sustareas en el menor tiempo posible y de facilitar este resultado a la tarea sucesora.

Gestor de Recursos: son los encargados de proveer de recursos cualificados para larealizacin de las tareas que engloba un proyecto. El manager del recurso tambor puedeactuar tambin como organizador maestro para la organizacin, desarrollando ymanteniendo la planificacin del recurso tambor.

Otros roles pueden ser asignados en caso de ser necesarios para el desarrollo delproyecto.

A continuacin se muestra un ejemplo de matriz de asignacin de responsabilidades en lagestin de proyectos.

# Tarea

1 Carta del Proyecto A R I I I I I I I

2 Plan del Proyecto A R I I I I I I I

3 Procesos del Proyecto A I R I C I I I I

4 Requerimientos del Proyecto A,R C I C C I I

5 Declaracin del Alcance del Proyecto A R C C I

6 Anotar los Cambios en el Proyecto A C R I I I I I I

7 Registro de los Riesgos del Proyecto A C C C C I I

8 Calendario del Proyecto A R I C C I I I I

9 Presupuesto del Proyecto A R I I C C I I

Contratista

Parte Implicada

Clie

nte

LiderdelProyecto

Pla

nificadordelProyecto

AdministradordelProyecto

DirectordePaquetesde

DirectordeRecursos

DirectordeTareas

Recurso

Gerencia

Sigla Rol Traduccin Descripcin

R Responsible Subordinado

Este rol realiza el trabajo y es responsable por su realizacin. Debe existir slo un R, si existe

ms de uno, entonces el trabajo debera ser subdividido a un nivel ms bajo.

A Accountable Responsable

Este rol se encarga de aprobar el trabajo finalizado y a partir de ese momento, se vuelve

responsable por l.

C Consulted Consultado Este rol posee la informacin o capacidad necesaria para terminar el trabajo.

I Informed Informado Este rol debe ser informado sobre el progreso y los resultados del trabajo.

Otro aspecto clave en el liderazgo es la gestin de los conflictos. La sinergia es el efecto que seproduce en los equipos cuando el output del mismo es superior a la suma de lo que cada

miembro podra obtener individualmente. Esto sucede cuando los miembros del equipo soncapaces de apoyarse en las fortalezas individuales para compensar las debilidades individuales.Esta diversidad que posibilita que un equipo obtenga mejores resultados que la suma de sus


25/173

25

partes puede tambin producir conflictos. Estos conflictos pueden ser productivos si conllevanel desarrollo de mejoras. Existe una matriz de prediccin del resultado de un conflicto enfuncin de la actitud adoptada por las personas involucradas.

Actitud

Resolucion

deproblemas

Imposicion Transigente Tranquilo Retraido

Resolucion

de

problemas

Resolucion

de

Problemas

(WW)

RP o

Imposicion

(WW o WL)

Resolucion

de

Problemas

(WW)

Resolucion

de

Problemas

(WW)

Resolucion

de

Problemas

(WW)

ImposicionImposicion

(WL)

Compaeros

Rancios

(LL)

Imposicion

(WL)

Imposicion

(WL)

Imposicion

(WL)

Transigente

Resolucion

deProblemas

(WW)

Imposicion(WL)

Transigente(LL)

Transigente(LL)

Transigente(LL)

Tranquilo

Resolucion

de

Problemas

(WW)

Imposicion

(WL)

Transigente

(LL)

Tranquilo

(LL)

Tranquilo

(LL)

Retraido

Resolucion

de

Problemas

(WW)

Imposicion

(WL)

Transigente

(LL)

Tranquilo

(LL)Retraido (LL)

Salvo si se est en una posicin muy dominante la mejor solucin para solventar un conflicto esla optar por la resolucin del problema mediante una opcin Win-Win. Una buena idea paratratar de resolver un conflicto consiste en entender el punto de vista de la otra persona antes deintentar explicarle el tuyo, es lo que se conoce como empata .Una buena tcnica para laresolucin de conflictos es el mtodo de la nube que se evapora (evaporating cloud) deGoldratt.


26/173

26


27/173


28/173

28

Durante la definicin del proyecto se han de definir claramente las hiptesis que se planteandurante la concepcin y planificacin del proyecto con el fin de mitigar las confusiones yconflictos que puedan surgir. Se debe tener presente que las hiptesis pueden hacer referencia acondiciones presentes y futuras dentro del dominio del proyecto. Por otra parte, en esta fasetambin se han de definir las limitaciones. Las limitaciones son entidades que puede ser que

limiten el proyecto, y a veces son hiptesis que estn fuera de nuestro control. En la definicinde nuestro proyecto se deben incluir nicamente aquellas limitaciones que se sabe que sonreales y que afectan materialmente al proyecto.

Todo proyecto debe tener un beneficio asociado. La mayora de las compaas solicitan unanlisis de retorno de la inversin (ROI) antes de la ejecucin del proyecto. Es por ello que senecesita una estimacin de costes (TCO - Total cost of ownership) que incluya todos los costesasociados a un proyecto hasta el fin de su ciclo de vida, y una estimacin de los beneficiosesperados.

Con el fin de desarrollar una adecuada definicin del proyecto se deben completar los siguientesobjetivos:

Financieros.

Retorno de la Inversin (ROI).

Valor Actual Neto (VAN).

Periodo de Retorno

Tasa Interna de Retorno (TIR).

Anlisis de flujos de caja.

Metas del Proceso

Ciclo de vida.

Disponibilidad.

Eficiencia.

Persistencia.

Entregables del proyecto.

xito del nuevo producto.

Posicionamiento de la compaa.

Satisfaccin del Cliente

Elaboracin de encuestas de satisfaccin.

Anlisis del servicio de atencin al cliente (tiempo y respuesta).

Devoluciones/quejas del cliente.

Valor aadido econmico.

Formacin de Empleados y Crecimiento del Nmero de Empleados

Satisfaccin de empleados.

Formacin.

Nuevos empleados.

El proceso de definicin de proyecto comienza con la identificacin de cuestiones a solucionar yde las acciones que deben acometerse para realizar el seguimiento de dichas cuestiones. Estas


29/173

29

cuestiones no deben de ser resueltas inmediatamente por la persona que las detecta sino quedeben ser asignadas a alguien que ser el encargado de resolverlas y cerrarlas. Se debe mantenerun repositorio con la siguiente informacin sobre las cuestiones y sus resoluciones:

Nmero de seguimiento.

Fecha de introduccin. Descripcin.

Estado (abierta/cerrada).

Persona responsable de la cuestin.

Fecha prevista de finalizacin o fecha de resolucin.

Adems, para un seguimiento efectivo se deben tener presentes los siguientes aspectos:

Solo debe haber una persona responsable para una cuestin dada. Puede ser que seannecesarias ms de una persona para resolver la cuestin, pero slo una ser responsable.

No hay que intentar resolver las cuestiones conforme se descubren, sino que se debeasignar a alguien para que las resuelva.

Siempre hay que tener una fecha de resolucin. Si no se puede dar una fecha, se ha desolicitar una fecha en la que se pueda conocer la fecha de resolucin.

Se debe hacer un seguimiento semanal de todas las cuestiones abiertas.


30/173

30


31/173

31

2.2.4- SOLUCIN CORRECTA

La solucin correcta comienza con la comprensin de los requerimientos de las partesimplicadas en el proyecto con el fin de alcanzar el xito del mismo, y contina plasmando estos

requerimientos en un alcance adecuado y en una correcta asignacin de responsabilidades. Lasolucin correcta es el camino principal para reducir todos los tipos de despilfarros.

Dar una solucin incorrecta al proyecto es el peor tipo de despilfarro que puede haber en lagestin de proyectos. Todo proyecto debe comenzar con la determinacin de los requerimientosdel cliente. Podemos en este punto distinguir entre dos tipos de proyectos principalmente. Unoscomienzan con una detallada lista de especificaciones de proyecto, en cuyo caso es bastantesencillo detectar los requerimientos del cliente puesto que estn escritos. Otros comienzan conun problema a resolver o una oportunidad a explotar. En este segundo tipo de proyectos es vitalentender los requerimientos del cliente para obtener una solucin efectiva.

La documentacin del proyecto debe describir los requerimientos de negocio de un proyecto en

forma de los resultados que el cliente espera. Segn Mekelburg, todo requerimiento debepoder plasmarse de la siguiente forma [parte implicada] espera ser capaz de [actividad denegocio].

El segundo punto clave en la definicin de requerimientos consiste en determinar el modo enque se evaluar el grado de cumplimiento de los mismos. Los criterios de cierre se deben definira la vez que se desarrollan los requerimientos con el fin de cerciorarse de que los requerimientosson evaluables. La herramienta utilizada para desarrollar y comunicar los requerimientos es laMatriz de Juran

Proceso Listo paraProducir

Identificar Clientes Desarrollar Producto

Optimizar Diseo delProducto

Desarrollar Proceso

Optimizar: Comprobar laCapacidad del Proceso

Transferir a Operaciones

Producto y Proceso Existente

Traducir

Descubrir Necesidades delCliente

Establecer Unidades deMedida

Establecer Medicin

Listado de Clientes

Necesidades del Cliente(en su lenguaje)

Necesidades del Cliente(en nuestro lenguaje)

Unidades de Medida

Necesidades del Cliente(en unidades de medida)

Caractersticas delProducto

Metas del Producto

Caractersticas delProceso

Proceso Listo paraTransferir


32/173

32

Nmero Requerimiento Unidad de Medida Sensor Criterio

1

Los propietarios del proyecto esperan ser

capaces de identificar el alcance completo del

proyecto

Elementos del

alcance

entregado

Aprobacin del

propietario del

proyecto

El dueo del proyecto aprueba el WBS a un

nivel que se identifiquen todos los entregables

2

Los propietarios del proyecto esperan ser

capaces de entender el calendario del

proyecto

Fechas

Carta de secuencia

de eventos del

proceso

Los principales entregables tienen una fecha

de entrega asociada

3Las partes implicadas en el proyecto esperanser capaces de identificar los elementos del

presupuesto

DineroTabla del

presupuesto

Todos los entregables tienen un presupuesto

asociado

Juran recomienda que la matriz permita una jerarqua de requerimientos. La idea consiste en queinicialmente se pueda definir un requerimiento general del proceso y a partir de este se puedendesarrollar requerimientos a un nivel ms bajo de detalle. La jerarqua empleada no debe sersuperior a 3 niveles y los requerimientos de la matriz deben estar en un lenguaje que entienda latotalidad de involucrados en el proyecto.

Escoger una direccin en la que encaminar la solucin si un completo estudio de mercado esuna solucin no vlida, ya que una vez que se toma una direccin es muy difcil volver atrs.El director de un proyecto debe de asegurarse de que un nmero amplio de alternativas se handesarrollado y tenido en cuenta antes de seleccionar la solucin que considera adecuada.

Nadler y Hibino definen 7 principios para la resolucin creativa de problemas:

Singularidad.

Propsitos.

Solucin despus-siguiente (after-next).

Sistemas.

Recoleccin limitada de la informacin.

Diseo de las personas.

Mejora de la lnea de tiempos.

El principio de la recoleccin limitada de la informacin afirma que no se debe convertir uno enexperto en la materia o el problema que a resolver, sino que debe enfocar la bsqueda enencontrar elementos que den soporte a las decisiones que se deben tomar. Los propsitos de este

principio son:

Focalizar los esfuerzos en obtener nicamente la informacin necesaria para unproyecto en concreto.

Dar sentido a la informacin existente. Fomentar la creacin de redes de trabajo para obtener informacin, contactos y

resultados.

Evitar la desorganizacin.

Disminuir la preparacin de documentos innecesarios que no son ledos.

Evitar la recoleccin de informacin como fin en s mismo sin importar los propsitosde uso de dicha informacin.

Maximizar el uso de tiempo esfuerzos y recursos.

El pensamiento crtico es el pensamiento que conduce hacia las buenas decisiones y hacia lasbuenas soluciones a problemas. El pensamiento crtico es el resultado de la interpretacin,


33/173

33

anlisis, evaluacin y la inferencia. A continuacin se enumeran los pasos que definen elpensamiento crtico:

Definir el problema en trminos del objetivo a alcanzar.

Considerar el problema desde varios puntos de vista.

Considerar un mnimo de tres posibles soluciones al problema. Establecer y utilizar criterios claros para seleccionar una de las soluciones que se han

desarrollado.

Evaluar posibles consecuencias no deseadas de la solucin adoptada.

Evaluar posibles obstculos de implementacin.

1Identificar

elProblema

2Puntos de

VistaAlternativos

3Soluciones

Alternativas

4Criterios de

Solucin

5Consecuencias

Imprevistas

6Obstculos de

Implementacin

7Solucin

Las habilidades asociadas al pensamiento crtico son tiles para la resolucin de problemas, latoma de decisiones, la planificacin y la argumentacin.

Hay gente que contrapone el pensamiento crtico con el pensamiento creativo, pero el autorconsidera que el pensamiento creativo es una parte necesaria del pensamiento crtico.

DeBono es el inventor del pensamiento lateral y propone la siguiente lista de elementos aconsiderar para disear operaciones:

Subir a un concepto ms amplio.

Bajar a una idea o concepto ms especfico.

Considerar alternativas.

Realizar un escaneo de los factores que pueden influir o afectar al diseo.

Cuestionar las ideas bsicas del proyecto.

Considerar cambios fundamentales en lo que se tiene.

Modificar lo que se ha pensado con anterioridad.

Desarrollar nuevas ideas.

Combinar posibles alternativas.

Seleccionar un concepto o principio y trabajar sobre l.

Mirar el contexto de las cosas para cambiarlas.


34/173

34

Plantear nuevas cuestiones para redefinir el problema.

Provocar otras ideas.

Fortalecer las ideas que han sido propuestas pero rechazadas debidas a alguna objecin.

Convertir en prcticos algunos acercamientos no prcticos.

Analizar el problema y la oportunidad.

El mtodo de los 6 sombrerosOtro mtodo desarrollado por Debono es el mtodo de los 6 sombreros que consiste en analizarun problema desde 6 puntos de vistas diferentes para comprender mejor el problema, y alcanzarmejores y ms innovadoras soluciones. El mtodo de los 6 sombreros nos permite centrarnuestro proceso de pensamiento y filtrar nuestras ideas. Este mtodo hace uso del pensamiento

paralelo que postula la resolucin de problemas mediante el anlisis de los mismos desde todolos ngulos posibles.

Un sombrero es algo que puede poner y quitarse fcilmente. Los sombreros son seales visualesque nos permiten cambiar fcilmente nuestro modo de pensar.

Los seis sombreros son:

El sombrero azul: el sombrero organizador (liderazgo de procesos).

El sombrero blanco: el sombrero de Dragnet o neutro (nicamente se consideran loshechos).

El sombrero amarillo: el sombrero de lgica positiva (se considera todo desde un puntode vista positivo).

El sombrero rojo: el sombrero emocional (sensaciones, sentimientos).

El sombrero negro: el sombrero negativo (qu hay de malo en el proyecto).

El sombrero verde: el sobrero creativo (qu pasara si intentramos).

Cuando se utiliza el mtodo de los 6 sombreros, todas las partes juegan todos los roles, es decir,no hay una persona que sea siempre el sombrero negro por ejemplo. Antes del comienzo de lasesin se debe establecer un orden secuencial de uso de los sombreros, aunque este orden puedecambiar en funcin de cmo discurra la sesin. No obstante se debe tener presente que todos lossombreros se pueden utilizar cuantas veces se deseen, con la nica restriccin de todos debenser usados al menos una vez.

Normalmente el sombrero azul se utiliza el primero y el ltimo. El primero para indicar elmotivo de la reunin y definir el problema, los objetivos, el resultado que se quiere alcanzar y lasecuencia inicial de los sombreros. Al final se utilizar para indicar lo que se ha conseguido, losentregables de la reunin, las conclusiones, los diseos, las soluciones, etc. No obstantetambin se podra utilizar el sobrero rojo al final para preguntar a la gente sobre sus opinionesacerca del resultado y si creen que se ha realizado un buen trabajo.

Mtodo TRIZTRIZ es un acrnimo ruso para Teora para Resolver Problemas de Ingeniera ("TeoriyaResheniya Izobretatelskikh Zadatch" o ), la teora deresolucin de problemas y de invencin, desarrollada porGenrich Altshuller y sus colegas desde

1946.TRIZ es un mtodo de resolucin de problemas de Ingeniera y por tanto nicamente es
http://es.wikipedia.org/wiki/Acr%C3%B3nimohttp://es.wikipedia.org/wiki/Idioma_rusohttp://es.wikipedia.org/wiki/Resoluci%C3%B3n_de_problemashttp://es.wikipedia.org/wiki/Genrich_Altshullerhttp://es.wikipedia.org/wiki/1946http://es.wikipedia.org/wiki/1946http://es.wikipedia.org/wiki/Genrich_Altshullerhttp://es.wikipedia.org/wiki/Resoluci%C3%B3n_de_problemashttp://es.wikipedia.org/wiki/Idioma_rusohttp://es.wikipedia.org/wiki/Acr%C3%B3nimo


35/173

35

vlido para la resolucin de problemas tcnicos que pueden surgir durante la elaboracin delproyecto.

TRIZ es una teora sobre la cual se ha desarrollado una metodologa, un conjunto deherramientas basados en modelos para la generacin de ideas y soluciones innovadoras para

resolver problemas. TRIZ provee de herramientas y mtodos para usarse en formulacin deproblemas, anlisis de sistemas, anlisis de fallas y patrones de evolucin de sistemas.TRIZnace del anlisis de miles de documentos de patentes, de los cuales se extraa el problema y lasolucin aportada. La presencia de ciertas pautas inventivas repetidas en distintos sectores, elacceso al conocimiento externo al problema y la evolucin de las tecnologas, sentaron las bases

para la metodologa. Triz reposa sobre un sistema de pensamiento dialctico, que complementalo anterior con la evolucin constante de los sistemas y la presencia y resolucin decontradicciones tcnicas. A diferencia de tcnicas como elBrainstorming (Tormenta de Ideas),

basada en la generacin de ideas aleatorias, TRIZ anima a crear un enfoquealgortmicopara lainvencin de nuevos sistemas y el refinamiento de viejos.

Dicho algoritmo se puede resumir en los siguientes pasos:

Ante un problema determinado, "MI PROBLEMA" hay que reconocer sus elementos ysu modelo, entrando en la fase conceptual "PROBLEMA MODELO".

TRIZ ha organizado sus herramientas para que a partir de un modelo de problema, sepueda identificar un modelo de solucin "MODELO DE SOLUCIN".

A partir de ah TRIZ no aporta muchos elementos para pasar de la solucin conceptual yabstracta a una aplicacin concreta "MI SOLUCIN".

PROBLEMAESPECFICO

PROBLEMA TPICO

(Contradiccin)

SOLUCINESPECFICA

SOLUCIN

TPICA

AbstraerConcretar

Matriz

Triz postula que todo problema de ingeniera puede enfocarse como una serie de conflictos entre39 parmetros. Los 39 parmetros de ingeniera definidos son:

1. Peso de un objeto en movimiento2. Peso del objeto inmvil3. Longitud de un objeto en movimiento4. Longitud de un objeto inmvil5. rea de un objeto en movimiento6. rea de objeto inmvil7. Volumen de un objeto en movimiento8. Volumen de un objeto inmvil

9. Velocidad10.Fuerza
http://es.wikipedia.org/wiki/Metodolog%C3%ADahttp://es.wikipedia.org/wiki/Herramientahttp://es.wikipedia.org/wiki/Ideahttp://es.wikipedia.org/wiki/An%C3%A1lisis_de_sistemashttp://es.wikipedia.org/w/index.php?title=An%C3%A1lisis_de_fallas&action=edit&redlink=1http://es.wikipedia.org/w/index.php?title=Evoluci%C3%B3n_de_sistemas&action=edit&redlink=1http://es.wikipedia.org/wiki/Brainstorminghttp://es.wikipedia.org/wiki/Algoritmohttp://es.wikipedia.org/wiki/Algoritmohttp://es.wikipedia.org/wiki/Brainstorminghttp://es.wikipedia.org/w/index.php?title=Evoluci%C3%B3n_de_sistemas&action=edit&redlink=1http://es.wikipedia.org/w/index.php?title=An%C3%A1lisis_de_fallas&action=edit&redlink=1http://es.wikipedia.org/wiki/An%C3%A1lisis_de_sistemashttp://es.wikipedia.org/wiki/Ideahttp://es.wikipedia.org/wiki/Herramientahttp://es.wikipedia.org/wiki/Metodolog%C3%ADa


36/173

36

11.Tensin, presin12.Forma13.Estabilidad del objeto14.Intensidad15.Durabilidad de un objeto en movimiento

16.Durabilidad de un objeto inmvil17.Temperatura18.Brillo19.Energa gastada por un objeto en movimiento20.Energa gastada por un objeto inmvil21.Potencia22.Gasto de energa23.Gasto de sustancia24.Prdida de informacin25.Prdida de tiempo26.Cantidad de sustancia27.Fiabilidad

28.Precisin de medida29.Precisin de fabricacin30.Factores nocivos que actan sobre un objeto31.Efectos secundarios nocivos32.Fabricacin33.Conveniencia de uso34. Facilidad de reparacin35.Adaptabilidad36.Complejidad del dispositivo37.Complejidad de control38.Nivel de automatizacin39.Productividad

Una vez se ha definido el problema como conflictos entre estas variables, Triz propone 40tcnicas para la resolucin de conflictos entre los parmetros de ingeniera anteriormentedefinidos y que son los siguientes:

1. Segmentacin2. Extraccin3. Calidad local4. Asimetra5. Fusin6. Universalidad

7. Introducir un objeto dentro de otro (Nested doll)8. Anti-peso9. Anti-accin preliminar10.Accin preliminar11.Amortiguacin de antemano12.Equipotencialidad13.Invierte la accin14.Esfericidad Curvatura15.Dinamismo16.Acciones parciales o excesivas17.Otra dimensin18.Vibracin mecnica

19.Accin peridica20.Continuidad de acciones tiles


37/173

37

21.Omisin22.Convertir limones en limonada23.Retroalimentacin24.Intermediario25.Autoservicio

26.Copia27.Objetos baratos con corta esperanza de vida28.Substitucin Mecnica29.Neumticos e hidrulicos30.Estructuras flexibles y coberturas delgadas31.Materiales porosos32.Cambios de color33.Homogeneidad34.Descartar y recuperar35.Cambio de parmetros36.Transicin de fases37.Expansin trmica

38.Oxidantes fuertes39.Atmosfera inerte40.Materiales compuestos

Se puede apreciar una descripcin detallada de las tcnicas antes mencionadas y los conflictosque resuelven en el Anexo I del presente documento.

TRIZ ayuda a tcnicos de diseo, de calidad, de I+D, de oficina tcnica, de fabricacin, etc. encuatro aspectos:

Resuelve los conflictos tcnicos (cuando la mejora de un parmetro o componente de unsistema, conlleva la penalizacin de otro), aplicando principios de invencin

estandarizados. TRIZ evita llegar a soluciones intermedias o de optimizacin delcompromiso.

Conduce hacia el conocimiento cientfico y tcnico necesarios para resolver elproblema. En muchas situaciones la dificultad del problema estriba en que la solucinest fuera del campo de especialidad del tcnico, de la empresa, del sector, o incluso dela industria en general.

Es una excelente herramienta para la previsin tecnolgica. Esto es, dada una necesidadfuncional cualquiera, TRIZ predice con detalle, un abanico de diseos novedosos quesatisfarn la funcin.

Las soluciones obtenidas son en muchos casos patentables, y la propia metodologaayuda a conseguir una mejor calidad en la cartera de patentes.

En paralelo con el desarrollo de soluciones alternativas, se debe desarrollar un mtodo quepermita seleccionar la direccin correcta. Normalmente se utiliza lo denominado tabla decriterios ponderados (weighted criteria table). Adems, en ocasiones, la solucin debe cumplircriterios GO - NO GO (MUST CRITERIA) incluso antes de ponderarlos. Solo se debenconsiderar aquellas alternativas que cumplen con los criterios MUST.

La toma de decisiones robustas consiste en adoptar decisiones que son tan inmunes como seaposible a la incertidumbre, a la incompletitud y a la evolucin de la informacin sobre la que se

basan.


38/173

38

El valor monetario esperado (EMV - expected Monetary Value) es un mtodo de eleccin entrealternativas con resultados incierto. Este mtodo hace frente explcitamente a los resultadosinciertos, cosa que no realizan ni la matriz de decisiones ni el mtodo de la nube que se evapora.EMV utiliza un rbol de decisiones para estimar un valor y una probabilidad para cada eleccinde decisin y resultado posible. Behn y Vaupel extendieron EMV de forma que desarrollaron

un modo para contabilizar el grado de confianza que uno puede asignar a un posible resultado.Asignar un nivel de confianza a una probabilidad es necesario para comparar elecciones dondeel nivel de confianza vara.

Ullman lleva el proceso de toma de decisiones robustas un paso ms all. El proceso de toma dedecisiones robustas genera mapas de confianza de las estimaciones del grado de cumplimientode un criterio por una alternativa cumple un criterio contra el grado de conocimiento de laestimacin. Existen programas especficos para realizar estos clculos.

Una vez determinada la direccin a tomar hacia la solucin, se est preparado para definir elalcance del proyecto. Este alcance dirige las estimaciones de coste y de planificacin. Laherramienta utilizada para organizar el alcance es el WBS (Work Breakdown Structure).

WBS en sintona con el pensamiento TOC proporciona elementos para organizar, integrar,asignar responsabilidades y controlar proyectos.

EL WBS se compone de paquetes de trabajo (Work packages), que son asignados adirectores de WP para su estimacin y ejecucin, y que estn compuestos por una o variastareas. Las personas a las que se les asigna los elementos de un WBS tienen que definir undetallado alcance del trabajo, establecer la secuencia de las tareas, y estimar los recursosnecesarios para realizar dichas tareas. Ellos son tambin responsables de identificar lasrelaciones entre sus WP y los de los dems. Los paquetes de trabajo se componen de:

Alcance a ser repartido por el WP

Especificaciones y estndares de los entregables

Lgica de la actividad

Estimacin de recursos para la actividad

Las bases para la estimacin de recursos de la actividad

Las tareas componen el nivel ms bajo dentro del WBS y a este nivel se desarrollan los costes ylas estimaciones de duracin.

Los elementos que componen un WBS deben de proporcionar un resultado evaluable, tangible,que debe ser proporcionado para completar un proyecto mayor o una parte de un proyecto.

Las principales funciones de un WBS son: Crear una estructura para los entregables.

Actuar como un vehculo para integrar y evaluar el rendimiento en coste y tiempo.

Asociar entregables con sus responsables.

Estructurar el anlisis del proyecto y el reporte.


39/173

39

Una buena alternativa para la asignacin de responsabilidades en uso conjunto del WBS y lamatriz RACI:

WBS

# Entregable

1 Soporte del Proyecto (project support) A1.1 Carta del Proyecto A R I I I I I

1.2 Plan del Proyecto A C R I C C

1.3 Direccin del Proyecto A,R

1.4 Reportes de Progreso A R I C C I

1.5 Cierre A I I I C R

2 Diseo del Sistema A

2.1 Requerimientos Funcionales A R I C C I2.2 Estudio Alternativo A I I C C

Responsabilidad

LiderdelProyecto

DirectordeDiseo

PlanificadordelProyecto

AdministradordelProyecto

EquipodelProyecto

Gerencia

Cliente

Sigla Rol Traduccin Descripcin

R Responsible Subordinado

Este rol realiza el trabajo y es responsable por su realizacin. Debe existir slo un R, si existe

ms de uno, entonces el trabajo debera ser subdividido a un nivel ms bajo.

A Accountable Responsable

Este rol se encarga de aprobar el trabajo finalizado y a partir de ese momento, se vuelve

responsable por l.

C Consulted Consultado Este rol posee la informacin o capacidad necesaria para terminar el trabajo.

I Informed Informado Este rol debe ser informado sobre el progreso y los resultados del trabajo.

La definicin del alcance, del coste y de la planificacin de un proyecto requiere establecerlmites e hiptesis. Los lmites delimitan qu se incluye dentro del proyecto y qu no. Por otrolado, todo plan de proyecto debe incluir las hiptesis necesarias para proporcionar unaestimacin razonable de los recursos necesarios para una tarea as como de la duracin de lamisma.

Una forma efectiva de desarrollar la lgica de un proyecto consiste en identificar inicialmentelas principales fases del proyecto en trminos de eventos clave para el proyecto. Cada eventodebe tener asociado un entregable y no se incluyen fechas. El resultado es una carta desecuencia de eventos. Este es un proceso que se debe e realizar en equipo de la siguientemanera:

Todo el equipo debe estar de acuerdo con la visin final del proyecto.

Trabajar para recoger hiptesis, riesgos y cuestiones.

Desarrollar WBS de tres niveles asegurndose que se enfoca en los entregables.

Desarrollar la secuencia de eventos de derecha a izquierda y hacia abajo.

La nica fecha permitida es la fecha de entrega final al cliente.


40/173

40


41/173

41

2.2.5- GESTIN DE LA VARIACIN

En la gestin de proyectos podemos distinguir principalmente entre dos tipos de variaciones:

Variaciones de causa comn: es la capacidad de un sistema para reproducir repetidasveces unos resultados medibles.

Variaciones de causa especial: son variaciones debidas a causas externas al sistema.

El rango necesario para cubrir casi todas las posibles variaciones de causa comn vara desde el-50% al +100% (95% de efectividad) del tiempo medio de ejecucin.

LPM utiliza buffers para paliar las variaciones de causa comn y la gestin de riesgos parapaliar las variaciones de causa especial.

El primer impacto que produce la variacin en la planificacin y la ejecucin del proyecto es laaparicin de despilfarros debido a retrasos de los siguientes tipos:

Externo a la tarea

Colas (el input est preparado, pero el recurso no)

Falta de sincronizacin (el recurso est disponible, pero el input no)

Interno a la tarea:

Multitarea: No se deben hacer varias tareas a la vez puesto que se generangrandes ineficiencias (hasta 40%).

Ley de Parkinson.

Sndrome del Estudiante.

Se debe tener presente que el coste de retrasar un da un proyecto no es slo el coste de losrecursos afectados sino tambin el lucro cesante.

LPM implementa los siguientes buffers para la gestin de variaciones de causa comn:

Project buffer: buffer de tiempo al final de la cadena crtica del proyecto.

Feeding buffer: buffer de tiempo que conecta cadenas no crticas con la cadena crtica.

Capacity Constraint buffer

Cost buffer: buffer monetario que comprende el coste total del proyecto.

Ocasionalmente pueden ser necesarios dos buffers adicionales:

Drum buffer: buffer utilizado para acelerar el proceso en caso de que el recurso tamborquede disponible pronto.

Resource buffer: buffer que alerta a los recursos necesarios para las tareas de la cadenacrtica que pronto habr una tarea a realizar.

El uso de buffers acompaados de una adecuada aproximacin LPM posibilita menores lneasde tiempo y estimaciones de coste para alcanzar el mismo nivel de completitud. Esto se debe aque los buffers concentran matemticamente la proteccin frente a riesgos de una manera querequieren menos proteccin total que la necesaria para todas las tareas.

La gestin de buffers debe siempre responder a dos preguntas: Cundo estar acabado el proyecto? Cunto va a costar?


42/173

42

La gestin de buffers requiere del conocimiento del estado actual de las tareas del procesoprecisando un tiempo estimado de finalizacin de las mismas.

Para la asignacin de tiempo a las tareas, Goldratt propone que a estas se les debe asignar un50% del tiempo normal de ejecucin y el buffer final debera de ser la mitad de la suma de las

duraciones de las tareas de la cadena crtica, lo cual comprende, aproximadamente, un tercio deltiempo total del proyecto. Otras estimaciones LPM utilizan el mismo principio estadstico dePERT (LPM SSQ).

Leach recomienda el uso de SSQ junto con un tamao de Project buffer mnimo del 25% de laduracin de la cadena crtica y un 10% de mnimo buffer de coste para controlar el sesgo.

Todas estas aproximaciones (PERT, SSQ, Monte-carlo, etc.) reducen el tamao relativo delbuffer conforme el nmero de tareas crece. Esto implica que los proyectos ms grandes son mspropensos a acabar en tiempo (cosa que no suele suceder). Leach deduce que esta desviacin sedebe al sesgo ocasionado porque los mtodos antes citados suponen que la variacin de lastareas es independiente entre dichas tareas, cosa que no siempre es verdad. Es por ellos que

Leach propone estimar los buffers como la suma de los clculos segn los mtodos antesmencionados y el sesgo segn la siguiente tabla:

Factor de Sesgo Impacto en la Planificacin Impacto en el Coste

OmisionesAlguno, no excede el impacto en

coste5%-10%

Fusin ("merging")


43/173

43

El Capacity Constraint Buffer se utiliza con el fin de asegurar que el recurso con ms demandatiene suficiente capacidad para realizar la tarea en el tiempo indicado. El grado de utilizacin delrecurso no puede ser del 100% porque si no, los tiempos de espera se disparan (teora de colas).Es por ello que suele dimensionar el buffer para una utilizacin del recurso de un 75%.

El buffer de coste realiza la misma f

evaluador gestión de proyectos

Documents