Issuu on Google+

CICLO DE VIDA DEL PROYECTO Y ORGANIZACION EL CICLO DE VIDA DEL PROYECTO Según el PMBOK, "es un conjunto de fases del mismo, generalmente secuenciales y en ocasiones superpuestas, cuyo nombre y número se determinan por las necesidades de gestión y control de la organización u organizaciones que participan en el proyecto, la naturaleza propia del proyecto y su área de aplicación". Para entender esto, veamos el sgte gráfico (de hecho muy parecido al ciclo de vida de un software o producto):

Fuente: PMBOK Versión Español - Ciclo de Vida de un Proyecto


Empecemos a analizar el gráfico, primero observemos que el ciclo se divide en 4 etapas: Inicio, Planificación, Ejecución (involucra el control y seguimiento) y el cierre del proyecto. En términos de costo (eje y) y tiempo (eje x), la ejecución es propiamente el que se lleva todo el paquete. Por lo tanto, si la ejecución es lo que determina el costo del proyecto "per se", ¿cual es la clave para minimizar ese costo y tiempo?, pues es la planificación. El tema es el siguiente: ¿cuántas organizaciones ponen sus costos y tiempos límites antes de empezar un proyecto, y el PM tiene que aceptar dichas restricciones?, ¿en qué momento hicieron una evaluación al respecto?... es la realidad de Latinoamérica como mercado emergente y no desarrollado. Ahora bien, lo mínimo que debemos exigir nosotros es un tiempo adecuado de planificación, ¿por qué?, porque por ejm: - Lo contratan a ud. como PM para un proyecto de interconexion con bancos para pagos, de antemano le dicen q tiene sólo 4 meses y un presupuesto de 6000 dólares. Ud. de primera mano por experiencia sabe que ese tipo de proyectos duran 6 meses. Obligatoriamente debe hacer saber eso a la Gerencia. La gerencia le dice que es imposible!!!, ok... Si ud. está de acuerdo y cree poder terminar el proyecto en 4 meses, se acepta el reto. Ud piensa que la planificación le durará 1 mes, la ejecución 2 meses y medio, y el cierre 1/2 mes. ¿Qué problemas puede tener?... El primero que la gerencia sea impaciente, que los usuarios presionen para que se empiece de una vez el proyecto porque quieren ver resultados. Si ud planifica 1/2 mes y empieza, debe hacer saber a la gerencia los riesgos que se corren (si ud no lo hace, no está comunicando correctamente nada). De hecho, va a sufrir sobrecostos porque no habrá mapeado bien las actividades y los recursos; por lo tanto ese proyecto puede durar más de 4 meses y obviamente no lo volverán a llamar. Los PM's debemos ser realistas y comunicar las cosas, es decir, si el proyecto cuesta más, hay que decirlo; si el proyecto necesita más recursos, hay que decirlo; si el proyecto no acabará en el tiempo, hay que decirlo; aún cuando ud. lo haya planificado mal, y con más razón cuando se está obligado a tiempos predeterminados por la gerencia. Una vez que ud. ha comunicado todo lo debido, la gerencia asumirá el riesgo y consecuencias; la garantía es que ud. cumplió con manifestarlo. La recomendación es tomarse su tiempo para planificar bien las cosas, eso le asegurará un tiempo de ejecución aproximado y estará dentro de los costos y tiempos que le aprobó la gerencia, aunque ellos no lo entiendan, ud. es dueño de lo que se debe hacer en el proyecto, a ellos sólo les interesará que se termine en el tiempo y que se cumplan los objetivos.


Ahora bien, el siguiente grĂĄfico nos muestra el comportamiento de algunas variables importantes reflejadas en tiempo y costo:

Fuente: PMBOK VersiĂłn EspaĂąol - Variables en costo y tiempo


Analicemos cada variable:  Influencia de los stakeholders.- Los stakeholders toman toda la importancia al principio porque son ellos quienes codefinen el alcance con el PM y además lo aprueban. Precisamente, por ello es que en la ejecución no deberían tomar mucha relevancia, ya que en el proyecto se ejecuta lo que se acordó. Esto no quiere decir que no tengan actividades asignadas o de apoyo.  Riesgos e incertidumbre.- La planificación tiene la mayor parte de riesgos, porque en esta etapa el proyecto aún se encuentra en definiciones y saltan a la luz muchas barreras y problemas. Si el proyecto no ha sido correctamente planificado, lo más probable es que el costo se eleve y el tiempo aumente. Más adelante, se verá la gestión de riesgos; de antemano puedo adelantar que muchos PM's no le dan importancia a los riesgos, por ende, no tienen planes de contingencia, y como resultado, el proyecto no cumple con los objetivos de costo, tiempo y calidad.  Costo de cambios.- Cuando se planifica correctamente, en la etapa de ejecución no deberían existir cambios, es decir: requerimientos nuevos, compras adicionales, nuevos stakeholders, etc. Cada cambio en el proyecto, tiene un costo y un impacto de tiempo. Usualmente esto surge porque la definición del alcance no ha sido clara o debidamente firmada. El responsable directo es el PM, no existe otro culpable, ya que es el líder quien maneja al grupo de stakeholders y quien controla todo el proyecto. Si estos costos surgen, no hay vuelta atrás, el PM debe informar al sponsor del proyecto (el que apadrina el proyecto $$$), cuánto es la desviación presupuestal y del cronograma. EL CICLO DE VIDA DEL PRODUCTO Y CICLO DE VIDA DEL PROYECTO No confundir ciclo de vida del producto con ciclo de vida del proyecto. Un proyecto puede producir uno o varios productos, y también un producto puede producir varios proyectos. Por ejemplo: el desarrollo de un ERP, puede tener varios proyectos en cartera; la construcción de un parque de diversiones también puede contener varios proyectos; un proyecto de generación de una nueva línea de negocio, puede tener outputs de varios productos, etc. Ahora bien, el reto es controlar todos los proyectos o productos resultantes. ¿Cómo se mide el éxito de un producto o proyecto?, pues mediante indicadores; se pueden obtener varios indicadores generales (es decir, indicadores conocidos en el mercado) e indicadores a la medida (propias del PM, que le ayude a controlar la situación de acuerdo a cada negocio). Los indicadores no están pintados, ni tampoco es necesario llenarse de indicadores sin sentido. Esto posteriormente se abordará en otros posts. FASES DE UN PROYECTO Un proyecto de una sóla fase, consta de los siguientes procesos:


Fuente: PMBOK Versión Español - Proyecto de una fase

Relación secuencial.- Como su nombre lo indica, se siguen las fases de forma secuencial y cada fase con sus respectivos procesos (que figuran en el gráfico anterior). Esta debería ser la temática de todos los proyectos, pero existen proyectos que por las circunstancias no se acomodan a este modelo y resulta más costoso, ya que no se pueden traslapar procesos. Es decir, con este modelo, no se puede acortar un cronograma a nivel de procesos; pero en la práctica, si podemos acortarlo a nivel de actividades. Relación de superposición.- Este tipo de modelo traslapa las fases (c/u respetando sus procesos). Usualmente se da cuando: se desea finalizar en un tiempo menor, se desean abaratar costos, o se desea obtener mayor beneficio por cada recurso. Pero tener mucho cuidado, ya que si se traslapan las fases y una de ellas se cierra incorrectamente, habrían reprocesos (con sobrecostos) en todo lo que resta del proyecto. Asimismo, si existen fases dependientes unas de otras, las fases pueden acumular actividades y/o procesos inmóviles (causando sobrecostos de oportunidad) y mayor tiempo de término.


Relación iterativa.- Este modelo se caracteriza por planificar cada fase, conforme se avanza el proyecto. Es decir, depende del resultado de una fase finalizada, para iterar la misma o pasar a la siguiente fase. Es claro que este modelo es el más costoso, el de mayor duración, pero de mayor calidad. ¿Qué modelo elegir?, pues depende del presupuesto, tiempo, calidad y entorno al proyecto. No hay una fórmula exacta, existen ocasiones que una empresa trabaja sólo con un tipo de modelo por políticas diversas y uno debe adecuarse a ello. El modelo de superposición se elige cuando no hay mucho dinero y hay poco tiempo (asumiendo los riesgos que este modelo trae). El modelo iterativo es muy costoso, pero asegura la calidad (el riesgo mayor es que planifica y define el alcance en la marcha, lo cual es peligroso). El modelo secuencial es el más usado y sobre el que mayor control se tiene. INTERESADOS El tratamiento de los interesados es un tema vital. El PMBOK dice lo siguiente: "Los interesados son personas u organizaciones que participan activamente en el proyecto, o cuyos intereses pueden verse afectados positiva o negativamente por la ejecución o terminación del proyecto". Es tan importante, que el PMBOK ha incluido un proceso de identificación de los interesados (más adelante se verá que forma parte del grupo de procesos de inicio y del área de conocimiento de comunicación). Un PM de mayor experiencia, probablemente ya haga un análisis sin llegar a la formalidad de la identificación de los interesados, pero nunca deja de hacerlo. ¿Qué pasa cuando dejamos de lado el análisis de identificación de interesados?, adjunto algunos ejemplos: - En un proyecto de TI, el PM prevee entregar una copia de la base de datos al proveedor (algo discutible, pero sucede en la realidad), para que el proveedor realice una evaluación, que difícilmente lo podría hacer remotamente o "in situ", pues el analista se encuentra en provincia. El PM cronograma esta actividad y lo comunica al equipo de proyecto. Cuando llega el momento, el auditor (quien no estaba incluido en el proyecto, ni tampoco se consideró como interesado), alza su voz para detener la entrega, pues considera que la información es confidencial y retrasa la actividad. - En un proyecto minero, el PM obvia incluir a la comunidad como interesado, y creo que ya todos conocemos como sigue la historia... (Proyecto Conga, Perú). Así como éstos, existen muchos otros ejemplos. La razón más convincente en mi opinión, para hacer un análisis de interesados, es porque en todos lados existe conflicto de intereses. Muchos de uds, que han entrado a reuniones en sus trabajos, se habrán dado cuenta la gente actúa según sus intereses y muy pocas veces con acciones de equipo; incluso quienes parecen actuar en equipo, tienen intereses personales de por medio, pero eso es parte de su estrategia. Ahí esta el punto del asunto, el fin primordial de gestionar interesados es elaborar estrategias para llegar a ellos y manipular sus actitudes a favor del proyecto. La manipulación es neutra,


no es buena ni mala, dependiendo como la usemos (más adelante se verá una matriz muy didáctica para identificarlos y elaborar estrategias). INFLUENCIA DE LA ORGANIZACION EN LA DIRECCION DE PROYECTOS La influencia de la organización se manifiesta en tres formas: mediante la cultura de la empresa, estructura de la organización y activos de los procesos de la organización. Cada uno de estos conceptos son extensos; sin embargo en este post lo que se quiere es dejar una idea concreta de cada uno de ellos.  La cultura de la organización trata de valores, formas de hacer las cosas, ética, etc. Lo importante para un PM es empaparse un poco de esta cultura y entender como desenvolverse en dicho ambiente. Un ejemplo claro son las empresas familiares: si un PM es contratado por una PYME familiar, se encontrará con una cultura horizontal, donde el dueño tiene cierta injerencia en labores operativas, donde el 80% del tiempo de los gerentes es la solución de problemas operativos, donde las personas pueden ser impuntuales o informales, etc. Por lo tanto, es de esperarse que la cultura de la empresa afecte el proyecto de alguna u otra forma, en ocasiones de forma positiva y en otras de forma negativa.  Los activos de los procesos de la organización abarcan procedimientos, políticas y procesos de la organización, así como bases de conocimiento que puedan servir de referencia para realizar ciertas actividades o resolver problemas comunes en el proyecto. Lo más importante es que el PM se alinee a los procedimientos que son obligatorios seguir en la empresa, y si alguno es perjudicial, comunicarlo oportunamente. Por último, la estructura de la organización afecta dos cosas importantes: el modo de dirección del proyecto y la disponibilidad de los recursos. Veamos de qué se trata cada estructura: Organización Funcional

Fuente: PMBOK Versión Español - Organización Funcional


La matriz funcional usualmente aparece en empresas pequeñas, donde le dan la responsabilidad a un gerente o jefe para dirigir un proyecto (se hace PM), no importando si tiene o no las facultades para dirigirlo y no tendrá autoridad sobre los demás gerentes funcionales. Organización Matricial

Fuente: PMBOK Versión Español - Organización Matricial Débil


Fuente: PMBOK Versi贸n Espa帽ol - Organizaci贸n Matricial Equilibrada


Fuente: PMBOK Versión Español - Organización Matricial Fuerte

 En la organización matricial débil, la coordinación del proyecto es delegada a algún analista senior o algún empleado de amplio conocimiento o potencial; sin embargo, no es una buena estructura porque el empoderamiento es casi nulo y muchos miembros del equipo de proyecto no apoyarán del modo que amerita el proyecto, precisamente por la falta de poder del PM. Esto es característico de las pequeñas empresas.  En la organización matricial equilibrada, si bien ya tenemos un PM nombrado, todavía existen problemas de empoderamiento, no sólo a nivel del manejo sino también en el tema de financiamiento. Esta es la estructura más común en las PYMES.


 En la organización matricial fuerte, existe un área de proyectos, y PM's a tiempo completo y debidamente empoderados. Si bien esta figura es muy ventajosa y es recomendable, por mi experiencia les puedo asegurar que no es perfecta. En muchas empresas burocráticas, las personas van a tener problemas de tiempo y muy probablemente generen retrasos en los proyectos que el PM deberá manejar adecuadamente. Esta estructura no es ajena a este problema y peor aún si existen conflictos de intereses. Organización Orientada a Proyectos

Fuente: PMBOK Versión Español - Organización Orientada a Proyectos

En este tipo de organización, cada PM tiene su propio staff dedicado enteramente a ver proyectos, por ejemplo, en empresas inmobiliarias quienes tienen gerentes de proyecto por obras; en empresas


con líneas de productos, etc. A pesar, que sigue siendo una buena propuesta, también es cierto que el staff no ve otra cosa que no sean las cosas sólo del proyecto que están llevando a cabo, y muy pocas veces apoyan a las otras áreas. Organización Combinada

Fuente: PMBOK Versión Español - Organización Orientada a Proyectos

La organización combinada nace como respuesta a la inconformidad frente a los otros tipos de organización respecto a la forma de manejo de proyectos que propone la empresa. Es decir, se desean aprovechar los "pro" y minimizar los "contra" al momento de hacer una fusión de las estructuras de trabajo. La observación más inmediata que se le puede hacer a esta estructura es


que demanda mucho trabajo implementarla y sostenerla, con procedimientos claros que permita trabajar a la empresa de esa forma. En resumen, se pueden sacar las siguientes conclusiones: 1. Para minimizar los sobrecostos de ejecución, realizar una buena planificación. 2. El sobrecosto es más caro en la ejecución del proyecto, pues necesita recursos adicionales más caros, tiempos que no se contabilizaron, compra de material y/o equipos que no se presupuestaron, etc; "el sobrecosto está en los detalles". 3. Escoger el modelo adecuado que amerite el proyecto, no siempre hay que seguir toda la metodología, sino hay que hacer lo necesario. 4.

Interesados = Manejo de conflicto de intereses

5. Las organizaciones estructurales son riesgos usualmente ajenos al proyecto. El reto del PM es adecuarse a la estructura y manejar los riesgos que existen a consecuencia de ello. Si la definición de la estructura depende de la PMO, recomiendo la organización combinada, por ser flexible y de fácil empoderamiento hacia el PM.


CICLO DE VIDA DEL PROYECTO Y ORGANIZACION